2087 replies to this topic

[mukuste]

 

Also after changing the Transparency in Atlantis (Bally)(1989)(Icpjuggla, Oldskoolgamer, Herweh)(1.2 Mod), lights don't black out.  The post inbetween the flippers goes black when in the down position.  I tried changing the post images to use black transparency, but no go.  any ideas on this one?

I couldn't figure out a workaround. mukuste, to test the animated BumperPost primitive, open debug window and type in "solbumperpost 1" to toggle between up and down positions.(for those that want to try this, you need to click on the playfield afterward, to allow the table to execute)

 

I think the primitive simply drops under the playfield surface. Changing the relevant line to include a small offset,

	BumperPost.RotAndTra5 	= BPStep * 2.5 + 1

fixes the issue for me.

[koadic]

It probably has to do with either the playfield image or a light (gi or otherwise) as the primitive lowers down to playfield height when lowered (down to 0 if I recall correctly, or close anyway). EDIT: spelling correction due to phone 'autocorrect'

Edited by koadic, 02 March 2014 - 02:55 PM.

[Slydog43]

you guys are awesome, fixed it right up and makes a lot of sense, thanks

[gtxjoe]

thanks for the quick reply and making these things easy and fun to learn about.  Ball does NOT get cut off now, thanks.  Still black spot on table now.  I tried moving wall up down, transparent, but I don't know what I am doing. JF, do you mind telling me this fix.  Thanks   (fun making fixes) 
 
Could I put a decal of a kicker cup on ??

That Haunted House kicker has a light insert, lgi5x, in the center of the kicker. That needs to be higher than the elevated playfield (height at 400) also. Try setting it to the same surface as your kicker or one slightly higher. On the unmodified table, I put it on a surface at height 401 at the kicker insert became visible

[IPJball]

Hey again,

Just used the latest dx9 test 7, and I noticed Funhouse night mod fs now has the same z fighting as Funhouse JPSalas fs now.

So, as Mukuste said, it is a table fixer. So would you please JPSalas, Aaron James, Koadic, and Teppotee take a look at those two?

If this can be fixed, it would be awesome! Thank you all for all your hard work again!

Thanks!

[jimmyfingers]

 

thanks for the quick reply and making these things easy and fun to learn about.  Ball does NOT get cut off now, thanks.  Still black spot on table now.  I tried moving wall up down, transparent, but I don't know what I am doing. JF, do you mind telling me this fix.  Thanks   (fun making fixes) 
 
Could I put a decal of a kicker cup on ??

That Haunted House kicker has a light insert, lgi5x, in the center of the kicker. That needs to be higher than the elevated playfield (height at 400) also. Try setting it to the same surface as your kicker or one slightly higher. On the unmodified table, I put it on a surface at height 401 at the kicker insert became visible

 

That may work but I just checked it and the easiest way and one which will likely fix some potential other items, is to change the transparency colour for the "pf" and "pf_on" images from the green it's currently set at to the pure black fix that is required on some tables now as previously discussed.  Do this change and set the kicker cup to kickerhidden and the black spot will be gone.  

 

 

I've been testing these updates since the first version and after about the fourth test version, I updated my Cab to play either the DX9 version or the DX7 version depending upon the table.  Today, after testing v7, I am very happy to say all of my tables on my cab (~135) are now running the DX9 version.  There are still a few minor glitches but nothing that jumps out and detracts from the game play.  Mukuste, you are incredible.  Your talent, dedication, and perservernce are truly inspiring.  JimmyFingers, You are the very best at troubleshooting and explaining how things work.  Reading your posts is like taking a 300 level college course on how VP works.  And a huge thanks to all of the others who have helped push this major acomplishment to this level in such a short time.  You make me very proud to be part of this community.  GREAT JOB!

 

Your post made my day!  Thanks for taking the time to express your kind thoughts and the original way that you've phrased it  Are you still doing any DB2S backglasses?  Yours were my favourite with the detail you put into them and in being actually authentic as well as how you did your warm lighting (some of the LEDS looked 3D even / recessed sometimes just like on a real back glass)!

Edited by jimmyfingers, 02 March 2014 - 05:04 PM.

[Practicedummy]

Not directly related to the topic, but I am amazed that the ball has weight and has been improved upon since VP 9.1. Seems to behave like a real machine. Need to adjust flipper and table settings on VP tables now.

[mukuste]

Not directly related to the topic, but I am amazed that the ball has weight and has been improved upon since VP 9.1. Seems to behave like a real machine. Need to adjust flipper and table settings on VP tables now.

 

It's funny that several people have remarked now that the physics feel improved to them. Since I didn't change anything on the physics code, I can only guess that it's purely from the increased framerate and reduced stutter.

 

But I'm already determined to improve several things about the physics code once this DX9 port is finished!

[htamas]

Thanks for the idea about how to fix the kicker cup issue. It works on many tables, but for instance on Elvira and the Party Monsters, selecting KickerHidden results in the ball just passing the kicker hole. Also, doing the 8h wall and setting it as the kicker surface makes the kicker pretty much being just a circle instead of a darker hole on the playfield.

Obviously I don't know what I'm doing ( no surprise there), but what's the correct way to fix this table? At the same time, it would be nice to even change the original look of the kicker so that it appears like a proper kicker hole, not just the dark dimple on the playfield...

[ClarkKent]

Not directly related to the topic, but I am amazed that the ball has weight and has been improved upon since VP 9.1. Seems to behave like a real machine. Need to adjust flipper and table settings on VP tables now.

 
It's funny that several people have remarked now that the physics feel improved to them. Since I didn't change anything on the physics code, I can only guess that it's purely from the increased framerate and reduced stutter.
 
But I'm already determined to improve several things about the physics code once this DX9 port is finished!

It seems to have something to do with free resources as the DX9 port does not need full graphics power. But in my experience this applies only to tables with vsync deactivated. There seem to be a similar behavior in Unity 3D - the physics also behave a litte bit different if framerate drops.

Nevertheless it's still lightyears away from behaving like a real pinball machine. The ball does not really feel like a steel ball. Mass is missing. But I have to admit that if I compare real machines with the VP counterpart that it plays similar. But that's also different from table to table: especially combo shots are much more difficult in the simulation as aiming is a big problem in VP but that is also table dependent (e.g. combos in Bad Cats are easier than in Roadshow in VP). I think with the right settings we can archive an extremely similar playing experience. But that's very very hard to archive, even if you have the real table at home. There are so many settings interacting with each other. I noticed that JP has a really great feeling for appropriate settings - many of his tables play very natural. On the counterpart I noticed over time that BMPR let the ball appear to have more mass but on the others side I think that the ball can not be controlled by the flippers as exact as without the special enhancement. That's at least my experience. So if the physics engine can be enhanced in the source in another way maybe that would be the better solution - but who is that good to mess with the physics?

Edited by ClarkKent, 02 March 2014 - 05:57 PM.

[jimmyfingers]

Thanks for the idea about how to fix the kicker cup issue. It works on many tables, but for instance on Elvira and the Party Monsters, selecting KickerHidden results in the ball just passing the kicker hole. Also, doing the 8h wall and setting it as the kicker surface makes the kicker pretty much being just a circle instead of a darker hole on the playfield.

Obviously I don't know what I'm doing ( no surprise there), but what's the correct way to fix this table? At the same time, it would be nice to even change the original look of the kicker so that it appears like a proper kicker hole, not just the dark dimple on the playfield...

As far as the work-around vs. any code change to fix / improve the kicker look and / or ball cut-off issues, setting to kickerhidden does not change the behaviour of the kicker (visuals only) and it will still capture a ball as long as the kicker is still set to "enabled".  On the Elvira table I've reconfirmed this, so I'm not sure what you are doing but if the table you're working on is the "Elvira_and_the_Party_Monsters_VP91x_v1.2FS" version and you are referring to the kicker at the top center (sw48), then switching it to KickerHidden indeed works find and the ball does not pass over it as you state (on my system at least and using the latest VP9_DX9_test7.exe).  

 

Also, copying the table's existing 15h wall object, renaming it to 8h, changing the height to 8, and finally assigning this new 8h object to the kicker (sw38) works fine for fixing the ball cut-off.  There is no kicker cup / hole type graphic on the table image that is bound to the table itself for the kicker hole, in the graphic itself it is just a dark hole so not sure if that is confusing you on the expected result or graphics aspect at all.  If you don't like how high it looks even at 8h, then try cheating the kicker object down a few units along the Y axis (i.e. from the current 218.75 to something like 221.75) and it will compensate for the view aspect.  This is something I've done when building in this "fix" to my mods to assist with the potentially overly high looking perch from the changes.

 

Here is what it looks like with no Y changes and just the other aspects described above altered:

 Capture of ball kicker fix (Elvira example).PNG   427.6KB   16 downloads

 

Here is what it looks like with the extra Y shift of 3 units down:

 Capture of ball kicker fix plus Y shifted 3 units down (Elvira example).PNG   431.24KB   15 downloads

 

Here is a capture of the editor showing the changes:

 Capture of editor for ball kicker fix plus Y shifted 3 units down (Elvira example).PNG   208.98KB   16 downloads

[mukuste]

 

 

Not directly related to the topic, but I am amazed that the ball has weight and has been improved upon since VP 9.1. Seems to behave like a real machine. Need to adjust flipper and table settings on VP tables now.

 
It's funny that several people have remarked now that the physics feel improved to them. Since I didn't change anything on the physics code, I can only guess that it's purely from the increased framerate and reduced stutter.
 
But I'm already determined to improve several things about the physics code once this DX9 port is finished!

It seems to have something to do with free resources as the DX9 port does not need full graphics power. But in my experience this applies only to tables with vsync deactivated. There seem to be a similar behavior in Unity 3D - the physics also behave a litte bit different if framerate drops.

Nevertheless it's still lightyears away from behaving like a real pinball machine. The ball does not really feel like a steel ball. Mass is missing. But I have to admit that if I compare real machines with the VP counterpart that it plays similar. But that's also different from table to table: especially combo shots are much more difficult in the simulation but that is also table dependent (e.g. combos in Bad Cats are easier than in Roadshow in VP). I think with the right settings we can archive an extremely similar playing experience. But that's very very hard to archive, even if you have the real table at home. There are so many settings interacting with each other. I noticed that JP has a really great feeling for appropriate settings - many of his tables play very natural. On the counterpart I noticed over time that BMPR let the ball appear to have more mass but on the others side I think that the ball can not be controlled by the flippers as exact as without the special enhancement. That's at least my experience. So if the physics engine can be enhanced in the source in another way maybe that would be the better solution - but who is that good to mess with the physics?

 

 

Are you doubting me?

 

The physics code isn't all that bad if you have a bit of a background in math; I think I understand most parts of it pretty well already. And there are several tasks which aren't hard to do but should already improve things. Since the better framerate improved things for so many people, I think that also decreasing the physics timestep (which is at 0.01s right now) will have a beneficial effect. This will require adjusting some constants which are set for the current timestep, but it shouldn't be that hard. Then there was this thread, where it was demonstrated that with a very simple mod, the accuracy of flipper shots can be improved dramatically, especially at low framerates.

 

One thing that I think will be very important will be to properly simulate the physics of rolling vs sliding balls. While VP does have a basic simulation of angular velocity, as I looked deeper into the code, it seems to be mostly a visual effect. So getting that properly tied into the rest of the physics might well contribute to the feeling of "weight" or "mass" that people sometimes find lacking. This will be a somewhat bigger project, but certainly manageable. The bigger problem here is that such a fundamental change will require re-tuning all physics parameters, but I hope the community will lend a hand here.

[ClarkKent]

 

 

 

Not directly related to the topic, but I am amazed that the ball has weight and has been improved upon since VP 9.1. Seems to behave like a real machine. Need to adjust flipper and table settings on VP tables now.

 
It's funny that several people have remarked now that the physics feel improved to them. Since I didn't change anything on the physics code, I can only guess that it's purely from the increased framerate and reduced stutter.
 
But I'm already determined to improve several things about the physics code once this DX9 port is finished!

It seems to have something to do with free resources as the DX9 port does not need full graphics power. But in my experience this applies only to tables with vsync deactivated. There seem to be a similar behavior in Unity 3D - the physics also behave a litte bit different if framerate drops.

Nevertheless it's still lightyears away from behaving like a real pinball machine. The ball does not really feel like a steel ball. Mass is missing. But I have to admit that if I compare real machines with the VP counterpart that it plays similar. But that's also different from table to table: especially combo shots are much more difficult in the simulation but that is also table dependent (e.g. combos in Bad Cats are easier than in Roadshow in VP). I think with the right settings we can archive an extremely similar playing experience. But that's very very hard to archive, even if you have the real table at home. There are so many settings interacting with each other. I noticed that JP has a really great feeling for appropriate settings - many of his tables play very natural. On the counterpart I noticed over time that BMPR let the ball appear to have more mass but on the others side I think that the ball can not be controlled by the flippers as exact as without the special enhancement. That's at least my experience. So if the physics engine can be enhanced in the source in another way maybe that would be the better solution - but who is that good to mess with the physics?

 

 

Are you doubting me?

 

The physics code isn't all that bad if you have a bit of a background in math; I think I understand most parts of it pretty well already. And there are several tasks which aren't hard to do but should already improve things. Since the better framerate improved things for so many people, I think that also decreasing the physics timestep (which is at 0.01s right now) will have a beneficial effect. This will require adjusting some constants which are set for the current timestep, but it shouldn't be that hard. Then there was this thread, where it was demonstrated that with a very simple mod, the accuracy of flipper shots can be improved dramatically, especially at low framerates.

 

One thing that I think will be very important will be to properly simulate the physics of rolling vs sliding balls. While VP does have a basic simulation of angular velocity, as I looked deeper into the code, it seems to be mostly a visual effect. So getting that properly tied into the rest of the physics might well contribute to the feeling of "weight" or "mass" that people sometimes find lacking. This will be a somewhat bigger project, but certainly manageable. The bigger problem here is that such a fundamental change will require re-tuning all physics parameters, but I hope the community will lend a hand here.

 

Very interesting. I think improving the accuracy of the flippers to be able to reliable aim like on a real table would be the much more important task than ball mass. If I can really control the ball the way I want then I can play like on a real pinball machine. That's especially necessary when doing combos and similar tasks (which is mostly an lucky coincidence at the moment).

 

Because of the physics with lower frame rates: It's very interesting that on tables with a lot going on (like AFM beta4 with many primitives and flashers) an animated dB2S backglass can really extremely slow down the game. The same game with another - non-animated backglass - do not show any slowdowns. And the lower fps result in harder control of the ball.

[mukuste]

I looked into the TAF Gold issue with the flashers.

 

The table builds its flasher objects from several alpha ramps, e.g. fl21, fl21a, fl21b, fl21c, but they are all visible at the same time, so they appear stuck. The proper fix is probably to change the table script to set .alpha=0 for all of these alphas which are not supposed to be visible. The strange thing is that I can't find any reference to these objects in the table script, but someone more experienced with scripting can probably figure out how it all fits together.

 

As an aside, the best and most performant approach in DX9 would be to have a single object and change its texture as appropriate.

Edited by mukuste, 02 March 2014 - 08:07 PM.

[ClarkKent]

Another interesting thing I noticed: If I do not start the dB2S backglass in Roadshow it plays totally different! 

 

My special version:

https://www.dropbox....916_MOD_1.1.vpt

 

It seems that the dB2S server somehow influences the physics engine. Maybe in the same way vsync/fps influences it.

[bodydump]

I looked into the TAF Gold issue with the flashers.

 

The table builds its flasher objects from several alpha ramps, e.g. fl21, fl21a, fl21b, fl21c, but they are all visible at the same time, so they appear stuck. The proper fix is probably to change the table script to set .alpha=0 for all of these alphas which are not supposed to be visible. The strange thing is that I can't find any reference to these objects in the table script, but someone more experienced with scripting can probably figure out how it all fits together.

 

As an aside, the best and most performant approach in DX9 would be to have a single object and change its texture as appropriate.

Looking at the table, those ramps are not even being used.  They have a constant (unwanted) "on" halo in 9.2 also.  It looks like they were never scripted and are actually unnecessary now since there are separate flasher halo ramps which are using image swapping.  It looks like with all of those flashers, fl21, fl21a, fl21b can be deleted leaving fl21c as it is the image of the unlit flasher.  This would have to be done with all the flashers of course.

[mukuste]

Ah! So for a change I found a bug in a table instead of people finding bugs in my code!

[ringorian]

Another interesting thing I noticed: If I do not start the dB2S backglass in Roadshow it plays totally different! 

 

My special version:

https://www.dropbox....916_MOD_1.1.vpt

 

It seems that the dB2S server somehow influences the physics engine. Maybe in the same way vsync/fps influences it.

Can you maybe 2-3 combinations which shows this on your side ?

[DJRobX]

Looking at the table, those ramps are not even being used.  They have a constant (unwanted) "on" halo in 9.2 also.  It looks like they were never scripted and are actually unnecessary now since there are separate flasher halo ramps which are using image swapping.  It looks like with all of those flashers, fl21, fl21a, fl21b can be deleted leaving fl21c as it is the image of the unlit flasher.  This would have to be done with all the flashers of course.

 

 

Nice!   I just deleted every FLnn* object leaving only the C's, and it seems to work perfectly now.    Thanks both of you for looking into it. 

[ClarkKent]

 

Another interesting thing I noticed: If I do not start the dB2S backglass in Roadshow it plays totally different! 

 

My special version:

https://www.dropbox....916_MOD_1.1.vpt

 

It seems that the dB2S server somehow influences the physics engine. Maybe in the same way vsync/fps influences it.

Can you maybe 2-3 combinations which shows this on your side ?

 

What do you mean exactly?

 

Maybe this effect only appears on systems with one graphics card for all 3 monitor. Maybe this does not appear on systems with separate graphics cards for the PF and the BG/DMD. Maybe not. This has to be tested if this has something to do with it. Or the dB2S server does draws off to much power from the system to have a similar effect as low fps?