== Urspr?ngliche Mitteilung von sdl at libsdl.org am
16.06.02 22:01
On all platforms except Amiga, hardware
surfaces
are only availible in fullscreen mode.
The problem is
that if SDL did this, it would have to clip the
image
to exclude any windows that may be on top of it…
Right. That is why Direct X has a function for that
purpose that can be
called by the user (making the graphic window slow)
or not (destroying GUI
windows that are on top of the graphic Window, thus
making the app
“pseudo-fullscreen”). For my app I would (and have
for the current version)
choose (2).
You could always submit a patch… I honestly am not
sure Sam would go for the idea of not clipping, as it
breaks the “window paradigm”, but it’s still worth
asking him.
While this is certainly possible, I don’t even
think
that even the Amiga port does this. If you feel
ambitious, I’m sure Sam would welcome a patch to
handle this case…
Do you think SDL/OpenGL prevents the use of
hardware acceleration in
non-fullscreen mode, or can I enable it and live
with the shortcomings ?
I am unsure if the final rendered-3D to 2D window blit
is accelerated under SDL/OpenGL, but the actual 3D
rendering (which is what takes the real time) is
accelerated on machines that are configured to support
it (most machines)… If you have a 3D accelerator,
and it works for other OpenGL programs, you should
have no problem.__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
As you are doing zoom (and possibly roatation)
operations I thinks this leaves you with 3 choices:
Do all your image manipulation (Zooming,
rotation,
warping, whatever) in software.
Do you mean in my software, or in software
provided by SDL and/or OpenGL ?
I was refering to 2D SDL video, so OpenGL doesn’t
apply. I don’t recall if SDL has a streatch-blit: If
not it isn’t hard to write…__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
NVIDIA does not make video cards, only graphics chips.
As someone noted, the Riva was their first, and they basically redid their
entire architecture right after that. It’s a very old card, and the
drivers they distribute for literally every single chipset they’ve made
since don’t work with it. You might be able to get 3D in Win32 if you can
find the old Riva 128 driver on the NV website, but you won’t be able to
use it in Linux - no Linux drivers for that card exist.
Just about anything newer (TNT and GeForce chips) will work with the
drivers you’ve downloaded though. TNT and TNT2 can almost be gotten free
nowadays they’re so old. GeForce2 is about the minimum useful card in
most people’s opinion. GeForce3 isn’t so bad for development IMO, and the
latest and greatest thing is the GeForce4.
The GF4 is total and absolute overkill unless you want the best possible
performance out of the next Id Software shooter game. And if you want
that, save your money since it won’t be out for another year anyway - by
that time we’ll probably be looking at the GeForce5, the Radeon 3 core,
and some bad-ass thing Matrox has been working on. =)On Sun, Jun 16, 2002 at 12:06:00AM +0200, Michael Schnell wrote:
Thanks anyway. I think I should buy an original Nvidia card.
–
Joseph Carter What’re you looking at?
hey did you fall off your pirch or something?
me? heh.
== Urspr?ngliche Mitteilung von sdl at libsdl.org am 16.06.02 23:26
I was refering to 2D SDL video, so OpenGL doesn’t
apply.
Now I’m a bit confused. Is Open GL strictly 3D ? As DirectX does provide
stretchblit (hardware supported, if the hardware can do it), I assumed
OpenGL would have same, too.
I don’t recall if SDL has a streatch-blit: If
not it isn’t hard to write…
I always can write a software version of stretchblit in the user program,
but what I am searching is hardware supported stretchblit. So do you mean it
would be “easy to write an SDL access function to access the stretchblit
provided by the OpenGL driver for the card in question” ?
In my test (using Jedi_JCL by the Jedi project as a Pascal encapsulation for
the SDL-functions) I do:
if (SDL_BlitSurface(zoom, @src, screen_, @upd) < 0) then
begin
Memo.Lines.Add(Format('Blit failed: %s', [SDL_GetError]));
end;
Thus BlitSurface can do a “stretch” (zoom) and seems to be the equivalent of
stretchblt in DirectX.
== Urspr?ngliche Mitteilung von sdl at libsdl.org am 16.06.02 23:21
I am unsure if the final rendered-3D to 2D window blit
is accelerated under SDL/OpenGL, but the actual 3D
rendering (which is what takes the real time) is
accelerated on machines that are configured to support
it (most machines)… If you have a 3D accelerator,
and it works for other OpenGL programs, you should
have no problem.
Hmm, my needs are strictly 2D, so the only thing I need from OpenGL is the
"Final Blitting"
You might be able to get 3D in Win32 if you can
find the old Riva 128 driver on the NV website, but you won’t be able to
use it in Linux - no Linux drivers for that card exist.
OK, so I’ll buy a new card for this project.
Just about anything newer (TNT and GeForce chips) will work with the
drivers you’ve downloaded though. TNT and TNT2 can almost be gotten free
nowadays they’re so old. GeForce2 is about the minimum useful card in
most people’s opinion. GeForce3 isn’t so bad for development IMO, and the
latest and greatest thing is the GeForce4.
As the only thing I need is 2D Strechblit of large images (no sophisticated
3D stuff) I suppose, any card with a good amount of ram should do. Do you
think a card with an vnidia chip is a good choice (regarding OpneGL support)
or should I search for something else ?
The RIVA 128 is a rather old chip (NVIDIA’s first really successful GPU). It
uses an older architecture than the more recent chips. As far as I know, the
current Linux NVdriver does not support it.
Right you are. I need to buy a new card (no problem in this project)
Any of NVIDIA’s current cards (GeForce 2 or later) should be well supported
for OpenGL in both Linux and Windows. Older GF2 cards are very cheap these
days. For Linux you’ll need the (unfortunately binary-only, but actively
maintained)
driver from www.nvidia.com.
I d/l ed them. The Linux installation seem a bit complicated. So I first
will do some test in Windows and proceed with Linux when they seem
promising.
== Urspr?ngliche Mitteilung von sdl at libsdl.org am 15.06.02 22:56
The images are small enough to fit in memory of a PC wit appropriate amount
of RAM, so I’d like just to blit them when necessary. I suppose there might
be some hardware support for the blitting. I do need a grid in front of the
picture which is zoomed and panned with it but the lines of which stay at
the same width. So I need fast line operations and/or overlay graphic.
OpenGL does those sorts of things very well, accelerated, on all major
OS’s… so long as you have a video card from the past 3 or 4 years,
and so long as you have drivers for it.
Ray, Thanks for the encouragements. So it seems to be doable.
I found out how to convert SDL_Surfaces to OpenGL textures in a NeHe
demo (should be linked of the SDL page). Beyond that I have no
knowledge of how to get your data into OpenGL textures.
I’ll take a look ! But what does this mean (“convert SDL_Surfaces to OpenGL
textures”) did you modify SDL or did you use SDL ? Anyway if this is the
way to go I will not hesitate to follow you.
== Urspr?ngliche Mitteilung von sdl at libsdl.org am 16.06.02 05:03
I found out how to convert SDL_Surfaces to OpenGL textures in a NeHe
demo (should be linked of the SDL page). Beyond that I have no
knowledge of how to get your data into OpenGL textures.
There’s a good example in the test/testgl.c example in the SDL source
archive.
=== Kommentar von MSCHNELL at MARIANNE (Michael Schnell) am 17.06.02 08:02
NVIDIA has what John Carmack refers to as his “gold standard” in drivers.
They are 100% technically correct for just about everything he’s tried to
do with them, and when they are ever found not to be, they are 100%
willing to fix it.
A TNT2 or GeForce2 MX will be more than sufficient for stretching things
to fit them on screen. If you’re changing the textures often, you may
need to work a bit to optimize how you do this so it will not give you
unexpected bad performance, but these issues are easily fixed and do not
at all depend on your choice of video hardware.On Mon, Jun 17, 2002 at 07:49:00AM +0200, Michael Schnell wrote:
Just about anything newer (TNT and GeForce chips) will work with the
drivers you’ve downloaded though. TNT and TNT2 can almost be gotten free
nowadays they’re so old. GeForce2 is about the minimum useful card in
most people’s opinion. GeForce3 isn’t so bad for development IMO, and the
latest and greatest thing is the GeForce4.
As the only thing I need is 2D Strechblit of large images (no sophisticated
3D stuff) I suppose, any card with a good amount of ram should do. Do you
think a card with an vnidia chip is a good choice (regarding OpneGL support)
or should I search for something else ?
–
Joseph Carter glDisable (DX8_CRAP);
this is college course in formal logic
knghtbrd: i hate that shit, much prefer fuzzy logic
kev: fuzzy logic tickles.
knghtbrd: lol
knghtbrd: fuzzy logic is so cool, it models the world really well
I’ll take a look ! But what does this mean (“convert SDL_Surfaces to OpenGL
textures”) did you modify SDL or did you use SDL ? Anyway if this is the
way to go I will not hesitate to follow you.
Thanks a lot !
-Michael Schnell, Krefeld, Germany,
mailto:mschnell at bschnell.de
I mentioned converting SDL_Surfaces into OpenGL textures as an example
of one way to get data into an OpenGL texture. I was able to do this
without modifying anything. Since you will have to load in the data by
some custom means anyway, this doesn’t seem useful anymore, unless you
load into an SDL_Surface as an intermediate step.
Also, I saw your discussions with other people about stretching
operations, and the 3D-ness of OpenGL. OpenGL does easily support
stretching or shrinking of textures, and it also easily will do 2D-only
applications. I have done three of them myself. OpenGL makes a far far
faster 2D engine than SDL ever could, because even “2D” OpenGL is done
in hardware. I think that the reality of the situation is that all
OpenGL is really 2D, and 3D is the part that is faked, but whatever.
Though it seems granted that the Victory erazor uses the
Nvidia 128 Graphic
chip the Win98 open gl driver by Nvidia says: “no Nvidia
Graphic card found”
The NVidia drivers don’t support the RIVA 128 card. It is
too old. You must have at least a TNT card.
Paulo Pinto> -----Original Message-----
From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Sent: s?bado, 15 de Junho de 2002 23:06
To: sdl at libsdl.org
Subject: RE: [SDL] Open GL, Linux, Windows
Thanks I’ll take a look. Good News, as Elsa seems to be out
of busyness
(their site is down since at least a week) .
AFAIK they have been bought by Creative. I don’t know
if they intend to keep the brand.
Paulo Pinto> -----Original Message-----
From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Sent: s?bado, 15 de Junho de 2002 17:20
To: sdl at libsdl.org
Subject: RE: [SDL] Open GL, Linux, Windows
== Urspr?ngliche Mitteilung von sdl at libsdl.org am 16.06.02 23:26
I was refering to 2D SDL video, so OpenGL doesn’t
apply.
Now I’m a bit confused. Is Open GL strictly 3D ? As DirectX
does provide
stretchblit (hardware supported, if the hardware can do it),
I assumed
OpenGL would have same, too.
Yes. If you want to do 2D in OpenGL you must draw with Z=0 and
use textures. I might had that since version 8.0, the same
applies to DX.
Paulo Pinto> -----Original Message-----
From: sdl-admin at libsdl.org [mailto:sdl-admin at libsdl.org]On Behalf Of
Sent: segunda-feira, 17 de Junho de 2002 6:44
To: sdl at libsdl.org
Subject: RE: [SDL] Open GL, Linux, Windows
I mentioned converting SDL_Surfaces into OpenGL textures as an example
of one way to get data into an OpenGL texture. I was able to do this
without modifying anything. Since you will have to load in the data by
some custom means anyway, this doesn’t seem useful anymore, unless you
load into an SDL_Surface as an intermediate step.
Also, I saw your discussions with other people about stretching
operations, and the 3D-ness of OpenGL. OpenGL does easily support
stretching or shrinking of textures, and it also easily will do 2D-only
applications. I have done three of them myself. OpenGL makes a far far
faster 2D engine than SDL ever could, because even “2D” OpenGL is done
in hardware. I think that the reality of the situation is that all
OpenGL is really 2D, and 3D is the part that is faked, but whatever.
And at that point, Michael, you should ask yourself whether you really need
SDL. SDL is used to provide common video, audio and IO facilities accross
different platforms. You don’t use audio, you don’t use IO (keyboard, mouse
etc. are handled by delphi/kylix as far as I understood your idea), and
you’ll not use much of the video except for initializing it with GL context.
As most of your drawing stuff will be written in pure portable GL code, you
could use some preexisting OpenGL component for Delphi/Kylix. I’ve found for
example glWindow on http://www.cfxweb.net/~delphigl/downloads.htm It is
Windows centric as it uses wgl* routines to setup the window, but you could
easily replace them with appropriate glx code for linux (you will have to
recompile the component on different platforms anyway). Initialisation of GL
context would be the only non-portable piece of code that you would have to
write twice.
I think that embeding SDL in Delphi only to embed OpenGL in it is just
overhead. Embed OGL directly in your application.
Regards,
Jacek–
±------------------------------------+
|from: J.C.Wojdel |
| J.C.Wojdel at cs.tudelft.nl |
±------------------------------------+
Try David’s glSDL wrapper ( http://olofson.net/mixed.html ) to esentially wrap
your 2D-esque operations in OpenGL for you…
However, that won’t solve the transformation part, as it just implements the plain SDL 2D API.
It might provide busmaster DMA transfers from the software shadow surfaces (which would eliminate the CPU-over-AGP bottleneck), but not all OpenGL drivers support DMA, and AFAIK, very few, if any, provide hardware format conversion.
//David
.---------------------------------------
| David Olofson
| Programmer
17/06/02 0.50.51, Joseph Carter wrote:
NVIDIA does not make video cards, only graphics chips.
As someone noted, the Riva was their first, and they basically redid their
entire architecture right after that. It's a very old card, and the
drivers they distribute for literally every single chipset they've made
since don't work with it. You might be able to get 3D in Win32 if you can
find the old Riva 128 driver on the NV website, but you won't be able to
use it in Linux - no Linux drivers for that card exist.
Just about anything newer (TNT and GeForce chips) will work with the
drivers you've downloaded though. TNT and TNT2 can almost be gotten free
nowadays they're so old. GeForce2 is about the minimum useful card in
most people's opinion. GeForce3 isn't so bad for development IMO, and the
latest and greatest thing is the GeForce4.
The GF4 is total and absolute overkill unless you want the best possible
performance out of the next Id Software shooter game. And if you want
that, save your money since it won't be out for another year anyway - by
that time we'll probably be looking at the GeForce5, the Radeon 3 core,
and some bad-ass thing Matrox has been working on. =)
You can buy a new GeForce4 64MB DDR TVout for 180$, and a GeForce2 64MB SDR TVout for 120$. I’d suggest the
GeForce4. If you have much money to burn out, the best actual video card is the Radeon 8500 (240$+).
OpenGL does easily support
stretching or shrinking of textures
How? Can I do that with glSDL? I need to have a window showing an hw surface, then resize and antialias it
realtime using hardware accel while I grab one of its borders with the mouse. DirectX does it (I wrote an example
in VB6).>> and it also easily will do 2D-only applications. I have done three of them myself. OpenGL makes a far far
faster 2D engine than SDL ever could, because even “2D” OpenGL is done
in hardware. I think that the reality of the situation is that all
OpenGL is really 2D, and 3D is the part that is faked, but whatever.
== Urspr?ngliche Mitteilung von sdl at libsdl.org am 16.06.02 22:01
On all platforms except Amiga, hardware surfaces
are only availible in fullscreen mode.
The problem is
that if SDL did this, it would have to clip the image
to exclude any windows that may be on top of it…
Right. That is why Direct X has a function for that purpose that can be
called by the user (making the graphic window slow) or not (destroying GUI
windows that are on top of the graphic Window, thus making the app
"pseudo-fullscreen"). For my app I would (and have for the current version)
choose (2).
While this is certainly possible, I don’t even think
that even the Amiga port does this. If you feel
ambitious, I’m sure Sam would welcome a patch to
handle this case…
Do you think SDL/OpenGL prevents the use of hardware acceleration in
non-fullscreen mode, or can I enable it and live with the shortcomings ?
As I need to create an App that can be used in Windows and in Linux (that is
why I wanted to use SDL) I can’t use it. Bus as I need to do the stuff in
Pascal anyway, and as supposedly the only API I need is “stretchblt”, maybe
it can help me learn what I need to do to access OpenGL and I can recreate
the OpenGL access functions in Pascal for both environments. That would mean
dropping SDL (and you get rid of me ). Is this reasonable ?
You can easily use it in windows. Just use your own makefile/VC6 project.
