DirectX 7?

[Patrick_McFarland]

Hmm, yeah, I kinda wish sdl 2.0 had everything in software so in the long run
all of this wouldnt matter. Exploit what you can with hardware APIs, if you
cant, fall back to an internal software routine.On 26-Sep-2002, David Olofson wrote:

On Thursday 26 September 2002 13:23, Neil Griffiths wrote:
[…]

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.net — http://www.reologica.se —

---

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

[Kylotan]

Neil Griffiths wrote:

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.

Let’s not lose sight of the fact that SDL is used for more than games.
And there are many simple games which will run too slowly on GDI. This
is why I would prefer to see a DX5 fallback kept in addition to the
latest DX47 or whatever version is around at the time for the more
up-to-date programs. If 3 back-ends is too much work in terms of
maintenance, personally I’d rather see the GDI option dropped than the
DX5 one. But I know many others would disagree.

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.

As word of mouth spreads, SDL should be reaching new audiences. Should
it be designed to please the current userbase and stay in its niche, or
perhaps to broaden the potential userbase by being more widely
applicable? For example, with DirectDraw now effectively gone from
DirectX, lots of us on GameDev.net are now promoting SDL as a more
usable alternative for simple 2D games, increasing its popularity among
Windows programmers and therefore users. So this choice is something to
think about.–
Kylotan
http://pages.eidosnet.co.uk/kylotan

[David_Olofson]

[…]

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?

Scaling, rotation, sub-pixel accurate blitting; that sort of things. Of
course, this is all possible to implement in software, but some of it
is not at all possible to make fast enough for real time graphics, since
there are simply too many and too expensive operation required for each
pixel.

Sure, you can cheat, but in what way? Just like with simplified s/w
OpenGL libs, some shortcuts will more or less break some applications, so
you end up needing a custom s/w engine for any serious work.

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…

Yeah, that’s the idea with glSDL - and sure, it could easilly be extended
with basic transformations, and advanced blending, which could also be
implemented in s/w. Sub-pixel accurate coordinates could just be
truncated, and you don’t really have to implement high quality
interpolation for the transformations.

Also, I think we can draw the line somewhere below 3D transformations,
since if you need those, you’re probably using the wrong tool. Simple
dx,dy; ddx,ddy style “fake perspective correction” would be nice, and
doesn’t cost much more than plain scaling.

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

Possibly, but that was coding behind a small existing API than deciding
at what point you should tell people to use OpenGL.

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?

It would require premultiplied alpha - which is indeed planned for the
new SDL, AFAIK. (Using both surface alpha and an alpha channel correctly
requires that the alpha channel is multiplied with the surface alpha -
something that would be pretty slow, especially on older CPUs, if done by
actually adding extra per-pixel multiplications.)

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?

No, additive and subtractive (both saturating) would be a reasonable
minimum addition, I think. Additive in particular is very useful. You may
think that these are very cheap (ADD/SUB instead of MUL), but the problem
is the saturation… MMX or better SIMD would work great, though, since
these usually have fast saturating arithmetics.

That’s not so hard to fake - but it is, of
course, slow.

Yeah - but even the current (non-cheating) implementation is at least
fast enough to use for antialiazing and other things that need alpha
blending for only a fraction of the screen area.

And I guess by transformations you mean rotations and
perhaps even skewing?

Yeah, or rather, “anything you can do by moving the four vertices of a
quad around”. I think that’s a cleaner and much more powerful interface
than anything with explicit parameters like “rotation angle”, “scale”,
“xshear”, “yshear” etc.

If so, is this something that we’d want to
provide from a Simple DirectMedia Layer?

Well, it’s either that, or don’t use SDL at all for rendering as soon as
you need these features. That’s not a problem per se. If you need that
kind of stuff, you basically need OpenGL.

That said, as soon as you leave SDL 2D, you run into one major problem:
You have to decide which 3D API(s) to support.

Apparently, OpenGL won’t work (properly) out-of-the-box on Win32 these
days, while DX does, and some 3D cards don’t have OpenGL drivers at
all! Thus, if you care about your application running properly on “any
3D accelerated machine out there”, it may not be a good idea to rely
entirely upon OpenGL.

Personally, I’ll probably never write an application with direct Direct3D
support, as I still think the API is a bad design from the ground up, and
because I simply don’t care enough to specifically develop large amounts
of code on and for Win32. (That said, keep in mind that I don’t code
games for food, and that I’m one of those Linux die-hards that feel
sick when using Windoze…

I think there are others that want to use the power of 3D acceleration
for 2D and maybe simple “3D effects”, but fear the loss of portability
that relying on OpenGL or D3D would result in. I’m probably not the
only one who doesn’t feel like implementing and testing a significant
amount of code at least twice.

This is why I think it might be useful to find some middle way, where you
can have the most useful “2D” features of OpenGL and D3D, as well as a
decent software rendering fallback, while still using the same, simple
and portable API.

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…

Right. I think it might be a good idea to start hacking an OpenGL based
prototype pretty soon, so people can start testing the new API in real
applications before it’s finalized. glSDL might serve as a starting point
for that, as it already has the basic functionality in place, behind a
proven API that we all know works well with s/w rendering.

//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.net — http://www.reologica.se —On Thursday 26 September 2002 15:56, Neil Griffiths wrote:

[Neil_Griffiths]

Hi,

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

You’ll find, if you bother to check, that it IS indeed faster if you
write for DirectGraphics as I have done. What I’m realizing now is
that until you test these things for yourself instead of making
blanket statements, it’s not worth discussing this any further with
you. Please actually TRY it out before coming back and commenting any
further.

What you don’t seem to grasp is that by using DirectX8 or OpenGL, you
can actually use features of AGP. You say you can’t transfer 4
textures 30 times a second on AGP? Interesting, you try transferring
your 640x480 image 30 times a second without any acceleration and I’ll
try it WITH acceleration.

AGP is meant exactly for transferring small amounts of data very
quickly across the bus, not large amounts of data. I fail to see your
point.

And exactly where do MS come into this? You seem to be a part of the
"Blame MS!" group of people. Don’t do it unless you can back up your
claims.

And as for ZSNES using OpenGL, try using Kobo Deluxe with and without
OpenGL. What’re you trying to prove?

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

That’s exactly how it’s done - each surface is a texture. Whether it
gets uploaded to the card as one texture or several is something you
don’t have to worry about, but each surface IS a texture.

I’m going to give you one more example of DirectGraphics (doing 2D
graphics on 3D) here:

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

It’s rendering to a surface - actually a texture.

Please go away and actually try it out before coming back and
offering any more of your opinions which appear to be made without any
previous experience. I’m not trying to flame you, but this is getting
ridiculous now. Offering ZSNES as proof, unfortunately for you, proves
very little. Without looking at the code, I assume it uses something
like OPENGL_BLIT which is certainly not the fastest way of doing
things. Just using OpenGL doesn’t magically improve things, you have
to write for it - which is what I’m all for by doing it for OpenGL and
DX8.

Neil.

[slouken]

As word of mouth spreads, SDL should be reaching new audiences. Should
it be designed to please the current userbase and stay in its niche, or
perhaps to broaden the potential userbase by being more widely
applicable? For example, with DirectDraw now effectively gone from
DirectX, lots of us on GameDev.net are now promoting SDL as a more
usable alternative for simple 2D games, increasing its popularity among
Windows programmers and therefore users. So this choice is something to
think about.

That’s good to know. I’ll let everybody know what happens when we’re
actually writing the video code. In the mean time, don’t worry.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

[David_Olofson]

Neil Griffiths wrote:

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.

Let’s not lose sight of the fact that SDL is used for more than games.
And there are many simple games which will run too slowly on GDI. This
is why I would prefer to see a DX5 fallback kept in addition to the
latest DX47 or whatever version is around at the time for the more
up-to-date programs. If 3 back-ends is too much work in terms of
maintenance, personally I’d rather see the GDI option dropped than the
DX5 one. But I know many others would disagree.

Well, I’m sure no one would complain about you maintaining a DX
backend.

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.

As word of mouth spreads, SDL should be reaching new audiences. Should
it be designed to please the current userbase and stay in its niche, or
perhaps to broaden the potential userbase by being more widely
applicable? For example, with DirectDraw now effectively gone from
DirectX, lots of us on GameDev.net are now promoting SDL as a more
usable alternative for simple 2D games, increasing its popularity among
Windows programmers and therefore users. So this choice is something to
think about.

Yeah. And I maintain that SDL 2.x needs to cover the kind of stuff that
causes people to use OpenGL or D3D instead, or there isn’t much of a
future in SDL’s 2D API. I don’t really think basic blitting with alpha
support will be enough motivation to use the API for much longer, even if
the speed is on par with native OpenGL and D3D when either of those is
present.

And where do we go if we don’t want to code for both OpenGL and D3D?
There is a need here, and it seems reasonable to me to extend the SDL API
to fulfill this need - and I’m not talking about turning it into another
3D API.

Many typical 3D features don’t belong in the SDL API at all, whereas some
features generally not found in OpenGL or D3D do. (Loading/saving
surfaces, blitting between surfaces, basic drawing primitives and that
sort of stuff. Maybe even tiling with sub-pixel accurate scrolling
belongs here. With 2D, I think that’s related to subpixel accurate
coordinates…)

//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.net — http://www.reologica.se —On Thursday 26 September 2002 17:35, Kylotan wrote:

[David_Moffatt]

I’m not sure if this has been covered but my main gripe with having to use
3D API’s for 2D games is the stupid texture size limit. It makes creating
interfaces painful and older machines are not supported. If you guys can get
around the texture size limit I wouldn’t care what API was used.>From: David Olofson <david.olofson at reologica.se>

Reply-To: sdl at libsdl.org
To: sdl at libsdl.org
Subject: Re: Re[2]: [SDL] DirectX 7?
Date: Thu, 26 Sep 2002 19:42:35 +0200

On Thursday 26 September 2002 17:35, Kylotan wrote:

Neil Griffiths wrote:

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.

Let’s not lose sight of the fact that SDL is used for more than games.
And there are many simple games which will run too slowly on GDI. This
is why I would prefer to see a DX5 fallback kept in addition to the
latest DX47 or whatever version is around at the time for the more
up-to-date programs. If 3 back-ends is too much work in terms of
maintenance, personally I’d rather see the GDI option dropped than the
DX5 one. But I know many others would disagree.

Well, I’m sure no one would complain about you maintaining a DX
backend.

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.

As word of mouth spreads, SDL should be reaching new audiences. Should
it be designed to please the current userbase and stay in its niche, or
perhaps to broaden the potential userbase by being more widely
applicable? For example, with DirectDraw now effectively gone from
DirectX, lots of us on GameDev.net are now promoting SDL as a more
usable alternative for simple 2D games, increasing its popularity among
Windows programmers and therefore users. So this choice is something to
think about.

Yeah. And I maintain that SDL 2.x needs to cover the kind of stuff that
causes people to use OpenGL or D3D instead, or there isn’t much of a
future in SDL’s 2D API. I don’t really think basic blitting with alpha
support will be enough motivation to use the API for much longer, even if
the speed is on par with native OpenGL and D3D when either of those is
present.

And where do we go if we don’t want to code for both OpenGL and D3D?
There is a need here, and it seems reasonable to me to extend the SDL API
to fulfill this need - and I’m not talking about turning it into another
3D API.

Many typical 3D features don’t belong in the SDL API at all, whereas some
features generally not found in OpenGL or D3D do. (Loading/saving
surfaces, blitting between surfaces, basic drawing primitives and that
sort of stuff. Maybe even tiling with sub-pixel accurate scrolling
belongs here. With 2D, I think that’s related to subpixel accurate
coordinates…)

//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.net — http://www.reologica.se —

---

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

Regards,
David Moffatt
@David_Moffatt

---

Send and receive Hotmail on your mobile device: http://mobile.msn.com

[David_Moffatt]

One other thing I forgot to mention is in 2D games I like to be able to
manipulate indivdual pixels in the images. Would this still be possible
using the 3D API?_________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

[Neil_Griffiths]

Hi,

DM> I’m not sure if this has been covered but my main gripe with having to use
DM> 3D API’s for 2D games is the stupid texture size limit. It makes creating
DM> interfaces painful and older machines are not supported. If you guys can get
DM> around the texture size limit I wouldn’t care what API was used.

Of course. It’s not hard. SDL would just have to split up the texture
into 256x256 (or whatever) sized textures without your knowledge.
You’d have your normal surface and wouldn’t have to know about it. You
can look at the DirectGraphics examples I linked to earlier today to
see how that work or take a look at David’s glSDL code.

DM> One other thing I forgot to mention is in 2D games I like to be able to
DM> manipulate indivdual pixels in the images. Would this still be possible
DM> using the 3D API?

Yes, there would be no point otherwise. However, don’t get stuck
thinking that it’s a 3D API. It isn’t, you’d still be treating it as
2D. It’s just that SDL itself would be using the features of your 3D
card to draw the graphics. Hell, something nice would be fake
anti-aliasing which would be to render at 800x600 and to scale down to
and display at 640x480 - and this could be done in hardware.

And in reply to Patrick from before…

PM> Hmm, yeah, I kinda wish sdl 2.0 had everything in software so in the long run
PM> all of this wouldnt matter. Exploit what you can with hardware APIs, if you
PM> cant, fall back to an internal software routine.

Right, that’s what I’ve been saying all along. There wouldn’t be
anything extra that would be done because of the OpenGL or DX8
targets. There would always be a software fall-back for people who
don’t have those - and GDI needs to be there. DirectX7 would also be
nice, I’ll admit, but there’s going to be a lot of work done there…
It’s just that we can take advantage of modern hardware and I believe
we should do that!

Neil.

[paul_at_theV.net]

As I checked last time, I think David’s glSDL does not cover all cases
of the surface splitting at the moment, for instance, very large surfaces
seems not supported.

At my work, I’ve coded some algo that splits an arbitrary surface to its
optimal textures, in other words, it always tend to use the largest texture
possible. Besides, it also assembles small surface pieces together onto
a single texture in a “smart” way to maximize texture usage.

So far it is working like a charm. I’ll check if I am allowed to share
the source, but anyway, it isn’t difficult stuff, I can post sample
binaries if anybody here is interested to take a look.

Regards,
.paul.On Fri, Sep 27, 2002 at 01:05:28AM +0100, Neil Griffiths wrote:

Hi,

Of course. It’s not hard. SDL would just have to split up the texture
into 256x256 (or whatever) sized textures without your knowledge.
You’d have your normal surface and wouldn’t have to know about it. You
can look at the DirectGraphics examples I linked to earlier today to
see how that work or take a look at David’s glSDL code.

[David_Moffatt]

What about being able to move graphic data to the video card periodically.
Will this incur a speed hit?

I have many specialised graphics routines which wouldn’t be covered in SDL’s
API (not just alpha blending). For example I am able to replace one colour
group with another to reduce the number of animations that have to be
loaded._________________________________________________________________
Chat with friends online, try MSN Messenger: http://messenger.msn.com

[Patrick_McFarland]

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.

No, Im not. The zsnes development team (which I am apart of) have gotten
several “bug reports” about zsnes not working on early pentium systems
because microsoft will not allow dx8 to be installed on a system that old.
This has also been confirmed by several of the windows port developers.

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.

As I said before, its a completely bad idea to display a surface as a texture.
Its slow, and its dumb. If you wanna make a complete opengl rendering pipeline
that uses a texture per sprite and per background, then yeah, you can do that.
But that takes alot of recoding, and still, mesa sucks in software mode, and
microsoft’s opengl32.dll (which I heard uses d3d as the rendering backend,
which means software mode in D3D, which also means (iirc) no software mode
in DX8.)On 26-Sep-2002, Neil Griffiths wrote:

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.

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

[Nick_Whitelegg]

Need I mention that Linux is a server OS, not a desktop OS?

It’s both. Right now I’m typing this on my home PC, running Linux, which I
don’t use as a
server

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.

Surely SDL makes programming games on Linux (and Windows) relatively
easy??? Without it, using raw X or the Windows API, yes it would be
difficult, but it would be difficult on Windows too.

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.

Such egalitarian principles should extend to running on lower end
machines. By lower end I don’t mean really over the top, like 386s, but
certainly higher end Pentium Is, and 32 or 64MB memory. Why should I have
to throw away money on upgrading my system because of lazy, inefficient
programming?

Nick

[Neil_Griffiths]

Hi,

PM> No, Im not. The zsnes development team (which I am apart of) have gotten
PM> several “bug reports” about zsnes not working on early pentium systems
PM> because microsoft will not allow dx8 to be installed on a system that old.
PM> This has also been confirmed by several of the windows port developers.

Well, I’ve just used google and searched for “directx8 pentium
problem”. Guess what? I found no problems at all. I went through 50
results with not one match for what you’re saying. I doubt it a lot.
Besides which, it’s immaterial anyway if there’s DirectX7 (or
whatever) to fall back on.

I will fix up my old P-90 in a bit and test it for myself BTW, because
I quite simply don’t believe you.

PM> As I said before, its a completely bad idea to display a surface as a texture.
PM> Its slow, and its dumb. If you wanna make a complete opengl rendering pipeline
PM> that uses a texture per sprite and per background, then yeah, you can do that.
PM> But that takes alot of recoding, and still, mesa sucks in software mode, and
PM> microsoft’s opengl32.dll (which I heard uses d3d as the rendering backend,
PM> which means software mode in D3D, which also means (iirc) no software mode
PM> in DX8.)

Slow? Sure, if if a 4x+ speed-up is what you call slow. Of course it’s
better to keep everything as seperate textures - which isn’t a problem
at all if you place the texture on a poly and move it to the place
it’s being blitted too. That would be much faster.

BTW, I can claim a 4x speed-up because this is how glSDL works - at
least this is how I’m sure it works from when I looked at the code.
I’m sure David will tell me if I’m wrong!

And of course it takes a lot of recoding. But that’s the whole point
anyway! SDL 2.0 is going to be a rewrite…

Microsoft’s OPENGL32.DLL is a software renderer actually, though in
NT/2K/XP it can use your video card’s OpenGL.

Neil.

[Neil_Griffiths]

Hi,

Need I mention that Linux is a server OS, not a desktop OS?

NW> It’s both. Right now I’m typing this on my home PC, running Linux, which I
NW> don’t use as a server

It’s not up for debate, it’s a server OS whether you use it as a
server or not.

When the kernel starts being written with desktop users in mind, I’ll
change my opinion, but right now it is still being written for
servers. Therefore my statement stands true.

NW> Surely SDL makes programming games on Linux (and Windows) relatively
NW> easy??? Without it, using raw X or the Windows API, yes it would be
NW> difficult, but it would be difficult on Windows too.

Yes, but getting fast graphics and decent sound without break-ups and
access to high-accuracy timers - things you really need for games -
are really tough to do in Linux. It’s not designed for that. And then
you have issues with threading and so on…

NW> Such egalitarian principles should extend to running on lower end
NW> machines. By lower end I don’t mean really over the top, like 386s, but
NW> certainly higher end Pentium Is, and 32 or 64MB memory. Why should I have
NW> to throw away money on upgrading my system because of lazy, inefficient
NW> programming?

That’s not what the FSF are there for though. They’re not telling
people what spec the software would run on (which limits the amount of
software that you’d be seeing if they did BTW), they’re saying that
software should give people freedom.

I agree in principle with what you’re saying - I certainly think that
system specs have gotten out of control and software really doesn’t
need the specs that it does, but that’s not for the FSF. It’s for some
other group…

Neil.

[Neil_Griffiths]

Hi,

DM> What about being able to move graphic data to the video card periodically.
DM> Will this incur a speed hit?

It would depend on how much data, obviously, but it would still be
faster than doing it unaccelerated.

DM> I have many specialised graphics routines which wouldn’t be covered in SDL’s
DM> API (not just alpha blending). For example I am able to replace one colour
DM> group with another to reduce the number of animations that have to be
DM> loaded.

Palette altering isn’t tough at all. Having said that, I’ve never
tried it in RGBA mode, only in colour index mode, but I can’t imagine
it being TOO difficult to implement!

Neil.

[Nick_Whitelegg]

NW> Surely SDL makes programming games on Linux (and Windows) relatively
NW> easy??? Without it, using raw X or the Windows API, yes it would be
NW> difficult, but it would be difficult on Windows too.

Yes, but getting fast graphics and decent sound without break-ups and
access to high-accuracy timers - things you really need for games -
are really tough to do in Linux. It’s not designed for that. And then
you have issues with threading and so on…

I suppose it really depends what sort of game you’re interested in. I’m
interested in writing updated (e.g. 16 bit colour) versions of the old
games of the 1980s which used to run on Spectrums and the like.
Experiments so far suggest SDL on Linux is just fine for such purposes…
Plus of course, the existing free 2D games on Linux written with SDL which
seem fine to me…

That’s not what the FSF are there for though. They’re not telling
people what spec the software would run on (which limits the amount of
software that you’d be seeing if they did BTW), they’re saying that
software should give people freedom.

True, I was thinking of the more general “Linux ethic” which includes not
just GNU but also the idea of being able to use lower end boxes. Luckily
most free Linux software will run on low-to-middle range memory specs
(32/64) although developments in the specs of things like Kylix are a bit
worrying…

I guess I use as my guideline the lifetime of a typical PC before it
finally bites the dust. This seems to be about 5 or 6 years. Therefore you
should really, ideally write for PCs manufactured early 1997 onwards…

The same goes for OSs. One person said Win95 is “7 years old”. But that’s
not so much the issue. The issue is when Win95 was last shipped with new
PCs. That was a mere four years ago. I know that as my PC came with Win95
and it’s four years old, it was about the time 98 started coming in.

Nick

[Patrick_McFarland]

One other thing I forgot to mention is in 2D games I like to be able to
manipulate indivdual pixels in the images. Would this still be possible
using the 3D API?

You can, but its slow. If you can, make sure you can make it a texture or
something. (Even keep a local buffer of the texture, and manipulate that,
and have a seperate routine read the buffer and make a texture of it
periodically)On 27-Sep-2002, David Moffatt wrote:

---

Chat with friends online, try MSN Messenger: http://messenger.msn.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

[Patrick_McFarland]

I’m not sure if this has been covered but my main gripe with having to use
3D API’s for 2D games is the stupid texture size limit. It makes creating
interfaces painful and older machines are not supported. If you guys can
get around the texture size limit I wouldn’t care what API was used.

Well, 3D cards started with 4 megs iirc, so are you sure you are going to use
more than 2-3 megs of graphics on the screen at once? If you are, you might
wanna make fallback software rendering routines.On 27-Sep-2002, David Moffatt wrote:

From: David Olofson <david.olofson at reologica.se>
Reply-To: sdl at libsdl.org
To: sdl at libsdl.org
Subject: Re: Re[2]: [SDL] DirectX 7?
Date: Thu, 26 Sep 2002 19:42:35 +0200

On Thursday 26 September 2002 17:35, Kylotan wrote:

Neil Griffiths wrote:

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.

Let’s not lose sight of the fact that SDL is used for more than games.
And there are many simple games which will run too slowly on GDI. This
is why I would prefer to see a DX5 fallback kept in addition to the
latest DX47 or whatever version is around at the time for the more
up-to-date programs. If 3 back-ends is too much work in terms of
maintenance, personally I’d rather see the GDI option dropped than the
DX5 one. But I know many others would disagree.

Well, I’m sure no one would complain about you maintaining a DX
backend.

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.

As word of mouth spreads, SDL should be reaching new audiences. Should
it be designed to please the current userbase and stay in its niche, or
perhaps to broaden the potential userbase by being more widely
applicable? For example, with DirectDraw now effectively gone from
DirectX, lots of us on GameDev.net are now promoting SDL as a more
usable alternative for simple 2D games, increasing its popularity among
Windows programmers and therefore users. So this choice is something to
think about.

Yeah. And I maintain that SDL 2.x needs to cover the kind of stuff that
causes people to use OpenGL or D3D instead, or there isn’t much of a
future in SDL’s 2D API. I don’t really think basic blitting with alpha
support will be enough motivation to use the API for much longer, even if
the speed is on par with native OpenGL and D3D when either of those is
present.

And where do we go if we don’t want to code for both OpenGL and D3D?
There is a need here, and it seems reasonable to me to extend the SDL API
to fulfill this need - and I’m not talking about turning it into another
3D API.

Many typical 3D features don’t belong in the SDL API at all, whereas some
features generally not found in OpenGL or D3D do. (Loading/saving
surfaces, blitting between surfaces, basic drawing primitives and that
sort of stuff. Maybe even tiling with sub-pixel accurate scrolling
belongs here. With 2D, I think that’s related to subpixel accurate
coordinates…)

//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.net — http://www.reologica.se —

---

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

Regards,
David Moffatt
david_moffatt at hotmail.com

---

Send and receive Hotmail on your mobile device: http://mobile.msn.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

[Patrick_McFarland]

Hi,

Of course. It’s not hard. SDL would just have to split up the texture
into 256x256 (or whatever) sized textures without your knowledge.
You’d have your normal surface and wouldn’t have to know about it. You
can look at the DirectGraphics examples I linked to earlier today to
see how that work or take a look at David’s glSDL code.

As I checked last time, I think David’s glSDL does not cover all cases
of the surface splitting at the moment, for instance, very large surfaces
seems not supported.

At my work, I’ve coded some algo that splits an arbitrary surface to its
optimal textures, in other words, it always tend to use the largest texture
possible. Besides, it also assembles small surface pieces together onto
a single texture in a “smart” way to maximize texture usage.

So far it is working like a charm. I’ll check if I am allowed to share
the source, but anyway, it isn’t difficult stuff, I can post sample
binaries if anybody here is interested to take a look.

Eh, yeah, very small textures would be nice (like, whatever the minimum is)
But the thing is, splitting an already predrawn surface up is bad. Make
each spite and tile a texture, and use opengl directly to do stuff. (Yes, Ive
said this a couple times, but its the only solution I can think of that would
allow you to use hardware acceleration effectivly.)On 27-Sep-2002, paul at theV.net wrote:

On Fri, Sep 27, 2002 at 01:05:28AM +0100, Neil Griffiths 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