Hi,
I am trying to put glSDL into my game. It seems to almost work. I
use SDL_GLSDL as my only flag when I want OpenGL on startup (a
command line argument activates this). I get a window that shows
me what I want to see with flicker.
You must use SDL_DOUBLEBUF to get double buffering - even on Linux,
in some cases. (Yes, some Linux OpenGL drivers really do complex
clipping and rendering directly into the window if you tell them to.
I think most drivers do this on other platforms.) You should use
double buffering anyway, since the “fake” double buffering you (may)
get otherwise may not provide retrace sync’ed flips.
So, with OpenGL or glSDL, without SDL_DOUBLEBUF, you’re likely to get
either tearing or horrible flickering. Use SDL_DOUBLEBUF at all
times, unless you really know what you’re doing.
The frames per second is
really bad too.
Are you sure you get the right OpenGL lib? Do you have accelerated
OpenGL at all?
Or translated; Are SDL applications using OpenGL natively accelerated?
Do any OpenGL applications get acceleration?
I read somewhere about not blitting directly to
the screen but I am unsure of how to do this exactly.
That’s about doing s/w rendering into the screen. That’s not what
happens when you (gl)SDL_BlitSurface to the screen - which is, in
fact the only way to have glSDL accelerate your blits at all. (Blits
between off-screen surfaces cannot be accelerated by OpenGL, at least
not without uncommon extensions.)
Here is how
I blit:
void DrawIMG(SDL_Surface *img, int x, int y)
{
SDL_Surface *screen=SDL_GetVideoSurface();
SDL_Rect dest;
dest.x = x;
dest.y = y;
SDL_BlitSurface(img, NULL, screen, &dest);
}
SDL_Surface *bg = LoadIMG(“gfx/startupbg.png”);
int done=0;
while (!done)
{
SDL_FillRect(screen,0,0);
DrawIMG(bg,0,0);
SDL_Flip(screen);
}
That’s fine (with the glSDL wrapper, mostly because it’s not 100% SDL
2D API compliant), but you really should SDL_DisplayFormat() the
image after loading it.
The glSDL wrapper will cheat and gett full acceleration either way
(but it’ll fail if you start modifying the image as a procedural
texture), but the backend version will have to convert and upload the
the surface for every single blit ==> dog slow rendering, especially
if your OpenGL subsystem doesn’t use DMA for texture uploading.
I also draw lines,
How? (I’m afraid I have bad news…)
boxes,
I’d strongly recommend using SDL_FillRect() for filled boxes, vertical
and horizontal lines and hollow boxes… (It translates to rathe
efficient OpenGL rendering operations, so short of avoiding some
function call overhead, you can’t do it much faster than that even
with native OpenGL code.)
and SDL_TTF fonts.
Problem: These will have to be handled as procedural surfaces. That
is, render the text into a surface, SDL_DisplayFormat() that, and
blit it to the screen. Don’t update the text surfaces more often than
you have to, because the uploading can be very expensive on some
systems, even if the rest of the OpenGL subsystem is very fast.
If you want scrolling text and the like, rather implement it like
emulated hardware scrolling; render text every now and then
(preferably into a bunch of small surfaces, to avoid occasional
stalls as a large texture is uploaded), and then scroll the resulting
surfaces around. You can use clipping to keep the text inside a box
and stuff like that.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Wednesday 03 March 2004 10.16, TomT64 wrote:
