I love making 2D games, but I also would like to have the features that a 3D
api provides, such as fast alpha blending, rotation, etc.
Is it crazy, or are there lots of things I haven’t thought about in
wondering if SDL for the future could be completely driven by opengl, and
that all our standard SDL requests get converted into opengl surfaces and
commands?
Most people have 3D accelerated cards now, and before long everyone will, so
that in itself doesn’t seem a problem, but there are probably many many
technical problems that I don’t have a clue about.
Hi !
It would be possible I think, but using it like that would make it a bit
slower, if you gonna use OpenGL you need to be aware of this as you have to
handle surfaces a bit different, you don’t have access to the surface data
itself as it is saved in video memory, so I don’t think it would work in
reality.
But you already have hardware acceleration for the 2D stuff today so I don’t
see much point in it, sure you can do a lot of fancy stuff with blending and
so on with OpenGL, but you can do this with normal surfaces to.
OpenGL textures have limtation with size must bu a multiple of 2, but there
are ways around this.
The biggest problem is that you don’t have access to the texture data once
it’s in video memory, sure this is true for some surfaces in 2D two.
Mikael> ----- Original Message -----
From: trinitychaos50@hotmail.com (Robert Clayton)
To:
Sent: Wednesday, July 25, 2001 10:10 PM
Subject: [SDL] SDL and 3D for the futureI love making 2D games, but I also would like to have the features that a
3D
api provides, such as fast alpha blending, rotation, etc.
Is it crazy, or are there lots of things I haven’t thought about in
wondering if SDL for the future could be completely driven by opengl, and
that all our standard SDL requests get converted into opengl surfaces and
commands?
Most people have 3D accelerated cards now, and before long everyone will,
so
that in itself doesn’t seem a problem, but there are probably many many
technical problems that I don’t have a clue about.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Noooooo! This would force me to stop SDL-based development for at least the
next 3-4 years! My computer is only a year old, and I do not indent to buy a
new one just because the internal handling of SDL goed OpenGL.
I don’t think this is a good idea. Most gamer PCs have 3D accelerated cards
and if they are happy they have a good driver for it.
But this kind of computer is not the only target for SDL. SDL is good for
(almost;) any kind of multimedia application, not only games. Consider some
kind of terminal based information system. You can develop it on your tuned
PC, but it may finally run on an embedded system, perhaps a cheap (and
robust!) 486 board is enough - probably not with windoze/dx…
This is a situation where SDL is a real gift for the developer.
Portability for 3D games is nice, but [see ‘How big is the the Linux game
market…’ thread]
You can of course make a wrapper around OpenGL, that offers the usual 2D
operations. A new API is probably better than using SDL API, because you can
optimize the API for it’s OpenGL backend. And a fallback to SDL_BlitRect()
and friends would make it perfect.
In fact a library of this kind would be wonderful for the minority I belong
to: My game could benifit from OpenGL accel although my computer doesn’t
offer it.
c yaOn Wednesday 25 July 2001 23:10, you wrote:
I love making 2D games, but I also would like to have the features that a
3D api provides, such as fast alpha blending, rotation, etc.
Is it crazy, or are there lots of things I haven’t thought about in
wondering if SDL for the future could be completely driven by opengl, and
that all our standard SDL requests get converted into opengl surfaces and
commands?
Most people have 3D accelerated cards now, and before long everyone will,
so that in itself doesn’t seem a problem, but there are probably many many
technical problems that I don’t have a clue about.
–
Benjamin Niemann (P!\K)
pink at odahoda.de
http://www.odahoda.de
Noooooo! This would force me to stop SDL-based development for at least the next 3-4 years! My computer is only a year old, and I do not indent to buy a new one just because the internal handling of SDL goed OpenGL.I love making 2D games, but I also would like to have the features
that a 3D api provides, such as fast alpha blending, rotation, etc.
Is it crazy, or are there lots of things I haven’t thought about in
wondering if SDL for the future could be completely driven by opengl,
and that all our standard SDL requests get converted into opengl
surfaces and commands?
Most people have 3D accelerated cards now, and before long everyone
will, so that in itself doesn’t seem a problem, but there are
probably many many technical problems that I don’t have a clue about.
There’s no need to replace the current 2D code; “2D on OpenGL” would be
more like an alternative video driver.
On many targets, OpenGL is the only way to get decent performance
(especially with blending), so it’s not like it’s just a way to get rid
of the 2D API wrapper code. It’s away to get high performance on more
target platforms.
I don’t think this is a good idea. Most gamer PCs have 3D accelerated
cards and if they are happy they have a good driver for it.
But this kind of computer is not the only target for SDL. SDL is good
for (almost;) any kind of multimedia application, not only games.
Consider some kind of terminal based information system. You can
develop it on your tuned PC, but it may finally run on an embedded
system, perhaps a cheap (and robust!) 486 board is enough - probably
not with windoze/dx… This is a situation where SDL is a real gift for
the developer.
Yes, of course.
2D on OpenGL is just a performance hack - but can’t get enough
performance for some games… One could claim that a game with that kind
of requirements should use OpenGL directly, but that isn’t exactly
helpful.
If you were developing a 2D game for 640x480+ resolutions using SDL on
Win32/DX, would you write an OpenGL implementation of the engine just
so that Linux users could get playable speed?
The lack of DMA based blitting on most current Linux targets is a real
problem, and the only solution I’ve seen so far, that doesn’t put
extreme requirements on the end user, is to use OpenGL. It would be kind
of nice if at least the most important parts of the SDL 2D API would work
transparently on top of OpenGL, as it’s a lot easier to find a Linux
system with proper 3D acceleration, than it is to find one with
sysram->vram DMA blitting.
Portability for 3D games is nice, but [see ‘How big is the the Linux
game market…’ thread]
Either way, there’s no problem with 3D games. SDL handles that just fine
already.
You can of course make a wrapper around OpenGL, that offers the usual
2D operations. A new API is probably better than using SDL API, because
you can optimize the API for it’s OpenGL backend. And a fallback to
SDL_BlitRect() and friends would make it perfect.
Yeah, I’m kind of playing with something like that. Not a high priority
project right now, though.
In fact a library of this kind would be wonderful for the minority I
belong to: My game could benifit from OpenGL accel although my computer
doesn’t offer it.
Yep. It would also make games that expect hardware acceleration for all
2D operations, or very fast CPUs, playable on more normal machines that
have only moderate CPU power but acceptable 3D acceleration.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 26 July 2001 09:55, Benjamin Niemann wrote:
On Wednesday 25 July 2001 23:10, you wrote:
David Olofson wrote:
Yep. It would also make games that expect hardware acceleration for all
2D operations, or very fast CPUs, playable on more normal machines that
have only moderate CPU power but acceptable 3D acceleration.
But SDL should at least detect when it’s fastest to use OpenGL
and when it’s fastest to go the old-school way - because if
say, OpenGL only has a software driver on the system, it’s
probably going to be slower than doing the 2D stuff directly.
Otherwise - I think it would be a nice feature 
And by the way - now we’re at it… It would be really nice
to have a (float32, float32, float32) RGB framebuffer (i.e.
96 bit float buffer) in SDL which would display with
hardware acceleration - the OpenGL function glDrawPixels
can do the conversion and should AFAIK use hardware
acceleration on many machines today.
This would be very handy for fancy 3D rendering…
Hi !
glDrawPixels is sooo slow, even on accelarated cards.
Mikael> ----- Original Message -----
From: anoq@hardcoreprocessing.com (Anoq of the Sun)
To:
Sent: Thursday, July 26, 2001 1:14 PM
Subject: Re: [SDL] SDL and 3D for the futureDavid Olofson wrote:
Yep. It would also make games that expect hardware acceleration for all
2D operations, or very fast CPUs, playable on more normal machines that
have only moderate CPU power but acceptable 3D acceleration.But SDL should at least detect when it’s fastest to use OpenGL
and when it’s fastest to go the old-school way - because if
say, OpenGL only has a software driver on the system, it’s
probably going to be slower than doing the 2D stuff directly.Otherwise - I think it would be a nice feature
And by the way - now we’re at it… It would be really nice
to have a (float32, float32, float32) RGB framebuffer (i.e.
96 bit float buffer) in SDL which would display with
hardware acceleration - the OpenGL function glDrawPixels
can do the conversion and should AFAIK use hardware
acceleration on many machines today.This would be very handy for fancy 3D rendering…
Cheers
http://www.HardcoreProcessing.com
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
Mikael Aronsson wrote:
glDrawPixels is sooo slow, even on accelarated cards.
Oh… I haven’t tried it - never mind then
David Olofson wrote:
Yep. It would also make games that expect hardware acceleration for
all 2D operations, or very fast CPUs, playable on more normal
machines that have only moderate CPU power but acceptable 3D
acceleration.But SDL should at least detect when it’s fastest to use OpenGL
and when it’s fastest to go the old-school way - because if
say, OpenGL only has a software driver on the system, it’s
probably going to be slower than doing the 2D stuff directly.
It would be nice if SDL could provide some kind of “performance
database”, but in the normal case, that would be up to the application
and the user.
Noticed that most serious 3D games let you pick a driver manually in the
configuration? That’s becaues there’s no safe way of autodetecting what
works best - the fastest driver may have serious rendering bugs that the
game doesn’t notice.
Otherwise - I think it would be a nice feature
Well, hopefully nicer than requiring 2D programmers to learn OpenGL just
in order to get some extra 2D performance on some systems… (Read: If it
was in SDL, it would actually be available in some games.)
And by the way - now we’re at it… It would be really nice
to have a (float32, float32, float32) RGB framebuffer (i.e.
96 bit float buffer) in SDL which would display with
hardware acceleration - the OpenGL function glDrawPixels
can do the conversion
Yeah, and it’s usually dog slow.
and should AFAIK use hardware
acceleration on many machines today.
Hmm… I don’t know of any consumer card that can accelerate conversions
from float pixel formats… Then again, there’s probably a lot I don’t
know of!
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Thursday 26 July 2001 14:14, Anoq of the Sun wrote:
Depends on the card. Not all accelerated cards have support for
accelerating glDrawPixels. eg, the Voodoo/DRI driver falls back
to software rendering for glDrawPixels.On Thu, Jul 26, 2001 at 02:19:43PM +0100, Mikael Aronsson wrote:
glDrawPixels is sooo slow, even on accelarated cards.
–
The more I know about the WIN32 API the more I dislike it. It is complex and
for the most part poorly designed, inconsistent, and poorly documented.
- David Korn