I just spent a greuling 2 months developing my SDL programs on a 486
laptop running windows 95 (I hope that no one else has to endure that
^o^). I have just purchased a celeron 366 with a ati rage pro agp
(anybody know how I get this to work with linux? send a message to my
email below if you do, it’s an emachine 366id if anyone wants to know,
it’s the rage I’m really worried about). But anyway what I’m trying
to figure out is what is a good average hardware config to target SDL
programs for (even if it’s just the rec. setup for my readme file).
Phoenix Kokido
members.xoom.com/kokido
@Wes_Poole
Disregard my plea for help with an ati rage, I don’t want to get a lot
of mail telling me I’m an idiot for not checking the xfree86 docs
first ^o^. 2 months ago I was trying to get a banshee to work and I
figured ati would be just as difficult, my bad. I still need to know
a average hardware target though.
Phoenix Kokido
members.xoom.com/kokido
@Wes_Poole
I just spent a greuling 2 months developing my SDL programs on a 486
laptop running windows 95 (I hope that no one else has to endure that
^o^). I have just purchased a celeron 366 with a ati rage pro agp
(anybody know how I get this to work with linux? send a message to my
email below if you do, it’s an emachine 366id if anyone wants to know,
it’s the rage I’m really worried about). But anyway what I’m trying
to figure out is what is a good average hardware config to target SDL
programs for (even if it’s just the rec. setup for my readme file).
It depends on what kind of program you’re writing.
The Maelstrom port to SDL targets a high end 486.
The CivCTP port to SDL targets a P2-200.
Executor targets about a P133.
The HElliZER demo targets a P133 or better.
(these numbers are really rough)
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Personally, I think the question should be more along the lines of
"good average hardware config to target THIS program". SDL is so light
that it can work on just about anything. It’s not going to add any
noticable slowdown to your program (It may actually be faster,
depending on what you used before).
I’d target for the game/app, not for the tool kit.On 12 Jun, Phoenix Kokido wrote:
I just spent a greuling 2 months developing my SDL programs on a 486
laptop running windows 95 (I hope that no one else has to endure that
^o^). I have just purchased a celeron 366 with a ati rage pro agp
(anybody know how I get this to work with linux? send a message to my
email below if you do, it’s an emachine 366id if anyone wants to know,
it’s the rage I’m really worried about). But anyway what I’m trying
to figure out is what is a good average hardware config to target SDL
programs for (even if it’s just the rec. setup for my readme file).
–
| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/
Okay, the game I’m working is based on isometric tiles, with tile
animations, and worlds that are much larger than a single screen, with
free scrolling movement so the world will have to be redrawn somewhat
in at least everyframe. Res will be 640x480 in 16 bit color. Plus
there will be moments, when the world movement will be frozen but
there will be several animated sprites on screen, and lots of
transparency (maybe 20 to 30+, majority with transparency at one
time). My early unoptimized test ran sluggishly on my 486, and way
too quick on this celeron 366. so would I be justified in guessing
maybe a 166 - 200 on a target range? Anybody doing anything similar
that they can give me a speed comparison with?
Phoenix Kokido
members.xoom.com/kokido
@Wes_Poole
[… snippage …]
… My early unoptimized test ran sluggishly on my 486, and way
too quick on this celeron 366. …
No such thing as to quick. You just need to redesign your algorithms and
models. Ideally (IMHO anyway) you should design to scale across hardware,
trading for lower frame rates as the hardware becomes slower. Timers are your
friends.
`course I’ve always been into 3D and other more warped stuff and haven’t really
ever written anything like what you are doing …
/devOn 13-Jun-99 Phoenix Kokido wrote:
// David E. Vandewalle |Weinberg’s Law: If builders built
// vandewal at skyblue.com | buildings the way programmers wrote
// david.e.vandewalle at lmco.com | programs, then the first woodpecker that
// ICQ# 29090828 | came along would destroy civilization.
Phoenix Kokido said:
time). My early unoptimized test ran sluggishly on my 486, and way
too quick on this celeron 366.
Well, if it runs faster than you want it (more fps than reasonable for
smooth animation and game play), then make sure to put a little slow
loop in there.
I usually do it like this:
while (game is running)
{
handle controls;
handle object movement/etc;
draw screen;
if (time since last iteration is less than how fast we want to go)
sleep the remainder;
}
If the “sleep the remainder” never happens, then the computer is
probably too slow for your game, or the graphics or computations are
too complicated.
This allows for people to run your game on Pentium XV’s running at
1,000,000 MHz, and it will never go “way too quick”. 
-bill!
[… snippage …]
… My early unoptimized test ran sluggishly on my 486, and way
too quick on this celeron 366. …
No such thing as to quick. You just need to redesign your algorithms and
models. Ideally (IMHO anyway) you should design to scale across hardware,
trading for lower frame rates as the hardware becomes slower. Timers are your
friends.
Thank you. There are too many vintage games that were designed to work
well around a specific range of hardware performance that they are
unplayable on a new system. XT games didn’t work on an AT, AT games
wouldn’t run well on a 486… It would be nice to scale both ways, one by
using a timing loop, the other by allowing the user to adjust resolution
and detail levels. In consumer level software, rarely have I found a
program whose new features justified a hardware upgrade.
Jeff DeMaagdOn Sat, 12 Jun 1999, David Vandewalle wrote:
On 13-Jun-99 Phoenix Kokido wrote:
----- Message d’origine -----De : Phoenix Kokido
? :
Envoy? : samedi, 12. juin 1999 14:30
Objet : [SDL] Average Hardware Setup
I just spent a greuling 2 months developing my SDL programs on a 486
laptop running windows 95 (I hope that no one else has to endure that
^o^). I have just purchased a celeron 366 with a ati rage pro agp
(anybody know how I get this to work with linux?
AGP shouled work
Rage pro us Mach 64 server
On my PCI RagePro it works fine
Stephane Magnenat
Thanks everyone for the hardware advice and system req comments, I
guess I’ll either write for my hardware (366Mhz) or just test on some
slower machines. I don’t want to tie this list up with my ati rage
problems, but I am having one last difficulty if anyone has any advice
please sent it to my email below instead of the list so it does’nt
bother anyone else, anyway I’m using the mach64 x server, but the
aspects of my screen are screwed up, my screen stops about an inch shy
of both sides (on a 14 inch monitor) and extends off the tops and
bottoms, I’ve tried using Red Hats Xconfigurator and X86Setup to set
my X86Config, but it I have’nt been able to fix the problem, I’m gonna
try the latest version of XFree86 now, I’m using the one that came
with redhat 5.2. Idealy I would like to get 640x480x16bpp up and
running (my monitor can’t do any res above that, and I don’t know if
X86Free fixed the color depth issues from the release I have now)
Phoenix Kokido
members.xoom.com/kokido
@Wes_Poole
My early unoptimized test ran sluggishly on my 486, and way
too quick on this celeron 366.
What do you mean too quick? Game speed should not be frame rate
dependent in any way. If you mean that the frame rate was higher than
needed, then yes, your estimate seems about right.
But it’s still one of the easier issues to slow a program down
Tomas Andrle / red_hatredOn Sun, 13 Jun 1999, Stuart Anderson wrote:
That’s true, I had 12 FPS limits in my code, but it was still
blindingly fast on my new computer, but I was getting under a FPS on
my other computer due to redrawing the whole screen every frame.
Phoenix Kokido
members.xoom.com/kokido
@Wes_Poole
Tomas Andrle wrote:> On Sun, 13 Jun 1999, Stuart Anderson wrote:
My early unoptimized test ran sluggishly on my 486, and way
too quick on this celeron 366.
What do you mean too quick? Game speed should not be frame rate
dependent in any way. If you mean that the frame rate was higher than
needed, then yes, your estimate seems about right.
But it’s still one of the easier issues to slow a program down
Tomas Andrle / red_hatred
William Kendrick wrote:
Phoenix Kokido said:
time). My early unoptimized test ran sluggishly on my 486, and way
too quick on this celeron 366.
Well, if it runs faster than you want it (more fps than reasonable for
smooth animation and game play), then make sure to put a little slow
loop in there.
I usually do it like this:
while (game is running)
{
handle controls;
handle object movement/etc;
draw screen;
if (time since last iteration is less than how fast we want to go)
sleep the remainder;
}
It is much better to do it like this:
while (game is running) {
starttime = gettime():
position+=velocity*time; /For Example/
draw_screen;
endtime = gettime();
time = endtime - starttime;
}
Using this framerate can be as high as the system will allow, while
gameplay remains at exactly the speed you want, no matter if the system
is 30fps or 30spf.
Stuart.
Well, it depends on your program…
I remember that Wolf3d ran on a 286, but was much better on a “fast” 386 or an
early 486, and gave you motion sickness on a 486 with a VESA video card.
Then, you get your Test Drive 3-like games, that you needed to turn the turbo
switch off on your computer, or turn the turbo swich on on your bionic fingers
to be able to use it. 
(It had not timing)
So, whatever you write it for, take into account that some computers are fast,
some aren’t, but everything must be relative.On Sat, Jun 12, 1999 at 12:30:25PM +0000, Phoenix Kokido wrote:
I just spent a greuling 2 months developing my SDL programs on a 486
laptop running windows 95 (I hope that no one else has to endure that
^o^). I have just purchased a celeron 366 with a ati rage pro agp
(anybody know how I get this to work with linux? send a message to my
email below if you do, it’s an emachine 366id if anyone wants to know,
it’s the rage I’m really worried about). But anyway what I’m trying
to figure out is what is a good average hardware config to target SDL
programs for (even if it’s just the rec. setup for my readme file).
–
– Michael Samuel
Actually at the end of my game loop is a call to the wait_frame
function from the SDL examples, it only delays if necessary, but I
guess I put to high of a value in my FPS define, or I need to do more
in my loop.
Phoenix Kokido
members.xoom.com/kokido
@Wes_Poole
Stuart Anderson wrote:> William Kendrick wrote:
Phoenix Kokido said:
time). My early unoptimized test ran sluggishly on my 486, and way
too quick on this celeron 366.
Well, if it runs faster than you want it (more fps than reasonable for
smooth animation and game play), then make sure to put a little slow
loop in there.
I usually do it like this:
while (game is running)
{
handle controls;
handle object movement/etc;
draw screen;
if (time since last iteration is less than how fast we want to go)
sleep the remainder;
}
It is much better to do it like this:
while (game is running) {
starttime = gettime():
position+=velocity*time; /For Example/
draw_screen;
endtime = gettime();
time = endtime - starttime;
}
Using this framerate can be as high as the system will allow, while
gameplay remains at exactly the speed you want, no matter if the system
is 30fps or 30spf.
Stuart.