1031 replies to this topic

[hanzoverfist]

Ok so as WRD has already mentioned, a problem exists with static/ non static rendering, it seems when a group of primitives are group by a collection in game rendering is ok when static rendering is enabled, but not ok when static rendering is off.

 

solution remove primitives from collection.

 

you can test this on JP's panthera table by selecting 'primitive39' as a collection and turn off static render, then run the table, you should see that some polygons will render incorrectly.

 

EDIT: Also, if you select 1 item in the collection (primitive 39 to be precise) and turn off static render on it, that item will not render at all in simulation. Maybe thalamus is experiencing this.

 

EDIT2: This bug is dynamic in nature, and results will probably vary per author/developer.

 

For those who do not have JP's table(probably few and far between)

https://youtu.be/-fLQ0_pHhxk

Edited by hanzoverfist, 12 June 2018 - 06:28 PM.

[Rawnei]

Potential SBS 3D bug? http://www.vpforums....=21658&p=407968

[hanzoverfist]

 

Potential SBS 3D bug? http://www.vpforums....=21658&p=407968

 

 

@Rawnei What you are talking about is completely different

[fuzzel]

Ok so as WRD has already mentioned, a problem exists with static/ non static rendering, it seems when a group of primitives are group by a collection in game rendering is ok when static rendering is enabled, but not ok when static rendering is off.

 

solution remove primitives from collection.

 

you can test this on JP's panthera table by selecting 'primitive39' as a collection and turn off static render, then run the table, you should see that some polygons will render incorrectly.

 

EDIT: Also, if you select 1 item in the collection (primitive 39 to be precise) and turn off static render on it, that item will not render at all in simulation. Maybe thalamus is experiencing this.

 

EDIT2: This bug is dynamic in nature, and results will probably vary per author/developer.

 

For those who do not have JP's table(probably few and far between)

https://youtu.be/-fLQ0_pHhxk

Ah good reminder There is a problem in the algorithm that checks all meshes in a collection if they use the same texture and material and combines them in one big render buffer if that is the case. I've always wanted to fix that but I kind of lost track of it

Though the grouping option was originally added for this situation I'm not sure if there should be some other flag to tell VP if elements can be combined into one big render call.

[hanzoverfist]

 

Ok so as WRD has already mentioned, a problem exists with static/ non static rendering, it seems when a group of primitives are group by a collection in game rendering is ok when static rendering is enabled, but not ok when static rendering is off.

 

solution remove primitives from collection.

 

you can test this on JP's panthera table by selecting 'primitive39' as a collection and turn off static render, then run the table, you should see that some polygons will render incorrectly.

 

EDIT: Also, if you select 1 item in the collection (primitive 39 to be precise) and turn off static render on it, that item will not render at all in simulation. Maybe thalamus is experiencing this.

 

EDIT2: This bug is dynamic in nature, and results will probably vary per author/developer.

 

For those who do not have JP's table(probably few and far between)

https://youtu.be/-fLQ0_pHhxk

Ah good reminder There is a problem in the algorithm that checks all meshes in a collection if they use the same texture and material and combines them in one big render buffer if that is the case. I've always wanted to fix that but I kind of lost track of it

Though the grouping option was originally added for this situation I'm not sure if there should be some other flag to tell VP if elements can be combined into one big render call.

 

Did not know that.. so that's good to know..

[Rawnei]

 

 

Potential SBS 3D bug? http://www.vpforums....=21658&p=407968

 

 

@Rawnei What you are talking about is completely different

 

 

What do you mean?

[toxie]

Backdrop lights are working on my tablet.  They had not before with previous versions (intel graphics card).

 

Thanks!!!!!!!

 

???

This code block is definetly weird (and it's mostly my own mess, too, so nobody to blame there ).. But good that it works now on Intel! 

 

Ok so as WRD has already mentioned, a problem exists with static/ non static rendering, it seems when a group of primitives are group by a collection in game rendering is ok when static rendering is enabled, but not ok when static rendering is off.

 

solution remove primitives from collection.

 

you can test this on JP's panthera table by selecting 'primitive39' as a collection and turn off static render, then run the table, you should see that some polygons will render incorrectly.

 

EDIT: Also, if you select 1 item in the collection (primitive 39 to be precise) and turn off static render on it, that item will not render at all in simulation. Maybe thalamus is experiencing this.

 

EDIT2: This bug is dynamic in nature, and results will probably vary per author/developer.

 

For those who do not have JP's table(probably few and far between)

https://youtu.be/-fLQ0_pHhxk

Ah good reminder There is a problem in the algorithm that checks all meshes in a collection if they use the same texture and material and combines them in one big render buffer if that is the case. I've always wanted to fix that but I kind of lost track of it

Though the grouping option was originally added for this situation I'm not sure if there should be some other flag to tell VP if elements can be combined into one big render call.

 

 

Will you look into this one? So that we don't duplicate work there..

[fuzzel]

Backdrop lights are working on my tablet.  They had not before with previous versions (intel graphics card).
 
Thanks!!!!!!!

 
???
This code block is definetly weird (and it's mostly my own mess, too, so nobody to blame there ).. But good that it works now on Intel! 

 

Ok so as WRD has already mentioned, a problem exists with static/ non static rendering, it seems when a group of primitives are group by a collection in game rendering is ok when static rendering is enabled, but not ok when static rendering is off.
 
solution remove primitives from collection.
 
you can test this on JP's panthera table by selecting 'primitive39' as a collection and turn off static render, then run the table, you should see that some polygons will render incorrectly.
 
EDIT: Also, if you select 1 item in the collection (primitive 39 to be precise) and turn off static render on it, that item will not render at all in simulation. Maybe thalamus is experiencing this.
 
EDIT2: This bug is dynamic in nature, and results will probably vary per author/developer.
 
For those who do not have JP's table(probably few and far between)
https://youtu.be/-fLQ0_pHhxk

Ah good reminder There is a problem in the algorithm that checks all meshes in a collection if they use the same texture and material and combines them in one big render buffer if that is the case. I've always wanted to fix that but I kind of lost track of it
Though the grouping option was originally added for this situation I'm not sure if there should be some other flag to tell VP if elements can be combined into one big render call.
 

 
Will you look into this one? So that we don't duplicate work there..

Yes but it will take some time until I find some time for this.

[jpsalas]

Hi!

 

It looks like many people with cabinets has only one key to add coins, which corresponds to the "5" key, and the Gottlieb System 1 tables add coins by hitting the "3" key instead of the "5" key. They use to fix that by changing the script of the tables,  and I mean that changing the GTS1,VBS will be the best way to add that "5" key, then all the Gottlieb system 1 tables will work. So in the GTS1,VBS file you'll find these lines:

 

            Case keyInsertCoin1  vpmTimer.AddTimer 750,"vpmTimer.PulseSw swCoin1'" : Playsound SCoin
            Case keyInsertCoin2  vpmTimer.AddTimer 750,"vpmTimer.PulseSw swCoin2'" : Playsound SCoin
 

then simply add a new one:

 

            Case keyInsertCoin3  vpmTimer.AddTimer 750,"vpmTimer.PulseSw swCoin1'" : Playsound SCoin

 

Now the "5" key, usually the default "AddCreditkey" will add coins too.

 

Could you, toxie or fuzzel, make this change in the GTS1.VBS file?

[Thalamus]

Wouldn't that end up with us adding two coins each time ? I like the idea. Coins should have been treated by the same kay from the beginning across all the different models. They are after all doing the same thing. Buying credits.

Edited by Thalamus, 15 June 2018 - 09:59 AM.

[Draifet]

I think I discovered a bug, if for example u change the color of some material on the material editor, but then u press the Cancel button, the changes are applied anyways.

[kiwi]

I think I discovered a bug, if for example u change the color of some material on the material editor, but then u press the Cancel button, the changes are applied anyways.

It looks like a work in progress, even the undo for the materials does not work.

[jpsalas]

Wouldn't that end up with us adding two coins each time ? I like the idea. Coins should have been treated by the same kay from the beginning across all the different models. They are after all doing the same thing. Buying credits.

Only if you added an extra line on the script, which is never done in vpinmame tables, as the vbs files handle the coins, only that those older Gottlieb only had 2 coin slots which corresponds in vpinmame to the keys 3 and 4. And that's ok for desktop users, at least I don't care if I press the 3, 4, 5 or 6 keys to add coins But for the cabinets it is a little problem, but changing the vbs fixes the problem for all the tables. I guess other vbs files should be checked too, so all machines add coins using at least the 5 key. 

[BorgDog]

Well, they really should add credits for whatever key is in the AddCredit button assignment, otherwise what's the point of having that field.  it could be g or m or , or a joystick button, whatever.

[Rajo Joey]

I have changed this in the VPMKeys.vbs and i could add games in every table. I never changed something in the table-scripts.

Maybe it's interesting for someone. Doesn't now, if that's a solution for others.

 

keyInsertCoin1   = 6   '(5)    Insert coin in slot 1
keyInsertCoin2   = 6   '(5)    Insert coin in slot 2
keyInsertCoin3   = 6   '(5)    Insert coin in slot 3
keyInsertCoin4   = 6   '(5)    Insert coin in slot 4

[Rawnei]

Request: Add 1440x3440 (Windowed Fullscreen) to supported display options.

 

I just ordered a VESA arm mount for my 34" monitor so I can rotate it and play in portrait mode! Landscape I run in 3440x1440 and rotated it becomes 1440x3440.

 

However I noticed that if you setup windows for portrait mode VPX will only let you go as high as 1440x2560 in the display preferences, I can change it to 1440x3440 via the registry and it works fine but it would be nice if it was supported in the display preferences.

[Rajo Joey]

I see the right solution with my 4k monitor, when I set to portrait and then open the settings in VPX.

In landscape mode I can't see the right solution.

 

Correction: Now I see in both modes the right solution. That's new for me.

Edited by Joey2001, 17 June 2018 - 02:12 PM.

[toxie]

 

Request: Add 1440x3440 (Windowed Fullscreen) to supported display options.

 

 

done.. let me know if it works..

[hanzoverfist]

 

 

Request: Add 1440x3440 (Windowed Fullscreen) to supported display options.

 

 

done.. let me know if it works..

 

@Rawnei, I only added it up to 1440x2560 because I could only test up to that resolution, and that is the question I will ask  toxie.

@Toxie, just a quick question is that a tested res, like I said just curious, if not I'm sure Rownei will let us know if it works or not.

[Rawnei]

 

 

 

Request: Add 1440x3440 (Windowed Fullscreen) to supported display options.

 

 

done.. let me know if it works..

 

@Rawnei, I only added it up to 1440x2560 because I could only test up to that resolution, and that is the question I will ask  toxie.

@Toxie, just a quick question is that a tested res, like I said just curious, if not I'm sure Rownei will let us know if it works or not.

 

 

Thanks! I will let you guys know as soon as I can.