2087 replies to this topic

[DJRobX]

The strange part is that it's not in the shape of a circle in 1920x1080. In 1024x768 it looks like mini-blinds. I suggest saving the screenshots then zooming in on them, you'll see what I mean. It reproduces in VMware as well as on Nvidia hardware if you want to take a look at the table directly. It's the hole by the goalie, but the other hole has similar funniness that's harder to see.




Sent from my iPhone using Tapatalk

[gtxjoe]

I am not at home to check, but I believe I have seen  the mini-blind effect also on Bob5453 flipper test table.  It has lights in the center of visible kickers

 

http://www.vpforums....s&showfile=6191

[DJRobX]

It looks like the vertices with these indexes just aren't building the intended model.  If you change it to be like the kicker hole above (Vertices+16), you get a solid pink circle.    It seems that the the "lid" code was copied from the kicker hole, but the same index building strategy may not work correctly for the vertices that build the "top outer ring" (32+). 

 

I"m not sure what the desired behavior is.  In VP9 DX7, the images of the playfield's kicker holes are visible (no pink circles - full holes aren't being punched out of the playfield).   So it seems like there shouldn't be holes punched in the playfield for a kicker cup?   Of course, that probably means balls getting cut in half.    It's almost like you'd need to copy a bit of the playfield image and place it into the hole at a lower depth bias (not punching a hole, but "bending" a hole into the playfield). 

 

I'm still learning and trying to make sense of how a lot of this works.   Now that I've given myself a headache I'm going to bed, LOL

 // Draw the top "lid" of the kicker hole invisibly (for the depth buffer)
         for (int l=0; l<14; ++l)
         {
            rgi[l*3  ] = 0;
            rgi[l*3+1] = l+1;
            rgi[l*3+2] = l+2;
 
            SetNormal(vertices+16, rgi+l*3, 3, NULL, NULL, 0);
         }
         float depthbias = -1e-4f;
         pd3dDevice->SetRenderState(RenderDevice::DEPTHBIAS, *((DWORD*)&depthbias));
         pd3dDevice->SetRenderState(RenderDevice::COLORWRITEENABLE, 0);         // write only to depth buffer
         pd3dDevice->DrawIndexedPrimitive(D3DPT_TRIANGLELIST, MY_D3DFVF_VERTEX, vertices+16, 16, rgi, 3*14);
 

Edited by DJRobX, 25 March 2014 - 06:55 AM.

[mukuste]

Wait a second, I'm confused. Are we talking about the UpperEjectHole? That one is set to KickerInvisible, so it shouldn't render anything at all. Why does disabling the draw call have an effect then? It seems that its visual component is produced by the assistscooplight, which is set to the playfield texture. Also of note is that the kicker is set to surface 5h, while the light is at playfield level.

 

By the way, if you aren't yet, I definitely recommend using Pix to debug such issues better. Set it up to do a full capture of Frame 1 and it will show you step by step how the frame buffer is built up.  A similar, more comprehensive tool is Intel GPA.

[mukuste]

For me it looks like this:

 

 Screenshot 2014-03-25 10.51.05.png   43.25KB   18 downloads

 

This is just the playfield texture and therefore how it should look, IMO.

 

Since the kicker is invisible, I don't see how changing the kicker code could change the rendering. Did you change anything else, either about the table or the code?

[mukuste]

Working pretty much perfectly on my setup.

Couple of minor glitches there is a thin black line on the middle of the boat (slightly to the right of the left ramp) on Melon's excellent new fish tales

 

I'll need a screenshot on that, can't reproduce anything out of the ordinary.

[kruge99]

From my recollection on the DX7 builds of VP, if it's property is 'visible' then the kicker cup should have an inverted cone primitive inside to 'trap the ball' and a kicker hole should have a cylinder that punches a hole through the playfield.

[mukuste]

From my recollection on the DX7 builds of VP, if it's property is 'visible' then the kicker cup should have an inverted cone primitive inside to 'trap the ball' and a kicker hole should have a cylinder that punches a hole through the playfield.

 

Ok, but this is neither a Cup nor a Hole kicker, its type is set to Invisible, so my understanding is that it shouldn't render at all.

[kruge99]

 

From my recollection on the DX7 builds of VP, if it's property is 'visible' then the kicker cup should have an inverted cone primitive inside to 'trap the ball' and a kicker hole should have a cylinder that punches a hole through the playfield.

 

Ok, but this is neither a Cup nor a Hole kicker, its type is set to Invisible, so my understanding is that it shouldn't render at all.

 

 

I agree, but could the weird primitive DjRobX found be probably responsible for cutting the ball in half?

[DJRobX]

Interesting - Mine is not set to invisible.  Both it, and RIghtEjectHole are set to "KickerCup" in the version of the table that I have.  

 

Setting it to invisible is an easy fix, but try setting it to KickerCup, and you hopefully will then see the problem with the texture it's trying to use to poke a hole in the Z buffer.   Thanks for the tips on using pix, I'll take a look, I'm very new to 3D debugging. 

 

I took a look at Melon's Fish Tales and I don't see any problems on that table either (tried both FS and desktop)

Edited by DJRobX, 25 March 2014 - 03:14 PM.

[unclewilly]

I like the z sorting in this. No graphics corruption on flasher objects in test 11 on my monster bash update.
Dx7 has corruption all over the place

[Pinball999]

Talking about Z axis. I've realized that non of the new releases are using a modified view and keep the default value (at 1).

It seems that changing the z value to 1.1 on most table gives more depth and increase the perceived 3D. (at least for me)

(1.15 or 1.2 gives also quite good results, but it generally creates some graphic issues with elements covering each other)

 

Have you been experimenting with it on your side? Do you prefer the default value?

Edited by Pinball999, 25 March 2014 - 03:41 PM.

[unclewilly]

You mean instead of using the lay back setting?

I was going to experiment with that as soon as I get this lighting done.

I'm curious how this looks with the tables.

Could you please me some settings that you have found that look good, so I can use them as a starting point for monster bash

[Pinball999]

No, on top of the layback settings. For MB for instance, I keep all angle + layback values, and just slightly change the z to 1.1 or a bit more.

It helps to make the objects "pop" from the screen.

 

It's such an easy change that I'm wondering why we don't see it in recent releases.

[grunger106]

Screenshot coming up

I'll get one the next time I fire up the cab.....

Could you open the coin door with END? I couldn't, but can't see why that would be related to a change in the graphics engine.

I can on other tables, and I haven't tried FT in 9.2.1.....

Edited by grunger106, 25 March 2014 - 06:35 PM.

[fuzzel]

No, on top of the layback settings. For MB for instance, I keep all angle + layback values, and just slightly change the z to 1.1 or a bit more.

It helps to make the objects "pop" from the screen.

 

It's such an easy change that I'm wondering why we don't see it in recent releases.

You mean the Z scale option in the layback settings. This feature came with 9.2.1 and it's main purpose is to add depth to already released tables

[Pinball999]

No, on top of the layback settings. For MB for instance, I keep all angle + layback values, and just slightly change the z to 1.1 or a bit more.
It helps to make the objects "pop" from the screen.
 
It's such an easy change that I'm wondering why we don't see it in recent releases.

You mean the Z scale option in the layback settings. This feature came with 9.2.1 and it's main purpose is to add depth to already released tables

I know But we should not limit it to older tables, since it can also improve the perceived 3D on tables created with 9.2.1.

[dyopp21]

I've been watching this thread for some time, and I have what may be a silly question:  When this is ready for an official release, will it completely REPLACE the DX7 version of VP on our cabs?  Or will we have to use the DX7 version on tables that haven't been updated to run on the DX9 version?  If I'm skipping way ahead, feel free to punch me. 

 

Also I'd like to add that the progress being made day-by-day to get VP to DX9 is amazing to watch.  Many thanks to mukuste and all that are involved.

 

I wish I knew more about programming and debugging and could offer some help, but I'm just a simple hack.

[LoadedWeapon]

yea i set mine to 1.1 or 1.2 on all my tables... I like it

[R-DuB]

Anyone have problems loading melons new CFTBL ?