Testing please...

Hi All,

[EDIT] - As someone (hi jon) has obviously mistaken my intensions with this post I should state that I am not after the testing of the collision detection routines, rather I would like to know what GL Platforms my app will/won’t run on and what it’s performance is likely to be.

Having just gone through the pain of rewriting/extending my collision routines [EDIT] and feeling the desire to actually release something[/EDIT] I thought I’d throw out a version of my “pet project” to see if I can get some voluntary testing.

An early screen shot of my app is available here .

The actually app can be downloaded here (700kb)

There is a readme.txt in the zip file that has the keyboard controls etc.

I have tested it on a PIII500 with a TNT2 and I develop on an AMD2400+XP with a geforce3. It has run on geforce256 and geforce4. I am currently using Detonator 40.72.

I have absolutely no idea if it will work on ATI based systems.

If some of you could run the app and post approx frame rates (ie. on the first map will do) and if it did/didn’t work that’d be muchly appreciated.

Oh yeah, I am aware that there are some bugs in the collision detection (and there is no sound…). I still have to add edge testing for my sphere->poly collisions.

Thanks,

Scott S.

PS. Hardware specs/driver versions would be good too…

[This message has been edited by rgpc (edited 05-08-2003).]

[This message has been edited by rgpc (edited 05-08-2003).]

[This message has been edited by rgpc (edited 05-08-2003).]

win2k, dual p3 733mhz, quadro4 fx1000, agp4x, 512mb P133 sdram

fps: 155 on average

Nice sphere reflection, nice shadows, choppy collision detection (as you’ve said), appauling trial-and-error game (but then, you’re not a game designer).

Nice one.

EDIT: Detonator driver version 43.45

[This message has been edited by knackered (edited 05-08-2003).]

Works fine on a gf2 here… except for the physic!
Quite often, the ball would just fall through the ground =)
75 - 77 fps

This reminds a game called Slide, or something like that. It was exactly the same kind of game with a 2D view. And it was quite funny.

[This message has been edited by tfpsly (edited 05-08-2003).]

Thanks knackered. I’m certainly not a game designer - not that this is supposed to be overly brilliant - and yes the collision detection is surely my nemesis…

tfpsly I suspect you have seen something I have loosely observed that I can’t seem to explain - the lower the frame rate, the less reliable the collision detection. I can’t quite explain it because all my detection algos are time based sweeps (ie. I calculate the equation of the collision between my two geometric shapes and work out the exact time of the collision). It may be that the slower frame rate just allows things to go wrong because there is a longer period of time to “slip through the cracks”.

I am hoping that the edge testing will sort this out (it’s particularly prevalent on the largest of the test maps - which again is probably due to the frame rate).

The concept of the game is loosely (very, very loosely - it has a ball and it rolls… When it doesn’t fall through the map ) based on “Marble Madness” which I seem to remember playing on the C64.

Cool game idea!

Graphics works fine on Radeon 9700, though the fps seems to slowly decline to long er I play. I starts at 1900fps , then quickly goes down to 90fps, but after a number or levels its down to 40fps.

Originally posted by Humus:
I starts at 1900fps

This seems normal. It seems the fps counter does average on a very long time. So during the first 10(?) seconds, it is that inaccurate, whatever your hardware is (I got such fps too).

then quickly goes down to 90fps, but after a number or levels its down to 40fps.

90 could sounds “normal”, but 40 sounds very low for your hardware.

I saw the same behavior, started at 1200 fps, decreased to a constant 120-140 fps.

The inertia of the ball seems a bit high to me. I’ve noticed a few minor problems with collisions. I thought there was a bug when i hit the tile with arrows the first times, then i understood it pushes your ball in the direction of the arrow.

Once, the ball has fallen through a tile which it should have hit. It was just after a jump in level 4.

Bumps act a bit strange, they do not always make your ball go at the same “height”. It seems like the reaction depends on the arrival angle, which means if you arrive like with a flat angle, you’ll be propulsed with a flat angle too…?

I saw lighting flicker occasionally under some tiles too. It’s very hard, when you’re doing a jump, to evaluate where you ball is going to fall down. The shadow looks nice but confuses you

All in all it seems to have a lot of potential. A solid Marble Madness-like game. I can very well imagine myself playing for hours to that game, if it was a bit more polished, and with more levels/features. I wish you good luck !

System specs: P4-2 Ghz, 1 Gb RAM, Win2k, Radeon 9700.

Y.

Nice!

273FPS on my Radeon 9700 with an Athlon XP 2000.

REALLY COOL!!!Wanna see some more levels!

150-170 fps on GFFX5800 / 2*Athlon MP1200 / Detonators 43.45

g0b

Hi! Downloading as I write… (I need to se this ).

You said that you had worse collision detection when FPS drops. This sounds to me as a typical case of physics time granularity getting to coarse for your equations to be stable. My solution in such cases (except for going through my algo) is to force the time step to a maximum value. If the frame delta time exceeds this maximum value, iterate the physics until the entire frame delta time is covered.

Example: Max physics delta time = 5 ms, Frame time = 12 ms, which means:

DoPhysics( dt = 5 );
DoPhysics( dt = 5 );
DoPhysics( dt = 2 );
Draw();

Hope you see what I mean.

BTW: Nice! I love those simple yet brilliantly looking and hard to conquer games - just as back in the C=64 days

Athlon 720MHz + Ti4200 : 210-230 FPS

Edit: I would like to see some control to rotate the camera. And another idea: the ball Y position is kind of “jittery”. Perhaps you can add a lowpass filter to the Y coordinate?

[This message has been edited by marcus256 (edited 05-08-2003).]

So much to answer and so little time!

Originally posted by Humus:
Cool game idea!

Thanks. The basic idea is an old one but it’s been a good exercise for me to actually apply some ideas etc. that I’ve had for a while. I was initially going to create a driving came and created a room with a bouncing ball in it to work out my initial collision detection routines. It was kind of fun to move the ball around the room and it reminded me of Marble Madness so I continued on what you’ve already seen…

Graphics works fine on Radeon 9700

Phew…

though the fps seems to slowly decline to long er I play. I starts at 1900fps , then quickly goes down to 90fps, but after a number or levels its down to 40fps.

Hmmm… How long does “1900fps” hang around? It might be (I’ll have a look tonight) that 1900fps is the frame rate on the Menu and you see that for the first couple of seconds. The latter levels are a bit more complex so there should be a bit of a decline (there’s still quite a bit of optimisation to be done).

What processor are you running?

Originally posted by tfpsly:
90 could sounds “normal”, but 40 sounds very low for your hardware.

Agreed, but it might be processor dependant.

As for the fps it counts the frames and determines the fps every 2 seconds (which is kind of long but I haven’t got around to changing it). This is simply - count frames for 2 seconds, divide by 2. If it takes any more than 2-4 seconds to decline to 90fps or so then there’s something else causing this (could be rather difficult to find given I don’t have access to a radeon - but a friend might be upgrading to one soon so that’ll help).

Originally posted by Ysaneya:
The inertia of the ball seems a bit high to me. I’ve noticed a few minor problems with collisions.

The collision response certainly needs to be looked at, as does the actual collision detection. There is a more stable version of the collision detection that I can turn on (ie. Use Vert->Poly for all objects) but it is slower.

I thought there was a bug when i hit the tile with arrows the first times, then i understood it pushes your ball in the direction of the arrow.

Surprise!

Should have put a description of the tiles in the readme… The tiles with the arrows accelerate the ball in the direction it is travelling, so if you’re on a narrow path then you need to be travelling in a straight line.

Once, the ball has fallen through a tile which it should have hit. It was just after a jump in level 4.

There’s two primary ways this can happen. The first is if you are jumping onto a part of the map and you just hit the edge of the map. There’s no edge detection at the moment so it’ll most likely go straight through.

The second is if you are rolling along the landscape and you suddenly “slip through a crack” - I’m not sure why this happens, and it seems to happen more then the fps is lower - but edge detection should fix this.

Bumps act a bit strange, they do not always make your ball go at the same “height”.

(I presume you mean the “bounce pads”) These simply set the value of the Y of the velocity of the object that hits it. (I think that’s right - I’ll have to have a look at it again…) So if you are moving quickly & almost horizontally you will shoot off on a parabolic tragectory. If you’re not seeing this then maybe there’s something wrong (and that’s going to be difficult to track).

I saw lighting flicker occasionally under some tiles too.

Yeah, it’s most likel on the map with the “almost vertical” bounce pad - I’ve noticed it too. I’ll have to play around with Polygon offset to see if I can eliminate that. But it has less flicker than Splinter cell and that game seems to be immensly popular - so mine would have to be more popular!

The shadow looks nice but confuses you

It’d probably benefit from having the shadows fixed as being vertical (perhaps that could be a difficulty setting). But heck, it’s my very first app with shadows so Im happy. Originally it didn’t have shadows and I didn’t have any problems judging where I was going to land, but now if I turn them off I keep falling off the map.

All in all it seems to have a lot of potential. A solid Marble Madness-like game. I can very well imagine myself playing for hours to that game, if it was a bit more polished, and with more levels/features. I wish you good luck !

Woohoo! Thanks for the encouragement. I actually didn’t play much marble madness - but I’m having a ball (sic) writing it. I’m really looking forward to my next probable project - SNOKIE (Anyone remember that one?)

Originally posted by NitroGL:
[b]Nice!

273FPS on my Radeon 9700 with an Athlon XP 2000.[/b]

Nice frame rate (as it should be…)

Originally posted by Mihail121
REALLY COOL!!!Wanna see some more levels!

That’s what the level editors for! I’ll sort out the collision det probs and add in some baddies (evil balls) etc. and then… (Got aways to go…)

Originally posted by Gob
150-170 fps on GFFX5800 / 2*Athlon MP1200 / Detonators 43.45

Originally posted by marcus256
Athlon 720MHz + Ti4200 : 210-230 FPS

This is kinda wierd isn’t it? (Actually it’s very wierd) Gob is it possible that you have FSAA turned on? I am surpised by marcus256’s performance - it certainly indicates that there isn’t necessarily a CPU limit on the performance (rather it’s fill limited).

Originally posted by marcus256:
You said that you had worse collision detection when FPS drops. This sounds to me as a typical case of physics time granularity getting to coarse for your equations to be stable.

My coln det is done recursively (and you may have indicated my problem). Each frame (I’ll see if I can improve that later) I test all my objects by “solving” the equation of their motion for t and finding the lowest t for each object. I then recurse until I have either hit a limit (which I think is 10 recursions) or I have used up all of the t available for the current frame. If someone can see any obvious flaws in this technique please point it out…

Edit: I would like to see some control to rotate the camera. And another idea: the ball Y position is kind of “jittery”. Perhaps you can add a lowpass filter to the Y coordinate?

Control of the camera will be added later on.

I am aware of the jittery nature of the Y position. This is possibly because after all the motion has been updated, I do a check to ensure that none of the objects have accidentally penetrated other objects.

This is necessary when I am calculating “Vert->Poly” collisions as the collision detection is done using the linear velocity of the object, and then the object is rotated, and this can cause vertices to enter into a target object. I will definitely look at a low pass filter though, thanks for the suggestion…

What I might do, is go sell a kidney or two so I can buy one or more of the Gems books as I have found that for the most part, collision detection tutorials etc. suck on the Web. Most seem to be of the level “If you want to detect collisions, you can use bounding spheres” which has far too little detail for what I am trying to accomplish…

And finally…

Thanks all for having a squiz. My main aim was to find out if it ran on ATI and how it ran on different configs. I’ll post another version in a couple of weeks when I’ve ironed out a few more of the problems…

Originally posted by rgpc:
[b]Hmmm… How long does “1900fps” hang around? It might be (I’ll have a look tonight) that 1900fps is the frame rate on the Menu and you see that for the first couple of seconds. The latter levels are a bit more complex so there should be a bit of a decline (there’s still quite a bit of optimisation to be done).

What processor are you running?[/b]

It hangs around a couple of seconds only …
Anyway, it seams it takes quite a performance hit with FSAA. Turning FSAA off and I get the same performance as NitroGL.

I did notice though some flickering in one level, but only at one place in one level. It’s the level which begins with a quite sharp ramp, like level 4 or 5 or so. The side of that ramp flickers a little.

Are there any strategies for minimizing the impact of FSAA? I guess the two (multi) pass nature of shadow volumes would cause an increase in the impact (or I could be wrong - I don’t know much about FSAA). If that’s the case then shadow buffers would probably help.

I could also try to force FSAA off when doing the reflections too… (Anyone know how?)

Sounds like the flickering is in the area I have noticed it. Its something i tried to fix by offsetting the sihouette vertices a small amount, which certainly helped. i’ll have to fiddle with Polygon offset to try and eradicate it…

Originally posted by rgpc:
This is kinda wierd isn’t it? (Actually it’s very wierd) Gob is it possible that you have FSAA turned on? I am surpised by marcus256’s performance - it certainly indicates that there isn’t necessarily a CPU limit on the performance (rather it’s fill limited).

I was a bit surprised too. I got quite varying FPS depending on track and zooming etc. The >200 FPS figure was taken at the first track, without moving, a minute or two after the game started (thought that would be the most repeatable figure).

Anyway, I have heard that those new flashy cards (GeForceFX & latest Radeons) have ditched the fixed function T&L path, and implement “legacy” OpenGL with vertex programs (is this also true for the tex/combiner path?), making “old” apps run slower on these new cards than on older cards (check http://www.tomshardware.com/graphic/20030311/index.html for some interesting figures - Ti4200 outperforms FX5600 Ultra).

Another thing is that I OC:d my Ti4200, so I think it’s somewhere in between Ti4400 and Ti4600.

[This message has been edited by marcus256 (edited 05-08-2003).]