Bernd Kreimeier wrote:
I would like feedback from SDL users on a few questions I have
been pondering for a while. Please be brief, and please do not
argue with other people’s requirements, just state them. I’ll
give a few examples in no particular order:
You mean what we’d like to have in SDL and/or what we
already use?
Ok, I use this:
- LFB (base address, row length, number of rows, internal format)
- Rectangular blits
- offscreen rendering
- abstraction of OS specific window (context, kbd, pointer)
This would be great to have :
- GL/Mesa rendering into SHM (software)
- hardware OpenGL
This, the imglib’s import, is very useful although I don’t
use it
for now:
- image import/export
I’d also enjoy a bit better integration with X11/Win
(unfortunately I know nothing about X11 itself) - e.g.
making window fullscreen/decorationless, limiting mouse to
window’s area etc.
Vasek
I would like feedback from SDL users on a few questions I have
been pondering for a while. Please be brief, and please do not
argue with other people’s requirements, just state them. I’ll
Hardware OpenGL <<<
I consider this point most urgent for a library used for games.
It will die sooner or later, if it does not provide an interface to
OpenGL.
- MarkusOn Tue, Sep 14, 1999 at 11:31:26PM +0100, Bernd Kreimeier wrote:
But it seems that this is an issue for OpenGL. A new SDL target, not
adding wrappers in SDL. What does SDL provide that OpenGL could take
advantage of? Bitblitting. SDL would not help speed up 3d stuff at all.
Now if SDL was extended to provide some access to 3d hardware, then I
could see an OpenGL to SDL target being useful, but I don’t know if
SDL has any plans for 3D stuff or not. Maybe they should consider this
instead.
Markus Enzenberger writes:>
On Tue, Sep 14, 1999 at 11:31:26PM +0100, Bernd Kreimeier wrote:
I would like feedback from SDL users on a few questions I have
been pondering for a while. Please be brief, and please do not
argue with other people’s requirements, just state them. I’ll
Hardware OpenGL <<<
I consider this point most urgent for a library used for games.
It will die sooner or later, if it does not provide an interface to
OpenGL.
Jesse Marlin wrote:
But it seems that this is an issue for OpenGL. A new SDL target, not
adding wrappers in SDL. What does SDL provide that OpenGL could take
advantage of? Bitblitting. SDL would not help speed up 3d stuff at all.
Now if SDL was extended to provide some access to 3d hardware, then I
could see an OpenGL to SDL target being useful, but I don’t know if
SDL has any plans for 3D stuff or not. Maybe they should consider this
instead.
Has anyone played SNES9X with gl support? It is must faster/prettier
than the software mode, but it is 2d. I wanted to add such
functionality to PowerPak, but don’t know how to take advantage of
OpenGL in 2d, not the way I would want to anyhow.
It would be nice if somehow SDL could provide blits to OpenGL which
would allow people with the hardware a much nicer/faster environment.
Also there is the SDL input problem though. It seems to not work with
GLUT. I guess not using glut is an option, but I didn’t want to have to
figure out how to manage windows for three or four different platforms
and not be able to test it. I guess the SDL developers have access to
all the machines that it would need to work on so that isn’t a problem
for them, and they wouldn’t need Glut.
Ryan Wahle wrote:
I would like to see Joystick support. Another thing I would like to see is
to have all the extra libraries put into one. I know that we don’t want
SDL to be bloated, but why not have the networking library, the image
library, the gui library all in one instead of having to work with 3
different libraries, just use the one SDL. If SDL is a shared library, I
don’t see any reason to not do this…
I agree.
Sort of setup.h file with on/off flags (#define SDL_USE_GUI 1) should be
used. Then if somebody don’t want support for something (e.g. GUI) (s)he can
simply #undef it.
VS
Hardware OpenGL <<<
I consider this point most urgent for a library used for games.
Hey, I said don’t argue ;-).
Rest assured that we are very much aware of this. The
purpose of my query is to collect things that have not
been mentioned in my example list, okay?
We can have a Vote pass later if needed for controversial
issues. I’d rather spec out what I suggest for changing
in, and adding, to SDL some time soon, and we can start
arguing then.
Again, this is a poll. List specific features that you
think should be in, don’t argue with the requirements
of others.
I maybe should amend that it would be nice to have some
indications like currently “using” or “want” as well,
to guide me in getting to know the legacy we deal with.
Thanks.
b.
But it seems that this is an issue for OpenGL. A new SDL target, not
adding wrappers in SDL. What does SDL provide that OpenGL could take
advantage of? Bitblitting. SDL would not help speed up 3d stuff at all.
Now if SDL was extended to provide some access to 3d hardware, then I
could see an OpenGL to SDL target being useful, but I don’t know if
SDL has any plans for 3D stuff or not. Maybe they should consider this
instead.
My feeling is OpenGL needs nothing from SDL, and vice versa. Meaning if
you write an OpenGL application it is inherently portable. SDL is
inherently 2D. So if your application is 2D in nature, use SDL. If it
is 3D, use OpenGL. But don’t worry about the issue of mixing the two.
I haven’t done any OpenGL programming myself, I’ve just looked at some
source examples and made minor tinkering changes. I guess the only
missing issues in OpenGL are sound support and possibly joystick input.
Shooting for portability with a simple recompile…Well you’re probably not
going to see that using OpenGL just yet like you can with SDL.
My feeling is SDL will fall by the wayside regardless of what gets
incorporated into it and as 3D becomes standard everywhere. So enjoy
it while it lasts…
I’m very impressed with q3test under linux. The high framerate and quality,
using the GLX/OpenGL accelerated solution, leads me to wonder what possible
place is there for SDL in 3D…
“Dave Ashley (SDL list)” wrote:
But it seems that this is an issue for OpenGL. A new SDL target, not
adding wrappers in SDL. What does SDL provide that OpenGL could take
advantage of? Bitblitting. SDL would not help speed up 3d stuff at all.
Now if SDL was extended to provide some access to 3d hardware, then I
could see an OpenGL to SDL target being useful, but I don’t know if
SDL has any plans for 3D stuff or not. Maybe they should consider this
instead.
My feeling is OpenGL needs nothing from SDL, and vice versa. Meaning if
you write an OpenGL application it is inherently portable. SDL is
inherently 2D. So if your application is 2D in nature, use SDL. If it
is 3D, use OpenGL. But don’t worry about the issue of mixing the two.
I haven’t done any OpenGL programming myself, I’ve just looked at some
source examples and made minor tinkering changes. I guess the only
missing issues in OpenGL are sound support and possibly joystick input.
Shooting for portability with a simple recompile…Well you’re probably not
going to see that using OpenGL just yet like you can with SDL.
My feeling is SDL will fall by the wayside regardless of what gets
incorporated into it and as 3D becomes standard everywhere. So enjoy
it while it lasts…
I for one hope that 3d doesn’t ever completely take over. 2d games are
still alot of fun.
bernd kreimeier writes:
Hardware OpenGL <<<
I consider this point most urgent for a library used for games.
Hey, I said don’t argue ;-).
Rest assured that we are very much aware of this. The
purpose of my query is to collect things that have not
been mentioned in my example list, okay?
We can have a Vote pass later if needed for controversial
issues. I’d rather spec out what I suggest for changing
in, and adding, to SDL some time soon, and we can start
arguing then.
Again, this is a poll. List specific features that you
think should be in, don’t argue with the requirements
of others.
Maybe a “Simple Direct” way to get at 3d accelerator functions. This is
pointless in linux right now for most video cards, but with XFree86 4.0
on the horizon it might be worthwhile to consider it.
John Garrison wrote:
I for one hope that 3d doesn’t ever completely take over. 2d games are
still alot of fun.
I concur. I also think that 2D games are a lot more fun to create. 3D games
will probably take over the supra-genre of fast, action-paced games that make you
feel, and not think.
2D still has a lot of merits for story telling games that make you think first,
and feel later. People think that increases in technology means increases in
polygon sophistication, rendering games around the same length and complexity of
storyline, which is a real vertical improvement, but if the hardware is utilized
for longer games with more in-depth interactions, we’ll see a horizontal
improvement.
Actually, my opinion is that games such as Halflife are still action games with
the story put in to elevate the action. It’s hard to do it vice versa with a 3D
engine such as Quake’s.
I haven’t really gone public with my tilebased engine yet, but my philosophy is
to create an engine (note that an engine is more than a graphics renderer) that
allows people to tell stories creatively. Oh, and to smash a few montster’s
heads in while you’re at it.
SDL is in the right time and place.–
Michael Labbe (not the pedophile)
John Garrison wrote:Has anyone played SNES9X with gl support? It is must
faster/prettier
GLUT. I guess not using glut is an option, but I didn’t want to have to
figure out how to manage windows for three or four different platforms
and not be able to test it. I guess the SDL developers have access to
all the machines that it would need to work on so that isn’t a problem
for them, and they wouldn’t need Glut.
One of the reasons I originally started experimenting with SDL was to see it’s
viability as a portable framebuffer to dump OpenGL scenes to. However, I
haven’t tried this in a while, and I met with zero success when I tried a few
months
ago. Does anyone know if this is feasible?–
Michael Labbe (not the pedophile)
My requirements (in descending order of priority-- that is, #1 is highest) are:
-
- LFB (base address, row length, number of rows, internal format)
-
- Double Buffering
-
14.image import/export
-
- Rectangular blits
-
- Span blitting
-
- Scaled blits
-
- offscreen rendering
-
- abstraction of OS specific window (context, kbd, pointer)
-
13.input devices (joystick, orbs)
10.>2. Failsafe GetPixel/PutPixel for debug
Warren E. Downs
b.
Hardware OpenGL <<<
I consider this point most urgent for a library used for games.
Hey, I said don’t argue ;-).
Right, but mentioning OpenGL is my trigger, I cannot help it 
I think too that this is the best design!
Please respond to sdl at surfnetcity.com.auTo: sdl at surfnetcity.com.au
cc: (bcc: Alessandro Porcu/unica/it)
Subject: Re: [SDL] SDL Query
On Wed, 15 Sep 1999, Ryan Wahle wrote:
I would like to see Joystick support. Another thing I would like to see
is
to have all the extra libraries put into one. I know that we don’t want
SDL to be bloated, but why not have the networking library, the image
library, the gui library all in one instead of having to work with 3
different libraries, just use the one SDL. If SDL is a shared library, I
don’t see any reason to not do this…
Making it a shared library will make the shared library very large, and
the application that uses it will use all that memory. It may be
duplicated only once per application but And most of it will go to waste
since not every SDL program needs all the functionality. TANSTAFFL. No,
I thinkit would be better to have several different libraries which depend
on each other in a fundamental way. A modular design approach would be
the most sensible, as not every program will need all the features the
whole library provides. My proposal for doing this would be to have:
-
A base library, containing nothing but a low-level device-independent
interface to the input, graphics and sound hardware, kind of like the
present state of SDL now. All the other libraries depend on this.
-
A drawing primitives library, which contains functions for drawing
simple graphics primitives such as lines, ellipses, rectangles, et. al.
-
A library similar top gtk-imlib that allows one to load all kinds of
image formats into an SDL_Surface.
-
A simple GUI toolkit. This naturally depends on (2) and (3) as well.
I would prefer this to be as basic as we can make it, with only stuff
like pushbuttons, checkboxes, and popup menus. I don’t think that most
people will need more than that for the kind of apps running under SDL.
-
A networking abstraction library. This may stand by itself or
require some of the threading functionality provided by (1).
Since not every program needs everything, the programmer has the freedom
to link only the libraries his or her program actually uses. I have the
feeling that the total size of this library set will exceed two megabytes
in binary once it is complete, and si I think the memory savings in
modularizing the library would be significant.
| Rafael R. Sevilla rsevilla at eee.upd.edu.ph |
| Instrumentation, Robotics, and Control Laboratory |
| College of Engineering, University of the Philippines, Diliman |
“Michael Labbe (Not the pedophile)” wrote:
John Garrison wrote:Has anyone played SNES9X with gl support? It is must
faster/prettier
GLUT. I guess not using glut is an option, but I didn’t want to have to
figure out how to manage windows for three or four different platforms
and not be able to test it.
Use GGIMesa. It is completely cross-platform, but does not suffer from
the massive GLUT bloatage.
I guess the SDL developers have access to
all the machines that it would need to work on so that isn’t a problem
for them, and they wouldn’t need Glut.
One of the reasons I originally started experimenting with SDL was to see it’s
viability as a portable framebuffer to dump OpenGL scenes to. However, I
haven’t tried this in a while, and I met with zero success when I tried a few
months
ago. Does anyone know if this is feasible?
Use LibGGI. It is designed specifically to be a "portable
framebuffer". If you wrote an SDL target for LibGGI, you would be able
to keep all the benefits of both APIs - the abstraction and portability
of LibGGI/GGIMesa and the excellent linear framebuffer management of
SDL.
Jon