When will blitting be enable when using OpenGL with SDL. Also, is there
TODO list for SDL. If not, it would be nice to have one so that people
can know what to expect and when.
When will blitting be enable when using OpenGL with SDL.
It’s not planned. Use texture mapped quads instead.
Also, is there
TODO list for SDL. If not, it would be nice to have one so that people
can know what to expect and when.
Did anyone post that wishlist a while ago?
-Sam Lantinga, Lead Programmer, Loki Entertainment SoftwareWhen will blitting be enable when using OpenGL with SDL. Also, is there
TODO list for SDL. If not, it would be nice to have one so that people
can know what to expect and when.
<Whap!><BANG!><THUNK!>
REPEAT AFTER ME: OPENGL IS A 3D API.
Just to make sure that you’re not going to do something irresponsible like a 2D
game in OpenGL.
Now, blitting. IMHO it’s not practical (and not desireable for me as a
programmer, even if it existed).
- If we did this, we’d need to start generating texture objects for surfaces.
- Since we have no real way of verifying surface integrity, we would need to
re-upload the entire texture to the video card every time that we did a blit. - Surfaces would need to be restricted to 256x256 (a hardware limitation on
older cards, like certain Voodoos).
So, let’s just say that “it’s a bad thing” and let’s do it ourselves by hand!
On the todo list, I don’t think anybody ever put one up in one place. I had a
few notes posted to the ML, try to dig through the archives.
Nichol
REPEAT AFTER ME: OPENGL IS A 3D API.
Sure, but what game doesn’t work in some sort of three-dimensional
space? Even side scrollers have parallax, etc.
Just to make sure that you’re not going to do something
irresponsible like a 2D game in OpenGL.
Tut, tut If I were making an isometric game like Diablo right now, I’d
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
break up sprites into 256x256 chunks, but that’s nothing terrible. A
billboarded quad is a sprite…
m.On Wed, Apr 05, 2000 at 05:07:47PM -0000, vining at pacificcoast.net wrote:
–
Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire
Michael Vance wrote:
Just to make sure that you’re not going to do something
irresponsible like a 2D game in OpenGL.Tut, tut If I were making an isometric game like Diablo right now, I’d
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
alpha blending, rotation, filtering, lighting, zooming, …
break up sprites into 256x256 chunks, but that’s nothing terrible. A
billboarded quad is a sprite…
And you only have to split it up into 256x256 on a Voodoo (die Voodoo
die). If you do the splitting up at runtime for most cards you don’t
have to do it (G400 and TNT have a 2048x2048 limit). There is a little
problem with splitting up textures naively: filtering and mipmapping can
produce visual artifacts in the transition if you are not careful.–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
REPEAT AFTER ME: OPENGL IS A 3D API.
Just to make sure that you’re not going to do something irresponsible like a 2D
game in OpenGL.
Come on, just because it isn’t made for 2D doesn’t imply that you are in some
way forbidden to use it that way, as long as it works. Since 3D gets all the
attention, all the hardware, all the driver and API support, what is a poor
2D programmer to do?
Sure, we could implement lighting effects, alpha blending, fog and a
lot more by hand, pixel-by-pixel in C or asm code crafted with love
and care, but when even low-end commodity hardware can do it much better
in hardware, why not take advantage of it? Just think of the lovely
multi-layer-parallax-scrolling space-shootemups we could do if we got the
same hardware attention as the 3D guys. And the RPGs and real-time strategy
games! And we’d get free rotation and bitmap scaling, complete with
filtering.
- Surfaces would need to be restricted to 256x256 (a hardware limitation on
older cards, like certain Voodoos).
We can tile, no problem, consoles have done it the last 25 years. And it
is possible to fall back on lower-quality software rendering if the hardware
doesn’t give us what we want.
Now, disclaimer: I have never tried using OpenGL for a 2D game, but I see
no reason it couldn’t be bent to my sinister purposes, even if it’s a snug
fit.
When will blitting be enable when using OpenGL with SDL. Also, is there
TODO list for SDL. If not, it would be nice to have one so that people
can know what to expect and when.<Whap!><BANG!><THUNK!>
REPEAT AFTER ME: OPENGL IS A 3D API.
Just to make sure that you’re not going to do something irresponsible like a 2D
game in OpenGL.Now, blitting. IMHO it’s not practical (and not desireable for me as a
programmer, even if it existed).
- If we did this, we’d need to start generating texture objects for surfaces.
- Since we have no real way of verifying surface integrity, we would need to
re-upload the entire texture to the video card every time that we did a blit.- Surfaces would need to be restricted to 256x256 (a hardware limitation on
older cards, like certain Voodoos).So, let’s just say that “it’s a bad thing” and let’s do it ourselves by hand!
On the todo list, I don’t think anybody ever put one up in one place. I had a
few notes posted to the ML, try to dig through the archives.Nichol
While I think blitting to/from texture maps and/or blitting from the 3D frame
buffer would be nice, in most cases they aren’t necessary.
It would be nice if (when availible) the same API functions can used to copy
to/from textures and from 3D framebuffers as are used for blitting. Not a
necessity, but a convienence…
What I think is REALLY ANNOYING, however, is that the documentation seems to
say that all blitting is disabled… I see no reason to disable off-screen
surface blitting in a 3D application.
Regards,
-Loren
Hi!On 5 Apr 2000 vining at pacificcoast.net wrote:
REPEAT AFTER ME: OPENGL IS A 3D API.
According to www.opengl.org, OpenGL is “a highly versatile 2D and 3D
graphics API”. It’s designed for 2D graphics as well.
Bye,
Christian
–
/ Coding on PowerPC and proud of it
/ http://www.uni-mainz.de/~bauec002/
Sure, but what game doesn’t work in some sort of three-dimensional
space? Even side scrollers have parallax, etc.
Pac Mac. 
Space Invaders. Tetris.
Tut, tut If I were making an isometric game like Diablo right now, I’d
use OpenGL.
I think it’d be much easier (and faster and less dependant on special
hardware (ie, VooDoo)) to just blit the isometric tiles onto the screen.
Does Diablo use/require enhanced 3D software/hardware? (I don’t know,
since I don’t use Windows.) I doubt it, honestly, since my roommate used
to play it on her old Pentium 133 w/ no fancy hardware.
-bill!
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.
Does Diablo use/require enhanced 3D software/hardware? (I don’t know,
since I don’t use Windows.) I doubt it, honestly, since my roommate used
to play it on her old Pentium 133 w/ no fancy hardware.
No, it does not require any 3D hardware. They use 2d blits.
Completely pre-rendered 2d sprites.–
Brian
Hi!
REPEAT AFTER ME: OPENGL IS A 3D API.
According to www.opengl.org, OpenGL is “a highly versatile 2D and 3D
graphics API”. It’s designed for 2D graphics as well.
Designed, yes, but it doesn’t work that way on all platforms that are “relevant” to us as game developers.
- Transferring large quantities of raw data over the bus == slow, painful.
- Pulling data from GL’s internal frame buffer == bad thing too, since it disturbs the FIFO queue.
- You will always hit unoptimized paths if you try to use the 2D API functions (especially glDrawPixels, although this is more of a
hardware limitation… bleccht!)
Predominantly, my worry is that people will treat it as an “ideal blitting API”. Which it’s not. If we built code into SDL to support blits
(this was something that Kenton and I came across while we were looking at doing the GL work ourselves (i.e. before the Loki people got
fed up with our wierd GPFing and did it themselves… ;-)) was that building OpenGL blitting into that API would only end up removing the
really cool bits of building a 3D application with OpenGL that actually make it feasible. (Free alpha blitting, etc.) Plus, you 'd always be
working in immediate mode, which really isn’t a good way to work. (Ooh, just thought that one up)
There are situations where it is feasible to create a 3D game using OpenGL that looks like a 2D one, but as a 2D API it’s a fiasco. Don’t go
there.
Sorry about inciting mass flaming here, but this is and has always been one of my pet peeves.
Christian
Nicho>On 5 Apr 2000 vining at pacificcoast.net wrote:
While I think blitting to/from texture maps and/or blitting from the 3D frame
buffer would be nice, in most cases they aren’t necessary.
Unfortunately, not true. We have no way of guaranteeing that an SDL_Surface has not changed since the last upload (since we can access
the surface’s pixels directly without going through another API), therefore we would need to constantly re-upload. A cruel world.
As for necessity, you’re right, but if you wanted to do something like rewrite SDL’s video aspect to do 2D blits on top of OpenGL you would
have to. Sucky.
It would be nice if (when availible) the same API functions can used to copy
to/from textures and from 3D framebuffers as are used for blitting. Not a
necessity, but a convienence…
A bad one. Not only do you end up forcing a re-upload each time but you work in immediate mode (even worse, forcing a glBegin/glEnd pair
per blit, because you can’t rely on the user to do it and you don’t know what mode you’ll be in, so you can’t do just one), don’t hit the best
pipeline, and run into a few other interesting hassles like that.
What I think is REALLY ANNOYING, however, is that the documentation seems to
say that all blitting is disabled… I see no reason to disable off-screen
surface blitting in a 3D application.
I don’t think it is. Whoops! (another one for my doc fix this evening) You still need to be careful though, because you need to remember that
you always have to re-upload the texture after blitting, and that SDL can’t read your mind here. Since you’re managing the texture object
yourself, and SDL isn’t, it doesn’t know where this accursed thing has to go. Bad practice for an API to rely on users doing the smart
thing… I think we can safely say that they never do 
Regards,
-Loren
Nichola
Mattias Engdeg?rd wrote:
REPEAT AFTER ME: OPENGL IS A 3D API.
Just to make sure that you’re not going to do something irresponsible like a 2D
game in OpenGL.Come on, just because it isn’t made for 2D doesn’t imply that you are in some
way forbidden to use it that way, as long as it works. Since 3D gets all the
attention, all the hardware, all the driver and API support, what is a poor
2D programmer to do?
I agree the snes9x emulator looks LOTS better with OpenGL. And it is
alot faster too.
Michael Vance wrote:
Just to make sure that you’re not going to do something
irresponsible like a 2D game in OpenGL.Tut, tut If I were making an isometric game like Diablo right now, I’d
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 toalpha blending, rotation, filtering, lighting, zooming, …
You really want to use OpenGL’s built in lighting?
have to do it (G400 and TNT have a 2048x2048 limit). There is a little
problem with splitting up textures naively: filtering and mipmapping can
produce visual artifacts in the transition if you are not careful.
Another good point that I’ll need to write down and use as necessary.
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
Nicholas
No, it does not require any 3D hardware. They use 2d blits.
Completely pre-rendered 2d sprites.
That’s what I thought! And it plays well on an unenhanced P133 and
looks perfectly gorgeous as-is.
-bill!
would you want to use OpenGL for HOMM3 or Civ:CTP? Nope.
Don’t forget Eric’s Solitaire!
-bill!
I agree the snes9x emulator looks LOTS better with OpenGL. And it is
alot faster too.
Hehe - I can maybe see a game console emulator looking better because
I bet OpenGL would be much faster at rendering the artifacts one normally
sees when playing video games on TV’s.
For example, an Atari 2600 emulator looks crappy, IMHO, because it’s too
crisp and perfect…
I want to see static! I want to see little fuzzy rectangular ghosts
move up and down the screen as I twist the paddle left and right.
(I mainly just want to be able to use a paddle on a PC under Linux,
PERIOD. )
-bill!
Sure, but what game doesn’t work in some sort of three-dimensional
space? Even side scrollers have parallax, etc.Pac Mac.
So that’s why you don’t use OpenGL in your games, Bill?
I think it’d be much easier (and faster and less dependant on special
hardware (ie, VooDoo)) to just blit the isometric tiles onto the screen.
Finally, a programmer who agrees with me. Just for that, I’ll get Gem Drop X
-bill!
Nicholas
I agree the snes9x emulator looks LOTS better with OpenGL. And it is
alot faster too.
On what system, on what hardware, and what were they using before? I bet it
doesn’t look better on my brother’s P/233 in software mode, but it might be
better on my friend Quetzal’s P/133 with a Voodoo 2.
You can’t attribute that to the superiority of OpenGL versus whatever it was
before, or a speed increase. I suspect that on many cards it’d just be painful,
and for all I know the original implementation might have been written in
embedded Perl. Which, judging by how much zsnes kicks snes9x’s butt, might be a
very distinct possibility.
Cheers,
Nicho