EasyCE 2.0

[MirekCz]

[simonjacobs]

[Digby]

[simonjacobs]

[Phantom]

[danyblue]

[Phantom]

[Karl]

[Phantom]

[Karl]

Thanks for the explaination Jacco.<br><br>Couldn't the asm function handle the rotation as well, using lookup tables or whatever?  the 3800.asm object file would rotate and then blit, the mips.asm would just blit, etc, etc.<br><br>That way all drawing would be onto the EasyCE buffer[240x320] in C which then would blit using the asm function in the update().<br><br>IMHO the sprites in 1.6 are more than sufficient.  I love the simplicity of your library.<br><br>Cheers<br>Karl<br><br><br><br><br>

[Phantom]

Karl,<br><br>I agree that the sprite system of 1.6 is sufficient for most applications, but in some cases, you redraw the backdrop just because you're moving sprites and you're too lazy to implement dirty rectangles. <br><br>So I figured, since all ARM devices require rotation and thus the intermediate buffer, I might just as well make good use of it and draw sprites on the intermediate buffer.  You could simply split the asm code in two parts (rotating & blitting) and execute the sprite code in between. Would be quite cool and fast. Only drawback is the boring sprite code in three versions.<br><br>- Jacco.<br><br>P.S. Register! You know you like it here. <br>Last modification: Phantom - 01/11/02 at 09:21:51

[Digby]

[Phantom]

[MirekCz]

[billcow]

Unfortunately, the ARM cpu, unlike the x86, only allows access to the entire 32-bits at once. I know this is also true on the SH3, but I haven't done any assembly programming on the MIPS, so it might be possible on that, but it's a moot point because all the MIPS PPCs have regular (240x320) framebuffers, and don't require rotating.