666 replies to this topic

[lio]

Changing the physics engine in VP would sort of turn VP into not being VP anymore I fear - I would also be very careful about that.

Concerning generic physics engines and the physics in FP: I doubt anything generic will really be as good as what VP has now.

But still I think "newton game dynamics" (the engine used in FP) is a very capable engine and I would imagine that they have made quite some good progress since the version that FP used.

Also the default settings in FP could have been better - people have made some changes for the better by adjusting the physics values that FP uses - I remember the .xml file with those values used to be an external file during FP's development but tweaking it with just the few people that had access to FP at that point wasn't easy and noone really enjoyed playing around with those values compared to doing other work...

So if Black deceided to properly update FP with a more recent version of the newton physics I believe it could play a lot better than last public version does.

[jimmyfingers]

@JF: do you mean the flipper made out of 3d primitives are faster than the build in (now dynamic) standard flippers? If that's the case the requested model manager could be a solution to have both standard flippers or if you like the real 3d ones.

Yah, they were but after some testing the difference isn't that much but was still slightly favoring the WIP 22b build of the table we're working on with the 3D flippers vs. the 22b build without on rev896 on my development system.  However to be sure and get exact elements I did some testing today and here are the results using both my development system and the mini-cab:

 

Testing set-up for both systems:

- Windows7

- no AA on,

- driver version 331.65

- VP closed and restarted for each test

- FPS / f11 hit immediately when the game started

- credits not entered until game fully booted (ROM wise)

- game started and ball left in plunger

- 3 samples for each config

- mini-cab is i5-4670K with GTX 760, VP running at 1920x1080

- development system is i5-760 with GTX 580 Ti, VP running at 1280x720

 

Development System:

Build rev893:

WIP table 22b:

 377, 366, 382 = 375 average

 

WIP table 22b with 3D mesh flippers:

359, 350, 351 = 353.3 average

 

Build rev896:

WIP table 22b:

349, 338, 350 = 345.7 average

 

About a 6% drop for going to 3D primitives and a 8% drop with same table on rev896

 

 

Mini-Cab System:

Build rev893:

WIP table 22b:

573, 576, 572 = 573.7 average

 

WIP table 22b with 3D mesh flippers:

532, 531, 531 = 531.3 average

 

Build rev896:

WIP table 22b:

536, 537, 537 = 536.7 average

 

About a 7.5% drop for going to 3D primitives and a 7% drop with same table on rev896

 

So, overall the difference between the 3D mesh flippers in this table as opposed to without and using rev 896 is about the same (one system got slightly better performance and one got slightly worse).  Overall, isn't it still a bit strange that it's so close considering one is the 3D mesh and one is the native, albeit now dynamically rendered flippers?  Of course, I know this depends on the polygons of the 3D mesh that was used and fuzzel could comment on that, but I imagine they were built pretty efficiently considering the results / numbers (although they do look a fair bit better than the stock flippers IMHO).

Edited by jimmyfingers, 26 January 2014 - 07:49 PM.

[koadic]

Hey fuzzel, I finally got back to working on a table with flashers after they were changed in 838, and it seems that no matter how I rotate the flasher, the image remains oriented the same way... this can be seen in the editor as well by checking the 'show image' box (effects 838 and on). This is really only an issue when using a half image, but makes it completely useless in these cases.

Also, while I am typing out a post anyway... I was wondering if the z offset in the backdrop settings could either be altered or have a new option added. Currently, the z offset acts more as a zoom lens (hell, that option could even be renamed to 'zoom') while I would prefer it to be a camera height adjustment. To use JP's Haunted House table as an example, the main playfield is raised by about 400 units (if I remember correctly) which completely throws the view settings out of whack where it is hard to get a decent view of both the flippers and playfield. This is the reason I initially modified the table so it could be brought down to only 100 units highto be able to get some better view settings. What I'd like is the ability to set a height offset to 400 (if you are effecting the camera) or -400 (if you are effecting the table) and make the playfield appear as if it were set to a height of 0.

[toxie]

I ask because I've often noticed that even when VP reports framerates of 60 or more, which should be absolutely sufficient for smooth gameplay, it often still seems to stutter. Is this a case of VP reporting a wrong framerate? Or maybe there are some quirks in its physics/timing code which make gameplay not smooth even at framerates at which it should be. I wonder if there is any insight on this.

 

There are various reasons for this:

a) the physics in VP ideally would run at a constant 100Hz, but if the framerate drops below that or even if the framerate is <200FPS, then the physics engine will try to catch up and do multiple iterations per frame (and on some rare frames will basically do nothing in contrast). this then leads effectively to an uneven animation (basically temporal aliasing in the animation of the ball(s), etc).

b) VPM runs in the background/separate thread and is also updating its emulation/sound at a fixed rate (depending on the emulated hardware), thus some frames can take longer to render in VP as the CPU might be busy with VPM (shouldn't be an issue on multicore, but apparently it still is for whatever reason, the code interaction of VP and VPM is pretty not straight forward, at least for me)

c) some frames in VP currently take much much longer than others, f.e. if a whole lot of lights are switched on/off/faded at the same time. this is smoothened out by the FPS counter, but the ball animation of course will look funky then to the human eye.

d) missing vsync

 

 

As for physics: i would also say that we should stay away from other physics packages for now. the main missing feature is collision detection with primitives, and i guess we could handle this with the already existing octree code in VP. we just have to sort the triangles (or a rough approximation of the object via bboxes) into the octree and this should (in theory) work then.

Edited by toxie, 26 January 2014 - 08:28 PM.

[fuzzel]

 

@JF: do you mean the flipper made out of 3d primitives are faster than the build in (now dynamic) standard flippers? If that's the case the requested model manager could be a solution to have both standard flippers or if you like the real 3d ones.

Yah, they were but after some testing the difference isn't that much but was still slightly favoring the WIP 22b build of the table we're working on with the 3D flippers vs. the 22b build without on rev896 on my development system.  However to be sure and get exact elements I did some testing today and here are the results using both my development system and the mini-cab:

 

Testing set-up for both systems:

- Windows7

- no AA on,

- driver version 331.65

- VP closed and restarted for each test

- FPS / f11 hit immediately when the game started

- credits not entered until game fully booted (ROM wise)

- game started and ball left in plunger

- 3 samples for each config

- mini-cab is i5-4670K with GTX 760, VP running at 1920x1080

- development system is i5-760 with GTX 580 Ti, VP running at 1280x720

 

Development System:

Build rev893:

WIP table 22b:

 377, 366, 382 = 375 average

 

WIP table 22b with 3D mesh flippers:

359, 350, 351 = 353.3 average

 

Build rev896:

WIP table 22b:

349, 338, 350 = 345.7 average

 

About a 6% drop for going to 3D primitives and a 8% drop with same table on rev896

 

 

Mini-Cab System:

Build rev893:

WIP table 22b:

573, 576, 572 = 573.7 average

 

WIP table 22b with 3D mesh flippers:

532, 531, 531 = 531.3 average

 

Build rev896:

WIP table 22b:

536, 537, 537 = 536.7 average

 

About a 7.5% drop for going to 3D primitives and a 7% drop with same table on rev896

 

So, overall the difference between the 3D mesh flippers in this table as opposed to without and using rev 896 is about the same (one system got slightly better performance and one got slightly worse).  Overall, isn't it still a bit strange that it's so close considering one is the 3D mesh and one is the native, albeit now dynamically rendered flippers?  Of course, I know this depends on the polygons of the 3D mesh that was used and fuzzel could comment on that, but I imagine they were built pretty efficiently considering the results / numbers (although they do look a fair bit better than the stock flippers IMHO).

 

Thanks Jimmy for testing. The 3D mesh flippers should have nearly the same amount of polys as the stock flippers but the amount is a bit higher. That means that the behavior is the expected one. Rendering polygons with DX7 is slower than just blitting an image. The 3D mesh flippers look better because I can use textures on meshes where the stock flippers don't support that.

 

 

Hey fuzzel, I finally got back to working on a table with flashers after they were changed in 838, and it seems that no matter how I rotate the flasher, the image remains oriented the same way... this can be seen in the editor as well by checking the 'show image' box (effects 838 and on). This is really only an issue when using a half image, but makes it completely useless in these cases.

Also, while I am typing out a post anyway... I was wondering if the z offset in the backdrop settings could either be altered or have a new option added. Currently, the z offset acts more as a zoom lens (hell, that option could even be renamed to 'zoom') while I would prefer it to be a camera height adjustment. To use JP's Haunted House table as an example, the main playfield is raised by about 400 units (if I remember correctly) which completely throws the view settings out of whack where it is hard to get a decent view of both the flippers and playfield. This is the reason I initially modified the table so it could be brought down to only 100 units highto be able to get some better view settings. What I'd like is the ability to set a height offset to 400 (if you are effecting the camera) or -400 (if you are effecting the table) and make the playfield appear as if it were set to a height of 0.

Do you mean rotating the flashers in the editor and the image remains the same? If so then it's a known problem. VP uses the function StretchBlt() to show the texture in the editor but StretchBlt only supports blitting an image into a rectangle area. If you rotate a flasher the area isn't a rectangle anymore

As for the camera: I will have a look later on that.

 

As for physics: i would also say that we should stay away from other physics packages for now. the main missing feature is collision detection with primitives, and i guess we could handle this with the already existing octree code in VP. we just have to sort the triangles (or a rough approximation of the object via bboxes) into the octree and this should (in theory) work then.

 

If the mesh is an easy one there is no problem generating collision to it but complicated ones are not that easy to approximate. Well I've never done that before so maybe I'm wrong here.

[toxie]

as said, in theory it should be enough to sort the triangles brute force into the octree. the bbox idea would just be an optimization to avoid that the octree becomes too deep.

 

and from what i remember the octree handles the rough collision phase, and then we basically need just an additional collision test for each leaf of the octree (i.e. triangle-sphere collision, should be easy).

[koadic]

Fuzzel, starting in 838 the image is no longer rotated in the player so basically the RotZ value has no effect.

[fuzzel]

Fuzzel, starting in 838 the image is no longer rotated in the player so basically the RotZ value has no effect.

rev 901 should fix this!

[fuzzel]

Ladies and gentlemen, please try rev 902. It introduces basic collision detection to mesh primitives. It seems to work quite well but I guess you can't use it as an alternative to a ramp so far.

[koadic]

I can't compile at the moment as I am at work, but I assume this also includes _Hit events, and hit threshold and the like?

[fuzzel]

Neither of them at the moment. But I'm working on them And good news: It should be possible to use a mesh primitive as a ramp

[toxie]

curious to see how you implemented that, cool work!

[fuzzel]

To be honest: the whole magic was already there

rev 903 adds the hit threshold and the hit event for mesh primitives

[unclewilly]

Hey fuzzel. My mb table has mesh wire ramps would be a great tester for mesh collision.

Wish this was in 9.2. Would have made the Drac code much easier

[koadic]

Just tried the collision on a wire ramp primitive and didn't have good results... It is a basic 4 wire ramp which I know is scaled properly, but as soon as the ball gets to the beginning of the ramp it's like it is hitting a wall and won't go through the ramp. At least there is collision, and assume it can easily be used for targets, but I am not even sure if a standard ramp built from a primitive would work or if it would just get stopped at the beginning. Will have to build one and run some tests...

EDIT: Well, after making a quick ramp, the ball will go past the starting point if I made it sufficiently wide enough, but it would not go all the way up the ramp. It would fall through part of the way up and then get stuck. I may have to try building the ramp another way though, as it really only has one side (the inside).

Edited by koadic, 27 January 2014 - 03:16 PM.

[fuzzel]

It can be a challenge to model a good mesh which can be used as a ramp. I haven't tried to create a wired ramp but it should be possible I guess...Here is a quick test table I used to test the implementation. The primitive in the middle of the table is a stretch ball cut in half. One other primitive (not on the table) is a simple bump mesh plane to see if the ball follows the bump and it does. I guess we have to experiment a bit with the collision detection and meshes

Attached Files

•  prim2.vpt   212KB   8 downloads

[toxie]

i'll take a look at the code this evening and see if somethings seems fishy with it..

[fuzzel]

Of course it's fishy, It's VP's physics engine

[mukuste]

It seems to me that the new collision code for primitives is basically adapted from the ramps one to one? This should mean that, barring bugs, a primitive which has the same geometry as a built-in ramp should give the same physics response?

[fuzzel]

Yes and no...parts are used from the ramp code and others from the surfaces. But the main collision code is the same