#155386 - strat - Tue Apr 29, 2008 12:31 am
I think there's a topic where this is discussed and it's mentioned that Nintendo's own NES-to-GBA emulator probably has code in VRAM.
Watching the recreation of the hangar from Metal Gear Solid made me wonder about using (as a last resort) a combination of self-modifying code and execution from VRAM as a fast way to render. If the GBA can handle a scene like that, it could probably run a whole 1st gen PSX game like Jumping Flash.
It also might be possible to fake a frame buffer in tile mode since most of the textures only have a few colors (some polygons appear to be flood-filled), freeing up lots of VRAM.
Basically I'm new to 3D coding and want to create a good software engine for the GBA before moving to 3D hardware. These ideas sound just twisted enough to work... is there anything to shoot them down?
#155403 - sajiimori - Tue Apr 29, 2008 5:45 am
If you're new to 3D coding, you should first make something that works, long before you think about something that works fast. Even experienced coders don't go straight from 'nothing' to 'fast' -- it's a sure way to end up with broken, incomplete, and Just Plain Bad code.
But writing a software renderer sounds like a great idea, and the GBA is a fine platform for it. I'd suggest developing it for your PC first, then porting it to the GBA. That will give you more freedom to experiment, without worrying about CPU and memory limitations at first. You'll also have access to much nicer tools that way, especially source-level debuggers.
#155421 - silent_code - Tue Apr 29, 2008 1:49 pm
sajiimori obviously knows what he's (i assume?) talking about. ;^)
i can only recommend that approach!
also, note that code execution from vram has already been talked of on the forum, so you might want to search a bit. you will surely find some valuable information.
good luck with your project and happy coding! :^)
ps: i'm a bit fan of software rendering (although i haven't done it for a long time myself), so feel free to share your project by posting some progress info at some point! :^D
#155442 - sgeos - Tue Apr 29, 2008 5:33 pm
| sajiimori wrote: |
| If you're new to 3D coding, you should first make something that works, long before you think about something that works fast. |
This applies to all coding, actually. The fastest renderer that never got done is useless. All you need is something that is "good enough" for what you are doing. Sometimes the trial effort will be good enough, and other times something fast is needed.
You may have architectural reasons or other reasons to drop code in VRAM.
-Brendan
#155464 - strat - Tue Apr 29, 2008 9:32 pm
| sajiimori wrote: |
| If you're new to 3D coding, you should first make something that works, long before you think about something that works fast. |
Oh yeah. I just like to know what's in the toolbox. My first plan is to code in C, profile, redo algorithms, and then resort to asm and other esoteric ideas.
I've found the GBA easier to program on than the PC, because its brand of memory-mapped IO is more intuitive than sifting through all the APIs (But I plan on looking at Allegro).
#155479 - kusma - Tue Apr 29, 2008 11:59 pm
| strat wrote: |
| Oh yeah. I just like to know what's in the toolbox. My first plan is to code in C, profile, redo algorithms, and then resort to asm and other esoteric ideas. |
Sounds like a good plan. I'd love to hear the performance-reports you'll (hopefully) have.
#155486 - sajiimori - Wed Apr 30, 2008 1:07 am
SDL is quite simple for PC development as well, especially if you render using a 32-bit software surface. Slow, but super easy for starters -- you can plot pixels by simply indexing into the framebuffer as a u32 array, and there's not even a palette to deal with.