2087 replies to this topic

[mukuste]

In the end the proper solution (and what should have been done from the start) is not to use the in-memory representation, but to write proper serialization functions for these data types. I did this for the 3D vector now. I mean, writing a 3D vector to a file with its dummy padding word is just bat shit insane -- and now we are stuck supporting this insanity indefinitely for the sake of backwards compatibility.

 

I added the note to the Vertex3D_NoTex2 structure. Vertex2D is unlikely to have its memory layout changed, and I haven't looked at the protection data struct. Couldn't harm to note it, you're right.

 

By the way, I wondered a while now; you seem like a resourceful guy, aren't you interested in joining the VP dev team proper?

[DJRobX]

Completely agree, just thinking tactically about what's there currently.    And yeah, it's probably time to request proper write access.   Would make it a lot easier to help out.  I'll send Toxie a note.    Thanks.   

[slashbot]

Thanks for the fix,just found a bug in test12a maybe there is already talked about this before, but i just want to report it:

 

The lights for skillshot in Lethal Weapon 3 (Data East) (1992) (oooPLAYER1ooo) (1.1) are not correct

 

Test12:

 

VP 920 rev640

Edited by slashbot, 23 March 2014 - 12:56 AM.

[DJRobX]

Thanks for the fix,just found a bug in test12a maybe there is already talked about this before, but i just want to report it:

 

Thanks for reporting this.   I just checked - the fix I wrote to preserve the order of scripted light changes also seems to fix this.   Once I get SVN write access I can check it in, or Mukuste can try the code I posted a few pages back. 

Edited by DJRobX, 23 March 2014 - 01:35 AM.

[GamerKid]

Tables are still pitch black for me

 

Edit: Well I'll be damned, the issue has to do with Transform and Lighting even though my graphics hardware supports it properly.

Edited by GamerKid, 23 March 2014 - 05:31 AM.

[arngrim]

i'm not sure if the white areas issue are considered resolved but the issue is there on scarface with test12a:

 

 Sans titre.png   1.5MB   20 downloads

 

what ca be done to fix it?

[mukuste]

Completely agree, just thinking tactically about what's there currently.    And yeah, it's probably time to request proper write access.   Would make it a lot easier to help out.  I'll send Toxie a note.    Thanks.  

 

Nice. Toxie can't do that, you'll have to contact maddes about that (that's what I did at least).

 

 

Tables are still pitch black for me

 

Edit: Well I'll be damned, the issue has to do with Transform and Lighting even though my graphics hardware supports it properly.

 

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

 

 

i'm not sure if the white areas issue are considered resolved but the issue is there on scarface with test12a:

 

Sans titre.png

 

what ca be done to fix it?

 

No, the hotfix was only for the table corruption bug. But I found a fix for this and it will be in the next release.

[bodydump]

 

i'm not sure if the white areas issue are considered resolved but the issue is there on scarface with test12a:

 

 

what ca be done to fix it?

 

 

This is the reason it's not working:

 

 

About the non-transparent ramps: those use the "magic" 123,123,123 color, which tells the engine "I don't have a transparent color", which then assumes that the texture has no transparency. However, it doesn't check if the texture has an actual alpha channel, so I'll have to add a check for that somewhere.

 

 

If you want a temp fix just change the transparency on the apron image from 123,123,123 to any color that's not in the image like bright green or something.  But I'm sure Mukuste will take care of the underlying problem.

 

Edit: He even answered the question as I was answering.  

Edited by bodydump, 23 March 2014 - 07:08 AM.

[tttttwii]

Thanks Bodydump, your advice helped. Even easier: Setting the apron to alpha instead of solid also solved the issue in one click! JPs AFM beta is now working like a charm.

 

Thank you all for your hard work, especially Mukuste, Toxie and Fuzzel for their great achievements in the last 12 month!

 

 

 

i'm not sure if the white areas issue are considered resolved but the issue is there on scarface with test12a:

 

 

what ca be done to fix it?

 

 

This is the reason it's not working:

 

 

About the non-transparent ramps: those use the "magic" 123,123,123 color, which tells the engine "I don't have a transparent color", which then assumes that the texture has no transparency. However, it doesn't check if the texture has an actual alpha channel, so I'll have to add a check for that somewhere.

 

 

If you want a temp fix just change the transparency on the apron image from 123,123,123 to any color that's not in the image like bright green or something.  But I'm sure Mukuste will take care of the underlying problem.

 

Edit: He even answered the question as I was answering.  

 

[grunger106]

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!

[gtxjoe]

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?

Edited by gtxjoe, 23 March 2014 - 10:36 AM.

[Pablouk]

Is there any reason for my dmd jumping back from the 3rd monitor to the playfield. It wont stay on the 3rd monitor i have to move each time i load a table. Iam sure this must have been covered already but it just seems to have happened since i started using dx9 ver

Thanks for any help

[slashbot]

Have you overwritten the VPinmame.dll with another version?

u need the Vpinmame cabinet version dll for the dmd to stay on the last position.

[Findusone]

testing 12a

 

I miss some playfield pictures in Austin Powers and Huricane.

https://www.dropbox....9qka/4WD1iIM670

 

[Pablouk]

Have you overwritten the VPinmame.dll with another version?
u need the Vpinmame cabinet version dll for the dmd to stay on the last position.

Yeah iam using the cab dll but it still stays on playfield it was ok until i use dx9 ver

[DJRobX]

testing 12a

 

I miss some playfield pictures in Austin Powers and Huricane.

https://www.dropbox....9qka/4WD1iIM670

 

 

Austin Powers is working fine here (even in VMWare on a mac).   What video card are you using?   Some have reported dark playfields with older Intel onboard graphics.

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?

 

You seem to be suggesting that this is something we should do during the beta, but it sounds like something you'll always want going forward, even once the DX9 port is official.   Many tables will need the authors to update for full compatibility even after the release is done (T2 being a good example).

 

The best solution with what we have now is to run regedit to import the settings you want prior to running VP.   An alternative might be to offer a command line switch that allows you to specify an alternate registry location to pick settings up from (something like "/registrysettngs="VPDX7").  If we did that, you would be able to update the command lines used in your front end to pick up different registry locations for different profiles.

Edited by DJRobX, 23 March 2014 - 03:04 PM.

[htamas]

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?

 

It sure is possible. That's what I do right now with a few tables that have issues when running with the DX9 test.

I simply configured PinballX to run those using the DX7 9.2.1 executable and the rest with my primary player which is the DX9 test.

Since both alpha ramp accuracy and vsync can be set individually on a table-per-table level, you can set alpha ramp accuracy to max. and vsync to 0 in DX9 VP video preferences and for the tables you want to run with DX7, you'd set these two in each table to whatever setting you want, overwriting the global setting.

There is no need to have a separate registry area to do this.

 

If those problematic tables get fixed, I just move them out of the DX7 area and back to the DX9 XML so that they'll be then run with DX9 like the majority.

[R-DuB]

I have just played The Addams Family 2.0 by Melon and the Thing animation stops before it finishes its cycle and then can not find the ball when using the VP9_DX9_test12a.

[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.

Edited by GamerKid, 23 March 2014 - 05:06 PM.

[Findusone]

 

testing 12a

 

I miss some playfield pictures in Austin Powers and Huricane.

https://www.dropbox....9qka/4WD1iIM670

 

 

Austin Powers is working fine here (even in VMWare on a mac).   What video card are you using?   Some have reported dark playfields with older Intel onboard graphics.

 

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