Homebrew without a Mac/Mac emulator. Yes we can.
You should look into Blast Works for Wii. It's pretty much a "make your own shoot-em-up" game.BryWI wrote:I always wanted to make a shoot em up. I just dont have the resources to do so. A really good idea would be to make a shoot em up engine where you can drop in your own art and make a game. open source of course. that would be cool in my opinion. I guess I'd have to start small and make a small demo by looking at the source of the other demos. I have too much going on music wise though to learn that stuff right now. And its nearly 4am and im rambling. I'll stop now
-
- Bringer of game signing
- Posts: 112
- Joined: Thu Jan 18, 2007 5:42 pm
- Location: Houston, TX
- Contact:
You need to convert the source (and header) files from mac format to windows format. Notepad++ can do this pretty easily.Versus wrote:Great! But how can I drag resources from Mac to Windows? For example, I want to compile 3DO_Orbit demo. But I have errors in each file loading. Is it mean HFV Explorer didn't work?
Also you will need to modify the makefile that I supplied with the demo. The make file in the project will work with armmake, but you have to modify the paths, as they are in Mac format, and not windows.
What I think we need, but it might be beyond me.. I'll poke at it in my free time (when I get some
) is..
a port of SDL...
I'm thinking I might start with some simple SDL demos/games and start building an SDL.h as the code uses it... Could take me a while, there are a lot of SDL commands..
Once we get SDL, thigns like SCUMMVM and lots of other SDL ports will be much easier, and there's some really nice SDL code out there..
desiv
![Smile :-)](./images/smilies/icon_smile.gif)
a port of SDL...
I'm thinking I might start with some simple SDL demos/games and start building an SDL.h as the code uses it... Could take me a while, there are a lot of SDL commands..
Once we get SDL, thigns like SCUMMVM and lots of other SDL ports will be much easier, and there's some really nice SDL code out there..
desiv
-
- Bringer of game signing
- Posts: 112
- Joined: Thu Jan 18, 2007 5:42 pm
- Location: Houston, TX
- Contact:
Hmm. Something like SDL for the Nintendo GBA (or DS) might port fairly easily, as the pixel formats are close enough. The big issue is converting to the 3DO buffer format would be expensive. This could be eliminated by not clearing the buffer, and setting up a full screen sized sprite in linear format.desiv wrote:What I think we need, but it might be beyond me.. I'll poke at it in my free time (when I get some) is..
a port of SDL...
I'm thinking I might start with some simple SDL demos/games and start building an SDL.h as the code uses it... Could take me a while, there are a lot of SDL commands..
Once we get SDL, thigns like SCUMMVM and lots of other SDL ports will be much easier, and there's some really nice SDL code out there..
Thank you!cdoty wrote: Also you will need to modify the makefile that I supplied with the demo. The make file in the project will work with armmake, but you have to modify the paths, as they are in Mac format, and not windows.
Also, I want to ask about modifying makefiles... Can I take your makefile and use it in all my 3do projects? If I understand correct, only this paths must be edited:
3DODEV = C:/3DODev/
ARMDEV = C:/ARM250/
-
- Bringer of game signing
- Posts: 112
- Joined: Thu Jan 18, 2007 5:42 pm
- Location: Houston, TX
- Contact:
Yep, as long as you place your .c source files in the Source directory, and assembly (.s) files in the same directory as the makefile. (SRC_C and SRC_S controls where the files are located).Versus wrote:Thank you!cdoty wrote: Also you will need to modify the makefile that I supplied with the demo. The make file in the project will work with armmake, but you have to modify the paths, as they are in Mac format, and not windows.
Also, I want to ask about modifying makefiles... Can I take your makefile and use it in all my 3do projects? If I understand correct, only this paths must be edited:
3DODEV = C:/3DODev/
ARMDEV = C:/ARM250/
-
- Bringer of game signing
- Posts: 112
- Joined: Thu Jan 18, 2007 5:42 pm
- Location: Houston, TX
- Contact:
No, the linker will only include stuff from the libs if it is actually used.Versus wrote:Okay...
Another question: I've found some *.lib files in LIBS = $(LIBPATH)exampleslib.lib $(LIBPATH)Lib3DO.lib $(LIBPATH)audio.lib........
If I'll add here all files located in libs directory, this will decrease the performance resulted Launchme or not?
You can see this happen if you remove audio.lib and music.lib. With those libs removed, LaunchMe is still the same size.
-
- Bringer of game signing
- Posts: 112
- Joined: Thu Jan 18, 2007 5:42 pm
- Location: Houston, TX
- Contact:
The codec 'might' exist for Windows; but using Basilisk would probably be easier. Set up the conversions in a makefile, and have it move the result file to a folder on the PC (it would be something like 'move -y file.stream "Computer:C:tmp"'). This would move the converted stream file to c:\tmp on the PC.Versus wrote:I want to convert my qucktime movie to *.stream format. Is it possible to do this on Windows?
-
- Bringer of game signing
- Posts: 112
- Joined: Thu Jan 18, 2007 5:42 pm
- Location: Houston, TX
- Contact:
Yeah, it could be a different format. Or, it could simply be byte swapped. The endian of a PC and the 3DO are not the same.Versus wrote:Mm... I don't understand clearly, but I'll try this later.![]()
Yesterday I tried to change a WAD file in Doom (REZFILE). But I failed... Possibly it is in another format, not the same WAD file for Doom 2 (PC). Is it any converter or other thing to edit 3DO Doom rezfile?
I would think that they customized the data, for the 3DO, to remove the need to do a conversion at load time.
Well, I spent a couple days trying to get compilation working with the GNU ARM tools for Cygwin (a freely available ARM cross compiler), but had no luck. I resolved the headers file format issue by opening and resaving them in Wordpad, but arm-elf-ld doesn't recognize the 3DO .lib files as a valid file format.
I took a wild guess it was expecting ARM ELF format files, so I used arm-elf-objcopy to reformat them. (This is the format "file" returns when looking at the .o files created by arm-elf-gcc.) That got past the file format errors, but then it always complained that the functions called from the program were undefined. Looking at the reformatted .lib files with nm and hexedit, it doesn't look like it generated a useful ELF format. It just put the ELF headers at the very end of the file, so I'm not surprised the linker couldn't find any useful symbols.
Anyway, I gave up on that angle and tracked down a copy of the ARM Toolkit. Compilation worked there on the first try, but I still have one problem. I'm not getting any sound when I run the Windows-compiled version. Here's what I did:
I built the Bounce demo from the original SDK in a Mac VM and created the CD image with the official laytool. I took that image and decompiled it with Opera FS [De]Compiler. I replaced the LaunchMe with the one I built on Windows (the Windows one was noticeably smaller, but I chalked this up to the SDK version having debug info). I then rebuilt the CD image with Opera FS [De]Compiler and booted it in FreeDO with a hacked BIOS. It launches and runs, but there's no sound. For the heck of it, I also went ahead and signed it, burned it, and ran it on a retail 3DO. Again, it boots and runs, but there is no sound.
Has anyone else built from Windows and gotten sound to work?
I took a wild guess it was expecting ARM ELF format files, so I used arm-elf-objcopy to reformat them. (This is the format "file" returns when looking at the .o files created by arm-elf-gcc.) That got past the file format errors, but then it always complained that the functions called from the program were undefined. Looking at the reformatted .lib files with nm and hexedit, it doesn't look like it generated a useful ELF format. It just put the ELF headers at the very end of the file, so I'm not surprised the linker couldn't find any useful symbols.
Anyway, I gave up on that angle and tracked down a copy of the ARM Toolkit. Compilation worked there on the first try, but I still have one problem. I'm not getting any sound when I run the Windows-compiled version. Here's what I did:
I built the Bounce demo from the original SDK in a Mac VM and created the CD image with the official laytool. I took that image and decompiled it with Opera FS [De]Compiler. I replaced the LaunchMe with the one I built on Windows (the Windows one was noticeably smaller, but I chalked this up to the SDK version having debug info). I then rebuilt the CD image with Opera FS [De]Compiler and booted it in FreeDO with a hacked BIOS. It launches and runs, but there's no sound. For the heck of it, I also went ahead and signed it, burned it, and ran it on a retail 3DO. Again, it boots and runs, but there is no sound.
Has anyone else built from Windows and gotten sound to work?
Welp, just answered my own question. I assumed the code that cdoty posted in his .rar was the same as the code from the SDK I'm using, so I never even looked at it. It's not quite the same -- bounce.c had set ENABLE_SOUND to 0. Changed that, recompiled, rebuilt and signed the ISO, and it worked.Mobius wrote:Has anyone else built from Windows and gotten sound to work?
I think I'm actually ready to start digging into some code to see if I can put together my own little demo.
![Smile :)](./images/smilies/icon_smile.gif)
-
- Bringer of game signing
- Posts: 112
- Joined: Thu Jan 18, 2007 5:42 pm
- Location: Houston, TX
- Contact:
I think I did that because I had problems with the libraries initially. Eventually everything seemed to work.Mobius wrote:Welp, just answered my own question. I assumed the code that cdoty posted in his .rar was the same as the code from the SDK I'm using, so I never even looked at it. It's not quite the same -- bounce.c had set ENABLE_SOUND to 0. Changed that, recompiled, rebuilt and signed the ISO, and it worked.Mobius wrote:Has anyone else built from Windows and gotten sound to work?
I think I'm actually ready to start digging into some code to see if I can put together my own little demo.
Glad to see you're still around -- I have a question for you. I've been working on a basic demo that displays some sprites and am a little confused about the DrawCels and DrawScreenCels functions. You (and the example code) used DrawCels, but I was unable to get anything to display unless I used DrawScreenCels.
According to the documentation, DrawCels positions the cels in relation to the top left of the specified bitmap (in this case, the first screen of the screen context), while DrawScreenCels positions them in relation to the top left of the user's physical screen. I built a point quad to map a cel before calling DrawCels, but nothing appeared. Switching to DrawScreenCels fixed it immediately. What exactly is the difference between the origin of the screen context and the origin of the physical screen? How should I position the cels to get them to appear on the screen when using DisplayCels? Is there any reason to use that sort of positioning when it seems simpler to use screen-relative positioning?
Is it to allow drawing to a buffered screen context? I got the feeling I was drawing to a frame buffer, but that the buffer was never being displayed for some reason, despite calling DisplayScreen right after DrawCels.
According to the documentation, DrawCels positions the cels in relation to the top left of the specified bitmap (in this case, the first screen of the screen context), while DrawScreenCels positions them in relation to the top left of the user's physical screen. I built a point quad to map a cel before calling DrawCels, but nothing appeared. Switching to DrawScreenCels fixed it immediately. What exactly is the difference between the origin of the screen context and the origin of the physical screen? How should I position the cels to get them to appear on the screen when using DisplayCels? Is there any reason to use that sort of positioning when it seems simpler to use screen-relative positioning?
Is it to allow drawing to a buffered screen context? I got the feeling I was drawing to a frame buffer, but that the buffer was never being displayed for some reason, despite calling DisplayScreen right after DrawCels.
I've been doing a lot of homebrew tinkering the last week or so. I started with a little sprite demo just to learn the basics. You know how it was a big deal back in the day with the Super FX2 and the sprite scaling and rotation it could do for the SNES in Mario World 2?
Well, all that is RIDICULOUSLY EASY on the 3DO! I mean, I'm talking stupid, stupid easy to do. This machine is a sprite manipulating beast! You have a picture, you tell the 3DO where to put each of the four corners, and it does it. It doesn't care if it's bigger, smaller, rotated, twisted, folded, or even backwards. It just does it.
But anyway, I moved beyond the demo a few days ago and started making an actual game. Just tonight, I felt like it was far enough along to try it out for real, so I signed the ISO, burnt it, and popped it into my 3DO. What a fun feeling to see MY game on the screen, working perfectly! I can't wait until it's further along and I can share with you guys!
It's a basic game, but I think you'll all approve. I need to polish it with things like sound, better AI, and an original banner screen, but it is pretty far along. I will release that "basic" version, then I plan to add some new features to make a "plus" version that is a little more original.
Anyway, watch this space for more.![Smile :)](./images/smilies/icon_smile.gif)
Well, all that is RIDICULOUSLY EASY on the 3DO! I mean, I'm talking stupid, stupid easy to do. This machine is a sprite manipulating beast! You have a picture, you tell the 3DO where to put each of the four corners, and it does it. It doesn't care if it's bigger, smaller, rotated, twisted, folded, or even backwards. It just does it.
But anyway, I moved beyond the demo a few days ago and started making an actual game. Just tonight, I felt like it was far enough along to try it out for real, so I signed the ISO, burnt it, and popped it into my 3DO. What a fun feeling to see MY game on the screen, working perfectly! I can't wait until it's further along and I can share with you guys!
It's a basic game, but I think you'll all approve. I need to polish it with things like sound, better AI, and an original banner screen, but it is pretty far along. I will release that "basic" version, then I plan to add some new features to make a "plus" version that is a little more original.
Anyway, watch this space for more.
![Smile :)](./images/smilies/icon_smile.gif)
Thumbs up, man! ![Smile :)](./images/smilies/icon_smile.gif)
Am currently working with a graphic artist on some material that is
meant to be a little graphic benchmark for the 3do someday.
When it all will be finished, ambitious coders would be very welcome!![Wink ;)](./images/smilies/icon_wink.gif)
It's supposed to be a simple 3D scene with some simple objects and
the camera "flying around" - a bit like that one, which was quite popular
in Germany around 1997, when the first 3D accelerator cards hit the
market:
http://www.noelnet.org/chataroh/3d/benches/pcpbss.html
![Smile :)](./images/smilies/icon_smile.gif)
Am currently working with a graphic artist on some material that is
meant to be a little graphic benchmark for the 3do someday.
When it all will be finished, ambitious coders would be very welcome!
![Wink ;)](./images/smilies/icon_wink.gif)
It's supposed to be a simple 3D scene with some simple objects and
the camera "flying around" - a bit like that one, which was quite popular
in Germany around 1997, when the first 3D accelerator cards hit the
market:
http://www.noelnet.org/chataroh/3d/benches/pcpbss.html
-
- 3DO ZERO USER
- Posts: 267
- Joined: Thu Nov 27, 2008 3:01 am
- Location: UK
It's great to hear that things are being tried in this area ![Cool 8)](./images/smilies/icon_cool.gif)
![Cool 8)](./images/smilies/icon_cool.gif)
My music... https://soundcloud.com/softkitty123