SDL and OpenGL, should it be so slow?

Started by
28 comments, last by DuncanBojangles 20 years, 5 months ago
I don''t think I''m ready to switch yet, ''cause I''ve used GLUT for a while now. I tried using SDL''s input and GLUT together, but I found out that the only way to have them both is if you open an SDL window. I found that this is because SDL''s keyboard event handling is included with their Video stuff. So, you have to initialize video and then setvideomode which brings up a window. Is there any way I can throw some NULLs in there and set up the keyboard but not open an SDL window? ''Cause SDL runs OpenGL very slowly on my machine.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.
"Donkey, if it were me, you'd be dead."I cna ytpe 300 wrods pre mniute.
Advertisement
''Cause SDL runs OpenGL very slowly on my machine.

That''s funny because my sdl+opengl programs have always run well over 300 FPS, not slow at all. Are you enabling Vsync? Did you set up the window properly? It sounds like you just passed in SDL_OPENGL to setvideomode and when that didn''t work, you started looking elsewhere. Things are not always simple in programming or work as you expect the first time.

Did you look at the glSDL library? I hear that speeds up SDL''s opengl more than plain SDL does.
I set up my window exactly like the SDL documentation does, so I''m not sure why it would run so slowly. One reason, extremely slow graphics card. But that can''t be the only factor, because my programs are slow to respond to event handling. Using GLUT and the dummy SDL window, my programs handled input flawlessly. It''s not just a frames per second problem, it''s total program. I just want to use the combination that works for me, and that happens to be GLUT and SDL event handling.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.
"Donkey, if it were me, you'd be dead."I cna ytpe 300 wrods pre mniute.
Sure but just because you can''t figure out the right way to make SDL and opengl work (which isn''t even the real problem it seems since you keep talking about your input) doesn''t mean you should tell people it doesn''t work at all, becuase that isn''t true.

" One reason, extremely slow graphics card."
That''s a big factor. If you want to use new 3D graphics you''ll need a decent 3D card. You can get one for $50 nowadays so there is really no excuse anymore for people not to have some kind of card (especially programmers)

" my programs are slow to respond to event handling."
There different ways to handle input when using SDL you know.
Were you using input code from the docs? Because that''s a bad way to do it and was choppy when I tried it. My compiler won''t even accept that code anymore.

Try reading keypresses each frame with
Uint8 *keys = SDL_GetKeyPresses() and then use if tests to test if a certain key was pressed. That''s what I did and it works much much smoother.

"I just want to use the combination that works for me"
Sure but you are making it harder and more inefficiant than you need to by using 2 different API''s that do essentially the exact same things (SDL being much better of course)
Are you saying you need multi-windows? One for opengl one for SDL? Because you really are ok using just an SDL window. Multi windows support may come in SDL 2.0
I understood that the documentation handled events slowly, so I did end up using SDL_GetKeyPresses() and it works just like my old Windows functions did. I don''t need two windows, I need GLUT for OpenGL because when I use SDL, the exact same program runs slowly. But to get SDL''s event handling(which isn''t slow when I don''t use SDL to do OpenGL commands), I need to initialize and open an SDL window because Keyboard handling is jumbled with video in SDL. I know what I''m doing, I''ve been programming for a couple years now, but the switch to Linux has thrown some wrenches into the gears. So, let''s review:
1. SDL runs OpenGL very slowly.
2. When SDL runs OpenGL, events are processed very slowly.
3. GLUT runs my programs fine.
4. When GLUT does OpenGL, SDL handles events extremely well, and on time.
5. But to get GLUT with SDL''s keyboard handling, I''m forced to open an SDL window.
6. I don''t need two windows.

I''m really annoyed with this, and I just want to be crystal clear on what is happening on my computer. If anyone can help me, that would be great. One last thing, is there High Resolution timer support in Linux? And does anyone know of a command similar to GetAsyncKeyState() on linux? Sorry to sound like a jackass, and thanks for all your help.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.
"Donkey, if it were me, you'd be dead."I cna ytpe 300 wrods pre mniute.
Coding for years and still using GLUT?
well mr.experience have you tried reading the SDL MAILING LIST ? Tried google.com for "glSDL" ?

Have any proof to back up these "facts" ?
I''d love an example the same program written both ways, it sounds like the brown stuff that comes from a bulls ass to me.

Like I said I''ve used SDL and OpenGL for a long time now and my programs have always been fast and responsive with SDL.

Not sure about the timer, I''d like to know this as well. If all else fails you can use SDL''s timer functions..
Programming for a few years, and yes, still using GLUT. When I make something I deem worthy of letting other people play, I''ll rewrite everything. But until then, I don''t like wasting time worrying about setting up windows and that junk. I only use GLUT to get the rendering context, everything else about it sucks. That''s where SDL comes in handy, on my computer only OpenGL with SDL sucks. They''re an almost perfect combo. There''s an SDL mailing list? I only ask fow help when I really need it, so I''ve never really thought about it. None of my programs ever made it to full game status, I just get sidetracked too easily. I''ve made the basics of a bunch of games, like First Person Shooters (which are really easy when you use .md2 models), car racing sims (not quite as "sim" as I want them to be), and then I spent a long time working on two games: a pogo stick game and a wakeboarding game. Both were closer than all my others to a "real" game, but then I got sidetracked. Then, I made the switch to Linux, so I took a break and got the hang of that for a while. So, yes, I have been coding for a few years. I''m not a dummy, or a noob. So stop treating me like one! Anyway, for the real help that''s been given, thank you. For those that have been treating me like a noob, shove off!

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.
"Donkey, if it were me, you'd be dead."I cna ytpe 300 wrods pre mniute.
Yes go to the sdl mailing list from www.libsdl.org and ask them why it''s so slow to use opengl in SDL and see what they tell you to do..
just tell them what you told us, that OpenGL with SDL sucks, GLUT is better than SDL, and see what they say about all that.
Oh, forgot to say. If you want to see example programs of both ways I made the programs, I used the bare minimums to set each up, watered down versions of the SDL documentation and the bare minimums of a GLUT application like those from "The Red Book". In SDL, I use SDLGetKeyState(NULL), found that out after reading the Cone3D website. SO both programs are the same, but the SDL one is frozen for a while, then all at once it reads the event buffer, and returns to the frozen state. I just want to know if I can combine SDL''s event handling and GLUT under one beautiful window.
P.S. Making your own model format and model creator is difficult. I''ll never do it again.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.
"Donkey, if it were me, you'd be dead."I cna ytpe 300 wrods pre mniute.
Okay, I''m going to the mailing list right now. Thank you for pointing me to the fact that SDL has a mailing list. Now I''ll go away and I''ll stop being a horse''s behind.

"Donkey, if it were me, you''d be dead."
I cna ytpe 300 wrods pre mniute.
"Donkey, if it were me, you'd be dead."I cna ytpe 300 wrods pre mniute.

This topic is closed to new replies.

Advertisement