868 replies to this topic

[RYSr]

Fuzzel

 

Is the intent to keep VPX10.1 compatible with VPX 10.0?

 

If not could  you perhaps let us know when 10.0 tables will stop working properly so we can use the beta on our CAB's for them until then?

 

I don't understand all the current changes, such as the rubber changes and if that already could cause problems on 10,0 tables

 

Although most changes so far seem to be for the authors, it seems that the POV export/import and the Ball XML override are 2 features the current VPX 10.0 users could be using.

 

Thanks for your continuing efforts with the beta...

Rich

[fuzzel]

The plan is to keep VP10.x as long as possible compatible to the 10.0 version. All current changes so far are just extensions mostly for authors but these won't break compatibility. And yes if something changes for example there are new game features than I will inform you all.

[gtxjoe]

Minor workflow enhancement requests"

- Sort the Edit->Select Element list by name by default

- Options window consists of expandable/collapisble sections.  Can that be changed to window with a vertical scroll bar?

 

Question

For drop targets, can the "isdropped=1" height be set?  If I double the vertical height scale of the target, the target does not drop down far enough by default

 

Thanks for all the VPX work!

[fuzzel]

Sort elements: I'll check that
Properties sections: I don't think that's possible
Drop targets: I'll check that. Probably I missed applying the scaling to the hit shape

[BorgDog]

Sort does not seem to be on in Collection Manager either, although Image Manager and Material Manager both are sorted by name.

[marco helmink]

I found something what crash my computer.
In de backdrop setting were you can scale the tables there are black lines. I think these are my tv border.
When I scale a table between the borders my computer stay on and not crash.
When I scale a table just over the black lines, my computer crash by showing the table and reboot.
WY is this? Is this a vp10 bug or do I something wrong?
In vp 9 you can scale the table over the lines.

[fuzzel]

Looks like a driver/system issue. Can you please create an extra help thread for this? This thread is about the beta testing/developing of the next VP version.

[marco helmink]

Ok, I'm going to an other thread.
Sorry

Edited by marco helmink, 29 January 2016 - 08:12 PM.

[nFozzy]

Speaking of drop targets, the issue posted in this thread is very real. I've had to modify 95% of games that have rom-controlled drop targets with extra scripting so the drop targets always reset properly.

[vampirolatino2]

question about kickerholes .... those that are not invisible goes trough plastics and all in front of them. How can be fixed? For example, kicker holes in Medieval Madness Dozer and NBA Fastbreak hmuek VPX tables.

 

I just change them to invisible but then the kickerhole graphic disappears, obviously.

[fuzzel]

Speaking of drop targets, the issue posted in this thread is very real. I've had to modify 95% of games that have rom-controlled drop targets with extra scripting so the drop targets always reset properly.

What about the drop speed setting, can it solve the issue? I don't really understand what I can do against it.

 

 

question about kickerholes .... those that are not invisible goes trough plastics and all in front of them. How can be fixed? For example, kicker holes in Medieval Madness Dozer and NBA Fastbreak hmuek VPX tables.

 

I just change them to invisible but then the kickerhole graphic disappears, obviously.

Yes that's a known problem. The reason for this is that there must be a kind of a hole in the depth buffer to render the kicker cup correctly otherwise you would see only the upper half of the kicker and the rest is blocked by the playfield/wall. At the moment there is no other way to do that. The only workaround for that is to flag all objects that are above/over the kicker to be dynamic objects so they are rendered every frame.

[nFozzy]

Neat, increasing drop speed works. 1.15 seems like the minimum value for it to reset consistently.

[jimmyfingers]

I don't think the drop target reset issue should be considered solved by forcing a set range of speeds that can only be used to make the "bug" not happen.  On a real machine generally you can see at least a bit of a delay from when a target goes down to when it is reset - maybe I suppose for this exact potential / problem avoidance.

 

Why not just put in the code a delay for when the animation is reversed / the target is returned back up, even if it has to be a separate field / parameter?  Having to set the drop speed to 1.15 to fix this issue leaves the drop target essentially unanimated again and defeats a reasonable amount of the purpose for having it as a new feature vs. the old drop walls (binary looking style) or simply having to do it all manually again.

[vampirolatino2]

thanks for the information

[kiwi]

BMP textures show strange values of size, and JPG images, the size shown is always 0x0.

 
Good if we can also see the properties of sounds, stereo-mono, frequency, bit, length,
and that the sounds are not supported by the own soundcard are still loaded and highlighted in the Sound Manager,

so that it is easy to locate them and convert them into the format supported by the own soundcard.

 

Thanks

 

Max
 

[Pin-Pete]

And I have still this annoying stutter problem, which is driving ME NUTS!!  

[toxie]

On the topic of stuttering:

 

I wasted a lot of time over the weekend (or actually not, depending on how you look at it ) looking into this. Apart from some physics stuff that is still suboptimal to put it mildly, i also discovered that some tables spent a looooooooot of time in the scripting. A prominent case that always confused me stuttering-wise (but its not just this table) is Kingpin.

 

There, up to 40% per frame are spent in the script sometimes!!

 

So one lesson here is that one should not overdo it with timers. Some of the Kingpin timers have a timer interval set of 0 or 1, which means that these will be triggered 1000 times a second, and there are a lot of timers and sometimes some costly routines in there!

(verifying this by setting them to f.e. an interval of 100, makes script time drop to <1% on my machine).

Another sideeffect of this is that even timers that are set to saner values like 10 or 20 will be affected, as these will have to catch up, too, in the case that a previous frame was rather costly.

-> e.g. micro-stutter

[fuzzel]

Oh yes and the result is not only micro stuttering but heavy stuttering if you have a mid range cpu. The only timer that should be at 1ms should be the vpmame timer but maybe this one can also be set to 5 or 10.

[jimmyfingers]

@toxie - doesn't it also depend a lot on what those timers are doing in their routines?  If one is calling lot's of graphic updates or other routines from the timer that in return do graphic update type tasks (changing images, lighting states, moving primitives, etc.), it's a lot more "costly" than if a timer is simply calculating a value and not even outputting anything to screen.  I think what is being done inside the timer routines or called from it must be part of the consideration as well and it's not a one sized fits all deal.

 

I think part of the problem is before VPX and maybe physMOD (not sure what revision it changed) a timer set at an interval level of 1 on a table didn't actually run at 1 and instead ran at the lowest possible which was 10.  So, a lot of people didn't see the negative affect previously as everything was forced to at least 10 times slower, however, now if nothing is changed in the code from the previous table and people use the same "1" it is actually running at that true interval and is 10 times more demanding than before (one reason for sure that people could feel that VPX in at least one element seems more demanding).  In the previous case if the timer routine worked fine when set to 1, then with VPX it will work fine with 10 and should actually be changed for any tables modified or evolving to VPX form a VP9 version or WIP.  I don't think a lot of people knew of that issue / characteristic (it could be / was easily shown with some counters in the timer routines and a screen output / text boxes). 

 

Occasionally, it is nice to be able to go to lower than 10 but for a timer interval, however as you say, carefulness with timers when not needing that level of precision would be prudent for efficiency and helping to avoid more processing than needed.  Can you clarify more about the impact of timers depending on the routines they work with.  From what I've seen and what I started with, it's a whole lot different situation and one that can cause visual impacts for timers that are related to graphic / screen visual changes vs. more computational ones?  Wouldn't it also be the case that the amount of "work" in general called from that timer is a huge variable factor in this situation vs. simply the timer value alone being set at 1 (the LampTimer for example with calling a lot of elements and the slew of items under the "UpdateLamps" for example vs. one that might simply increment a counter value only)?

Oh yes and the result is not only micro stuttering but heavy stuttering if you have a mid range cpu. The only timer that should be at 1ms should be the vpmame timer but maybe this one can also be set to 5 or 10.

Hey fuzzel, I was just about to reply that setting the actual vpmame timer to anything other than 1 would seem risky for missing event or having it do something maybe unexpected with that key piece of processing for VPM tables.  However, with just thinking about it for a moment, if that timer on old VP9 tables (PinMameTimer) was set at 1 and was a typical / standard VP timer object, than it must have suffered / experienced that same original issue in VP9 where no timer ran lower than 10 even if set lower (that I was just discussing).  So, I guess that would prove that setting to 5 or 10 could / would be safe.  But you never know, part of the original aspect of VP9 with some switches or triggers sometimes seemingly missing events with VPM tables / events for unknown reasons could have been related to that and we're actually getting better results maybe now with VPX because of it.  In any case it seems that setting to 10 shouldn't have had any worse effect than how it behaved with VP9 but that might be at least one timer that should at least have a reasonable amount of caution exercised when attempting to adjust.  I imagine too that even still with all this, going higher than 10 by much amount could / would definitely risk missing events that have changed at the ROM level and would miss detection or registration.

[toxie]

In general what you say is true, but there is also always a constant overhead with each script call that is triggered, so even if nothing is done, there will still be some (small) cost that can sum up if a lot of timers are triggered all the time.

 

And, as you say, the timers are basically now triggered 10x as often as in VP9.X (PM5 already features the same factor 10).. This should be considered by all authors porting tables..

 

So if you do the math, then even a timer running at an interval of 5 is pretty much overkill (as it would require a monitor with 200Hz and a machine that can output 200FPS to even show the effect)..

 

I will try to implement a mechanism that will cut off timers if overall the script is already running too long in a single frame.