hello. i’m working on a simple 3d game and have gotten to the point where I’m interested in trying it out on various systems for speed/compatibility tests.
it’s only a couple megs and is located at: http://home.earthlink.net/~mvignol/barrel_patrol_3d.zip
please post system config (cpu + gfx card), FPS and whether it was fullscreen or windowed.
any other feedback is also welcomed.
thanks.
-miles vignol
fathom_games@hotmail.com
[This message has been edited by mv (edited 05-15-2001).]
Nice work!
Tried it at work… 
p3 700
old ati rage 128
windowed
Gave me about 12-18 fps… Have you adjusted the movement and rotational speed according to the time it took to draw the scene?. I though it came to a crawl when the fps went down. (Usually when there was smoke around)
Cheers
Win98
P3 @600
128MB 100MHz sdram
TNT2 m64 32MB
~45FPS Fullscreen
~40FPS windowed
Note when windowed it still looked very much like it was fullscreen (my desktop res was 800*600)
A very promising game, should be really good when complete- only a small bugs and niggles at the moment.
Thanks. I intend to lock the FPS at a certain number so that the game time doesn’t slow down when it’s drawing slowly, but I need to find a good FPS that would be realistic for most people. I’m just now trying to gather information to determine that number (I was hoping for 50-60 FPS). I’m developing on a 550 Celeron with a GeForce 2 MX and getting 60-80, but maybe my card is more power than most people have at the moment.
The transparent fx really are the main speed killer. I can decrease the amount of smoke pretty easily if I ever get around to creating a menu system.
You shouldn’t try to limit the game to a certian FPS, it should be made so that all velocities and accelerations are constant even although the FPS may vary- this makes it much better to play. It is surpisingly easy to do: what I did was noted that I was getting about 80FPS and the walking speed was ok so to get to m/s or what ever I multiplied all movement values by 80 this obviouly makes it run too fast since movement is based per a second while it is recalulated every 1/80th of a second. So what you do is multiply this 80 by the time of the 1 frame that has been drawn-
t2 = TimeGetTime();
frametime = t2 - t1;
t1 = t2;
FPS = 1/frametime;
speed = 80*frametime
…
movement.x += (some trig etc.) * speed;
I implemented this in about 6 minutes, it is easy and very effective but is also important for when you want to know the real speed in m/s etc. for sound and physics things.
I’ve considered this, but there are a lot of places to affect this change. I may end up doing it tho, because the FPS is seemingly a bit too difficult to pin down.
The way it works now (altho it’s disabled for these speed tests) is to sleep if it’s faster than the desired FPS and skip the Draw routine if it’s not keeping up. It seems to work, but the idea of sleeping then skipping seems a little wasteful. Certainly the other method of a variable time-frame is ideal, but like I said, there’s a lot of places to implement it.