Optimize OpenGL When Acceleration NOT Available?

Optimize OpenGL When Acceleration NOT Available???

Hi,

Working on my triple cross-platform video game “LettersFall 2”.
( game currently builds and runs on Linux/Windows®/Mac® OS X® )
Game uses SDL 1.2, SDL_image, SDL_mixer, SDL_ttf, and OpenGL.

Game runs great on a computer with hardware accelerated OpenGL.
Problem is that when hardware acceleration is not available
then game runs very slowly with software OpenGL.

Does anyone know how to fix this performance issue?

The average office computer is quite old and may not have
hardware accelerated OpenGL
and I wish for game to run full speed on these computers as well…

Please make some suggestions!
Thanks!

Jesse "JeZ+Lee"
16BitSoft®
Video Game Design Studio
www.16BitSoft.com

You are out of luck. OpenGL requires that even with software rendering, the
full specification is fulfilled, hence the slowness you get.

So either you don’t support environments with software rendering, or you
implement your software render in top of SDL.

Sorry for the brief explanation, typing on the phone is not easy.–
Paulo

Am 2010 10 12 19:57 schrieb “Jesse Palser” :

Optimize OpenGL When Acceleration NOT Available???

Hi,

Working on my triple cross-platform video game “LettersFall 2”.
( game currently builds and runs on Linux/Windows®/Mac® OS X® )
Game uses SDL 1.2, SDL_image, SDL_mixer, SDL_ttf, and OpenGL.

Game runs great on a computer with hardware accelerated OpenGL.
Problem is that when hardware acceleration is not available
then game runs very slowly with software OpenGL.

Does anyone know how to fix this performance issue?

The average office computer is quite old and may not have
hardware accelerated OpenGL
and I wish for game to run full speed on these computers as well…

Please make some suggestions!
Thanks!

Jesse "JeZ+Lee"
16BitSoft®
Video Game Design Studio
www.16BitSoft.com


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

Thanks for the response.

Back in the old days, game developers utilized:
“Dirty Rectangle” optimizations
to improve speed.

Is this technique possible with OpenGL?

Basically I would like to only update small area
of OpenGL screen.

Thanks!

JesseOn 10/12/2010 02:59 PM, Paulo Pinto wrote:

You are out of luck. OpenGL requires that even with software
rendering, the full specification is fulfilled, hence the slowness you
get.

So either you don’t support environments with software rendering, or
you implement your software render in top of SDL.

Sorry for the brief explanation, typing on the phone is not easy.


Paulo

Am 2010 10 12 19:57 schrieb “Jesse Palser” <SLNTHERO at aol.com
<mailto:SLNTHERO at aol.com>>:

Optimize OpenGL When Acceleration NOT Available???

Hi,

Working on my triple cross-platform video game “LettersFall 2”.
( game currently builds and runs on Linux/Windows®/Mac® OS X® )
Game uses SDL 1.2, SDL_image, SDL_mixer, SDL_ttf, and OpenGL.

Game runs great on a computer with hardware accelerated OpenGL.
Problem is that when hardware acceleration is not available
then game runs very slowly with software OpenGL.

Does anyone know how to fix this performance issue?

The average office computer is quite old and may not have
hardware accelerated OpenGL
and I wish for game to run full speed on these computers as well…

Please make some suggestions!
Thanks!

Jesse "JeZ+Lee"
16BitSoft®
Video Game Design Studio
www.16BitSoft.com http://www.16BitSoft.com


SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

glViewport and glScissor are of interest.

With software rendering, the biggest enemy of performance is probably
fill rate. If you can let people lower their fullscreen resolution or
just play the game in a small window, you might have a chance at
tolerable performance. But, in general, software rendering is so slow
that I don’t bother to think about it at all.

As an aside, I’d be curious if shaders could help. I’ve only tried
this with hardware rendering, but a simple shader (for example, a
shader that handles one texture unit and one light source) requires a
lot less computation than OpenGL’s fixed function pipeline. So you
might try a super simple shader and see if it helps. But I wouldn’t
be surprised if your software OpenGL driver just chokes on any shader
at all.–
Terry Welsh
mogumbo ‘at’ gmail.com
www.reallyslick.com

It is, though most people don’t bother anymore. Also, certain effects
make it more difficult to determine the rectangle needed.
Still, on Windows, you can use the update rectangle from WM_PAINT and
the InvalidateRect function to keep track of your update region just
like with GDI, and most other platforms should have something similar.
To work within SDL, you’ll need to keep track of the update region
yourself and update the entire window whenever it receives focus. Use
glScissor to draw only to the update region, or keep track of it
yourself and draw only whatever objects intersect the update region.On 12 October 2010 15:36, Jesse Palser wrote:

Hi,

Thanks for the response.

Back in the old days, game developers utilized:
“Dirty Rectangle” optimizations
to improve speed.

Is this technique possible with OpenGL?

Basically I would like to only update small area
of OpenGL screen.

Thanks!

Jesse

Game runs great on a computer with hardware accelerated OpenGL.
Problem is that when hardware acceleration is not available
then game runs very slowly with software OpenGL.

… do i… do i smell someone running a pentium 2 with an s3 virge video
card ?

if you want to use opengl as your backend, you’ll just have to set opengl’s
requirements as your game requirements. generally, everything since the
i810 (p3 class) should be happy.

if you’re still not getting good performance with a card that can indeed
offer opengl performance - you have a driver problem on the system.

Hi,

“glScissor” was what I was looking for!
Thanks!

JesseOn 10/12/2010 03:45 PM, Ian Mallett wrote:

glViewport and glScissor are of interest.


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

With software rendering, the biggest enemy of performance is probably
fill rate. If you can let people lower their fullscreen resolution or
just play the game in a small window, you might have a chance at
tolerable performance. But, in general, software rendering is so slow
that I don’t bother to think about it at all.

All of this is absolutely true. Fillrate is probably the largest speed
concern for graphics applications (and this includes GPU accelerated ones
too).

Cruddy performance is to be expected for CPU implementations, because they
lack the parallelism necessary for such parallelism.

glScissor and glViewport limit the drawing to certain areas, but don’t think
that this will necessarily make things faster. The only thing these will do
is discard fragments that fall outside of these coordinates. That is to
say, a triangle that takes up 10 pixels on a 200x100 screen renders no
faster than a triangle on a 800x600 screen.

If you want to start talking about speed, you can start writing shaders in
GPU ARB assembly, which is pretty much the fastest human-readable code on
earth. As mentioned elsewhere, simple shaders may run more quickly, so you
might do well to render everything with shaders. Keep in mind that,
although any type of shader increases speed, context changes can get costly,
and they decease portability. So, as you seem to be targeting fairly poor
hardware, shaders may not be a good idea.

In short, you’re stuck. All I can recommend really is to target better
hardware or reduce your draw code’s complexity enormously.

IanOn Tue, Oct 12, 2010 at 1:59 PM, Terry Welsh wrote:

We had a similar problem, making our application running at acceptable
speeds on systems without HW acceleration. It’s possible, but it feels
a lot like programming for the C64. glScissor, culling, and LOD
textures (or a different set of textures) are the basic tools. What
also helps:

Don’t pass objects that you know for sure are out of sight to the
render loop, a sort every second over pre-calculated bounding boxes is
much faster than letting OpenGL’s culling check 60 times a second.

Change the alpha blending settings. Choose a blend func that only uses
absolutes (values that don’t depend on the current state), you get
gif-like transparency, but it’s nearly as fast as disabling alpha
blending.

All in all, the golden rule is: everything that doesn’t need to be
done by OpenGL or in it’s loop AND doesn’t need to be run at max speed
should be done outside. Pre-calculate as much as you can, use
old-school optimizations sine or cosine tables and stuff like that.

I guess that’s all I can say :wink:

bw,
MartinOn 12/10/2010, Jesse Palser wrote:

“glScissor” was what I was looking for!

Hi,

I do have a state-of-the-art computer.
( Ubuntu 10.10, 3GHz 4 core, 8GB RAM, 1GB VRAM, etc )

I received an email some time ago
from a user who said my game was too slow.

Their computer was very old, but I said I would find a solution.
Working on this now and testing in an XP virtual machine
with hardware acceleration disabled.

With all of your suggestions
I should be able now to solve this issue.
Many thanks!

PS - I’ll post the sources when I am finished…

JesseOn 10/12/2010 04:36 PM, Martin Voigt wrote:

On 12/10/2010, Jesse Palser wrote:

“glScissor” was what I was looking for!
We had a similar problem, making our application running at acceptable
speeds on systems without HW acceleration. It’s possible, but it feels
a lot like programming for the C64. glScissor, culling, and LOD
textures (or a different set of textures) are the basic tools. What
also helps:

Don’t pass objects that you know for sure are out of sight to the
render loop, a sort every second over pre-calculated bounding boxes is
much faster than letting OpenGL’s culling check 60 times a second.

Change the alpha blending settings. Choose a blend func that only uses
absolutes (values that don’t depend on the current state), you get
gif-like transparency, but it’s nearly as fast as disabling alpha
blending.

All in all, the golden rule is: everything that doesn’t need to be
done by OpenGL or in it’s loop AND doesn’t need to be run at max speed
should be done outside. Pre-calculate as much as you can, use
old-school optimizations sine or cosine tables and stuff like that.

I guess that’s all I can say :wink:

bw,
Martin


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org