2087 replies to this topic

[arngrim]

here's mb killer edition simple test, don't worry about the crappy resolution (will keep the resolution next time ), the creature panel lights are making the panel disappear, and the lights of frankenstein are flockering as far as i can see

 vp9dx9mbkiller.rar   963.14KB   35 downloads

Edited by arngrim, 16 February 2014 - 07:14 AM.

[teppotee]

Tested with MB (seems to be a good test table) and noticed few things as well with the alpha lights. Not sure if this goes to the known GI issues you mentioned. Errors highlighted in screenshot. (using version 2.1)

 

The performance is incredible compared to the old dx7 version! From 35FPS to around 600 Can't wait to get this as my main version in near future!

Attached Files

•  mbErrors.png   2.1MB   14 downloads

[koadic]

Tepp, those all look like layering order issues, now that the lights are dynamic as well and need to be accounted as such and adjusted in the editor just like ramps and flashers.

[teppotee]

That's probably true (about the layering). Just reporting in case the desired solution is to have full backwards compatibility without the need to go through all table objects. Still... the performance gain so huge that it will be worth doing in case it can't be done.

Edited by teppotee, 16 February 2014 - 08:05 AM.

[mukuste]

Ok, I fixed the red lights, that was rather simple.

 

Can someone explain how the creature panel lights are done? I can't find the objects in the editor.

[jimmyfingers]

Thanks for the latest update mukuste. It seems that more layering / ordering issues are changed than just that to make the fading lights try and work correctly. The alpha ramp ordering by height I think is going to cause more problems than what it will solve and I feel that this is one thing that should be reverted to the previous functioning as I’ll explain.

 

Right off the bat a decent example is indeed with Monster Bash and I experience the same thing that Angrim posts about above. When I assess the table (same PC killer version 2.1 as his and screen shot – video - already provided by him), I can see that the two alpha ramps (green halos) that are ordered incorrectly (I imagine not by coincidence being the two lowest ramps) are totally in front of the back alpha ramp / image that is the main creature panel / back drop.  Here’s a screen capture and I’ve selected the bulb halo ramp but highlighted the back panel several units behind.

 

 Capture of Monster Bash Creature Panel Issue .PNG   93.78KB   22 downloads

 

This is going to be an issue as clearly the alpha ramps for the bulb glow / halo are in front physically but their order is seemingly now getting decided solely by their height and deemed lower than the panel.  This type of problem will likely happen more with alpha ramps that are angled or, like these, almost vertical.  It seems of interest and I’m going to guess here that some type of midpoint calculation is at work now, otherwise there’s no reason why the 3rd light should also not yield the problem (l83) as it’s top height of 330 is below the top height of the panel (ramp3 / creatureplasticSign image) which is set to 375.  However, if you’re working with the panel / ramp3 midpoint of 210 (375 top 45 bottom), then the midpoints of l81 and l82 (135 and 205 respectively) fall below ramp3’s at 210 (and drawn wrong / behind) and l83’s midpoint, being higher at 280, does not get drawn incorrectly behind. 

 

This is going to be a problem showing up in many spots / tables and won't be necessarily just an ease of compatibility / minimal changes needed aspect but how one would even fix as the position is not really something that can be tweaked.  However, before at least we could use drawing order (back / front) to compensate and get the necessary shingling aspect needed (the height in the Monster Bash table can not really be altered for any of the objects involved). I know when I've had alpha lights / halos close to each other along the Y axis of the table with some angle or largely upright (like in this case) and at similar heights, I've totally needed to use the draw in front option.  So, more than the task of working with old tables, fixing them at all becomes something that may not even be possible now with ordering being handled by height alone and not workable until a whole new lighting process is developed where none of this is needed. 

 

I get that the lights needed to potentially have something because of the fading / updating of light states when multiple objects cover each other, and even the transparent layering / ordering being after non-transparent (I’m assuming here also pre-rendered) but changing the draw order to be solely based on height of alphas / transparent ramps will be something that breaks too much from what I can tell / theorize and at best should be left until there is a more real 3d environment with new lighting models where we’re not slicing 2d planes in front of various objects.   I also believe that the other devs thought about this concept but decided against it / never implemented it.

 

As far as the work around for the fading lights which now has them cycling through correctly - but not the GI - using the drawing in back of the last light to be updated,  that makes sense why it would only work for fading lights where there’s only two objects on top of each other. Drawing the one in back after it’s changed still yield’s the goal of having the other become in front and in the way that routine works would be fine.  But, with the GI8 having 8 light objects, simply placing the last one to change in the back isn’t going to guarantee that the one that is now in front will be the next light to go on / have it’s state changed (this I imagine is why it’s not working and also why on some light map fading lights, that use 3 objects, it also isn’t working correctly – I did a quick test with a Centaur WIP that I could send you the link to in a PM if necessary).  It may not be possible, but it seems that a fix for all of this would be to alter the draw order as a precursor / prerequisite to a light’s state being changed (i.e. don’t draw the last one to change in back, but draw the one that is about to change, in front – just before it happens).  Maybe this would require some additional coding for lights but if you could work something like that it would be ideal and I bet you then the GI8 / light map fading would work.  Hopefully you get what I’m angling at and maybe even already thought of that route but couldn’t do it for some reason or logic / programming constraints.

 

I’ll try and do more tests tomorrow as it’s super late now. 

 

Thanks for all of your efforts and things like getting the ball stretching going properly now in windowed full screen mode.

Edited by jimmyfingers, 16 February 2014 - 09:29 AM.

[Sheltemke]

Just tried the few table what had (micro)stutter for me with ANY settings with the vp 9.2.1 revs: Monster Bash PCKiller 2.1(the 2.0 LP runs perfectly with dx7 vp), STTNG teppotee with Primitive Cannon setting 1, Starship troopers, Checkpoint, Banzai Run.

All those table runs perfectly smoothly with the dx9 test3.

 

You are my new hero Mukuste Amazing job you doing.

 

edit: When you release the final version this community will forget in short time what the "stutter" word means

Edited by Sheltemke, 16 February 2014 - 10:50 AM.

[LoadedWeapon]

Man wish I dident have to work all day! yea this will bring vp to alot more people I think with maybe even playing on onboard video.. amazing improvements. . Thanks for all the work!

[JohnnyDoe]

On scared stiff(Scared_Stiff_VP91x_1.4.4FS) I get this instead of the spinning spider on the apron I think its called.

 

 ScaredStiff.png   40.59KB   23 downloads

[gtxjoe]

1) Space Shuttle rosve 1.3:  All light inserts go black during end of game/match game.  The black must be coming from the PFGI light object as the light inserts images do not contain black inserts.  The PFGI inserts are pure black (0,0,0), so shouldn't this be transparent?   Maybe when PFlight2.state=1 (PFGI0).   Just noticed it occurs during pre-game animation when playfield GI goes off.

 

2)  Recommend creating a separate VP registry entry for VP9DX9 as anyone wanting to run multiple flavors of VP will need separate settings as windowed fullscreen not supported on older VP

 

Thanks for all the work!

Edited by gtxjoe, 16 February 2014 - 03:34 PM.

[ringorian]

2) Recommend creating a separate VP registry entry for VP9DX9 as anyone wanting to run multiple flavors of VP will need separate settings as windowed fullscreen not supported on older VP

Thanks for all the work!

Could this be done already ? If yes , how ?

[LoadedWeapon]

Just give him some time to finish.. has worked on it less than a month and we can already play in dx9.. im sure he can handle these few bugs that are left.. I have full confidence that this will be fully working soon..

[unclewilly]

Another bug on monster bash.  when an alpha ramp is on top of a light object.  it disappears.  the writing on the drac lights shown previously.  also the creature which was done on an alpha ramp also disappears

 

as seen in the ss directly above

Edited by unclewilly, 16 February 2014 - 08:41 PM.

[mukuste]

@ JF:

 

I didn't explain well. The way the lights routine works is that a changed light is made to draw LAST. This means that first the "wrong" lights are rendered, and finally the most up to date light is rendered, overwriting the other lights. Therefore, "last" actually means "draw on top" here. Then, when another light changes its state, it now takes the "king of the hill" spot at the end of the draw order.

 

This whole trick needs the engine to handle the draw order itself, otherwise it doesn't work. This is why I had to introduce the draw order changes. I recognize it's not perfect, but I've given up any hopes of 100% VP9 compatibility, I don't think it's possible with the new renderer without excessive work put into it at least. I've settled for something which is "good enough" to play most VP9 tables reasonably. It just won't be possible to fix all the small glitches, as when I fix one, most likely another one appears due to the change.

 

The reason I prioritized the proper drawing of the lights for this patch is that they are important to gameplay. If I don't see what targets are lit, I don't know what to shoot for. If, on the other hand, some flasher renders glitchy, it may be annoying but it doesn't change the game as such. I think the lights work much better in this patch.

 

In the end, I want to move on to VP10 and provide exciting new features for the community. Endless tweaking of the renderer to support old tables will only get us so far.

 

I also want to point out that, if we really want to have a dynamic camera in VP10, we do need automatic depth sorting since letting the author do that only works for a fixed point of view.

 

Finally, as for MB: I improved the depth calculation routine a bit, but still it buys us only 3 out of 4 properly rendering lights on the creature panel (up from 2). I found a simple fix, however: the Ramp3 (the panel itself) should be changed from an Alpha ramp to a Solid one. This lets the engine figure out that the panel isn't transparent and the lights should be drawn on top of it. As far as I see, the panel has no reason to be an alpha ramp anyway, so this doesn't degrade the rendering in any way.

 

@ gtxjoe:

 

Black was only transparent in the DX7 renderer. It used color keying for that, which is not supported in DX9.

 

Windowed fullscreen should actually work reasonably well in the old player (except for ball stretching) if you first set it up in the new one. The old one just lacks the menu option for it.

 

@ JohnnyDoe:

 

That's... weird. I can reproduce the bug, but I have no idea why it happens. It also happens only in release builds, not in debug ones... those are the most annoying bugs...

EDIT: Huzzah! I figured it out. All's well now.

Edited by mukuste, 16 February 2014 - 10:05 PM.

[DJRobX]

My my, this is really looking good!  Indiana Jones is near perfect now.  

 

TZ (FS Megapin) has a pretty catastrophic result with this version though, some texture appears that covers up the whole upper-left section of the playfield.

 

 

You can get the table here:

 

http://www.hyperspin...Zone-by-MegaPin

[unclewilly]

I'm not that concerned with compatibility

I'd rather have the new features possible for vp 10.

We could nitpick glitches and tie up development forever.

I'd rather get to vp10.

[bent98]

I hope someone on the pinmame team ports to dx9 also.

Edited by bent98, 16 February 2014 - 11:39 PM.

[DJRobX]

I hope someone on the pinmame team ports to dx9 also.

I would do that myself but I don't think it would be worth it.  Now that the Unit3D pinball project has given a way to grab the DMD graphical data, it seems it would make more sense for VP10 to pick up the Unity method of grabbing the DMD data, and rendering the visual for itself.   Then you could have the DMD properly behind the alpha ramps in CV, for example.  

 

Another option would be that B2S server could do the DMD rendering on pincabs.   This would make more sense, since the B2s server already knows where the DMD should go.   And then you wouldn't have the strange draw-order issues (DMD is behind - F3/Reset - DMD is now in front) that we sometimes have now.

Edited by DJRobX, 16 February 2014 - 11:52 PM.

[mukuste]

My my, this is really looking good!  Indiana Jones is near perfect now.  

 

TZ (FS Megapin) has a pretty catastrophic result with this version though, some texture appears that covers up the whole upper-left section of the playfield.

 

 

You can get the table here:

 

http://www.hyperspin...Zone-by-MegaPin

 

Huh. Test3 indeed has some weird glitches (though mine look different). Whatever I did between Test3 and now seems to have fixed it though! So TZ should work again in the next release.

 

(My version of that table claims to be Megapin 1.3, although I can't find that on that site. They seem to be more or less the same though.)

[DJRobX]

The glitches look different every time I restart the table.   Suggests something is reading uninitialized memory, maybe whatever you did to fix SS fixes this also?