Great job Madskillz, those sprites are very well done.

Shh... I didn't just make that mistake...

You know, it's kind of funny that the original game ran on 3.58 MHZ Z80, although I would assume that the game gear had some sort of gpu to supplement the cpu.

you're confusing me even mroe, could you stop being so criptical and confusing in your posts? Else I am gonna delete all of those, thanks

QuoteBegin-art_of_camelot+15 Oct, 2007, 18:17-->

QUOTE (art_of_camelot @ 15 Oct, 2007, 18:17)

You know, it's kind of funny that the original game ran on 3.58 MHZ Z80, although I would assume that the game gear had some sort of gpu to supplement the cpu.

like an Nvidia 8800 Ultra is a Graphics Processing Unit.  or an ATI Radeon HD 2900XT ^^  wish I had something in this range on my comp.

in this context, we're kinda generalizing the use of the acronym GPU to include non-graphics card graphics hardware.  In many ways, the game gear operates like the NDS/GBA/GBC/GB.  A separate piece of hardware reads certain areas of dedicated RAM and displays graphics accordingly, without the CPU needing to do anything.

basically.  the problem with our calc is that we have to send data to the screen 1 byte at a time for 768 bytes.  And iirc, we need to spend about 70 cycles on each byte.  Doing the math, that's a lot of wasted time waiting to send one byte to the screen 768 times.

This isn't too bad on 86 or 89 because their screens automatically read a special part of RAM and the screen reflects the data there.  So those calcs don't waste all that time waiting for the screen to update correctly.  You can simply spend 4 cycles rewriting one byte to change one pixel.  On 83+/84+, you have to spend at least 70 cycles to change one pixel because the info has to be sent to the calc.

Keep in mind too that handhelds have built in color/gs, so the sprite data is all you need to set a color.  no messed up 2 layer thing for 4 level gs.  and no switching layers every other frame to create gs.  the screen has it already

because the hardware prior to DS was designed for sprites only.  Built in 3D rendering hardware wasn't introduced until DS, which iirc supports either OpenGL or DirectX (or maybe neither and I'm just confused).

To make a raycaster w/ the stripped processor would have been hard because you would have to render every pixel at 30 fps, which is not a lot of time.  By the time you finish redoing every pixel, a second might have already gone by.  Not to mention that the hardware updates at a rate of 60 fps, which means you have horrible artifacts.

I know someone on GBAdev.org was working on a GBA raycaster, which looked feasible.

with the DS, you program as if it were 3D on a comp, so it really doesn't matter as much anymore.  Although you can only have one screen be 3D, not both, since the hardware was designed to only 3Dize one screen at a time.  Although I think it'd be cool to get 3D on the other screen using the processor.  Maybe you could get the ARM7 to work in parallel and update the second screen.  I'm not sure, but that might be cool.  Although one 3D screen works out pretty fine