OpenGL software mode

I guess you''re using the MS software implementation.. it is slow. :o) either go hardware or write your own :o) (no, not opengl, custom software renderer)

cya,
Phil


Visit Rarebyte!
and no!, there are NO kangaroos in Austria (I got this questions a few times over in the states )

What is your rendering loop? Are you recreating the vertex buffers every frame?

OpenGL software emulation (i.e. you don''t have a 3-D card) will be slower than a hand-tuned assembler software renderer. But, if you have a real 2-D game, and don''t want hardware acceleration, then a hand-tuned assembler (or well-written C) version will be needed to get good frame rates.

How might you directly access the vram in windows, other than mode 13h?

I used to fiddle around with tile engines in mode 13h on a 286, so I know the assembly behind them, but I don''t know how to get to the vram and sync with the refresh in windows. Any hints?

You might look into other software implimentatoins of OpenGL on Microsoft. SGI had one that showed improvement over Microsoft''s. I''m sure you could find it on www.opengl.org. If I remember correctly, it installs opengl.dll. I think SGI''s implimentation showed a big boost vs Microsoft''s implimentation, but still no where near as good as hardware.

R.

Hello there,


try,

Turning of texture filtering.
Only enabling blending when absolutly required.
Enable glAlphaTest for rendering sprites rather than blending.
Sort tiles by texture to avoid texture state changes.
If your not using the depth buffer dont clear it.
If your tiles always cover the whole screen never clear the
color buffer.

Hope it helps

Mark

Edited by - MButchers on December 6, 2001 6:20:28 AM

Heh - a list of most of the undocumented speed thingies for OpenGL

I already knew them, but thanks
It took me a long time to find them out. Nice to see some others actually willing to share that info!

In my 3-d stuff I eliminate redundant state changes by sorting primitive elements (single collections of polygons) by render pass, texture-mapping state, texture size, and then by other states.

That's too much for a 2-d engine, so I just do the opaque background with no alpha, sort the alphas back to front, do the alpha masked ones first (just GL_ALPHA_TEST), then do the blended alphas.

The problem, though, is drawing just the background of a non-isometric engine gives me less than 10 fps w/o a hardware card. I was curious if I was doing anything wrong, but now I'm guessing it's OpenGL.

What I guess I'll do is write the software renderer, too, and select the fastest method on the fly, between OpenGL textured quads, OpenGL bitmaps, and the software renderer, so I can still get hardware acceleration, should it be present. This is what I'm assuming QII does when you choose software mode - it's not a software implementation of OpenGL, but a full-blown 3-d software engine.

Rendering tiles manually isn't really hard, especially if I'm abstracting the actual rendering call. Even with alpha testing/blending they're easy in ASM, slightly more complex with MMX, but my problem is accessing the VRAM (framebuffer?) to actually write the tiles into, and how to sync with the video retrace.

The video buffer was easy in DOS - you just set your mode, set your palette and wrote to address 0xA000000. All of the setting was done via software interrupts. Syncing with the vertical retrace was done with interrupts as well.

You can't do interrupts and still use windows, though.

How do you access what ever you need to access to render to the window? Create a fullscreen window and use GDI to draw a fullscreen bitmap? SetDIBits would do the trick, because they accept a single pointer for the image data, which should be as simple as a memcpy, but still, that's relying on windows do do the actual drawing for you.

I can't see calling SetDIBits being faster than the MS implementation of OpenGL, and that still doesn't solve the issue of timing with the vertical retrace.

I still have to test it, though, so I can't say it's not faster. I'll work on that now. Does anyone know about how tap into the retrace though?

Thank you all for your time,
-- Succinct



Edited by - Succinct on December 6, 2001 6:34:35 PM

The best way to code a software engine would be to use DirectDraw7. I''d give up on using an API designed for hardware acceleration if you don''t have the hardware to begin with! You may need to avoid certain effects which are done best in hardware (like alpha blending) or write ASM routines to do them (they''ll still be slower this way) but, in general, you should be able to get good speed this way. It is also the only way I can think of to get good speed.

btw quake2 did not use opengl for software rendering. quake2s hand optimized assmebly software renderer used directdraw (pretty sure). quake2 software rendering ran in 8bit pallete mode. and last but not least QUAKE2 DID NOT USE A TILE ENGINE.

AP -
I'm not sure how you would use a vertex array for tiles. The texture changes each tile. The only way to use arrays is to use one big texture and change the coords, but texture sizes are limited by glGetIntegerv( GL_MAX_TEXTURE_SIZE ), which normally isn't big enough to hold all of my tiles.

Yes, though, I am using display lists, as you only need to bind the texture just before rendering.

TerranFury -
Well, I'm more of a 3-d guy, and I'm very fond of OpenGL. I've no intentions as of right now to use DX for graphics . I may have to, in order to access the frame buffer for a software renderer, but I would like to avoid it if possible. Heh - mainly because the box I'm developing on crashes if I have COM up and I force a program reset through my IDE.

lol @ a person -
[sarcasm]
QII didn't use a tile engine?

Oh My Gosh!

heh - aren't I quite the surprised one.
[/sarcasm]

Anyway - the question comes to this, folks - I'm already planning on making a software rendering option. I've already written most of the the tile drawing code in assembly. I'm also not really planning on changing API's unless it is absolutly necessary. Is there any way to access the framebuffer and tap into the vertical retrace w/o using DX?

-- Succinct


Edited by - Succinct on December 6, 2001 11:14:45 PM

Succinct

for the software renderer you can use
CreateDIBSection to create a device independant
bitmap and access the data bits directly,then just
use bitblt to flip to the front buffer,
I have an old bit of code at home if you would
like me to email it to you , its in c++ builder 4,5.

Mark

hehe - Though I use MSVC for my actual "production" game code, I throw all of my tools together using BCB 4, so I'm familiar with it.

I'm pretty sure I could figure out how to do it (I've used CreateDIBSection before), but if you'd like to send that code my way anyway, my e-mail is succinct_online@hotmail.com

Thank you for your help (everyone)!

-- Succinct

P.S. After pouring over the MSDN, I still can't see anyway to sync the frames with the refresh.

Any ideas for that one?

Edited by - Succinct on December 7, 2001 7:18:32 PM

Isn''t it interesting how OpenGL performance, under windows and no hardware acceleration sucks?

I''ve done some 2D projects for the university, using OpenGL for rendering. I''d get good performance only on HW acc machines. In software mode...

However, before anyone blame OpenGL, let me tell you that this is not the case. There is hardware support for DirectX even since those old Trident 9680(DX 3, I think - DirectDraw). How Microsoft done the OpenGL''s software implementation is beyond me, but I guess it''s not the most optimized thing in the world.

Its performance under Linux(using MESA) is much better, but still not enough, specially if one enables lighting and alpha-blending. What amazes me is what I saw in BeOS, with no hardware acceleration... that lovely teapot with lighting running very fast! But they say its an OS designed with multimedia in mind...

Gaiomard Dragon
-===(UDIC)===-