DirectX 7?

Hiya,

NB> Not for 2D graphics it isn’t.

It is if you have a 3D accelerator. Otherwise I’d agree.

Neil.

Vesselin Peev wrote:

I wasn’t the first to use Windows 95 so this must be true. I must have used
a slightly later OEM release in early 1996.
As for the Trio64 I mentioned, I remember going to the driver properties
page and
reading that the driver is DirectX 1.0 compliant, but in reality Windows
must have run
DirectX 2.

I just went through some old boxes and threw away about 6 copies of the
original GDK disks for Windows 95.

First there was Windows 3.x which no one wrote games for so MS came out
with WinG which everyone tested and most companies and people ignored.
Then came Windows 95 and you still had to kill the GDI and put the
display in some tweaked mode (like ModeX) to do full screen games. So,
MS came out with the GDK and it sort of worked. The GDK begat DirectX
1.0 and the rest, as they say, is history.

	Bob Pendleton

P.S.

I went through some old boxes a few months ago and found about 6 copies
of the original GDK disk and the freeby distribution of NT. Chucked 'em
all.>

Oh, I feel somewhat nostalgic for these times… :wink: but not really. We are
much better
now with DX 9 and OpenGL 1.4… and SDL!

----- Original Message -----
From: “Travis Howell”
To:
Sent: Wednesday, September 25, 2002 11:05 AM
Subject: Re: [SDL] DirectX 7?

Vesselin Peev wrote:

You are almost right about DirectX versions of different Windows-es.
But Windows 95 sure had DirectX 1.0.

No the original version of Windows 95 didn’t have DirectX included but
Windows 95 OEM Service Release 2 included DirectX 2.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


±-----------------------------------+

No, thats wrong. 3D accelerator or not, its slower, and often not smart for
other reasons. DirectX 8 has serious issues (cant run on 486s or Pentiums or
K6s), DirectDraw is basically shot, and Win95 users cant install it (Microsoft,
due to not supporting it, added in a check to prevent that from happening
(money grubbing bastards))

Because of this, DX8 is not suitable for 2D games. And thusly, its not suitable
for SDL 2.0 as well. DX7 is, but really, we probably could get away with doing
something like build multiple drivers (one that does DX7 and one that does DX3,
so we dont have to kick out NT4 users (Unless Sam puts his foot down and says
NT4 is dead)) out of one set of code, but have it enable DX7 specific functions
when building the DX7 portion (this works due to the fact that DX is massivly
backwards compat)

So, yeah, if you wanna basically screw everyone that has an old machine (but
one that is perfect for playing 2D games) and everyone that doesnt run
Win98/ME or Win2k/XP, yeah, go ahead and use DX8. But I specifically Sam wishes
to piss off around 2/5ths of the SDL userbase.On 25-Sep-2002, Neil Griffiths wrote:

Hiya,

NB> Not for 2D graphics it isn’t.

It is if you have a 3D accelerator. Otherwise I’d agree.

Neil.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

there was no DirectX 1.0, it started at 2, and no, win95 nor win95a came with
DX, osr2.x came with 2 or 3 (cant remember which)

DirectX 1.0 was called WinG and was for win3.1On 25-Sep-2002, Vesselin Peev wrote:

You are almost right about DirectX versions of different Windows-es.
But Windows 95 sure had DirectX 1.0.
I remember running 2D accelerated games with a S3 Trio64 with installing
only a small
video driver that came with the card that had nothing to do with the DirectX
runtime itself.
Oh yes, and the Windows 95 setup sure advertised that the new OS "revved up"
game
experience.

I think that Windows XP came with DirectX 8.1a, not DirectX 8 – not the
8.1b that comes with Service Pack 1.

----- Original Message -----
From: “Neil Bradley”
To:
Sent: Wednesday, September 25, 2002 7:36 AM
Subject: Re: [SDL] DirectX 7?

SDL 2.0 will probably use DirectX 8 or newer and fall back to GDI if
DirectX 8 isn’t available. This isn’t set in stone yet though.
What versions of DirectX do the different versions of Windows ship with?

From memory:

NT 4.0: DirectX 3
’95 : None
’98 : DirectX 5
’98SE : DirectX 6
2K : DirectX 7
XP : DirectX 8

At least for 2D work, DX 5 is sufficient enough.

–>Neil



Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

[DirectX 8 not suitable for SDL 2.0]

So what’s the big deal? If you want to write a (2D) game that runs
on low-end and older machines, use the SDL 1.x branch. No one is
forcing you to use SDL 2.x. (Unless, of course, having 2.x means
that the 1.x branch is no longer maintained with bug fixes and
such.)

Now, I know next to nothing about SDL 2.0, but I was under the
impression that it was going to be a total rewrite. A kick-ass game
toolkit that takes advantage of the latest and greatest features
available. If that is truly the case, then obviously it should use
DirectX 8. But I am not Sam, so I may be mistaken about this.–
Matthijs Hollemans
All Your Software
www.allyoursoftware.com

No, thats wrong. 3D accelerator or not, its slower, and often not smart for
other reasons. DirectX 8 has serious issues (cant run on 486s or Pentiums or
K6s), DirectDraw is basically shot, and Win95 users cant install it (Microsoft,
due to not supporting it, added in a check to prevent that from happening
(money grubbing bastards))

By Pentium does this mean Pentium I? They’re still around.

I can confirm that my Windows OS is Win95. It was still supplied on new
PCs as recently as summer 1998, and thus is still in common use. Thus I
would add my vote for Directx8 to be avoided.

Nick

So what’s the big deal? If you want to write a (2D) game that runs
on low-end and older machines, use the SDL 1.x branch. No one is
forcing you to use SDL 2.x. (Unless, of course, having 2.x means
that the 1.x branch is no longer maintained with bug fixes and
such.)

But it means you can’t take advantage of any new features added to the
library. Proprietary software makers often fall into the trap of not
supporting any PC or OS more than 2 or 3 years old, forcing the user into
unnecessary costly and wasteful upgrades. I thought the whole free
software ethic was to be as inclusive as possible?

Nick

Hi,

PM> No, thats wrong. 3D accelerator or not, its slower, and often not smart for
PM> other reasons. DirectX 8 has serious issues (cant run on 486s or Pentiums or
PM> K6s), DirectDraw is basically shot, and Win95 users cant install it (Microsoft,
PM> due to not supporting it, added in a check to prevent that from happening
PM> (money grubbing bastards))

It renders to textures, that’s how it does 2D. I know it’s faster,
I’ve seen it. I also have DirectX 8 running fine on my laptop, which
happens to be a Pentium, so what’s the deal?

So you haven’t got DirectDraw? Big deal. You do exactly what GL_SDL is
doing. We can already guess that SDL will render to OpenGL, there is
no issue at all with doing the same with Direct3D. Look, here’s an
example of how you can do 2D with DirectX 8:

http://www.flipcode.com/tutorials/tut_dx8adv2d.shtml

Windows '95 is 7 years old right now, I don’t see that as being a
problem. Have you left your OS running as-is for 7 years then get
pissed off when the latest software doesn’t work on it?

PM> Because of this, DX8 is not suitable for 2D games. And thusly, its not suitable
PM> for SDL 2.0 as well. DX7 is, but really, we probably could get away with doing
PM> something like build multiple drivers (one that does DX7 and one that does DX3,
PM> so we dont have to kick out NT4 users (Unless Sam puts his foot down and says
PM> NT4 is dead)) out of one set of code, but have it enable DX7 specific functions
PM> when building the DX7 portion (this works due to the fact that DX is massivly
PM> backwards compat)

And, I guess, OpenGL is also not suitable for 2D games? Sure.

PM> So, yeah, if you wanna basically screw everyone that has an old machine (but
PM> one that is perfect for playing 2D games) and everyone that doesnt run
PM> Win98/ME or Win2k/XP, yeah, go ahead and use DX8. But I specifically Sam wishes
PM> to piss off around 2/5ths of the SDL userbase.

I’d love to see where you get your numbers from. People who play games
will nearly always have fairly modern hardware. Those who don’t won’t
care that SDL will be dropping back to GDI which Sam has already said
SDL will be doing.

2/5ths of the SDL userbase are not going to be using Windows '95. Most
of the SDL userbase will be made up of Linux users and programmers.
The majority of the rest will be made up of emulation fans and games
players. All of these will have reasonably up-to-date hardware and
software. That’s pure logic - and I’d love to see you back up your
claims.

Basically, you should take advantage of current technology, not stick
to the old days because you know how to use DirectDraw. There’s a good
reason for rendering to textures. It’s fast on pretty much every piece
of graphics hardware since 1996.

Get with the times. And for people not with the times, they have GDI.

Neil.

PS It’s interesting to see how in your next e-mail you say that
anything under 640x480 isn’t acceptable. How are you planning to do
that at a reasonable framerate on the 486, one of the reasons you
suggest we shouldn’t use DX8 for? You’re inconsistant. And no, pixel
doubling from 320x240 isn’t a great solution. You just have bigger
pixels, it doesn’t look better. It still looks blocky and you have no
more effective screen area, the main reason for WANTING to use a
higher resolution.

Hi,

NW> By Pentium does this mean Pentium I? They’re still around.

Yes - he’s just wrong about it not working. I’m not the only person on
this list to say that DirectX8 is working fine on a Pentium either.

NW> I can confirm that my Windows OS is Win95. It was still supplied on new
NW> PCs as recently as summer 1998, and thus is still in common use. Thus I
NW> would add my vote for Directx8 to be avoided.

Because you wouldn’t want to use OpenGL instead or even drop back to
GDI? gasp

You’re very much in the minority of games players and programmers if
you still use Windows '95. It’s an unsupported OS and, after 7 years, I
don’t have issue with that. But no way should we not take advantage of
current technologies which can make things a WHOLE lot faster just
because you haven’t upgraded to something newer.

I’m making the assumption that OpenGL will be a rendering target for
2D in SDL, but I think that’s a fairly safe assumption to make because
of David’s excellent work on GL_SDL. Therefore it makes absolute sense
to use DirectX8 as another target, keeping up with the times (and
taking advantage of enhancements in video card drivers). And for those
who can’t use DirectX8 or OpenGL as 2D rendering targets, there’s GDI.

Programmers should look to the future and embrace new technologies if
there are benefits. There are, embrace them - don’t cling on to the
past. That’s the problem with the whole x86 architecture, but hey…
that’s going off-topic. :slight_smile:

Neil.

[DirectX 8 not suitable for SDL 2.0]

So what’s the big deal? If you want to write a (2D) game that runs
on low-end and older machines, use the SDL 1.x branch. No one is
forcing you to use SDL 2.x.

That sounds like a bad idea to me. As soon as the new version is
reasonably stable, we should use that. Keeping an old tree alive is
basically the same thing as forking the project, and the community does
not have unlimited resources.

I think the time would be much better spent implementing support for
more than one DX version, if there’s actually a need.

(Unless, of course, having 2.x means
that the 1.x branch is no longer maintained with bug fixes and
such.)

Well, that level of maintenace might be realistic, but what happens
when people start asking for 2.x to be backported into in 1.x, since they
don’t want to use 2.x? heh

Now, I know next to nothing about SDL 2.0, but I was under the
impression that it was going to be a total rewrite. A kick-ass game
toolkit that takes advantage of the latest and greatest features
available.

The latest and greatest portable features, unless the design goals
differ from those of 1.x.

If that is truly the case, then obviously it should use
DirectX 8. But I am not Sam, so I may be mistaken about this.

The way I see it, a DirectX 8 backend should be seen as Win32-only
alternative to glSDL, not an alternative to the GDI and DX3 backends. DX8
"2D" is 2D-on-3D using DirectGraphics instead of OpenGL. These backends
(glSDL and “D3DSDL”) are in no way alternatives to DirectDraw and other
pure 2D backends, until everyone has working 3D acceleration. The
features one would reasonably expect from a DX8/OpenGL wrapper cannot be
emulated in s/w with seriously usable performance, especially not without
insane amounts of work.

IMHO, having SDL 2.x require DX8 is not very different from coding
applications directly for, and only for OpenGL. Even if SDL 2.x provided
software emulation of any featuers that normally require 3D acceleration,
it wouldn’t be much better than just using OpenGL and some s/w OpenGL
implementation when there’s no h/w acceleration. Then why bother with a
new graphics API in the first place, rather than just making SDL 2.x a
glorified portable OpenGL utility library?

I’d certainly prefer to have the extremely portable “real” 2D support
left around for applications where it’s sufficient, and just have DX8 and
OpenGL support through backends similar to glSDL as a transparent option
for users that have DX8 and/or OpenGL.

As soon as we start thinking about advanced transformation and blending
features and other stuff that require 3D acceleration for usable
performance, we’re bound to end up with something that’s too limited for
serious use, or complex enough that trying to implement a good
OpenGL-over-DX8 wrapper seems like a better idea.

Maybe we’ll just never get around this “need to support both D3D and
OpenGL” obstacle until one of the APIs is dead and forgotten. I don’t
think SDL 2.x can solve that, but then again, I might be mistaken on what
kind of level the API will be on. (If it’s aware of “tiled layers”,
sub-pixel accuracy and that kind of stuff, then maybe it could handle
serious 2D-on-3D gaming…)

//David Olofson - Programmer, Composer, Open Source Advocate

.- Coming soon from VaporWare Inc…------------------------.
| The Return of Audiality! Real, working software. Really! |
| Real time and off-line synthesis, scripting, MIDI, LGPL…|
-----------------------------------> (Public Release RSN) -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture |----------------------------> http://www.linuxdj.com/maia -’
http://olofson.nethttp://www.reologica.se —On Thursday 26 September 2002 13:43, Matthijs Hollemans wrote:

SDL 1.x might not be maintained. Or, in kernel terms, it will be taken out of
stable, and put into maintaince. Which means, to get any of the newer stuff,
you have to use SDL 2. This especially makes sense if you have a game where
everything can be turned off, and ran on an ancient pentium, but everything
turned on needs some 300mhz 686. Loosing backwards compat isnt exactly bad, but
loosing a large chunk of target platforms is.On 26-Sep-2002, Matthijs Hollemans wrote:

[DirectX 8 not suitable for SDL 2.0]

So what’s the big deal? If you want to write a (2D) game that runs
on low-end and older machines, use the SDL 1.x branch. No one is
forcing you to use SDL 2.x. (Unless, of course, having 2.x means
that the 1.x branch is no longer maintained with bug fixes and
such.)

Now, I know next to nothing about SDL 2.0, but I was under the
impression that it was going to be a total rewrite. A kick-ass game
toolkit that takes advantage of the latest and greatest features
available. If that is truly the case, then obviously it should use
DirectX 8. But I am not Sam, so I may be mistaken about this.

Matthijs Hollemans
All Your Software
www.allyoursoftware.com


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

Yeah, I ment Pentium I. (Though, technically, its two different processor
generations, 54 which was without mmx, and 55c, which had mmx) BTW, someone
told me that ppros might not be able to use DX8 either.On 26-Sep-2002, Nick Whitelegg wrote:

No, thats wrong. 3D accelerator or not, its slower, and often not smart for
other reasons. DirectX 8 has serious issues (cant run on 486s or Pentiums or
K6s), DirectDraw is basically shot, and Win95 users cant install it (Microsoft,
due to not supporting it, added in a check to prevent that from happening
(money grubbing bastards))

By Pentium does this mean Pentium I? They’re still around.

I can confirm that my Windows OS is Win95. It was still supplied on new
PCs as recently as summer 1998, and thus is still in common use. Thus I
would add my vote for Directx8 to be avoided.

Nick


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

Yeah, thats what Im trying to get at. Linux (being, really, the main Free
Software OS) is still realistically ran on 486s and Pentium 1s. Though this
is a Windows argument, Linux proves a point here: Hardware that is old doesnt
die. As much as microsoftized developers try to push for new hardware, most
users cant afford it, or want to bother with it. (Windows is far from copying
choice files from /etc, and cloning your /home dir)On 26-Sep-2002, Nick Whitelegg wrote:

So what’s the big deal? If you want to write a (2D) game that runs
on low-end and older machines, use the SDL 1.x branch. No one is
forcing you to use SDL 2.x. (Unless, of course, having 2.x means
that the 1.x branch is no longer maintained with bug fixes and
such.)

But it means you can’t take advantage of any new features added to the
library. Proprietary software makers often fall into the trap of not
supporting any PC or OS more than 2 or 3 years old, forcing the user into
unnecessary costly and wasteful upgrades. I thought the whole free
software ethic was to be as inclusive as possible?

Nick


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

[…]

I’d love to see where you get your numbers from. People who play games
will nearly always have fairly modern hardware. Those who don’t won’t
care that SDL will be dropping back to GDI which Sam has already said
SDL will be doing.

It might be better if it dropped back to DX3 - but then again, anyone
that actually cares could just contribute a backend for it, if it’s that
important…

2/5ths of the SDL userbase are not going to be using Windows '95. Most
of the SDL userbase will be made up of Linux users and programmers.

Good point. And we either have prefectly fine OpenGL support, or
basically no acceleration at all. Same situation, really; DX8 or GDI -
OpenGL or Xlib/fbdev/.

The majority of the rest will be made up of emulation fans and games
players. All of these will have reasonably up-to-date hardware and
software. That’s pure logic - and I’d love to see you back up your
claims.

Basically, you should take advantage of current technology, not stick
to the old days because you know how to use DirectDraw. There’s a good
reason for rendering to textures. It’s fast on pretty much every piece
of graphics hardware since 1996.

Get with the times. And for people not with the times, they have GDI.

Right. There’s only one thing I’m worried about: How do you take
advantage of the power of OpenGL and DX8 while still maintaining the same
API for 2D APIs and software rendering?

The obvious way is the way of the current glSDL; just don’t provide
anything new but raw speed. glSDL even deliberately “breaks” surface
alpha on RGBA textures the same way SDL does, just to be compatible.

The other way is to figure out a reasonable feature set for “advanced
2D”, and make sure that there’s a software fallback for every feature
added. Some things (like sub-pixel accurate blitting) could simply be
ignored when there’s no acceleration, but transformations and blending
effects aren’t that easy to fake…

//David Olofson - Programmer, Composer, Open Source Advocate

.- Coming soon from VaporWare Inc…------------------------.
| The Return of Audiality! Real, working software. Really! |
| Real time and off-line synthesis, scripting, MIDI, LGPL…|
-----------------------------------> (Public Release RSN) -' .- M A I A -------------------------------------------------. | The Multimedia Application Integration Architecture |----------------------------> http://www.linuxdj.com/maia -’
http://olofson.nethttp://www.reologica.se —On Thursday 26 September 2002 13:23, Neil Griffiths wrote:

Its not faster. And it never will be faster. Well, maybe with Nvidia who really
doesnt put much time into their 2D stuff. 2D is slower done with textures
because you have to push 4 (or so) textures 30+ times a second. AGP wasnt ment
to handle that. Try using OpenGL mode with ZSNES. Its slow as hell. It was a
bad idea what Microsoft did, and I dont think anyone realizes that. You
obviously dont.

Now, if you wanna turn around and use OpenGL to do 2D stuff, but each sprite
is a texture, and run things that way, thats something totally different, and
that is not how DirectDraw is now emulated with Direct3D.

Hi,

PM> No, thats wrong. 3D accelerator or not, its slower, and often not smart for
PM> other reasons. DirectX 8 has serious issues (cant run on 486s or Pentiums or
PM> K6s), DirectDraw is basically shot, and Win95 users cant install it (Microsoft,
PM> due to not supporting it, added in a check to prevent that from happening
PM> (money grubbing bastards))

It renders to textures, that’s how it does 2D. I know it’s faster,
I’ve seen it. I also have DirectX 8 running fine on my laptop, which
happens to be a Pentium, so what’s the deal?

So you haven’t got DirectDraw? Big deal. You do exactly what GL_SDL is
doing. We can already guess that SDL will render to OpenGL, there is
no issue at all with doing the same with Direct3D. Look, here’s an
example of how you can do 2D with DirectX 8:

http://www.flipcode.com/tutorials/tut_dx8adv2d.shtml

Windows '95 is 7 years old right now, I don’t see that as being a
problem. Have you left your OS running as-is for 7 years then get
pissed off when the latest software doesn’t work on it?

PM> Because of this, DX8 is not suitable for 2D games. And thusly, its not suitable
PM> for SDL 2.0 as well. DX7 is, but really, we probably could get away with doing
PM> something like build multiple drivers (one that does DX7 and one that does DX3,
PM> so we dont have to kick out NT4 users (Unless Sam puts his foot down and says
PM> NT4 is dead)) out of one set of code, but have it enable DX7 specific functions
PM> when building the DX7 portion (this works due to the fact that DX is massivly
PM> backwards compat)

And, I guess, OpenGL is also not suitable for 2D games? Sure.

PM> So, yeah, if you wanna basically screw everyone that has an old machine (but
PM> one that is perfect for playing 2D games) and everyone that doesnt run
PM> Win98/ME or Win2k/XP, yeah, go ahead and use DX8. But I specifically Sam wishes
PM> to piss off around 2/5ths of the SDL userbase.

I’d love to see where you get your numbers from. People who play games
will nearly always have fairly modern hardware. Those who don’t won’t
care that SDL will be dropping back to GDI which Sam has already said
SDL will be doing.

2/5ths of the SDL userbase are not going to be using Windows '95. Most
of the SDL userbase will be made up of Linux users and programmers.
The majority of the rest will be made up of emulation fans and games
players. All of these will have reasonably up-to-date hardware and
software. That’s pure logic - and I’d love to see you back up your
claims.

Basically, you should take advantage of current technology, not stick
to the old days because you know how to use DirectDraw. There’s a good
reason for rendering to textures. It’s fast on pretty much every piece
of graphics hardware since 1996.

Get with the times. And for people not with the times, they have GDI.

Neil.

PS It’s interesting to see how in your next e-mail you say that
anything under 640x480 isn’t acceptable. How are you planning to do
that at a reasonable framerate on the 486, one of the reasons you
suggest we shouldn’t use DX8 for? You’re inconsistant. And no, pixel
doubling from 320x240 isn’t a great solution. You just have bigger
pixels, it doesn’t look better. It still looks blocky and you have no
more effective screen area, the main reason for WANTING to use a
higher resolution.

Read next time, I said this was a problem with X. Pixel doubling is a nice way
to fake 320x240. Its cheap cpu wise, and looks the same as 320x240. 486s can
do pixel doubling resonably well with little to no noticable fps loss.And also,
New Gamers run 3D games. 2D is basically dead. So saying anything about new
hardware is kinda stupid if you limit yourself to 2D games.On 26-Sep-2002, Neil Griffiths wrote:


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

Its not faster. And it never will be faster. Well, maybe with Nvidia who
really doesnt put much time into their 2D stuff. 2D is slower done with
textures because you have to push 4 (or so) textures 30+ times a second.
^^^^^^^^^^^^^^
Why is it so? Multi-texture or am I missing something important?

AGP wasnt ment to handle that. Try using OpenGL mode with ZSNES. Its slow
as hell. It was a bad idea what Microsoft did, and I dont think anyone
realizes that. You obviously dont.

In my own experiment, the test/testsprite.c runs 4x faster when I
ported it over to OpenGL and use texture as surfaces. Or maybe I
am just another guy use Nvidia cards??

Regards,
.paul.On Thu, Sep 26, 2002 at 08:42:11AM -0400, Patrick McFarland wrote:

Its not faster. And it never will be faster. Well, maybe with Nvidia who
really doesnt put much time into their 2D stuff. 2D is slower done with
textures because you have to push 4 (or so) textures 30+ times a second.
^^^^^^^^^^^^^^
Why is it so? Multi-texture or am I missing something important?

depends on the size of the surface, and the max size of the texture the
card can support. Obviously you cant fit 640x480 on a 256x256 texture, so
you have to split it up.

AGP wasnt ment to handle that. Try using OpenGL mode with ZSNES. Its slow
as hell. It was a bad idea what Microsoft did, and I dont think anyone
realizes that. You obviously dont.

In my own experiment, the test/testsprite.c runs 4x faster when I
ported it over to OpenGL and use texture as surfaces. Or maybe I
am just another guy use Nvidia cards??

No, what Im talking about is make the whole final surface first, THEN upload
it to opengl textures. thats what directdraw does with d3d.On 26-Sep-2002, paul at theV.net wrote:

On Thu, Sep 26, 2002 at 08:42:11AM -0400, Patrick McFarland wrote:

Regards,
.paul.


SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl


Patrick “Diablo-D3” McFarland || unknown at panax.com
"Computer games don’t affect kids; I mean if Pac-Man affected us as kids, we’d
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." --Kristian Wilson, Nintendo, Inc, 1989

Hi,

PM> Yeah, I ment Pentium I. (Though, technically, its two different processor
PM> generations, 54 which was without mmx, and 55c, which had mmx) BTW, someone
PM> told me that ppros might not be able to use DX8 either.

FYI, DirectX works fine on my P-300MMX - the CPU in my laptop. And
yes, I said 300 - and yes, it’s a Pentium MMX.

I really wouldn’t believe what “someone” told you, test it yourself. I
have, this is why I can vouch for DirectX working on my P5.

PM> Yeah, thats what Im trying to get at. Linux (being, really, the main Free
PM> Software OS) is still realistically ran on 486s and Pentium 1s. Though this
PM> is a Windows argument, Linux proves a point here: Hardware that is old doesnt
PM> die. As much as microsoftized developers try to push for new hardware, most
PM> users cant afford it, or want to bother with it. (Windows is far from copying
PM> choice files from /etc, and cloning your /home dir)

Need I mention that Linux is a server OS, not a desktop OS? It’s not
designed for games - thus the difficulties that many people have
programming games for Linux and why DGA is coming out etc etc. Of
course that requires privileged access which goes against the whole
Linux philosophy of abstracting the hardware from the user - because
Linux is meant to be a server-based OS. So, of course, it works on 486s
and Pentiums. What does it really need to do other than, at the most
basic of levels, handle files and connections? It doesn’t require
high-end hardware unless it’s a high-load server and even then
wouldn’t require the latest graphics card.

The FSF is not about making things work on old hardware. It’s about
providing good software for free. There’s no clause anywhere that says
"It must run on a 486sx-25" or anything.

What I’m against is people, like yourself, blindly saying “No, we
can’t have DirectX8 support in SDL!” when there’s no reason for it. If
there was a DirectX7 target too, that would be absolutely fine by me,
but that’s not what you’re arguing for, you’re arguing that DirectX8
isn’t suitable. You’re wrong. It is. I’m all for having a DirectX7
target too if that would make you happy - I have no problem with that.
I just don’t follow your arguments that you’ve made like people would
have to download DirectX8 (they’d have to do that with 7 too…) and
so on. :slight_smile:

But just because old hardware doesn’t die doesn’t mean that we should
limit SDL so it’ll work on it. We have to look to the future and if we
can provide a route for old hardware to work, that’s great - but that
is not how it should be designed.

And I’m also against your comment about "microsoftized developers"
pushing for new hardware. It’s nothing to do with Microsoft,
programmers are becoming lazier and lazier because machines are so
powerful and have so much memory now that it’s rare they need to
optimise. Part of the fault could be attributed to MS, maybe, but most
of the blame would have to be laid on the publishers who push and push
for software to be released ASAP - even when the developers know the
product isn’t ready. This even happens with console games, but what
would normally happen there is they’d have feature reduction.

Some blame can also be given to Universities/Colleges - I don’t know
of many who teach optimisation techniques. These days it’s becoming a
bit of a black art, known only by a select few. :-/

Neil.

Hi,

DO> It might be better if it dropped back to DX3 - but then again, anyone
DO> that actually cares could just contribute a backend for it, if it’s that
DO> important…

Sure, for certain. I’m not against having a DirectX7 backend either -
I’m just against people saying "No! Not DirectX8! It wouldn’t work!"
when it would.

DO> Good point. And we either have prefectly fine OpenGL support, or
DO> basically no acceleration at all. Same situation, really; DX8 or GDI -
DO> OpenGL or Xlib/fbdev/.

Absolutely, that’s my point. :slight_smile:

DO> Right. There’s only one thing I’m worried about: How do you take
DO> advantage of the power of OpenGL and DX8 while still maintaining the same
DO> API for 2D APIs and software rendering?

Now THAT is an issue for discussion, I agree. But then, at a most
basic level, what 2D graphics could we do using OpenGL and DX8 that we
couldn’t support using DirectDraw or fbdev? I mean, so long as we keep
it simple so that we’re still providing a surface, the same palette
information and so on, I don’t see a problem. As long as externally
it’s the same…

Of course, you would know more about this than me because of your work
on glSDL. :slight_smile:

DO> The obvious way is the way of the current glSDL; just don’t provide
DO> anything new but raw speed. glSDL even deliberately “breaks” surface
DO> alpha on RGBA textures the same way SDL does, just to be compatible.

Then why couldn’t we change way the alpha works so that we get the
speed advantages in OpenGL/DX8 and it still works in software?

DO> The other way is to figure out a reasonable feature set for “advanced
DO> 2D”, and make sure that there’s a software fallback for every feature
DO> added. Some things (like sub-pixel accurate blitting) could simply be
DO> ignored when there’s no acceleration, but transformations and blending
DO> effects aren’t that easy to fake…

Yes, I see where you’re coming from. Well, as for blending, are you
just talking alpha here? That’s not so hard to fake - but it is, of
course, slow. And I guess by transformations you mean rotations and
perhaps even skewing? If so, is this something that we’d want to
provide from a Simple DirectMedia Layer?

I guess it would be best to come up with a wish-list of the features that
people would like to see supported by SDL 2.0 and design an API based
around that and see if there would be any obvious flaws or benefits…

Neil.

depends on the size of the surface, and the max size of the texture the
card can support. Obviously you cant fit 640x480 on a 256x256 texture, so
you have to split it up.

I see what you mean now. But if textures are properly managed, i.e.,
multiple surfaces may reside in one square texture, and if vertice
are sorted according to textures, I see no big issue in a real
world 2D game of doing it with GL or D3D backend. After all, it is
not only just the background that gets painted on the screen. If it
is a scrolling background that needs update every frame, chances are
it is using tiles.

AGP wasnt ment to handle that. Try using OpenGL mode with ZSNES. Its slow
as hell. It was a bad idea what Microsoft did, and I dont think anyone
realizes that. You obviously dont.

In my own experiment, the test/testsprite.c runs 4x faster when I
ported it over to OpenGL and use texture as surfaces. Or maybe I
am just another guy use Nvidia cards??

No, what Im talking about is make the whole final surface first, THEN upload
it to opengl textures. thats what directdraw does with d3d.

Oh, really? That is probably something we want to avoid :wink:

Regards,
.paul.On Thu, Sep 26, 2002 at 09:11:59AM -0400, Patrick McFarland wrote: