Does Sdl Gfx Allow For Easier Open Gl Ports?
- Thread starter stustaff
- Start date
sebt3
homebrew player (P. & C.)
That's what I was trying to do.stustaff said:
I was configuring with :
Code:
./configure --host=$TARGET_SYS --with-gnu-ld --prefix=$PND_BASEDIR/$PRJ --with-renderer-sdlGfx=1 --with-renderer-openGl=0 --with-internal-xdg=1 --without-asian-ttf-file
Last edited by a moderator:
ledow
Member
SDL_gfx is a completely unaccelerated library (unless you count using MMX, which isn't relevant to the Pandora).
That page discusses replacing OpenGL (which requires OpenGL compatible hardware) with a software rendering using SDL_gfx - literally drawing every polygon, line, square, etc. one at a time using the CPU. Their rationale is that it will then work on machines that have no OpenGL capabilities at all.
SDL_gfx is just a 2D primitives library. I used it to make STPPC2x on the GP2x (Wiz / Dingoo / etc. etc.) because the GP2X doesn't really have any hardware that can accelerate 2D graphics at all and because I didn't want to have to write routines to draw lines, boxes, circles and polygons. It has about 30 functions that do things like draw squares by, well, drawing a box full of pixels - the code is literally a for-loop that does exactly what I would have done without it. Textured polygons etc. are one of its slowest functions but it can still do them, in plain C, even on machine that have no graphics acceleration at all - and that's what xmoto contributed to it because their entire game is basically textured polygons that never move or change.
It's *not* a replacement for OpenGL unless you're only ever using 2D polygons on a 2D surface, drawing each individually and don't care about the speed - most people and games *don't* do that and use sprites more than hand-picked polygons. That said, SDL_gfx is pretty damn fast for what it is and all the games in STPPC2x are not optimised for graphical display at all (other people wrote them for other machines and I hardly touched them) and yet SDL_gfx on a 200MHz machine just throws polygons, squares and circles around like there's no tomorrow even on unaccelerated 200MHz hardware. But look at STPPC2x - it's basically just a collection of lines and boxes with the occasional circle that at most moves at about 10fps to rotate a square (and even that never matters because the graphics aren't *supposed* to be pretty). Nothing you couldn't write better by using sprites in a second, it's just that I wanted to change the existing code as little as possible and the existing code used GTK's / Windows GDI's existing primitive (shape) routines.
And read the SDL_gfx source code - it basically just sets pixels individually or uses the SDL functions already available to do the same thing. It's more a convenience library for a programmer that can't be bothered to write a "draw filled circle" routine than anything else. I don't see how anyone who's already writing a game targeting an OpenGL device would find it useful, and there are dozens of similar libraries for every backend imaginable (SDL, Allegro, etc.). However, if you've already started a 2D game on SDL and need to draw a textured polygon, it's an incredibly handy piece of code. But it's performance and capabilities and nowhere near what are capable with even the most bog-standard OpenGL (or any other type of acceleration) calls. In fact, I ditched it in all my other games because a tiny routine of your own is often much faster and it does have problems with speed (e.g. it's rotate bitmap functions are incredibly slow compared to *anything* hardware-accelerated).
That page discusses replacing OpenGL (which requires OpenGL compatible hardware) with a software rendering using SDL_gfx - literally drawing every polygon, line, square, etc. one at a time using the CPU. Their rationale is that it will then work on machines that have no OpenGL capabilities at all.
SDL_gfx is just a 2D primitives library. I used it to make STPPC2x on the GP2x (Wiz / Dingoo / etc. etc.) because the GP2X doesn't really have any hardware that can accelerate 2D graphics at all and because I didn't want to have to write routines to draw lines, boxes, circles and polygons. It has about 30 functions that do things like draw squares by, well, drawing a box full of pixels - the code is literally a for-loop that does exactly what I would have done without it. Textured polygons etc. are one of its slowest functions but it can still do them, in plain C, even on machine that have no graphics acceleration at all - and that's what xmoto contributed to it because their entire game is basically textured polygons that never move or change.
It's *not* a replacement for OpenGL unless you're only ever using 2D polygons on a 2D surface, drawing each individually and don't care about the speed - most people and games *don't* do that and use sprites more than hand-picked polygons. That said, SDL_gfx is pretty damn fast for what it is and all the games in STPPC2x are not optimised for graphical display at all (other people wrote them for other machines and I hardly touched them) and yet SDL_gfx on a 200MHz machine just throws polygons, squares and circles around like there's no tomorrow even on unaccelerated 200MHz hardware. But look at STPPC2x - it's basically just a collection of lines and boxes with the occasional circle that at most moves at about 10fps to rotate a square (and even that never matters because the graphics aren't *supposed* to be pretty). Nothing you couldn't write better by using sprites in a second, it's just that I wanted to change the existing code as little as possible and the existing code used GTK's / Windows GDI's existing primitive (shape) routines.
And read the SDL_gfx source code - it basically just sets pixels individually or uses the SDL functions already available to do the same thing. It's more a convenience library for a programmer that can't be bothered to write a "draw filled circle" routine than anything else. I don't see how anyone who's already writing a game targeting an OpenGL device would find it useful, and there are dozens of similar libraries for every backend imaginable (SDL, Allegro, etc.). However, if you've already started a 2D game on SDL and need to draw a textured polygon, it's an incredibly handy piece of code. But it's performance and capabilities and nowhere near what are capable with even the most bog-standard OpenGL (or any other type of acceleration) calls. In fact, I ditched it in all my other games because a tiny routine of your own is often much faster and it does have problems with speed (e.g. it's rotate bitmap functions are incredibly slow compared to *anything* hardware-accelerated).
sebt3
homebrew player (P. & C.)
It work for the PSP... It work on the N900... So It should work on the pandora too.ledow said:
All he want is xmoto running on pandora
Last edited by a moderator:
sebt3 said:It work for the PSP... It work on the N900... So It should work on the pandora too.ledow said:
All he want is xmoto running on pandora
There are actually quite a few good 2d 3d games if you know what I mean
but yes started looking because of xmoto it's a great game and it's so close eh running on nokia that it's frustrating! As you yourself know
Last edited by a moderator:
Similar threads
