58 replies to this topic

[TedB]

2. what im most concerned about is the amount if any stutter is added to the table. my tables seem to be notorious for causing people to have ball stutter. this would be my main concern with applying the engine to my tables.

i dont have anything new enough to try to apply this to right now and im a little short on time at the moment.
do you think you could add this routine to my freddy nightmare on elm street table and send it my way. this table seems to cause the most issues for people and i think it may be a good test of if the engine causes stutter

I agree, might have no impact on some machines but PCs that already are struggling to run tables could be affected.
After a lot of tweaking my cabinet now runs most tables pretty good. Even UWs excellent tables. Freddy Nightmare on Elm Street is indeed a very good table to test performance. If a setting isn't correct, it is really noticeable and the table stutters a lot (and then becomes unplayable)
I used this table to check performance after every setting, overclocking or driver change. It is now performing ok on my cabinet with a minor stutter that is only vissible to the trained eye (even at multiball).
If you need an additional tester, I would gladly test it on my cabinet to see if performance is not affected. I think I will notice any performance change on this table.

[jimmyfingers]

I've been testing this on one of my tables, it took some time to understand how to use the parameters but I think I got the hang of it now.

It probably depends on witch table you are working on but I feel that the default parametes are adding too much sideways momentum. On a well tuned EM table the Momentum code doesn't really improve the behaviour at all. It probably makes more of a difference on the newer and faster SS tables.

Here is a little video I made of two (real) balls with different mass rolling down the glass of my pincab. I needed to see how much the mass would change the ball trajectory to be able to tune the physics on my table. I have made many different trials like this when working on the tuning for my EM tables .
Rolling Balls

If you are not increasing the friction to around .00325-.0035 for an EM and leaving the deafult MXLevel at .034 and MXThreshold at 12 you may get to much lateral depending on your slope settings (if they are less than 4) so maybe also try MXLevel just at .03 or a totally different combo I use somtimes as MXLevel at .06 and MXThreshold at 6 (but I've come to use the former in my current MODs).

To be honest though, it's the EMs that I made this routine for and for which I feel it can work best if tuned and if table physics changed to match / compliment the effect can be great. In Toronto a new place opened called Pinball Cafe and I was amazed at how slow real life pins were seeming compared to the average VP. But they weren't just slow with the ball like it was rolling on a carpet, the slow ones had the ball spend tons of time bouncing off things side to side and once headed down table rather straightly, would motor pretty good.

So, I believe EMs can indeed benefit and possibly more so than the faster newer games where lot's of speed may not stand out. I appreciate that you've taken and interest and assessed on one of your tables. May I suggest that you tell me one of your titles that you would like to try it on and I will MOD it with the experience I've obviously now gained regarding implementing the BMPR and the relevant nuances with the table to incorporate desirably. In a couple days I could send you a version for your assessment? There is a tuning component for sure to get the best result and my learning curve has changed as the more tables I've done for personal use. It takes a bit of time to review video or real life physics of the table, add and adjust general table physics and elasticity, and then test the feel on a desktop test station as well as an actual cabinet. I think the change may look off to some people a bit as I believe we've got very much used to a overall fast speeds for VP so slowing it down to try and more closely match a real life pin may almost look unnatural at first.

Let me know what you think about a suggestion for one of your tables.

2 questions jimmy.
1. what range of elasticity are you using for the rubbers. i usually set mine round abouts at .7 i think. id have to check my starter table to be sure.

2. what im most concerned about is the amount if any stutter is added to the table. my tables seem to be notorious for causing people to have ball stutter. this would be my main concern with applying the engine to my tables.

i dont have anything new enough to try to apply this to right now and im a little short on time at the moment.
do you think you could add this routine to my freddy nightmare on elm street table and send it my way. this table seems to cause the most issues for people and i think it may be a good test of if the engine causes stutter

i appreciate you doing this. anything that makes the ball movement more realistic is a plus to vp.

also curious as to how this effects the nudging.

should have some time to play with it some tonight

thanks jimmy, your work is much appreciated

1. I have been working with .6 for more down facing rubbers, .7 - .75 for side rubbers, and .75-.85 for up facing rubbers (especially to posts on the top of the slingshots).
2. The stutter / FPS hit is hardly noticeable and I'm not really sure if it causes anything as I was saying in a previous post that it seems VP is quite content doing this processing many times a second as long as it's not dropping walls or using alpha ramps. I think eve the demo table is a good test as you can queue up 4 balls using the launch key, turn the momentum effect on or off, and then watch the FPS.

In the earlier post I discuss my observations on performance. I'd be happy though to take a stab at Freddy (no pun intended) as you're tables are a good starting point because you've often used the B2B already which saves a lot of time implementing and your elasticity levels are pretty high and good to start with. I'll need a few days to try and do it justice and get my hands on some video as well as with today being mothers day I really have to hop off the computer and get some MD related chores done

I will initially assess Freddy for the performance aspect as you suggest before going into other more fine details. If a table is already at the border-line of stuttering it may make a little more difference just because sometimes at that point just a few less FPS can become noticeable where as 50 or so frames when you got 500 or more is nothing. I have implemented it on one of your tables that I got a little stutter before and didn't notice any increase so we'll see what happens with Freddy.

As far as nudging goes, I think it does have a slight effect but with the cut-off values at 1 for MX and -1 MYU (Up) it's not applying as the ball is almost stopped. I personally like the slight effect I think it causes for things like giving the table a push when it's on the top of a lane guide, probably just because it's overall increasted the bounciness with it's effect and the increase in elasticity I give to the table objects after the higher friction.

Thanks for the kind words UW. Just trying to give back and want people to give it a fair shot or reserve full judgement until they see a properly tuned table using the system. I know it's made a difference as I see on the dozen or so tables on my min-cab everytime I play them how they've become more organic in their feel if for nothing else to at least assist the ball down table acceleration and a little lateral.

[Lynny]

I'm trying to implement this into a table, but its a bit slow going for me. I've not messed with too much of the scripting.

If anyone has a table they need tested, I would love to test this out on my pincab and compare the look and feel with the original tables. Just PM me, I'd be happy to help in any way I can.

Peace,
Lynny

[Arcade4]

Would be nice if one of you nice table builders would just upload a test table so all of us non programmer types could get a feel for what is going on here.

[rosve]

To be honest though, it's the EMs that I made this routine for and for which I feel it can work best if tuned and if table physics changed to match / compliment the effect can be great. In Toronto a new place opened called Pinball Cafe and I was amazed at how slow real life pins were seeming compared to the average VP. But they weren't just slow with the ball like it was rolling on a carpet, the slow ones had the ball spend tons of time bouncing off things side to side and once headed down table rather straightly, would motor pretty good.

So, I believe EMs can indeed benefit and possibly more so than the faster newer games where lot's of speed may not stand out. I appreciate that you've taken and interest and assessed on one of your tables. May I suggest that you tell me one of your titles that you would like to try it on and I will MOD it with the experience I've obviously now gained regarding implementing the BMPR and the relevant nuances with the table to incorporate desirably. In a couple days I could send you a version for your assessment? There is a tuning component for sure to get the best result and my learning curve has changed as the more tables I've done for personal use. It takes a bit of time to review video or real life physics of the table, add and adjust general table physics and elasticity, and then test the feel on a desktop test station as well as an actual cabinet. I think the change may look off to some people a bit as I believe we've got very much used to a overall fast speeds for VP so slowing it down to try and more closely match a real life pin may almost look unnatural at first.

It would be great if you could try your hands on my new Capt. Fantastic. I've tried many different settings but you can probably point me in the right direction.

[jimmyfingers]

I added the routine to Freddy table and as expected and from all my previous other experience with it in other tables, it's undetectable. I can't see it in the FPS whether it's toggled on or off and I can't see a difference in the stutter. Even with multi-ball I don't see a difference. The numbers of the FPS are just so similar but also vary over time for whatever goes on in the background that there's nothing that stands out from one mode to the other (off or on).

Again, I think this type of script processing / calculating within VP and for the computers that we have now just flies through - it really appears to be the alphas, drop walls, lamp updates (with playfield images), and graphic updates tied into routines that seem to take their fair share of processing demands. But I think VP, is happy to do tons of non-graphical related calculations in the script per second and not miss a beat.

UW, I'll PM you about getting this basic implementation of the BMPR in your Freddy table to you for you to assess for yourself.

[unclewilly]

that sounds great jimmy.
send it my way and ill get an update to the table done so people can compare it to the older version.
ill also optomize the alpha light routine and plunger which should help people with the stutter as well

[TedB]

Wouldn't it be better to send the table for testing (also) to people that do have stutter issues?


... and yes I am volunteering

[unclewilly]

depending on how bad the stutter is, the optomization i do on the alpha flashers and plunger may fix your issues. well see. when he sends me the table and i fix the flasher routines and plunger i will place a beta test link to get feedback from the users

[TedB]

depending on how bad the stutter is, the optomization i do on the alpha flashers and plunger may fix your issues. well see. when he sends me the table and i fix the flasher routines and plunger i will place a beta test link to get feedback from the users

I thought you wanted to see if the additional code would add stutter. Appearantly you don't have stutter on your machine. So if you are trying to see what kind of impact the script has on stutter your computer is probably not the best to test it on. By optimizing the table you are adding variables and you will still not know if the script results in stutter on problematic machines.

Anyway, thanks for checking this Looking forward to play testing any version.

[jpsalas]

I don't think any calculation done with the script will affect the tables. Today CPUs can handle a lot of code in the script. What VP suffers is from old code based in direct draw 7 which is no longer is supported in modern graphics cards, and it is when the CPU has to do graphics jobs that the stutter comes. I believe (know) you can throw at VP all kind of calculations and it will go through them like nothing, but add a few lights as big as the table, and make them blink and you'll notice that stutter at once. So the problem in VP are the big lights, the big dropwalls and the amount of alpha ramps, mostly the alpha ramps and the dropwalls. Take a look at the magnet code, or the collision code, and you'll see a lot of calculations there, but that will never slow a modern cpu.

Edited by jpsalas, 15 May 2012 - 05:45 PM.

[jimmyfingers]

I don't think any calculation done with the script will affect the tables. Today CPUs can handle a lot of code in the script. What VP suffers is from old code based in direct draw 7 which is no longer is supported in modern graphics cards, and it is when the CPU has to do graphics jobs that the stutter comes. I believe (know) you can throw at VP all kind of calculations and it will go through them like nothing, but add a few lights as big as the table, and make them blink and you'll notice that stutter at once. So the problem in VP are the big lights, the big dropwalls and the amount of alpha ramps, mostly the alpha ramps and the dropwalls. Take a look at the magnet code, or the collision code, and you'll see a lot of calculations there, but that will never slow a modern cpu.

Exactly! Thanks JP as you corroborate my thoughts / theories in my last post above that come from all the time I've spent working with the routine (even VP in general for that matter) as well as after validating with UW's Freddy table specifically. The extra technical explanation you provide is informative and useful.

[htamas]

What VP suffers is from old code based in direct draw 7 which is no longer is supported in modern graphics cards, and it is when the CPU has to do graphics jobs that the stutter comes.

Now this brings up the (probably dumb) question: is it even feasible to update the VP code to use a more up-to-date ddraw or directx version?

But I sort of suspect that if this was doable with a reasonable effort, it would have been done already... so since I have no clue about this type of programming, I'm still curious about the opinion of those who do know.

[kruge99]

I don't think any calculation done with the script will affect the tables. Today CPUs can handle a lot of code in the script. What VP suffers is from old code based in direct draw 7 which is no longer is supported in modern graphics cards, and it is when the CPU has to do graphics jobs that the stutter comes. I believe (know) you can throw at VP all kind of calculations and it will go through them like nothing, but add a few lights as big as the table, and make them blink and you'll notice that stutter at once. So the problem in VP are the big lights, the big dropwalls and the amount of alpha ramps, mostly the alpha ramps and the dropwalls. Take a look at the magnet code, or the collision code, and you'll see a lot of calculations there, but that will never slow a modern cpu.

Putting the vpinmame window on a second display can also slow down some systems - I know because it slowed my system down. So many factors to consider.


Best Regards,
Todd.

[Knome]

"But I sort of suspect that if this was doable with a reasonable effort, it would have been done already... so since I have no clue about this type of programming, I'm still curious about the opinion of those who do know."

What would give you that idea?

Nudge is easy, just look at VP 1 or later, and that is not getting fixed either. What is getting done and what is not getting done and what is getting done away with I suspect is not based on difficulty.

[jimmyfingers]

I don't think any calculation done with the script will affect the tables. Today CPUs can handle a lot of code in the script. What VP suffers is from old code based in direct draw 7 which is no longer is supported in modern graphics cards, and it is when the CPU has to do graphics jobs that the stutter comes. I believe (know) you can throw at VP all kind of calculations and it will go through them like nothing, but add a few lights as big as the table, and make them blink and you'll notice that stutter at once. So the problem in VP are the big lights, the big dropwalls and the amount of alpha ramps, mostly the alpha ramps and the dropwalls. Take a look at the magnet code, or the collision code, and you'll see a lot of calculations there, but that will never slow a modern cpu.

Putting the vpinmame window on a second display can also slow down some systems - I know because it slowed my system down. So many factors to consider.


Best Regards,
Todd.

True that vpinmame window locations have been known to smooth out or add stutter to the playing experience. There are also many other elements for stutter regarding the computers on which they run, the hardware drivers, services they run, wireless networking, etc., but I think JP's and my points were more regarding the effects on stutter from the elements within a VP table or it's script - all other things being equal.

[unclewilly]

id suspect its based on whatever the mish mash of devs are confident in doing.

id suspect if the nudge was so easy to fix, someone who thinks its an easy fix could go ahead and fix it being as vp is open source. but it doesnt seem as if anyone has stepped up to the plate for that issue.
so maybe its not that easy of a fix. or maybe the current devs just arent interested in fixing it.

i think as these devs arent getting paid and work on stuff in there free time they probably work on what they feel like working on

[jimmyfingers]

"But I sort of suspect that if this was doable with a reasonable effort, it would have been done already... so since I have no clue about this type of programming, I'm still curious about the opinion of those who do know."

What would give you that idea?

Nudge is easy, just look at VP 1 or later, and that is not getting fixed either. What is getting done and what is not getting done and what is getting done away with I suspect is not based on difficulty.

I think there's probably a lot more at work regarding changes to how the graphics / DirectX 7 elements are being utilized that could very much make it not "easy". I think the devs and authors have done a great job and in the mere 2 past years I've been part of VP the changes have been great with things like alphas, layback, and even other users developing external elements to facilitate things like EM scoring on a 2nd screen like Rosve's B2S, which had been a dream for VP now come true.

[Knome]

I don't know how easy it would be to fix VP, that is true. But opinions were asked for and my opinion is if it existed in every other version it really does not matter how easy it is because it is worked out already. I don't write code though. I can copy and paste though, and for anyone that does know something about coding it there can't be much more to it than that.

I don't really play VP much though. I understand why it is popular though, and I could see myself getting hooked into it some day, but it would have to function in all areas at least as good as it ever did, not worse. It just seems worth it to me. But it is not my place to argue with anyone that thinks it's not. I will argue with someone that says alpha and other new things more than make up for it. Nothing in my opinion is good enough to get at the cost of more basic function.

If nudging is not one of the most important functions of a pinball simulation, nothing graphics wise would even be on the list.

Edited by Knome, 16 May 2012 - 01:25 AM.

[jimmyfingers]

Now this brings up the (probably dumb) question: is it even feasible to update the VP code to use a more up-to-date ddraw or directx version?

But I sort of suspect that if this was doable with a reasonable effort, it would have been done already... so since I have no clue about this type of programming, I'm still curious about the opinion of those who do know.

I don't know how easy it would be to fix VP, that is true. But opinions were asked for and my opinion is if it existed in every other version it really does not matter how easy it is because it is worked out already. I don't write code though. I can copy and paste though, and for anyone that does know something about coding it there can't be much more to it than that.

I don't really play VP much though. I understand why it is popular though, and I could see myself getting hooked into it some day, but it would have to function in all areas at least as good as it ever did, not worse. It just seems worth it to me. But it is not my place to argue with anyone that thinks it's not. I will argue with someone that says alpha and other new things more than make up for it. Nothing in my opinion is good enough to get at the cost of more basic function.

If nudging is not one of the most important functions of a pinball simulation, nothing graphics wise would even be on the list.

The opinions of those who DO know "this type" of programming was asked by htamas (specifically regarding the graphic and directX7 legacy element) and by your own admission regarding not writing code, that is clearly not you. I guess you're "arguing" with me then because I was the one that said that good things have come like alpha ramps and layback but did not say it was to be compared to other possible physics or "core" improvements but is indeed something to be appreciative for and is progress in the areas that the people who contribute their free time with VP choose to explore. So, to get into VP or be hooked, it needs to fit all of your expectations and be as good as ever, not worse - when did it get worse? Still having some room for improvement doesn't mean ever in the last couple years that it has taken a step back.

This topic and an element of this forum is still about improving things but some humility and gratitude for the people to date that have contributed to the code, the tables, the graphics, the scripts and overall playable product should be observed / respected even if the end result doesn't make the grade for you to warrant your time getting into the hobby.

Let's get back on topic which is actually trying to contribute something and respectfully trying to add, what we in the community can, for VP.

Edited by jimmyfingers, 16 May 2012 - 03:35 AM.