How well does SDL with OpenGL run on windows

My company would like to develop a cross platform graphics application. I am
investigating all technologies and I love SDL
with OpenGL as far as capabilities. My question is, if such an app were
developed,
what percentage of windows users, including XP, could I expect to run
the application
without problems, or having to download drivers, etc?

Thanks,
Matt

My company would like to develop a cross platform graphics application. I
am
investigating all technologies and I love SDL
with OpenGL as far as capabilities. My question is, if such an app were
developed,
what percentage of windows users, including XP, could I expect to run
the application
without problems, or having to download drivers, etc?

I’d guess “all of them”, presuming they have a working video card driver
that
functions with other OpenGL applications. SDL doesn’t require anything
extra
(well, beyond the SDL shared libraries).–
Chris Herborth (@Chris_Herborth)
Otaku no Sensei

Matthew Marcella wrote:

My company would like to develop a cross platform graphics
application. I am
investigating all technologies and I love SDL
with OpenGL as far as capabilities. My question is, if such an app
were developed,
what percentage of windows users, including XP, could I expect to run
the application
without problems, or having to download drivers, etc?

Thanks,
Matt

I have a 3dfx Voodo3 card and Windows XP.
Had to download 3rd party drivers, because the ones which came with
Windows totally messed up the texture coordinates everywhere everytime,
but now it works just fine.
The program will probably run correctly, if built correctly to check and
see that my card doesn’t support almost any exstension… :slight_smile:

I have 3ds max which uses OpenGL as it’s graphics driver, and I’m also
developing a game using SDL+OpenGL, so I can say that OpenGL works fine
here.

Hope this answers your question.

RK.

Well… AFAIK, the only computers with XP and OpenGL working “out of the box” would be those from builders that bother installing it after installing WinXP. (No idea how many that would be.) For the rest, it’s up to the users.

I would assume that most players that know the arenas of Unreal Tournament and/or Quake III like their own back yards will know what to do if you add “Hardware accelerated OpenGL” to the system requirements list.

I’m more worried about the ones that go “What’s a 3D accelerator?”…

However, everyone seems to be using “unified drivers” these days, so knowing the make of the video card is usually sufficient. All you need to do is download a file, run it, click “next” a few times and reboot. (I wish it was that easy with Linux… heh Then again, with most current distros it’ll Just Work™ on most cards.)

Perhaps describing how to get WinXP to reveal the make of the video card and/or the 3D chip would solve the problem for most users? (A list of common chips with URLs to driver providers would help as well.)

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Fri, 07/06/2002 10:12:17 , Matthew Marcella wrote:

My company would like to develop a cross platform graphics application. I am
investigating all technologies and I love SDL
with OpenGL as far as capabilities. My question is, if such an app were
developed,
what percentage of windows users, including XP, could I expect to run
the application
without problems, or having to download drivers, etc?

My company would like to develop a cross platform graphics application. I
am
investigating all technologies and I love SDL
with OpenGL as far as capabilities. My question is, if such an app were
developed,
what percentage of windows users, including XP, could I expect to run
the application
without problems, or having to download drivers, etc?

Thanks,
Matt

Matt,

Two bits of information for you:

  1. Mentioned thursday on this list, but repeated here in case you did not
    read that thread: there is a company called SciTech Software which sells a
    product called GLDirect. GLDirect is a Win32 library that provides a DirectX
    wrapper for OpenGL. This allows for a Win32 version of the cross platform
    application to detect if the host system has OpenGL installed, and if not
    use the GLDirect interface to emulate OpenGL through DirectX. Note that this
    solution requires that the host system has as least DirectX 6 installed.
    GLDirect is both a $20US end user product that gives that system OpenGL for
    any application as well as a licensible product that you can embed inside
    your application. You need to contact andrewb at scitechsoft.com about
    acquiring a license.

  2. I was in a discussion with the author of Poser a while back, a high
    quality cross platform 3D application. They licensed a rendering API from
    Viewpoint for their needs. That API (which I don’t recall the name for)
    provides a software renderer if necessary, but defers to any accelerated 3D
    rendering system should the host system have DirectX or OpenGL installed on
    their Win32 or MacOS based computer.

I am investigating both of these solutions for myself. I am yet to determine
if SDL would be able to interface with the GLDirect embedded in the
application solution. But I am confident (but I have not yet tested) that
the GLDirect installed at the OS level would be able to host SDL’s use of
OpenGL.

For the Viewpoint solution, I am waiting for a callback from the Poser
author about that product’s name and availability. (We used to be
officemates.) But since that solution is neither the OpenGL or DirectX API,
but a wrapper of their own, SDL would not be able to interface with it. For
that situation, just use SDL for everything but video. I have not tried
writing an SDL application that uses the other SDL subsystems except video,
but I believe that it is possible.

I hope this info helps.
-Blake

----- Original Message -----
From: mattmarcella@passur.com (Matthew Marcella)
Sent: Friday, June 07, 2002 7:12 AM
Subject: [SDL] How well does SDL with OpenGL run on windows

At 10:12 6/7/2002 -0400, you wrote:

My company would like to develop a cross platform graphics application. I am
investigating all technologies and I love SDL
with OpenGL as far as capabilities. My question is, if such an app were
developed,
what percentage of windows users, including XP, could I expect to run the
application
without problems, or having to download drivers, etc?

From experience, a very small percentage :frowning: If your Windows product
involves end-users
you have no control over (system-wise) choosing OpenGL is, unfortunately, a
bad choice.
Bad drivers (Or more often, no drivers at all and running in s/w mode) are
the biggest
problem. If your avg end-user sees your app running very slowly, he will
blame your
app. Most won’t know that they should try to install better drivers, or if
they do
they will have a hard time finding out WHERE to download them. (Does
GLSetup for NT
finally exist??) The majority of the users don’t even want to go through
’all’ that
trouble (Unless your game is made by a certain 2-lettered game company
probably :wink: )

Regards,
Dimitri

Friday, June 7, 2002, 2:47:34 PM, Blake wrote:

BS> 1) Mentioned thursday on this list, but repeated here in case you did not
BS> read that thread: there is a company called SciTech Software which sells a
BS> product called GLDirect. GLDirect is a Win32 library that provides a DirectX
BS> wrapper for OpenGL. This allows for a Win32 version of the cross platform
BS> application to detect if the host system has OpenGL installed, and if not
BS> use the GLDirect interface to emulate OpenGL through DirectX. Note that this
BS> solution requires that the host system has as least DirectX 6 installed.
BS> GLDirect is both a $20US end user product that gives that system OpenGL for
BS> any application as well as a licensible product that you can embed inside
BS> your application. You need to contact andrewb at scitechsoft.com about
BS> acquiring a license.

BS> I am investigating both of these solutions for myself. I am yet to determine
BS> if SDL would be able to interface with the GLDirect embedded in the
BS> application solution. But I am confident (but I have not yet tested) that
BS> the GLDirect installed at the OS level would be able to host SDL’s use of
BS> OpenGL.

We used GLDirect in our game MindRover to provide an alternative for
people who couldn’t use OpenGL. It does work, but it’s not quite
complete OpenGL – for example, GLScissor didn’t work properly (they
may have fixed that by now).

If you’re already dynamically loading OpenGL from a DLL, it’s very
easy to load GLDirect instead, and then it pretty much works. If
you’re statically linking, it’s more effort. But I don’t see why SDL
would have much problem using it, though you might have to make a
modification to some SDL code to test for GLDirect and load it.

You will pay a slight performance price (which may be acceptable)
and you’ll have to make sure your code works in both environments. We
had several places where we had to make changes to have things work
right, and in some cases we had to dynamically treat things
differently because there was no common correct behavior.

You’ll also have to shell out several thousand dollars (I don’t know
their current price) for the redistribution license or convince your
customers that they want to pay an extra $20 for the privilege of
using your product.

In our case, we used GLDirect because we had a finished product that
needed better video support, we had not encapsulated our OpenGL code
very well, and the cost of acquiring GLDirect was less than the cost
of writing a D3D version. If you’re writing new code, it may be more
cost effective – and it will certainly give you more control – to
plan to support both from the beginning.

 Kent-- 

Kent Quirk, CTO, CogniToy
@Kent_Quirk
http://www.cognitoy.com

— Romi Kuntsman wrote:

I have a 3dfx Voodo3 card and Windows XP.
Had to download 3rd party drivers, because the ones
which came with
Windows totally messed up the texture coordinates
everywhere everytime,
but now it works just fine.
The program will probably run correctly, if built
correctly to check and
see that my card doesn’t support almost any
exstension… :slight_smile:

I have 3ds max which uses OpenGL as it’s graphics
driver, and I’m also
developing a game using SDL+OpenGL, so I can say
that OpenGL works fine
here.

Hope this answers your question.

RK.

Hmm… this is mor of a continuation of another
thread, than the direction of this one, but I just had
a thought. First, there are pretty much two reasons
why Windows people ask about the D3D API:

  1. They are worried about OpenGL support on the Win32
    (especially WinXP) platform.

  2. they like to use the D3D API…

I think I just had a thought that might help. Mesa is
a (for all intents and purposes) full implementation
of the OpenGL API. I know Mesa is primarily known as
a software renderer, but (at least under Unix) it does
support several 3D cards. (I’m using Mesa to drive my
Voodoo Banshee.) Given that Mesa already supports
multiple backends (Software/Voodoo/Matrox), it seems
logical that it wouldn’t be that difficult to make it
able to support one more (D3D)… I’m sure this would
be no trivial task, but I’m sure it’s less daunting
than writing a complete OpenGL->D3D wrapper from
scratch.

As for the people that wish to code to the D3D API, I
see no reason that they can’t licence TransGaming’s
D3D->OpenGL wrapper…

Any suggestions?

-Loren__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

Hmm… this is mor of a continuation of another
thread, than the direction of this one, but I just had
a thought. First, there are pretty much two reasons
why Windows people ask about the D3D API:

  1. They are worried about OpenGL support on the Win32
    (especially WinXP) platform.

I’ve had enough of this FUD.

Vendors are AFRAID to drop OpenGL support. Microsoft weilds a big hammer,
but Id Software wields a bigger one in this area. There are millions of
people who play Id’s games and no vendor in their right mind will cut
themselves off from that many customers overnight.

Notice that chipsets such as those from Matrox, the Kyro II, and a host of
others have basically fallen by the wayside? Because their OpenGL support
was sub-par in comparison with the competition.

Microsoft has been promising an end to OpenGL support in Win32 for the
past four years now. But the chipset makers know that OpenGL is the one
hammer they’ve got, and some of them have been willing to whack Microsoft
with that hammer if they don’t at least play nice with DirectX. As for
software vendors, guess what? Companies are still making OpenGL games,
and many of them OpenGL-only games. A number of them now support also
DirectX, but warn that this is a slower path.

DirectX hurts SDL’s portability, but I wouldn’t mind seeing support for it
anyway, especially if SDL supported DX8 for its 2D functions natively.

  1. they like to use the D3D API…

I can’t speak for these people much. Direct3D’s API has improved, but
most of the people I know who prefer it do so for the standardization
rather than the API, which they agree still sucks it hard.

I think I just had a thought that might help. Mesa is
a (for all intents and purposes) full implementation
of the OpenGL API. I know Mesa is primarily known as
a software renderer, but (at least under Unix) it does
support several 3D cards. (I’m using Mesa to drive my
Voodoo Banshee.) Given that Mesa already supports
multiple backends (Software/Voodoo/Matrox), it seems
logical that it wouldn’t be that difficult to make it
able to support one more (D3D)… I’m sure this would
be no trivial task, but I’m sure it’s less daunting
than writing a complete OpenGL->D3D wrapper from
scratch.

I can’t say this is even a good project in the context of SDL, because
it’s completely outside of SDL’s purpose. That said, if someone makes
Mesa build as a D3D wrapper, I’d be quite interested in seeing it running
with SDL. In that case, it should be trivial or unnecessary to alter SDL
for the purpose.

As for the people that wish to code to the D3D API, I
see no reason that they can’t licence TransGaming’s
D3D->OpenGL wrapper…

I can, but I’m not at all fond of the company at the moment. That’s an
off-topic rant all its own though, so I’ll help preseve what remains of
Sam’s sanity and not bring it here. =)On Fri, Jun 07, 2002 at 01:22:14PM -0700, Loren Osborn wrote:


Joseph Carter Have chainsaw will travel

  • Mercury calmly removes XT-Ream’s arm…
  • Mercury then proceeds to beat XT-Ream with XT-Ream’s arm.
    wow, all this quake hacking is making Mercury violent here
  • mao is glad the quake forge project is in good hands

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020607/f719c81b/attachment.pgp

ATI and NVidia are also in the professional GFX board markets, where OpenGL is
the standard. So if MS doesn’t support OpenGL, then they make it harder for
the AutoCAD people, because DirectX is too messy for CAD makers. Expecially
after the release of OpenGL 2.0. All big GFX-chip manufacturers are actively
in the process of developing OpenGL 2.0, so they will most likely not drop
OpenGL support from their products, which means good for CAD and professional
design program sellers.

In my opinion OpenGL 2.0 will lift OpenGL usage, because it’s much simpler
than DirectX, and at least equal in power.

ANIWSUMMOn Friday 07 June 2002 23:56, Joseph Carter wrote:

Vendors are AFRAID to drop OpenGL support. Microsoft weilds a big hammer,
but Id Software wields a bigger one in this area. There are millions of
people who play Id’s games and no vendor in their right mind will cut
themselves off from that many customers overnight.

Notice that chipsets such as those from Matrox, the Kyro II, and a host of
others have basically fallen by the wayside? Because their OpenGL support
was sub-par in comparison with the competition.

Microsoft has been promising an end to OpenGL support in Win32 for the
past four years now. But the chipset makers know that OpenGL is the one
hammer they’ve got, and some of them have been willing to whack Microsoft
with that hammer if they don’t at least play nice with DirectX. As for
software vendors, guess what? Companies are still making OpenGL games,
and many of them OpenGL-only games. A number of them now support also
DirectX, but warn that this is a slower path.

ATI and NVidia are also in the professional GFX board markets, where
OpenGL is the standard. So if MS doesn’t support OpenGL, then they make
it harder for the AutoCAD people, because DirectX is too messy for CAD
makers. Expecially after the release of OpenGL 2.0. All big GFX-chip
manufacturers are actively in the process of developing OpenGL 2.0, so
they will most likely not drop OpenGL support from their products, which
means good for CAD and professional design program sellers.

This does not matter to Microsoft. Often these people use proprietary
systems anyway. It’s a niche market. It’s not like these people will
switch to Linux if Microsoft starts screwing with them, they’re locked in
to the established software base.

In my opinion OpenGL 2.0 will lift OpenGL usage, because it’s much
simpler than DirectX, and at least equal in power.

It’s also at least a year away from the first official driver support, and
two years away from widespread support in general-consumer class cards.

Most of the world does not have $500 for the latest card every six months.
While my GF2 MX400 is starting to look dated based on the games that will
be out later this year, it’s about what the common person has today. This
is hardly OpenGL 2.0 material.

That said, the OpenGL 2.0 API is looking to kick serious ass.On Sun, Jun 09, 2002 at 01:06:51AM +0300, Sami N??t?nen wrote:


Joseph Carter What’re you looking at?

im fcucking druk

  • Knghtbrd makes sure to log everything Crow- says tonight …
    heheh
    He said he’d marry me! damnit!!
    dude no way
    MrBump - he’s not THAT drunk
    Knghtbrd: I’m crushed :o)

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020607/8e227b64/attachment.pgp

[…]

You’ll also have to shell out several thousand dollars (I don’t know
their current price) for the redistribution license

That’s not an option for Free/Open Source games (unless possibly if you’re selling the game data under a more “traditional” licence), and probably not even for “hobby productions”, regardless of licence.

or convince your
customers that they want to pay an extra $20 for the privilege of
using your product.

I think it would be easier to have them download native OpenGL drivers for their card. (They have to figure out what make their card is, but it’s free…)

I’m sure people that don’t understand what “requires OpenGL” means in the first place, are very unlikely to pay for something they don’t even know what it’s for. “All the other games work without this! Are you affiliated with this company, or what’s all this about!?”

(Getting a support call/mail like that would have me thinking various things about Microsoft, that would certainly not look good written out.)

In our case, we used GLDirect because we had a finished product that
needed better video support, we had not encapsulated our OpenGL code
very well, and the cost of acquiring GLDirect was less than the cost
of writing a D3D version.

You need a company to even think along those lines - but it’s good to know that someone at least provides a solution for some developers and users. (Do they have to pay to Microsoft to avoid being attacked, BTW…? :wink:

[…]

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Fri, 7/06/2002 16:03:56 , Kent Quirk <kent_quirk at cognitoy.com> wrote:

Hmm… this is mor of a continuation of another
thread, than the direction of this one, but I just had
a thought. First, there are pretty much two reasons
why Windows people ask about the D3D API:

  1. They are worried about OpenGL support on the Win32
    (especially WinXP) platform.

I’ve had enough of this FUD.

Vendors are AFRAID to drop OpenGL support. Microsoft weilds a big hammer,
but Id Software wields a bigger one in this area.

I certainly hope you’re right.

There are millions of
people who play Id’s games and no vendor in their right mind will cut
themselves off from that many customers overnight.

So, why did Microsoft when they released WinXP…? (Sure, they can afford it, and very few are going to chose another OS just because of that, but anyway.)

Notice that chipsets such as those from Matrox, the Kyro II, and a host of
others have basically fallen by the wayside? Because their OpenGL support
was sub-par in comparison with the competition.

Good point…

Microsoft has been promising an end to OpenGL support in Win32 for the
past four years now. But the chipset makers know that OpenGL is the one
hammer they’ve got, and some of them have been willing to whack Microsoft
with that hammer if they don’t at least play nice with DirectX. As for
software vendors, guess what? Companies are still making OpenGL games,
and many of them OpenGL-only games. A number of them now support also
DirectX, but warn that this is a slower path.

DirectX hurts SDL’s portability, but I wouldn’t mind seeing support for it
anyway, especially if SDL supported DX8 for its 2D functions natively.

I would think DirectX is more likely to hurt the portability of SDL applications than the portability of SDL itself. :slight_smile:

SDL already supports DirectDraw (as well as verious other single platform APIs) for 2D, and ading glSDL style support for DirectGraphics would only improve things, as more users would get lightning fast 2D out-of-the-box with most SDL 2D applications. (In a way, you could say that “D3DSDL” would make glSDL like speed more widely available, and thus make games that require it more portable.)

Supporting Direct3D for anything but 2D is mostly an application side issue, but yes, that might hurt portability - if a significant number of SDL developers start using Direct3D instead of OpenGL. (Whether or not that would be SDL’s fault is a matter of how much you want to blame the SDL developers for the poor choices made be some of SDL’s users. :wink:

[…]

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Fri, 7/06/2002 13:56:16 , Joseph Carter wrote:

On Fri, Jun 07, 2002 at 01:22:14PM -0700, Loren Osborn wrote:

[…]
I’m sure people that don’t understand what “requires OpenGL” means in the first place, are very unlikely to
pay for something they don’t even know what it’s for.

That’s a BIG error. There are -thousands- of people who just want to
1)Buy the most expensive video card along with their new PC (maybe with daddy’s money). It’s not important what
it does, or what it’s needed for, or wich drivers are needed.
2)Buy the newest game on the market
3)Expect to see it running perfectly and immediately
4)If it doesn’t run, they don’t wonder why. It’s a su*kin’ game, so they just return it back to the shop and
buy another one. They will NEVER download a new driver, or look for a game patch, because sometimes they DON’T
EVEN KNOW WHAT A “DRIVER” IS (“is that the guy who drives my limousine?” :frowning: ). They just bought the computer
with all programs and drivers already installed. It’s unuseful to say that this approach to PCs has been set by
Micro$oft.

This is the sad reality: ff your game is not idiot-proof, you won’t sell much of it. That’s a problem that
consoles don’t have (they don’t even require installation).

CRV?ADER/KY

[…computer illiterate users…]

It’s unuseful to say that this approach to PCs has been set by
Micro$oft.

Right, but you can’t avoid the fact that Microsoft is asking for it.

Now, I actually think one of the few good things Microsoft has done is making computers available to more users. However, but I don’t really think that gives them the right to enforce a proprietary, non-portable and inferor solution upon everyone (developers as well as users) - especially not when it’s at the expense of an open, widely available de-facto and real standard.

Oh, and this does hurt users as well in the long run (regardless of what they think of Microsoft); this kind of strategy always did and always will.

This is the sad reality: ff your game is not idiot-proof, you won’t sell much of it. That’s a problem that
consoles don’t have (they don’t even require installation).

…and in most cases, you can’t even develop a game for a console at all, unless you’re officially “approved” by the maker of the console.

Is that the kind of world we want the PC market to become?

Anyway, I’ll try not to comment on the philosophical/political side of these things on the list any more. It’s counterproductive, and no matter what we say or do; we can’t force Microsoft anywhere. All we can do is try to find ways to deal with the current situation for our own projects, and hope that id Software and other giants in the gaming industry, and their fans, will manage to beat some sense into Microsoft eventually.

//David

.---------------------------------------
| David Olofson
| Programmer

david.olofson at reologica.se
Address:
REOLOGICA Instruments AB
Scheelev?gen 30
223 63 LUND
Sweden
---------------------------------------
Phone: 046-12 77 60
Fax: 046-12 50 57
Mobil:
E-mail: david.olofson at reologica.se
WWW: http://www.reologica.se

`-----> We Make Rheology RealOn Mon, 10/06/2002 18:27:37 , CRV?ADER/KY wrote: