[SDL] When will there be blitting support when using OpenGL

vining at pacificcoast.net vining at pacificcoast.net
Wed Apr 5 11:58:13 PDT 2000


>Tut, tut If I were making an isometric game like Diablo right now, I'd

Interestingly enough, Diablo II doesn't. It uses Glide, which has the "advantage" of being an API which puts you a lot closer to the guys of a 
system and means that you don't have to deal with some of the crap which I've mentioned here. (This is not to say that I support the use of 
Glide; I don't)

>use OpenGL. Just for the raw fillrate, if not for the "free" special
>effects such as alpha blending, etc. In the worst case you have to

You can do this w/o going through OpenGL, plus you have more control. Just look at the MMX based niceties that make up Nox. (Off course 
this does mean kicking the processor into MMX mode and out, but I'll live...) And you can optimize the hell out of alpha blending using a LUT. 
I can produce statistics if you want...

There are also a few other circumstances where you start running into those little "titchy" things... one example is bill boarding. In a pure 
2D api, even if you are doing rotation, you don't need to billboard. You can just take the 3D->2D converted coordinate of a sprite's center 
and perform a 2D blit. You can't do this in OpenGL without redoing great whacking gobs of mathematics through yourself. and if you're 
doing it from scratch you don't need to worry about getting everything working just right because you'll have the code lying around 
anyways. 

Besides which, billboarding sucks. I have two solutions: The first is (if memory serves) about 6 muls/sprite, and I'm still waiting for the 
final proof from our guru mathematician to make sure it will work. (He designs the systems, I make them work with OpenGL) The second 
involves icosahedrons and lookup tables, and is really quite trippy.

Oh yeah... a few other things that are more difficult (to get going at a good speed) with OpenGL that are more feasible with a 2D API and 
framebuffer access: complex rippling/reflecting water, shadows, motion blur. :-)

>break up sprites into 256x256 chunks, but that's nothing terrible. A
>billboarded quad is a sprite...

OK, let's try this again. My main complaint with OpenGL for 2D based games is that you don't get raw access to the framebuffer -- the 
ability to dump pixels without either going through glDrawPixels() or glTex/*Sub*/Image2D.  So if I want to do anything interesting 
involving 2D blitting, I need to go through one of those paths, as opposed to doing my manipulation myself.

glDrawPixels() is notoriously slow. On top of that, in most circumstances you won't be hitting an  (well, ok, THE) optimized GL pipeline. 
You will probably end up hitting the very bottoms of unoptimizunity.

Also, there's the sprite thing. Worrying about alpha values and blend modes suck. :-)

I will concede that in certain situations, it works. However, my worry about SDL blit modes using OpenGL is that it won't encourage 
"smart usage". Plenty of people seem to have the attitude that OpenGL would make an ideal blitting API, which it wouldn't.

There are definitely situations where it's practical to use OpenGL's 3D functions and polygon drawing to create something that LOOKS like 
a 2D game (ehrmm, what are some examples? Myth 2 would serve, as would what I'm currently working on... must show that to you, you'd 
like it)... it's when you use it to actually do it in the old fashioned way that things get out of hand. Picking an example out of thin air, 
would you want to use OpenGL for HOMM3 or Civ:CTP? Nope.

Now, if I was porting Diablo II over to Linux, I don't know what route I'd go, and if I'd continue to use the "software"/Glide pair, or to 
abandon Glide, or to redo the Glide section in OpenGL. In that particular section it depends on the source code layout and how they're 
managing things.  Hopefully we'll get the opportunity to do just this :-)

>m.

This reply has been a LOT longer than I intended. :-)



More information about the SDL mailing list