666 replies to this topic

[jpsalas]

@all authors: I checked the flipper settings and found that the visible flag of the flippers are actually not only a switch to show/not show the flippers but it also enables/disables the flipper collision check. I would like to separate these switches into the Visible (flipper is shown/not shown) and Enabled (flipper collision check on/off). I don't know how many tables use this old Visible flag handling because if I change this those tables would need an update. What do you think?

Today it's not possible to use primitives for flippers without drawing the VP-flippers too.

I have used "invisible" flippers on several tables, mostly the Bally ones which uses dropwalls, so those will need to be updated, or maybe not since I have used "black" flippers which are invisible but collidable . I know other authors have made tables with several flippers which change positions, and other have added different difficulty settings which also use several flippers. But I mean that to separate the "visible" and "collidable" is a very nice option. And it should not be a problem to update those tables that may need it.

[unclewilly]

So do the touchscreen controls rotate with the table?
Maybe I'll make a semitransparent overlay I can add to tables showing buttons in the appropriaTe area of the screen.

Have an early birthday present coming.
Lenovo yoga 2 pro. Damn you devs and your touch screen support

[toxie]

touchscreen rotates with table (so far only 270 degrees supported), yes..

 

as for the overlay: if you want, you could also send me the bitmaps for the gfx and i could support that natively in VP then (en/disable possible via options, or maybe even via a seconds counter so that its only showing in the beginning?).. also these could move then, if at some point it will be configurable (different buttons, regions, etc)..

 

as for the damn you: i also "had" to buy one because of these damn early tests, so i'm in the same boat..

Edited by toxie, 15 January 2014 - 12:48 PM.

[fuzzel]

Oh man I hate that pressure

[toxie]

some more results of some recent tables(rev  868):

 

WCS94 mod 1.1.  :   ball trail off, alpha slider in middle, RO off

 

vertex in ram off:  27 avg fps (

vertex in ram on:  28 avg fps

RU off, vertex on: 28 avg fps

RU off, vertex off: 27 avg fps

RO on                : 27 avg fps

alpha slider all the way to left: 26 avg pfs

 

so no significant results for any setting.....

 

interesting.. so there is a different limit there (CPU/VPinMame??) maybe..

if you could test some more tables, that would be highly appreciated..

Also have you tried the usual VPinMame tricks (ddraw vs d3d vs "normal")?

 

as for performance in general: the good thing is that VP9 has a huuuuuuuuuuuge backlog of tables that were made, so if one compromises on quality a bit one can still play all of the old ones..

[fuzzel]

rev869 introduces a visible and enabled checkbox for flippers. In older versions the visible checkbox disables the flipper and the collision checking. Now you can handle both but it can break some older tables if they make use of the old behavior.

[bosvrucht]

interesting.. so there is a different limit there (CPU/VPinMame??) maybe..

if you could test some more tables, that would be highly appreciated..

Also have you tried the usual VPinMame tricks (ddraw vs d3d vs "normal")?

 

as for performance in general: the good thing is that VP9 has a huuuuuuuuuuuge backlog of tables that were made, so if one compromises on quality a bit one can still play all of the old ones..

 

 

Well,  i am still impressed what this little CPU/GPU can do.  a lot of current tables run fine, like embryon.  It looks like it is mostly some of the newer MOD tables that are too much.

 

I tried DDRAW=0 and also frameskip, but no change. It is not vpinmame holding things back.

 

I tried another current table:  "Indiana Jones VP920 MOD 2.0"  ,  ball trails OFF

 

HDR, RU: ON ,  RO, vertex: OFF:   66 FPS avg (completely playable, mostly smooth gameplay)

HDR, RU: ON,   RO off, vertex ON:  43 FPS avg

HDR ON, RU: OFF,   RO off, vertex OFF:  48 FPS avg

 

"Atlantis VP 9.2  1.2 FS"

 

RU off:   107 avg FPS  (completely playable, smooth gameplay)

RU on:    98 avp FPS 

 

strange thing is that RU on is faster for Indiana Jones, but slower for Atlantis????

 

Also tried an Ooold table  "Flintstones v2.1 JPG-PINSFS JW MOD  FS" .  This is an old table, but it looks fantastic on an 8" screen.

 

RU on: 486 avg FPS (obviously smooth gameplay)

RU off: 401 avg FPS

 

 

Also tried apollo 13 again, with 1024 text.limit.  Was mostly playable, but not buttery smooth.  Did not get to 13 ball multiball,  without nudge......pretty much impossible.

 

Edited by bosvrucht, 15 January 2014 - 03:09 PM.

[toxie]

cool, so at least there is some kind of difference for some tables.. otherwise it would have really been strange..

maybe i'll fool around a bit this evening with other (internal) options, who knows, maybe we can squeeze some more few FPS out on this chipset..

[unclewilly]

I'll send you an overlay once my yoga 2 pro arrives so I can place them right. Or do you just need the transparent images.

I was going to do a semitransparent image of a button. Or something for each control

[toxie]

i guess the transparent images are okay, as these would then be basically mapped to each input region separately (so that it would be flexible in case of differently configured regions)..

and the overall transparency could then be steered by the user (-> video options), along with if it is blended out over time..

 

but no need to hurry..

[bent98]

 

Hey Toxie / fuzzel, would you guys be able to implement a Z-scale option that could help extend out the table view along the Z axis? There's some new views / table types coming out that look promising but are a bit flat and it seems that if we could stretch everything along the Z-axis that we might be able to get some really cool things happening. I think it could potentially work if it was merely all visual / when rendering and could even help add some depth.
 
A second idea on this is whether there could be any way to move the perspective (“camera view”) up or down along the Z axis independent of the results from the combination of incline, FOV, and layback settings. Incline seems like it's just uniform angle and from older tables / pre-layback days we could see that on FS tables where everything filled the screen as a rectangle but was just all at the same angle, FOV seems to give a little bit of the Z-axis aspect but along with other changes it's making at the same time, and layback seems to just be more forward or back, which is totally useful obviously, but sometimes it might be cool to have all of those set but than simply change the height (almost like for the height of the player).
 
I think the first suggestion / request would be cool to initially check out if it might be simple enough somewhere in the renderer to just be able to set a multiplier for the Z-Axis drawing (If we could set that on the table like with X and Y Scale) with maybe a 1.5 to 2 factor that might be great for some of these new views and maybe a lower setting for some current tables that might yield more depth in FS. I only played with the FP and BAM aspect one evening for the static table views but it did seem to allow (in real-time though) the extension and stretching along the Z which seemed pretty key in it's implementation and for yielding more depth.
 
Some food for thought if you guys feel up to some other things to try with VP.

Nice idea. Will have a look asap.

 

Hey FuzzeI know everyone is in a VP/Tablet frenzy but I was wondering if you had any progress on Jimmy's idea. Would be cool if we could get that implemented and also any possible tweaks to the physics engine (ie Ball spin).

 

Thanks again to you and Toxie for all you amazing work on VP thus far.

[htamas]

I challenge you... to a FRENZY!

 

[fuzzel]

I had a look into it yes. Unfortunately ours not that easy to add this to VP. I have to apply the scale matrix to every object separately. FP uses sharders and you can easily apply another shader to the transformation chain. But that doesn't mean that it won't come, it will just take a bit longer

[toxie]

 

hello ,

i have a probleme with VP 9.2.824 and better
indeed every release since this one disactivate the keys i use. i m' using GP wiz40 for my pincab keys 
http://groovygamegea...products_id=235

So when i use 9.2.824 or better my keys doesn't answer anymore. i tried to solve it test lot of things without success

do you have any idea ?

thx

 

i have the same problem with 853

 

 

This also should've been fixed with 868, btw.. Forgot to notice..

[toxie]

I tried another current table:  "Indiana Jones VP920 MOD 2.0"  ,  ball trails OFF

strange thing is that RU on is faster for Indiana Jones, but slower for Atlantis????

 

Also tried apollo 13 again, with 1024 text.limit.  Was mostly playable, but not buttery smooth.  Did not get to 13 ball multiball,  without nudge......pretty much impossible.

 

Maybe RU on being faster on IJ is because you only tested RU off with also RO off? (wild guess)

 

As for the 1024 tex limit: That shouldn't be too bad in general, as the screen res is 'just' 1280 anyhow..

 

From my own (limit) experiments so far, RU off (everything else set to default values) seems fastest..

[jpsalas]

I had a look into it yes. Unfortunately ours not that easy to add this to VP. I have to apply the scale matrix to every object separately. FP uses sharders and you can easily apply another shader to the transformation chain. But that doesn't mean that it won't come, it will just take a bit longer

Now that we are talking about objects height, is it possible to make the default bumper 15 units taller? On all my tables (and I guess most of the other authors do the same) I always put the bumpers on a wall 15 units high, since the default bumpers are too short. I'm aware that a default higher bumper will break all the older tables, so maybe it will be possible to do as with the plunger? Old bumper should be default, and new bumper But I guess most new tables will use a primitive or two to make the bumpers Well, just an idea I got

[toxie]

 

Now that we are talking about objects height, is it possible to make the default bumper 15 units taller? On all my tables (and I guess most of the other authors do the same) I always put the bumpers on a wall 15 units high, since the default bumpers are too short. I'm aware that a default higher bumper will break all the older tables, so maybe it will be possible to do as with the plunger? Old bumper should be default, and new bumper But I guess most new tables will use a primitive or two to make the bumpers Well, just an idea I got

 

rev 875 now has an additional height offset for bumper elements.. there you could basically set the 15, and that's it..

Edited by toxie, 16 January 2014 - 08:15 AM.

[fuzzel]

rev 876 adds the scaling option for the z axis. Please test this if I forgot something here

[unclewilly]

Won't be able to test for a few days.
What exactly does the z axis scaling do?

[LoadedWeapon]

Does this let you add depth to the table kinda like bam for FP?