Low Level Graphics

[Orange Pumpkin]

I there a possiblity of making low level graphic programs on this consoles (gp32/gp2x/gp2x wiz). I mean something like this skynet/ie/~darkstar/assembler/tut6.html, exept this is about windows. I know there is SDL but I would like to start from the very lowest level (I know it is not easy but any way). BayTheWay is there a assembler compiler in the SDK ??



Thanks in Advance Orange Pumpkin


Any news about the f-300 or the last one was that they cancelled the project ??

 

[Exophase]

You can use GCC as a front end to assemble things. The GNU assembler is included as part of binutils.

Very few people use much of the hardware acceleration on GP2X. You can't access it directly anyway, you have to mmap a window to the hardware registers off of /dev/mem to get this sort of access. Doing it in assembler is technically possible but would be a lot of work for very little purpose. There's really no reason to use ASM to setup the graphics, and once you do you'll probably just be working with a plain framebuffer. From there it's more of a matter of just knowing ARM ASM than knowing anything particular to graphical programming.

 

[paeryn]

As Exophase said, low level is of limited use. Acceleration wise all you have is a blitter (which takes a fair bit of setting up - small blits can actually take longer to set up than what you gain by using the blitter's acceleration) and a display scaler (doesn't actually alter the framebuffer, just how the screen displays it - takes no time to zoom, but you don't have access to sub-pixels, plus no filtering).

Also the framebuffer is in non-cached memory. You can alter the cache settings to allow the CPU to cache it, but you'll need to explicitly flush the cache as the display hardware cannot see the CPU's cache.

Only do it if you really need the speed gain from assembler. Make sure that the drawing routines are causing any slowdown before coding them in assembler.

SDL wil give you direct access to the framebuffer if you want it, that way SDL handles all the set-up for you - as long as you use my version of SDL (also in Open2X, it uses the blitter for blitting / filling, and easy [display]zooming), GPH's is a full software version - the framebuffer is in cached memory (fast user access) but copied to non-cached memory on SDL_Flip (required for display hardware - and take ages, plus NO hardware acceleration / scaling).

Note:
My version of SDL isn't 100% compatable, in most cases it is but a few things don't work as expected (like the cursor pointer needing to be switched off AFTER setting the screen up whereas in normal SDL you can switch it off before), there may be other issues in paletted modes (8-bit and less) as they haven't had as much (read near-zero) testing and I haven't touched the code for a long time, but if you use it let me know if you hit any problems.