666 replies to this topic

[fuzzel]

Check out rev908. I added a new checkbox to the primitive physics settings: "Is Toy". It overwrites the "Collidable" flag if set. It is usefull for primitives which are never hitable at all. Otherwise VP calculates collision parameters for every mesh primitive even if "Collidable" is unchecked. The reason for another flag is that you can enable/disable the "Collision" flag from within the script while playing. Keep in mind that the collision detection for mesh primitives is somewhat static. If you move/scale/rotate... a mesh from out of the script it won't have an impact on the collision detection. All collision parameters are precalculated!

[koadic]

So, in other words, the collidable flag for primitives isn't usable for moving targets like Drac in Monster Bash? Darn...

[fuzzel]

unfortunatly no...maybe I can find a way to change the collision data on the fly but at the moment this isn't possible.

[koadic]

Hey Fuzzel/Toxie, I noticed one small visual bug (present even in 9.1.5 official) that had been driving me crazy for the last few days... It is pretty obscure and I am the only one to probably run into an instance where it even occurred so it's no biggie if you don't want to bother fixing it (as I have found a workaround for it). IF a wall is created with a side set as a slingshot (right click a control point > slingshot), AND that wall is set to be droppable, AND the side visibility is turned off, THEN it will leave visual artifacts on the screen at the edges of the wall side that is the slingshot.

This only became apparent when I was experimenting a little bit, and was finally able to work around it by changing the 'Slingshot Color' to pure black. I just wanted to mention it is all.

[fuzzel]

rev909 should fix that

[BobAlbright]

Just tried to play a game of Grand Prix (16-9 Grand Prix as it gets downloaded) (2005). I notice that if I try to run it with the backglass, it crashes. Take the db2s out of the equation and it works just fine. Why is this? And is there something I could do to get the backglass to work. Currently running 9.2 rev 886

 

Ok--just downloaded the latest version and it works. Sorry for the post

Edited by BobAlbright, 03 February 2014 - 02:49 PM.

[marco helmink]

Thanks.

 

Monster bash is now loading perfect!!

 

with the rev 908

Edited by marco helmink, 03 February 2014 - 08:29 PM.

[jpsalas]

Is there any way to fix the order of the new flasher objects? I have changed all the flasher effects in my AFM test table and I'm finding impossible to fix their display order. Each time I fix them then they get reordered again. I have tried all the methods, using the Drawing Order (hit) and the Drawing order (Select), and each time they are at different positions, and they display wrong of course. Do I miss something? Or it is really that hard to get them to stick in place?

 

here it is a link to the table in case someone want to take a look:

 

http://www.mediafire...VP916_Beta3.zip

(the name should be VP921 beta and not VP916 )

 

All the flashers are in the layer 8.

 

A note about the table: I tried using FP ufos, and it worked fine but the table was very slow, so I made the UFO using normal VP primitives without a mesh, and the speed is much better.

 

JP

[koadic]

Yeah, changing the drawing order can be finicky some times... Try this, instead of right clicking to open the context menu, move your mouse off the table (away from any flashers or ramps anyway) and hit the context menu button on the keyboard (if you have one, usually placed between the right alt and ctrl on US keyboards, or you can use Shift+F10 as an alternative). Make one change and make a mental note of the order, then close the window, then open the window again... if the change stuck, then proceed to adjust the order.

[fuzzel]

oh yes the drawing order is really a tricky one. The problem for all of this is that VP actually uses one big drawing order list for sorting the elements on a table and draws them. When you use the drawing order option (hit or select) you get a small snapshot of the list but it's not the complete list. You change the order of some elements but there are elements in between that could interfere with those elements you don't see in drawing order list. Perhaps it makes more sense to add another drawing order dialog showing the complete long list so you can search for the element(s) which you have problems with?

[maxfx4u]

I'm having some issues with  ''9.2.1 rev906.exe" more specfically with the flippers. I'm coming fresh off rev 800, and I notice a big difference in the way the flippers are performing.

It seems my shots are veering hard to the sides, and shots up the middle are difficult. Ive noticed a difference with tables that have vysync enabled, and dissabled. when enabled the veering

shots are very profound. when dissabled the effect is diminished, but still there. 

[The Loafer]

Max: that is specific to using the vsync option, I don't think there is much that can be done at this time, sort of a sacrifice to getting smoother frame rate.

[maxfx4u]

the veering shots are still there even when not using vsync. just not as pronounced. so is this a known issue?

[mukuste]

@fuzzel: I finally got around to incorporating your flipper vertex buffer code into my branch (though heavily adapted to use only a single VB by adjusting the world transform). In the process I think I found a bug:

   for(int i=0;i<14;i++ )
   {
      iidx[i*6  ] = o;
      iidx[i*6+1] = o+1;
      iidx[i*6+2] = o+2;
      iidx[i*6+3] = o;
      iidx[i*6+4] = o+2;
      iidx[i*6+5] = o+3;

      iidx[84+i*6  ] = 72+o;
      iidx[84+i*6+1] = 72+o+1;
      iidx[84+i*6+2] = 72+o+2;
      iidx[84+i*6+3] = 72+o;
      iidx[84+i*6+4] = 72+o+2;
      iidx[84+i*6+5] = 72+o+3;
      o+=4;
   }

This code here is supposed to set up the indices for the mantle of the base and end cylinders, respectively. However, it creates only 14 quads per mantle, but since the cylinder is meshed using 16 vertices per cap, 16 quads are needed to cover the whole mantle. When I used this code in my DX9 renderer, I could clearly see the hole from the two missing quads.

 

I managed to fix the bug, but it was unfortunately rather involved due to all the hardcoded indices and offsets. Anyway, it's in my dev branch at https://github.com/c-f-h/vpinball. I don't know if it's worth backporting at this time; as far as I understand, the reason it doesn't show up in the current SVN builds is because there the hole is actually facing away from the viewer. My code first orients the flipper in standard orientation (angle=0), so in that case it shows up.

[jimmyfingers]

the veering shots are still there even when not using vsync. just not as pronounced. so is this a known issue?

If the FPS are anywhere below about 200, the problem can still occur.  The only reason it is so present with v-sync is that it takes and holds the FPS much lower than where the problem has been observed to start manifesting (60 even though the visuals are silky smooth).  I discuss this issue in more detail in the Monster Bash FS PC Killer Edition thread here:

 

http://www.vpforums....e=5#entry253334

[jpsalas]

Thanks koadic and fuzzel for the tips. I managed to get the drawing order of the flashers right I'll upload the table in a few minutes (AFM VP921 beta 3)

 

At first I used mostly the Drawing order (Hit) to try to adjust a few flashers, one bu one. And it was frustrating. But now I think I understand what happens when you use the Drawing order (Hit): it selects those objects under the mouse, and you may change the order of those objects, but all those objects are moved to the top. Each time you use the menu, all those objects are moved to the top, even if you only move one of them in the menu. So when I tried to adjust other objects they were all in the wrong position again because some of the objects were moved to the top the last time I used the menu, even if I didn't touched those objects. So if you try to fix the drawing order using that "Hit" menu you are going to have a hard time, since all the objects shown in the menu keep moving up, even if you don't move them in the menu, and they will be on top of all the other objects that were not in the menu.

 

The solution that worked for me,  was to move all the flashers to its own layer (I used 53 flashers in the table ). I Selected all the flashers, and used the Drawing Order (Select), either from the mouse or from the menu (I used CTRL SHIFT S). Then I moved them like I wanted and it worked fine

[fuzzel]

@fuzzel: I finally got around to incorporating your flipper vertex buffer code into my branch (though heavily adapted to use only a single VB by adjusting the world transform). In the process I think I found a bug:

   for(int i=0;i<14;i++ )
   {
      iidx[i*6  ] = o;
      iidx[i*6+1] = o+1;
      iidx[i*6+2] = o+2;
      iidx[i*6+3] = o;
      iidx[i*6+4] = o+2;
      iidx[i*6+5] = o+3;

      iidx[84+i*6  ] = 72+o;
      iidx[84+i*6+1] = 72+o+1;
      iidx[84+i*6+2] = 72+o+2;
      iidx[84+i*6+3] = 72+o;
      iidx[84+i*6+4] = 72+o+2;
      iidx[84+i*6+5] = 72+o+3;
      o+=4;
   }

This code here is supposed to set up the indices for the mantle of the base and end cylinders, respectively. However, it creates only 14 quads per mantle, but since the cylinder is meshed using 16 vertices per cap, 16 quads are needed to cover the whole mantle. When I used this code in my DX9 renderer, I could clearly see the hole from the two missing quads.

 

I managed to fix the bug, but it was unfortunately rather involved due to all the hardcoded indices and offsets. Anyway, it's in my dev branch at https://github.com/c-f-h/vpinball. I don't know if it's worth backporting at this time; as far as I understand, the reason it doesn't show up in the current SVN builds is because there the hole is actually facing away from the viewer. My code first orients the flipper in standard orientation (angle=0), so in that case it shows up.

Ah good find: I'll check it when I'm back home. There are some tables (e.g. Monopoly) where you have a rotating flipper so perhaps this issue is popping up there? Anyway I'll see if I can fix it in the main branch.

 

 

Thanks koadic and fuzzel for the tips. I managed to get the drawing order of the flashers right I'll upload the table in a few minutes (AFM VP921 beta 3)

 

At first I used mostly the Drawing order (Hit) to try to adjust a few flashers, one bu one. And it was frustrating. But now I think I understand what happens when you use the Drawing order (Hit): it selects those objects under the mouse, and you may change the order of those objects, but all those objects are moved to the top. Each time you use the menu, all those objects are moved to the top, even if you only move one of them in the menu. So when I tried to adjust other objects they were all in the wrong position again because some of the objects were moved to the top the last time I used the menu, even if I didn't touched those objects. So if you try to fix the drawing order using that "Hit" menu you are going to have a hard time, since all the objects shown in the menu keep moving up, even if you don't move them in the menu, and they will be on top of all the other objects that were not in the menu.

 

The solution that worked for me,  was to move all the flashers to its own layer (I used 53 flashers in the table ). I Selected all the flashers, and used the Drawing Order (Select), either from the mouse or from the menu (I used CTRL SHIFT S). Then I moved them like I wanted and it worked fine

Ah that makes sense. The "Drawing Order (Hit)" operates only on those elements which are under the mouse cursor when you activate this option and only those elements which are currently visible because the layer is visible.

[toxie]

the veering shots are still there even when not using vsync. just not as pronounced. so is this a known issue?

If the FPS are anywhere below about 200, the problem can still occur.  The only reason it is so present with v-sync is that it takes and holds the FPS much lower than where the problem has been observed to start manifesting (60 even though the visuals are silky smooth).  I discuss this issue in more detail in the Monster Bash FS PC Killer Edition thread here:
 
http://www.vpforums....e=5#entry253334

This is something that still confuses me.
I can understand that the lag for the flipper is higher if the fps are lower, but the physics should actually react exactly the same overall.
Do you guys have a revision number where this started?

Edited by toxie, 06 February 2014 - 04:57 PM.

[jimmyfingers]

 

 

the veering shots are still there even when not using vsync. just not as pronounced. so is this a known issue?

If the FPS are anywhere below about 200, the problem can still occur.  The only reason it is so present with v-sync is that it takes and holds the FPS much lower than where the problem has been observed to start manifesting (60 even though the visuals are silky smooth).  I discuss this issue in more detail in the Monster Bash FS PC Killer Edition thread here:
 
http://www.vpforums....e=5#entry253334

This is something that still confuses me.
I can understand that the lag for the flipper is higher if the fps are lower, but the physics should actually react exactly the same overall.
Do you guys have a revision number where this started?

 

It's likely not something from any recent VP work / revision as I first noticed the problem when JP released his initial Whitewater table back in November 2011.  It was alpha ramp heavy and the flippers would behave the same general (occasional) way.  On my mini-cab, at the time of it's release, I think i was only getting somewhere between 150-200 FPS.   I spent a lot of time trying to figure out why the flippers were acting the way they did and wasn't until after that I realized and could confirm it was frame rate related.  Now with vsync forcing down to 60-75 Hz, it's very easy to reproduce.  Again, it's only with flippers that have a higher speed setting, unfortunately, I've found those to be the best.

 

I'll try and create a demonstration table of this problem in the next couple weeks but have a number of things on the go right now so not a lot of time (VP and real life).

[Slydog43]

I like your comments JimmyFingers, as there have been so many great changes to VP recently, but playability and reliability is very important.  This is why I play VP instead of FP as the physics is so important to the realism aspect.

 

Is setting the adaptive V-Sync to 1 the same as setting it to 60?