VBGamer

That's a really cool game! Add some sound effects and a highscore list and you've got a perfectly good driving game! It ran smoothly at 50-60 FPS on my Athlon XP 2500+ with 1024 MB Duel RAM and a 128 MB Radeon 9500 graphics card.

59 - 61 FPS on default settings WinXP Home 256MB RAM Intel Xtreme Graphics Controller with 64MB Video Memory(Dell Inspiron 1100 - Laptop) DirectX 9.0b installed Not bad! Keep up the good work.

8 FPS, 45 to 50 CPS on default settings. 8 MB ATI RAGE PRO TURBO AGP, Windows 2000 SP 4, DirectX 9.0b, Pentium 3 600 Mhz. Are you using any sort of geometry reduction algorithm such as ROAM or possibly an Oct Tree?

To Eric: Not really. Although I'd probably incorporate progressive meshes and simplification meshes. The problem was that DX fires an error when I try to simplify some of the meshes I have. Maybe a problem with the exporter? I am having problem with skinned mesh detection. DX8.1 for VB doesn't have a intersectsubset kind of method. I got no problem intersecting with static meshes, though. FYI. On the original machine I developed it on I had 6fps/48cps average. It was a K62-500mhz with SiS530 internal gpu. On the machine I'm using now (a Duron 850 with SiS630 internal gpu, I got around 30+ fps. I got a 60fps with a 320x240 res, so probably it's the video that can't keep up.

The idea behind the ROAM algorithm is that the set of vertices that you render is constructed by your program. The idea is that geometry farther away doesn't need as many vertices as geometry that's closer to you. See http://www.llnl.gov/graphics/ROAM/ and http://www.cognigraph.com/ROAM_homepage/ What exactly does the CPS measure? I know I don't have the best video card in the world, but I do know that if proper techinques are used, it can render some very cool things. Generating a large level in a 3D drawing program and then exporting to an .X file, and then having DirectX render the entire set of triangles is going to slow down a lot of 3d video cards. I hope I didn't sound rude. I don't mean to be. I think you've got some really great potential, and I think if you put some more work into this you'll have something really amazing. I was really impressed by the demo. I like the tail lights and dust trails, they're nice touches. The collision detection with the fences, and the fact that the car goes up and down when moving over bumps in the road might be small details, but it shows that you know what you're doing. I played the demo in 320x240, and the pixels are gigantic on my screen, but it was really a lot of fun in that resolution [:)] . It's like playing something on a GBA or SNES. Too cool for words.

Average 60 FPS and 60 CPS on 640x480, 800x600 and 1024x768. 640x480 was just slyghtly faster. Side-note: it appeared to slow down a bit when I was turning the wheels. (actually sometimes it ate 20 FPS) Interesting enough, in 320x240 I got something around 45 FPS. Strange, eh? My specs: - Athlon XP 2200+ (1800 mHz) processor - 256MB DDR266 memory - 7200 RPM IDE HD - ATI Radeon 9600XT 256MB graphics card - Windows XP Professional Service Pack 1 - VSync turned off in the driver settings - DirectX 9.0c - Yeah I guess that's enough.

To Eric: No prob, really. I've developed vgl3d on a slow pc. Weird thing on that pc was software mode (you know, the non-accelerated mode of old games) was much faster on that machine. DirectX8 didn't have that kind of mode (the reference rasterizer is TOO slow). CPS is cycles per second. VGL3d is looped-/procedural- based, so I included that info. To VBBR: Maybe the dust effects is slowing the GPU down... maybe. Pretty weird. It's really just billboarding. 320x240 is slower? Weird indeed! Thanks for the info. Most of you guys have nice pcs. <sniff>. Thanks to those giving info so far! I appreciate it!

60 FPS, 60 CPS in all resolutions, regardless of wether windowed mode is on or off. It's pretty slick! I was impressed. Pentium 4 3GHz with Hypertheading 128MB ATI Radeon 9800 Pro 1GB RAM DirectX 9.0b

I'll bet you had VSync turned on? When we're testing framerates it's best to turn it off...

I had it set to application preference in my advanced display settings, but even when I turned it off, the framerates were the same. My monitors refresh rate is set at 85, so I don't think that's the problem either. Since you had the same framerates, he probably has his own framerate cap on, or something.

Which is not good if you're testing the FPS, anyway. Also I think that with my hardware I should have got something better than 60 FPS.

Can't test it out until I get home... The school blocks acces to angelfire (free pages...). The screenie looks cool though, keep up the good work!

VGL3d has frame limiter / frame skipper on. Framerate tests here is for consistency and timing checks, not for system benchmarking. I've seen people report about more than 100fps on tests, but what's the point if the screen refresh is only, say, 72hz? That measures the only the videocard rendering power. The one I'm keeping an eye on is actually the CPS, or cycles per second. A game, for example, might display only 30fps on a slow machine, but can maintain 60cps. It means the game timing is still at par. Heck, if all I wanted was to get maximum framerates from you guys, then I'd only die in envy. ;-)

I really really don't understand why people insist on using a frame cap instead of using time based modelling, it's so much simpler and more effective.. rene

Actually, you should use both. [:)] A frame rate cap can help the game maintain a constant frame rate. A game that plays at a constant 30 FPS maintains the illusion of motion much better than a game that has a frame rate that fluctuates between 30 and 60 FPS. A problem with time based modeling is that the faster the frames per second, the lower your accuracy becomes because you have a predefined precision. If your delta time between frames is too small, then you run the risk of values being continuously rounded down. This could make things like particle-systems not move at all.

Not nescesarily.. just do something like this (ripped from my physics engine) updatetime = GetTickCount() Dim deltatime As Int32 = updatetime - lastupdate Dim timestep As Single = 1 / IterationsPerSec 'this is actually a constant Dim iterations As Int32 = deltatime * 0.001 * IterationsPerSec For k = 0 To iterations 'do stuff Next k lastupdate = updatetime

I'd like to add that, usually, time-based modeling requires a multiplying factor to all variables that involve moving, spinning, or timing. It does so to make all movements consistent with one another. However, imagine you have to multiply thousands of variables in a big project. That would add an unneccessary CPU hit. Also, like I've said, there's no point of having 120fps when your monitor refresh is only 60hz, say. It's only a waste of both GPU and CPU resources. Better give back the extra milliseconds back to the system. Cycle-based system only requires you to estimate the time required for a given sequence. If something will last for 2 seconds, and you have a cyclerate of 60cps, then all it needs is 120 cycles. Easy. It doesn't care if the framerate is 30, 45 or 60, the system will try it's best to maintain the cycle rate. I wouldn't say cycle-based systems are perfect. The system is always trying to recalibrate itself, so cycle accuracy isn't 100% on frequently changing framerates. But in comparison with time-based system, it doesn't add extra variable recalculations that would further slow down a slow PC.

But suppose you're using frame-based animation and the user gets something like 20 or 15 FPS... Wouldn't that make the animation slow?

Yeah, even if you have the frame rate capped at 30 FPS, someone will run the game and only get 15 FPS, meaning the game isa only going half the peed it should. This is especially critical in Online games, since multiple characters will have to be kept in sync (can't have the AI moving 2 times as fast as you [;)]).

Sorry about the doiuble post, the page said it could not be displayed, so I assumed it didn't post...

Isn't there a command here to delete posts? It's the second time this happens, just in this thread.

Here's a cycle system: A game running at 30fps/60cps runs at the same time as a game running at 60fps/60cps. It's cycles that determine a loop, not framerates.

Then I think 60 CPS is a too high cap. Still, some peole could get something like 40 CPS for example. In my opinion you should cap the CPS to something like 30 or 40

And how about people who have enough horsepower to run the game? The suggested requirements are nowhere near to PC gamer's Entry Level Configuration, for example. The idea of frameskipping is to let those with less resources to run the game, and yet give those with the requirements the enjoyment of smooth-running game.

well if it's the cycles that determine the loop, then what's the need for the extra framerate limiter? rene

I get 60FPS and 60CPS. But I'm running a Athlon 64 bit 2800+ (1.8GHZ), 1.16 GB of ram, and a Radeon 9800 128MB ram. Nice work though.