2087 replies to this topic

[DJRobX]

Yes, I use an INTEL onboard card for the DMD. The playfield and the backglass are working with a geforce 560.

But I'm not sure, if this is the reason, because with version 10 and 11 Huricane and Powers works fine for me.

With version 12a, i've got the problems with the dark playfields

 

 

So you're seeing a dark playfield on the GeForce 560?   What OS are you running?   What Nvidia driver version?  Are you using any enhancements in the nvidia control panel? 

[ClarkKent]

Since latest test version the top of the ramp borders in Bad Cats are not transparent anymore. And I also have the problem with apron in the latest beta of AFM.

[Findusone]

 

Yes, I use an INTEL onboard card for the DMD. The playfield and the backglass are working with a geforce 560.

But I'm not sure, if this is the reason, because with version 10 and 11 Huricane and Powers works fine for me.

With version 12a, i've got the problems with the dark playfields

 

 

So you're seeing a dark playfield on the GeForce 560?   What OS are you running?   What Nvidia driver version?  Are you using any enhancements in the nvidia control panel? 

 

Yes, I see the dark playfield is on the GeForce. I use win7 64bit, my Geforce driver version is 335.23, and I use the factory settings in the nvidia control panel.

[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

And for some reason pressing END doesn't open the coin door, although that's the key binding (Home does SLAM TILT ok) Is that just me?

 

Working the video card much harder as you'd expect - the fan noise coming of the minicab is much louder now!

 

You should definitely try the frame rate limiter, 120 fps works well for me and keeps the video card cool!

 

I'll check out Fish Tales (anyway wanted to give that table a spin).

 

 

 

Regarding separate registry request, the reason for the request is to be able to run both dx7 and dx9 versions with unique VP settings for use with the PinballX/Hyperpin frontends.

 

DX9 would be used for the majority of tables with max alpha ramp accuracy setting and frame rate specified via vsync.  While tables with dx9 related issues, I will run in dx7 environment with alpha ramp setting set to middle and vsync set to 0.  I don't think this is currently possible.  Is there a way to do this without separate registry entry?

 

I think we'll have a separate registry key for the official release, unless the suggestions posted by others completely eliminate that need.

 

 

 

That's interesting; how did you come to that conclusion?

 

I used a 3rd party software to emulate Hardware TnL and the tables were correctly visible aftward. I was also able to use software TnL to the same effect.

 

That's a very good find. I tried it and indeed switching to software vertex processing fixed the rendering on my Intel card completely. I'll lobby to get a checkbox in the video options for that.

 

 

Since latest test version the top of the ramp borders in Bad Cats are not transparent anymore. And I also have the problem with apron in the latest beta of AFM.

 

Those were discussed already and are fixed in the next release.

[gtxjoe]

I am trying to compile the dx9 build.

- If I open VBATest.net2008.vcproj in the DX9 branch, it compiles the VP 9.1.5 build.

- If I open VBATest.net2008.vcproj in the DX7 branch, it compiles the VP 9.2.1 build.

(I installed VS2008, DirectX SDK Feb 2007, tortoiseSVN and checked out rev 963.)

What am I missing?

 

Also is the "Release MinDependency Fast + SSE" build config used the releases?

 

 

EDIT:  Got it working with the tip to use the trunk folder and cmake.  Just followed instructions in the README_cmake.txt file.  Thanks!

Edited by gtxjoe, 23 March 2014 - 11:17 PM.

[DJRobX]

(I installed VS2008, DirectX SDK Feb 2007, tortoiseSVN and checked out rev 963.)

What am I missing?

 

Also is the "Release MinDependency Fast + SSE" build config used the releases?

 

You want the trunk.    I run the MinDependency Fast+SSE version on my cab and it seems to work fine.

 

You may have issues building if the VS 2008 project isn't up to date.   Currently I know the 2010 project is good, but don't be surprised, in general, if you have to go in and add files and mess around with stuff a bit to get a successful compile.  Mukuste doesn't use VC project files so if he adds something new you'll need to add it. 

 

Feel free to PM me if you have any questions or problems building, this thread is long enough as it is, probably would be better not to clog it up with this subject. 

Edited by DJRobX, 23 March 2014 - 08:48 PM.

[mukuste]

I am trying to compile the dx9 build.

- If I open VBATest.net2008.vcproj in the DX9 branch, it compiles the VP 9.1.5 build.

 

That's... not really possible, unless you have the 9.1.5 sources lying around somewhere and the paths are pointing to that instead. EDIT: Aaah, you mean the actual branch... that's very old and out of date afaik. Should probably be deleted. As Rob said, you want the trunk.

 

I don't know if the 2008 project is up to date, the only thing I can tell you is to run CMake to get an up to date VS solution (I always keep the CMake file current).

 

So far I just used a bog standard Release configuration to build the releases, it seemed to work fine.

Edited by mukuste, 23 March 2014 - 08:49 PM.

[DJRobX]

Seems to be a collision issue in 12a - ball gets stuck on the right ramp in WCS 94 every time.

 

Edited by DJRobX, 23 March 2014 - 10:15 PM.

[mukuste]

Hmm.... tricky one.

 

I figured out that some of the HitTriangles on that table have zero normal, which is bad news. The revision which triggered this is r949, the reason is that Normalize() doesn't check for zero length before dividing, like the old code used to.

 

But the real issue is that we shouldn't have any hit triangles with zero normal. Turns out they come from ramps, here to be precise:

         Vertex3Ds rgv3D[3];
         rgv3D[0] = Vertex3Ds(pv3->x,pv3->y,rgheight1[i+1]);
         rgv3D[1] = Vertex3Ds(pv1->x,pv1->y,rgheight1[i]);
         rgv3D[2] = Vertex3Ds(pv4->x,pv4->y,rgheight1[i+1]);

         HitTriangle * const ph3dpoly = new HitTriangle(rgv3D);

And here is a list of ramps which trigger this bug:

Ramp1002
Ramp1003
Ramp709
Ramp1023
Ramp1021
Ramp601
Ramp1026
Ramp1027
Ramp294
Ramp303
Ramp966

It seemed that cvertex was 2 on all of those that I checked. Not sure yet what the root cause is here, have to find one of those in the editor first. I really wish the dropdown menu for finding elements by name wouldn't extend past the border of the screen...

 

EDIT: Aha! Those seem to be the ramps which have Top Width or Bottom Width 0. Why do they exist?

Edited by mukuste, 24 March 2014 - 01:17 AM.

[unclewilly]

This was probably made when the first alpha ramps were introduced to vp.

Authors didn't know about the script able alpha property at that time. So to do some animations you would set an alpha ramps width to 0 to make it disappear and the open another ramp with the next frame of animation.

This was also before we could cycle images to a single ramp

[mukuste]

Hm, it doesn't seem to be this... actually these ramps are triangles which are put around the exit holes of some of these ramps. I just don't understand why they are there, if they are purely visual (and should have Collidable disabled), or whatever.

[gtxjoe]

I really wish the dropdown menu for finding elements by name wouldn't extend past the border of the screen...

 

If you know the name of the object/objects, you can also select them via Edit->Select Element

 

If you want to move them, unlock them, transpose, move to layer, etc but they are covered by other objects, one trick is to place a timer object off the table, select it.  Then use the Edit->Select Element menu to select the objects of interest.  After that you can right click on the timer object, to modify the property of all the selected objects 

[Arcade4]

Hurricane in test 12a. Worked fine in 11.

 

 

 

Attached Files

•  IMG_0862small.jpg   126.73KB   14 downloads

[bodydump]

Hm, it doesn't seem to be this... actually these ramps are triangles which are put around the exit holes of some of these ramps. I just don't understand why they are there, if they are purely visual (and should have Collidable disabled), or whatever.

Highly possible that they are just visual.  Koadic and I didn't rebuild that ramp when we modded.  We only redid the lip graphics.  I'll take a look when I get a chance.

[GamerKid]

 

 

That's interesting; how did you come to that conclusion?

 

I used a 3rd party software to emulate Hardware TnL and the tables were correctly visible aftward. I was also able to use software TnL to the same effect.

 

That's a very good find. I tried it and indeed switching to software vertex processing fixed the rendering on my Intel card completely. I'll lobby to get a checkbox in the video options for that.

Thanks for the support; also glad to be of help!

[boiydiego]

if the final release is there from dx9 then PLEASE note in the download what thing best to set in vp for making it work like it should like vsync on 120 etc etc

because this threat is getting to long to remind the change to make in vp ..

[mukuste]

Ok, I added a check for degenerate triangles in the ramp code, which fixes the WCS'94 issue.

 

Hurricane in test 12a. Worked fine in 11.

 

I guess this is just the solid ramp transparency problem again?

[Arcade4]

Ok, I added a check for degenerate triangles in the ramp code, which fixes the WCS'94 issue.

 

Hurricane in test 12a. Worked fine in 11.

 

I guess this is just the solid ramp transparency problem again?

Probably. I do not have enough knowledge to know.

I did go back an load it in Test 11 and it loaded perfectly.

[DJRobX]

Confirmed that the ramps are working again.  Now I noticed something else with this table - the kicker cups have pink garbage on them.  Happens on both my laptop and on my cab.

 

 

If I change the window resolution to 1024x768 it affects this:

 

 

If I comment out the DrawIndexedPrimitive line in this code - (after case KickerCup):

// Draw the top "lid" of the kicker hole invisibly (for the depth buffer)
  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+32, 16, rgi, 3*14);
         pd3dDevice->SetRenderState(RenderDevice::DEPTHBIAS, 0);
         pd3dDevice->SetRenderState(RenderDevice::COLORWRITEENABLE, 0x0f);      // re-enable color writes

The pink stuff goes away.

Edited by DJRobX, 24 March 2014 - 11:16 PM.

[mukuste]

I can't see much from these screenshots, but maybe it's the background shining through? That code draws an invisible disk on top of the kicker hole so that the playfield doesn't overwrite the kicker hole. Basically, this call should never render any pixels itself, but it punches a "hole" in the depth buffer. If it does render something, then there must be a bug, perhaps some render state not being set correctly.