PDA

View Full Version : Testing please...



rgpc
05-08-2003, 04:12 AM
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 and feeling the desire to actually release something 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 (http://www.cendantmobility.com.au/Delivery/Image_0004.jpg) .

The actually app can be downloaded here (http://www.cendantmobility.com.au/Delivery/Test_20030508.zip) (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).]

knackered
05-08-2003, 04:32 AM
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).]

tfpsly
05-08-2003, 04:46 AM
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).]

rgpc
05-08-2003, 05:02 AM
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... http://www.opengl.org/discussion_boards/ubb/wink.gif

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 http://www.opengl.org/discussion_boards/ubb/wink.gif ) based on "Marble Madness" which I seem to remember playing on the C64.

Humus
05-08-2003, 05:39 AM
Cool game idea! http://www.opengl.org/discussion_boards/ubb/smile.gif

Graphics works fine on Radeon 9700, though the fps seems to slowly decline to long er I play. I starts at 1900fps http://www.opengl.org/discussion_boards/ubb/eek.gif, then quickly goes down to 90fps, but after a number or levels its down to 40fps.

tfpsly
05-08-2003, 06:38 AM
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.

Ysaneya
05-08-2003, 07:14 AM
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.

NitroGL
05-08-2003, 07:36 AM
Nice!

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

Mihail121
05-08-2003, 08:20 AM
REALLY COOL!!!!Wanna see some more levels!

Gob
05-08-2003, 12:01 PM
150-170 fps on GFFX5800 / 2*Athlon MP1200 / Detonators 43.45

g0b

marcus256
05-08-2003, 12:30 PM
Hi! Downloading as I write... (I need to se this http://www.opengl.org/discussion_boards/ubb/biggrin.gif ).

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 http://www.opengl.org/discussion_boards/ubb/wink.gif

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

rgpc
05-08-2003, 05:12 PM
So much to answer and so little time! http://www.opengl.org/discussion_boards/ubb/biggrin.gif


Originally posted by Humus:
Cool game idea! http://www.opengl.org/discussion_boards/ubb/smile.gif

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 http://www.opengl.org/discussion_boards/ubb/eek.gif, 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?

rgpc
05-08-2003, 05:16 PM
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).

rgpc
05-08-2003, 05:38 PM
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.


http://www.opengl.org/discussion_boards/ubb/biggrin.gif 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! http://www.opengl.org/discussion_boards/ubb/biggrin.gif



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. http://www.opengl.org/discussion_boards/ubb/smile.gif 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?)

rgpc
05-08-2003, 05:48 PM
Originally posted by NitroGL:
Nice!

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

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! http://www.opengl.org/discussion_boards/ubb/biggrin.gif 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).

rgpc
05-08-2003, 06:05 PM
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...

rgpc
05-08-2003, 06:07 PM
And finally... http://www.opengl.org/discussion_boards/ubb/biggrin.gif

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

Humus
05-08-2003, 07:03 PM
Originally posted by rgpc:
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?

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.

rgpc
05-08-2003, 08:02 PM
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...

marcus256
05-08-2003, 10:50 PM
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).]

CAD_Swede
05-08-2003, 11:26 PM
Originally posted by rgpc:
Hi All,

[B]PS. Hardware specs/driver versions would be good too...


hey! Very cool. 150fps on Radeon9700Pro with a dual 1000 MHz Pentium III Xeon system.

However, I did notice something you might want to look into. On the first level, when the ball was launched 'up' on the starting tile, there was a greyish circle that seemed to be an artifact of the shadowing code down in the "down-right" corner of the board.

Edit: This didn't happen on the first start, only on subsequent respawns when I had rolled myself off the board.

Not sure how to describe this, though. I took a screen dump that I could send you, if you want to give me your Email address? (Maybe it's on your profile here, tell me if you want the screen shot, it's half a meg in size.)

Good idea to always put in a screen dump feature in ones code. Nice game idea, too! Very Marble Madness like, as others have said.

Good luck!

/Henrik


[This message has been edited by CAD_Swede (edited 05-09-2003).]

[This message has been edited by CAD_Swede (edited 05-09-2003).]

tfpsly
05-08-2003, 11:43 PM
Originally posted by rgpc:
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 .

Then there is something else causing this on my Gf2mx + Athlon XP 2000+ :-P

EDIT : I mean that the fps counter starts displaying some insane too high value, and then slowly converge to 70 fps (it takes a delay of maybe 10 seconds). As if you were averaging current fps and the previously computed one, to get rid of too fast changement.

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

Ysaneya
05-09-2003, 12:44 AM
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.


I'd simply place the light on top of the scene, so that all shadows fall back under the ball. It's not easy to evaluate the heights with an isometric view.. but you should definately put the shadow in. I remember Marble Madness, and how difficult it was to control the ball when you jump. If you want a difficulty setting, you could even make the light source move randomly, to confuse the player :)

Y.

knackered
05-09-2003, 01:12 AM
Maybe you should all use fraps ( http://www.fraps.com ).
I'll try it with fraps to see what the real frame rate is when I've got a min.

rgpc
05-09-2003, 01:30 AM
Originally posted by CAD_Swede:
However, I did notice something you might want to look into. On the first level, when the ball was launched 'up' on the starting tile, there was a greyish circle that seemed to be an artifact of the shadowing code down in the "down-right" corner of the board.


Hi Henrik,

I might know what this is but I'd like to see the screen grab. It might be the fact that on non-nVidia hardware (and TNT2) I don't have access to NV_depth_clamp, so it might be an artifact caused by the shadow volume not being closed off. I did make a short attempt at using infinite shadow volumes but the results I got were a little unexpected (which was probably due to a bug I found a bit later).

If you could e-mail me the screen grab that'd be great (my profile has the e-mail). I'll probably have to revisit the infinite shadow volume (or think of some other way of closing the volumes correctly).

You can probably also notice that the shadowing on the map "walls" has holes in it (visible when you are at the top of the initial "bounce" after respawning). This is the same problem (not a problem on geforce tho')

Ysaneya
05-09-2003, 01:33 AM
Probably a stupid question, but how do you use the level editor ? I couldn't figure out how to add some tiles, mouse buttons didn't seem to have any effect ?

Y.

rgpc
05-09-2003, 01:47 AM
Ah, yes... Not a stupid question at all (pretty dumb that I didn't supply any docos - again... http://www.opengl.org/discussion_boards/ubb/smile.gif)

Firstly, the level editor needs much improvement.

You start by (A) loading an existing map or (B) creating a new map. If you select (B) then you need to enter the width and height of the desired map (say 32x32). The maximum number of "tiles" will be w-1xh-1.

When you've clicked OK the top left will show a basic 2d representation of the map (which starts as a single blue square in the middle of the map area). Each square in this 2D representation is a single point in the map - 4 adjacent points makes a single tile.

You have 2 tool groups available - height & tile type. Height allows you to raise & lower (for now) the points to create the altitude and slope of your tiles. Tile type lets you add the start, finish, bounce and "zoom" tiles in your map.

Select the Height tool group and click "+" (the default tool). Click to the left, above and above left of the existing point (in the 2D map). Each time you do this the square you clicked on get coloured blue. If you pause for a second (or two) the map will display your efforts in a 3D representation, with the camera centred on the last point you clicked.

The tile types operate a little differently. Instead of clicking on 4 points to make a square, you need only click on the bottom right point to set that square to your desired type.

Have a look at some of the test maps to see how they are set up (test.map is a good start).

If you want to add your map into the game save it as testx where x is a number from 7 onwards (the game increments through test.map, test2.map ... etc.)

Hope that helps... http://www.opengl.org/discussion_boards/ubb/biggrin.gif

Jan
05-09-2003, 03:03 AM
Nice game.
Runs smoothly (also the collision detection) on an Athlon 1.3 GHz, with a Geforce 4200.

BUT! Donīt use the ^ key for the console! I could still choke id for doing that, since NO program does this on german keyboards. I donīt know how id does it, they are the only ones, where it does work.
Why donīt you use F1 or TAB.

Jan.

CAD_Swede
05-09-2003, 04:42 AM
Originally posted by Jan2000:
BUT! Donīt use the ^ key for the console! I could still choke id for doing that, since NO program does this on german keyboards. I donīt know how id does it, they are the only ones, where it does work.

ID does it though nasty conversion tables and by treating '`' and '~' as completely separate, hardcoded, non-overridable special cases. They listen to the scan code of the keys rather than the normal Windows VK_XXX codes, etc, etc... It's quite quite nasty and the reason why others can't implement it like ID does is that they refuse to stoop that low. ;-)

/Henrik

marcus256
05-09-2003, 05:11 AM
I agree 100% with Henrik! ID may have done many good things for uss (OpenGL, for one thing), but the "console key" is the one thing I really blame ID for. I have had several headaches regarding that key when I designed GLFW. Many people want me to put in support for "the console key", but after many twists and turns, I came to the following conclusion (quite simple, really):

ID is using a character key as a function key! It's a no-no don't-do! It would be like me (being Swedish) using the letter Å for bringing up a console or whatever.

Hence, in GLFW all keys are mapped according to the localized setting, meaning that characters (printables) may differ from language to language. Function keys, such as F1-F..., the arrow keys, page up/down etc, are pretty safe though.

Wouldn't it be logical if we used page down/up for showing/hiding the console (if it's the flashy style that rolls down/up on the screen)? Come to think of it, some keyboards/systems do not support page up/down. F1 or TAB are good alternatives.

Uhm, sorry for going OT (again)


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

abrodersen
05-09-2003, 05:28 AM
Nice game, but the graphics i quite ****ed up on my PC (PIII 933Mhz, Radeon 9700 Pro).

There's a screendump at http://www.daimi.au.dk/~rip/TestImage.png

Don't know if this is my card that is broken, or it is a common thing for Radeon cards! I've noticed the problem in other apps aswell, though never as bad as this.

Anders

rgpc
05-09-2003, 05:29 AM
Actually I plan on making the keyboard remappable so it won't matter whether it's squiggly (~) or bent (^). http://www.opengl.org/discussion_boards/ubb/biggrin.gif

I think TAB is probably the best idea. Although if I were doing an FPS I'd immediately associate TAB with bringing up the Multiplayer scores...

rgpc
05-09-2003, 05:36 AM
Originally posted by abrodersen:
Don't know if this is my card that is broken, or it is a common thing for Radeon cards! I've noticed the problem in other apps aswell, though never as bad as this.


Yek! I'll take the easy line and say that I think it might be your card/drivers, but it could be anything really. I wonder if anyone else has seen this? Are the artifacts animated? Or do they just stay in one place?

Are you overclocking? Do the artifacts reduce (in number or size) when you zoom out? If you turn shadows & dynamic cube mapping off (S & C on the keyboard) do they change in any way?

Maybe there's something wrong (with the card/drivers) that is being triggered by something in the way I draw my geometry?

abrodersen
05-09-2003, 05:50 AM
The artefacts are animated. They are jumping around like small bugs ;-)

If I zoom out, it appears that there's fewer artefacts, but I can't really say for sure.

Turning shadows off, all of the large dots disappear and 99% of all the small dots disappear aswell, leaving the same number of artefacts as I get in other apps.

Cubemapping didn't change anything.

The card is not overclocked, and the drivers are standard Catalyst 3.2 drivers. You are probably right about it being the card. :-(

Anders

rgpc
05-09-2003, 06:10 AM
I'll hazard a guess and say that maybe something is wrong with the z-buffer on the card (or driver...). One way to test it would be to change the line...

setvar gl_drawskybox 0

to

setvar gl_drawskybox 1

in the ball.cfg file.

Then have a look and see if the dots are suddenly the colour of the back ground (although this may not work). I kind of suspect that maybe you can see all the way through the geometry for some reason (could be way off though but it might be worth testing - why I don't know http://www.opengl.org/discussion_boards/ubb/smile.gif)