DirectX 7?

Patrick_McFarland · September 27, 2002, 5:02am

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.

Properly managed would have to make those tiles uploaded as textures themselves
and have the renderer itself make everything. (Real rendering pipeline instead
of the hack stuff uses now)

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

Yeah, that was my whole D3D issue in the first place. Now, having a completely
done opengl rendering pipeline, yeah, you get massive speed.On 26-Sep-2002, paul at theV.net wrote:

On Thu, Sep 26, 2002 at 09:11:59AM -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

Patrick_McFarland · September 27, 2002, 5:02am

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.

Um, as far as I know, the fastest pentium I was a 233. Until you can prove
otherwise, Im going to have to assume its a P2 mobile chip, or not Intel.
(Or, either you or the manufacturer is lying.)

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.

sSying that linux isnt a desktop os just invalidated everything else you are
going to say. Hundreds of thousands of people use linux as their desktop os.
I am one of those people. As such, I am not going to respond to anything
else you say.On 26-Sep-2002, Neil Griffiths wrote:

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.

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.

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

Neil_Griffiths · September 27, 2002, 5:33am

Hi,

PM> Um, as far as I know, the fastest pentium I was a 233. Until you can prove
PM> otherwise, Im going to have to assume its a P2 mobile chip, or not Intel.
PM> (Or, either you or the manufacturer is lying.)

Yes, but you keep on proving over and over that you don’t know a lot.

http://processorfinder.intel.com/scripts/default.asp?CHRID=51
(choose TCP mobile, 66MHz bus, oh look - 300MHz!)
http://www.infohq.com/Computer/intel-mobile-cpu.htm
http://www.infohq.com/Computer/mobile-cpu-speed.htm

So, I’ve proved it, I’m telling the truth - and you come away looking
like an ass. Go you!

You know, unlike yourself, I actually like to check up on things so I
actually know what I’m talking about. You should try it sometime.

PM> sSying that linux isnt a desktop os just invalidated everything else you are
PM> going to say. Hundreds of thousands of people use linux as their desktop os.
PM> I am one of those people. As such, I am not going to respond to anything
PM> else you say.

Linux is NOT a desktop OS. It is a server OS. It is NOT designed for
desktop tasks, it is not designed for games, it is not designed for
office work - it’s designed to handle consecutive tasks/users and to
be as stable as possible. I never said you can’t use it on your
desktop, but that doesn’t make it a desktop OS. The fact that people
have produced office applications and games for it doesn’t make it a
desktop OS, it means people have worked with what they have. Have you
seen the problems you can have trying to work with timers, sound and
graphics under Linux? You can do it, but doing it quickly and
accurately is going to be a problem while Linux is designed for server
applications.

When you find Linus and all the other people under him working on
making a kernel which allows access to timers and access to sound
which isn’t through a file-like system - and allows access to your
graphics card (even if through a wrapper to reduce the risk of
crashing) - only THEN will Linux start to become a desktop OS, but
right now it is still being designed with server applications in mind.
And not you, nor anybody else, can change the fact that Linux is a
server OS until that happens. You can use it on your desktop, but it’s
still designed as a server OS.

If you don’t have anything else constructive to say, I actually wish
you wouldn’t reply to anything else I say. Hardly anything you’ve said
has been accurate or useful so it’s not like anyone is missing
anything.

Neil.

Neil_Griffiths · September 27, 2002, 5:50am

Hi,

PM> Yeah, that was my whole D3D issue in the first place. Now, having a completely
PM> done opengl rendering pipeline, yeah, you get massive speed.

There are two ways to do it. Bind a surface to a texture. That’s fast.
We can see that. The other way is, as you say, having a rendering
pipeline. More complex to handle, but faster. But we can do that with
DirectGraphics (not D3D) too. So what - has your opinion changed now
or something?

PM> Well, 3D cards started with 4 megs iirc, so are you sure you are going to use
PM> more than 2-3 megs of graphics on the screen at once? If you are, you might
PM> wanna make fallback software rendering routines.

He was talking about texture size as in the limit of 256x256 on
certain cards, the main culprit being the Voodoo series.

As a matter of interest, the first 3D card for the PC (the Diamond
Edge) came with 2MB, the ViRGE came with 2MB and so did the Voodo,
though shortly after came out with 4MB.

PM> You can, but its slow. If you can, make sure you can make it a texture or
PM> something. (Even keep a local buffer of the texture, and manipulate that,
PM> and have a seperate routine read the buffer and make a texture of it
PM> periodically)

No, because your texture would be bound to a surface. SDL would have
to manage re-uploading the texture after a change though, but this
could be done, for example, after either a SDL_Flip(),
SDL_UpdateRect() and so on.

Neil.

Nicolai_Haehnle · September 27, 2002, 7:13am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Friday 27 September 2002 14:30, Neil Griffiths wrote:

PM> Um, as far as I know, the fastest pentium I was a 233. Until you can
prove PM> otherwise, Im going to have to assume its a P2 mobile chip, or
not Intel. PM> (Or, either you or the manufacturer is lying.)

Yes, but you keep on proving over and over that you don’t know a lot.

http://processorfinder.intel.com/scripts/default.asp?CHRID=51
(choose TCP mobile, 66MHz bus, oh look - 300MHz!)
http://www.infohq.com/Computer/intel-mobile-cpu.htm
http://www.infohq.com/Computer/mobile-cpu-speed.htm

So, I’ve proved it, I’m telling the truth - and you come away looking
like an ass. Go you!

You know, unlike yourself, I actually like to check up on things so I
actually know what I’m talking about. You should try it sometime.

Great. So you say you have a Pentium that some version of DirectX works on.
Other people send bug reports because said version of DirectX doesn’t work
on their Pentiums.

You said yourself that it was a Pentium MMX. Doesn’t this hint to a set of
CPU features (MMX, maybe CMOV) that weren’t present on the very first
Pentiums?
Those names are really pointless anyway. You’re better off comparing
different sets of CPU features as reported by CPUID (see /proc/cpuinfo on
Linux).

cu,
Nicolai
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9lGfAsxPozBga0lwRAlwwAKDRBv3Xsm6IpjlqqjKskMq89ooBoQCffvRU
3L7ImfI8kHfLs1D2qfNPELE=
=cHII
-----END PGP SIGNATURE-----

Jimmy · September 27, 2002, 7:48am

Guys, enough.

Could you please move this to your own email addresses, or something.
This is breaking down into a flame war, and I already get a tonne of
email a day.

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.

On Fri, 2002-09-27 at 05:46, Neil Griffiths wrote:

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.

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

–
Jimmy <@Jimmy>
Jimmy’s World.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20020927/88784389/attachment.pgp

David_Moffatt · September 27, 2002, 7:34pm

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.

This is true. I use an old P200 for all my programming. Its a Cyrux chip
actually and DirectX 8 wont install on it. Its been a long time but it says
my processor is too old. If you guys really want to know the exact message
I’ll try and install it again otherwise you can take my word for it.>From: Neil Griffiths <n.griffiths at virgin.net>

Reply-To: sdl at libsdl.org
To: Patrick McFarland
Subject: Re[2]: [SDL] DirectX 7?
Date: Fri, 27 Sep 2002 10:46:31 +0100

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.

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

Regards,
David Moffatt
@David_Moffatt

Chat with friends online, try MSN Messenger: http://messenger.msn.com

Neil_Griffiths · September 28, 2002, 7:24am

Hi,

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.

DM> This is true. I use an old P200 for all my programming. Its a Cyrux chip
DM> actually and DirectX 8 wont install on it. Its been a long time but it says
DM> my processor is too old. If you guys really want to know the exact message
DM> I’ll try and install it again otherwise you can take my word for it.

Well, I tested it on my P-90 and it wouldn’t install either, so he was
right - I apologise for not believing you on that issue Patrick. It
appears that it requires MMX. I’ll certainly admit when I’m wrong!

However, I left my original quote above and I’ll say it again:

“Besides which, it’s immaterial anyway if there’s DirectX7 (or
whatever) to fall back on.”

I don’t take anything else back though on the grounds that I was
correct and had tested them out. However, I don’t want to say anything
else on the matter because I don’t want it to get into a flamewar,
something I mentioned a while ago and was brought up again recently by
others.

Neil.

Patrick_McFarland · September 28, 2002, 3:22pm

Hi,

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.

DM> This is true. I use an old P200 for all my programming. Its a Cyrux chip
DM> actually and DirectX 8 wont install on it. Its been a long time but it says
DM> my processor is too old. If you guys really want to know the exact message
DM> I’ll try and install it again otherwise you can take my word for it.

Well, I tested it on my P-90 and it wouldn’t install either, so he was
right - I apologise for not believing you on that issue Patrick. It
appears that it requires MMX. I’ll certainly admit when I’m wrong!

It does work on pmmx? hmm. writes that down somewhere

However, I left my original quote above and I’ll say it again:

“Besides which, it’s immaterial anyway if there’s DirectX7 (or
whatever) to fall back on.”

Eh, not if you use dx8 specific functions. Im not sure if ms added ddraw
functions in dx8 or not. But, yeah, this whole thread is getting pretty
flamey.On 28-Sep-2002, Neil Griffiths wrote:

I don’t take anything else back though on the grounds that I was
correct and had tested them out. However, I don’t want to say anything
else on the matter because I don’t want it to get into a flamewar,
something I mentioned a while ago and was brought up again recently by
others.

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

David_Olofson · September 30, 2002, 6:46am

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.

A server kernel I’d say. (Linux is a kernel; not an OS.)

KDE or GNOME are hardly server applications, and you don’t have to
install anything but Linux, some libc and a bunch of other libs and
daemons not found in a typical server. Is it still a server OS if you
don’t even have basic file sharing and rlogin/telnet/ssh installed…?

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.

Well, IMHO, using a server kernel for a desktop OS isn’t a bad idea,
provided there is support for what you need. I’ve never had to explicitly
defragment a Linux fs, I don’t have to wait for minutes with a frozen
file manager after moving or deleting a few thousand files, and I don’t
have to wait for up to half a minute before even trying to look at a CD I
insert. I have to do all the latter with Win98, and some even apply to
Win2k.

If you’re trying to tell us a server kernel is a bad thing to have in a
desktop system, at least, I’m not bying it.

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…

Right. However, most of these issues are ones that will have to be dealt
with before 2.6/3.0 for other reasons, since the underlying problems also
affect high end MP servers. Most importantly, this means that worst case
latency has to be reduced significantly, which just happens to greatly
benefit multimedia as well.

As to hr timers, the lack of those are more a function of lack of need
and interest than anything else. The RTC has been there for ages, but
still, no one has bothered to implement a proper “multimedia timer” API
for it. Also, “HZ” (100 Hz on x86 by default) will be increased
significantly in 2.6/3.0, so the old timers will get much better
resolution as well. Just a matter of minor tweak - not redesign.

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…

Users, maybe?

I don’t think there will be much serious work to support low end
hardware, unless enough people need it.

That said, there is uClibc, busybox and a bunch of single floppy
distros and whatnot for embedded systems, and embedded graphics support
is improving as well - but I’d say it seems like even the embedded
systems are getting too powerful to motivate much further work on
minimizing footprint and maximizing performance on really low end
hardware.

And what can you really do, anyway? On machines like Pentium(MMX) or
slower, you’re approaching the level where you have to “cheat” to get
serious performance, and that means you have to use custom
implementations for many things anyway.

Or, as an example, should we implement various forms of fake, dither
based alpha and that sort of stuff in SDL? Now that the vast majority of
us already develop on and for machines with >700 MHz and 32 MB 3D
accelerators or better…?

Who are we going to force to do all this 486/586 asm hacking?

//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 Friday 27 September 2002 11:55, Neil Griffiths wrote:

David_Olofson · September 30, 2002, 6:53am

Yes, but it doesn’t come for free. At least OpenGL allows you to upload
rectangles within textures, so you don’t have to update the whole texture
if you only change a few pixels every frame.

Just keep in mind that texture uploading is often just as slow as
software rendering to VRAM, so you shouldn’t pump more pixels than
corresponding to a 320x240 screen or so per frame. This is usually not a
problem, since you don’t have to update procedural textures at the full
rendering frame rate, and you can even update a part of a texture each
frame. Just “double buffer” each procedural texture, so you can have one
for rendering and one for “slow update”, and then switch.

//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 Friday 27 September 2002 01:22, David Moffatt wrote:

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?

David_Olofson · September 30, 2002, 6:57am

glSDL handles that, although the current implementation has some
restrictions. This is just a matter of implementing it properly - having
a 2D-over-3D wrapper “tiling” textures transparently is no major issue.
(Not even with filtered scaling enabled, actually, since the wrapper
knows which tiles belong together.)

//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 Friday 27 September 2002 01:20, David Moffatt wrote:

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.

David_Olofson · September 30, 2002, 7:09am

[…]

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.

That’s where it gets complicated… As long as the “wrapper” knows which
tiles belong together, it’s just a matter of copying border pixels around
to keep the filtering from “leaking” around the edges of quads.

However, as soon as you explicitly render surfaces side by side (as in a
tiled map), you end up in a situation where the API can’t easilly figure
out what to do. Disabling texture filtering seems to be the only way to
deal with that, even with FSAA, as whatever texture filtering you use,
edges will look different… :-/

Now, if the API supports “tiled layers” as a form of virtual surfaces,
this could be solved relatively easilly. (Well, at least it doesn’t take
a full scene analyze before rendering each frame.

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!

Absolutely.

Considering the poll results, it’s rather strange that the insterest in
the 2D-on-3D approach isn’t even bigger than it is. I’ve received info on
29 machines now, and only one lacks accelerated 3D.

//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 Friday 27 September 2002 02:05, Neil Griffiths wrote:

David_Olofson · September 30, 2002, 7:13am

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.

That’s just because I’ve been lazy.

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.

Well, that’s exactly what we need, preferably in a generic form, so that
it can be used for both OpenGL and DirectGraphics.

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.

Both would be very interesting. If you’re allowed to share the source,
I’d be happy to integrate it into glSDL.

//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 Friday 27 September 2002 03:34, paul at theV.net wrote:

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

David_Olofson · September 30, 2002, 7:21am

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

Well, the data does have to be transferred over the AGP - and by now, I
think we all know what that means if there’s no busmaster DMA. It could
be relatively slow on some platforms and/or drivers, so better not rely
on it being any faster than s/w rendering into VRAM.

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.

That sounds like something you definitely should not do in real time,
unless you’re low on texture RAM. Sounds like a typical load time thing
to me, in fact.

Any other examples?

Either way, I think you can still rely on texture uploading speed being
sufficient for at least some 70,000 pixels per frame, and unless you need
insane amounts of graphics, prerendering stuff and uploading it to
texture RAM should go a long way, especially if there’s fast alpha,
additive and subtractive blending as well.

//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 Friday 27 September 2002 03:52, David Moffatt wrote:

David_Olofson · September 30, 2002, 7:35am

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.

Actually, it is slow - unless you have the AGP aperture and/or
busmaster DMA working properly. On some drivers, textures must be
uploaded to the card before they can be used, and that’s done with the
CPU, and consequently is just as slow as normal s/w rendering.

The only situation where it virtually always pays off is when you want to
scale a super low res emulator screen to fit a 640x480+ screen. In such
cases, the texture uploading bandwidth requirement is low enough that
it’s not an issue if it’s limited to “software speed”.

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!

glSDL uploads individual surfaces to OpenGL as textures, which generally
means that it goes directly to texture RAM - through DMA, if you’re lucky.

Textures are also kept in system RAM (ie they don’t “go away” when
uploaded) as normal SDL s/w surfaces, so you can lock them, modify them,
and unlock them. As you unlock a surface, glSDL automatically updates
it’s corresponding texture area. (This is why I want an optional rect
argument for SDL_LockSurface(). Without it, glSDL will always have to
update the whole surface, even if you only changed a single pixel.)

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…

OTOH, we’re talking about major recoding of SDL - not SDL applications.
Sure, there probably have to be some API changes that will break SDL 1.2
apps, but considering what glSDL can do already, and what it could do
with only major API tweaks, it’s not like anyone will have to rewrite any
SDL graphics code to work with it.

//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 Friday 27 September 2002 11:46, Neil Griffiths wrote:

David_Olofson · September 30, 2002, 7:49am

[…]

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)

There is no minimum in glSDL… (There might be a minimum for OpenGL, but
that’s not an issue, as glSDL just uses the part of the texture it needs
anyway. This is where “multiple surfaces on one texture” should kick in,
BTW; another TODO.)

But the thing is, splitting an already predrawn surface up is bad.

Why? glSDL does it all the time, or it would have to use insane texture
sizes (unsupported by OpenGL) for S(o)Font font surfaces and the like.
(Yes, the fonts in Kobo Deluxe are chopped up by glSDL as needed to fit
them in the smallest possible square texture.)

Make each spite and tile a texture, and use opengl directly to do
stuff.

Yeah, but then you don’t have anything that runs Direct3D, or without 3D
acceleration…

(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.)

What’s the big deal with a few quads more or less…? It doesn’t even
break texture filtering, if you’re into that. (You probably know that
virtually every consumer 3D card in excistence will tesselate everything
to triangles. Same “problem” - which really isn’t, unless you use vertex
color modulation and stuff on quads.)

//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 Friday 27 September 2002 06:51, Patrick McFarland wrote:

David_Olofson · September 30, 2002, 8:19am

[…]

Linux is NOT a desktop OS. It is a server OS. It is NOT designed for
desktop tasks, it is not designed for games, it is not designed for
office work - it’s designed to handle consecutive tasks/users and to
be as stable as possible.

Yeah, we all know by now that desktop OSes should not be stable, nor
multitask properly.

(Sorry, couldn’t resist!

I never said you can’t use it on your
desktop, but that doesn’t make it a desktop OS. The fact that people
have produced office applications and games for it doesn’t make it a
desktop OS, it means people have worked with what they have. Have you
seen the problems you can have trying to work with timers, sound and
graphics under Linux?

Most of this is because of poor drivers and lack of APIs to make use of
existing features - not becaues of limitations of the kernel.

Yes, we are indeed talking about a kernel designed for servers, but that
doesn’t mean it’s inherently broken when it comes to other tasks. Indeed,
it used to be in some regards, and it still hase some minor issues, but
those are issues that start to affect high end servers as well, and
consequently, will be fixed in 2.6/3.0, or have been fixed already.

You can do it, but doing it quickly and
accurately is going to be a problem while Linux is designed for server
applications.

Well, for the record, I’ve always had much more trouble with audio on
Windows than on Linux… Even standard Linux does 10-20 ms pretty
reliably, but I’ve never managed to get below some 50 ms on Windows.

And let’s not talk about Linux/lowlatency…

When you find Linus and all the other people under him working on
making a kernel which allows access to timers and access to sound
which isn’t through a file-like system -

So mmap() and ioctl() based interfaces, optionally wrapped in thin
interface libs won’t work? You just have to screw the whole
kernel/system interface up to get decent multimedia performance?

I beg to differ.

and allows access to your
graphics card (even if through a wrapper to reduce the risk of
crashing) -

A wrapper does not reduce the risk of crashing significantly. Only
client/server or kernel driver based designs can do that. Indeed, the
former is not too great for games, and I think Linux has failed to
present anything truly useful of the latter kind. That’s not an effect of
the read()/write()/mmap()/ioctl() interface, though.

only THEN will Linux start to become a desktop OS,

When the remaining scheduling latency issues have been fixed, and fbdev
has turned into something truly useful, I don’t think there’s much more
that needs to be done, actually. Sure, timers utilizing the full APIC or
PIT resolution would be cool, but with HZ == 1024 or something on all
workstation hardware, it’s no big deal if it’s ruled out for performance
reasons. The RTC is still there, and happily generates up to 8192 Hz -
and you’ll need RTLinux or RTAI to make much use of that.

but
right now it is still being designed with server applications in mind.

Yes. I don’t think that is a big an issue as you make it sound, though.

And not you, nor anybody else, can change the fact that Linux is a
server OS until that happens. You can use it on your desktop, but it’s
still designed as a server OS.

I agree, but not completely, and not with your idea of how Linux must
change. I think it’s possible to achieve decent multimedia performance
without entirely ruining security and stability.

As to more traditional desktop applications, what’s missing…? (Well,
apart from the applications, that is.

If you don’t have anything else constructive to say, I actually wish
you wouldn’t reply to anything else I say. Hardly anything you’ve said
has been accurate or useful so it’s not like anyone is missing
anything.

Looks like we have too much opinion and adrenaline here, and a lack of
hard facts… Oh well. This is about operating systems, so it’s to be
expected. sigh

//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 Friday 27 September 2002 14:30, Neil Griffiths wrote:

Nick_Whitelegg · September 30, 2002, 9:15am

Or, as an example, should we implement various forms of fake, dither
based alpha and that sort of stuff in SDL? Now that the vast majority of
us already develop on and for machines with >700 MHz and 32 MB 3D
accelerators or better…?

Maybe commercial games programmers have such specs. For people
who write in their spare time, I suspect it’s not necessarily
the case. I don’t see why I should trash my perfectly functional 300mhz
PII until it breaks, unless someone would care to give me a grand
Indeed, it’s better to develop for lower end machines I think. The base
line spec I would go for would be a 32mhz, P166 or thereabouts, running
Linux or Windows 95. As I’ve said before, PCs tend to have a life of 5 or
6 years old and that would be about the sort of spec you’d get then, if I
remember right.

Who are we going to force to do all this 486/586 asm hacking?

I doubt you’d need assembly to write a fast 2D game on a low end Pentium.
On a 300mhz PII, my own C++ game in development (2D, platform type thing,
featuring pixel sprite collision, 16 bit colour) runs way too fast
unless forcibly delayed. So I’d imagine such a game would run about right
on a high end 486/low end Pentium. Indeed, for simple 2D games
(Pacman, Space Invaders and the like) one can use C or C++ on even a 20mhz
386. I know, I did In fact, come to think of it, wasn’t Doom written
in C?

Nick

atrix2 · September 30, 2002, 9:21am

dont forget that Doom 1 ran on 486’s :P> ----- Original Message -----

From: bssnrw@bath.ac.uk (Nick Whitelegg)
To:
Sent: Monday, September 30, 2002 9:14 AM
Subject: Re: Re[4]: [SDL] DirectX 7?

Or, as an example, should we implement various forms of fake, dither
based alpha and that sort of stuff in SDL? Now that the vast majority of
us already develop on and for machines with >700 MHz and 32 MB 3D
accelerators or better…?

Maybe commercial games programmers have such specs. For people
who write in their spare time, I suspect it’s not necessarily
the case. I don’t see why I should trash my perfectly functional 300mhz
PII until it breaks, unless someone would care to give me a grand
Indeed, it’s better to develop for lower end machines I think. The base
line spec I would go for would be a 32mhz, P166 or thereabouts, running
Linux or Windows 95. As I’ve said before, PCs tend to have a life of 5 or
6 years old and that would be about the sort of spec you’d get then, if I
remember right.

Who are we going to force to do all this 486/586 asm hacking?

I doubt you’d need assembly to write a fast 2D game on a low end Pentium.
On a 300mhz PII, my own C++ game in development (2D, platform type thing,
featuring pixel sprite collision, 16 bit colour) runs way too fast
unless forcibly delayed. So I’d imagine such a game would run about right
on a high end 486/low end Pentium. Indeed, for simple 2D games
(Pacman, Space Invaders and the like) one can use C or C++ on even a 20mhz
386. I know, I did In fact, come to think of it, wasn’t Doom written
in C?

Nick

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