666 replies to this topic

[boiydiego]

got fps problems with newest monster bash with high end pc with intel i7 , other tables run at 1600fps monster bash only 48fps setting the vsync does not help alot !

other people mostly on intel processors have it i think..

Edited by boiydiego, 06 February 2014 - 06:25 PM.

[toxie]

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

1 tries to automatically detect your refresh rate, so if that doesn't work use the refresh rate of your monitor please..

[fuzzel]

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.

I added a flipper with angle 0-360 but I couldn't see a hole in any of the angles?

[mukuste]

 

 

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?

 

 

This relates to what I just wrote in the DX9 thread. It's not true that the physics stepping times are independent of framerate, so there can definitely be an influence.

 

 

 

 

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.

I added a flipper with angle 0-360 but I couldn't see a hole in any of the angles?

 

 

Hm. In my code, I set up the VB with angle=0 (tip points up) and then rotate the flipper to the standard right flipper position. I then see the hole near the tip of the flipper (i.e. in the smaller cylinder). Maybe the way you set it up the hole just happens to be in the part of the cylinder which faces inside the flipper? You might try disabling the 3 quads which make up the "body" of the flipper to get a better look.

 

Mathematically, I think there can be no doubt that there must be a hole

[Shadowsclassic]

This really isn't a bug report more feedback I guess.  I just wanted to say that I always try to thank the table builders for their great tables, but I realized I have never really thanked those that make it all possible.  Just like with the new Monster Bash that I could not even run at first but you guys got on it and with the latest build the game plays perfect.

 

You guys do totally amazing work and you keep driving this hobby forward by making VP bigger and better with every new release.  I just wanted to thank you all for all you do, you don't get near enough recognition for your amazing work, you are VP!

 

Thanks for all the memories!!!

 

Brian

[fuzzel]

You're welcome

[maxfx4u]

 

 

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?

 

For me on my system, rev800, 840 the lag is not present. The later builds ive tried are rev865, 906 are pretty much unplayable for me.

 

 

[toxie]

very strange..

so 840 is the last good, 865 the first bad?

inbetween the only major performance critical thing that happened was a new video settings option, could you check what you have set there (is called 'do not force vertex buffers into sysram' by now)?

[maxfx4u]

Those are just the revisions that ive tried, but rev 906, 865 both are unchecked.

[toxie]

Okay, then this is the same behaviour as with the old revisions.. If you want to help tracking this down, then please test more revisions inbetween 840 and 865, so that we can nail it down to a specific change..

Edited by toxie, 07 February 2014 - 01:03 AM.

[maxfx4u]

ok

[mukuste]

So I'm pretty sure that SetNormal() computes normals with wrong facing. I made a test table with a light close to the table (both the table and a screenshot are attached). You can see that for all objects, the sides facing away from the light are brighter than those facing the light.

 

I tried to understand what SetNormal() is doing, but the algorithm is... weird. I would expect it to take the cross product between the vectors meeting in a vertex, but instead it computes this in a loop:

		vnormal.x += (rgv[l].y - rgv[m].y) * (rgv[l].z + rgv[m].z);
		vnormal.y += (rgv[l].z - rgv[m].z) * (rgv[l].x + rgv[m].x);
		vnormal.z += (rgv[l].x - rgv[m].x) * (rgv[l].y + rgv[m].y);

I don't know how that makes sense. The sum of rgv[l] and rgv[m]? Anyone understand that? Maybe I should just try replacing it by the standard algorithm.

Attached Files

•  2014-02-07 04_11_33-Visual Pinball Player.jpg   63.38KB   5 downloads
•  lighttest.vpt   128KB   5 downloads

[toxie]

This is again some weird legacy stuff that i also never understood.. It was like that since day one of VP9 (mesh.cpp originally), so we never touched it to not change the behavior of old tables..

 

And as so far no one also ever used the new, more flexible lighting really (before it was always just two hardwired directional lightsources that didn't even respect the transformation of the table when changing the table/backdrop parameters), so there also was no need changing this yet..

 

Feel free to correct all this kind of nonsense in the DX9 branch, please..

 

EDIT: I wonder though how you should replace it.. Just standard "First calculate all triangle normals in a loop, then calculate the vertex normals from that (weighted by the dotproducts of the adjacent triangles??)" maybe?

Edited by toxie, 07 February 2014 - 12:46 PM.

[unclewilly]

Just curious if you guys have a roadmap for the future development.

Are you guys looking to finish up with the feature set for vp9 in the near future. And then merge the vp9/vp10 branches.

Or are you looking to continue adding features to vp9 until the main render engine is completed for vp10.

And as always I appreciate all the work you guys are doing on my favorite piece of software.

I only ask about the roadmap because as a table developer I'm not sure what direction to go next, either start up with new projects (mostly originals) or wait for vp10 and work on bringing my old tables up to vp9.2 standards.

[toxie]

I would say that VP10 is still some months away from being something that should be developed on. Testing things earlier yes, but releasing stuff no.

Otherwise we will have instant legacy problems due to unfinished/buggy features yet again. And this we should avoid, as it has lead (in VP9) to this damn paranoia from us developers, always being afraid of breaking some already existing tables by adding/changing stuff in this whacky engine.

 

Until then VP9 will be developed along, but i don't think there will be any super-revolutionary things added. More like finishing it up so that it could potentially be the final and thus pretty stable/feature complete VP9 release.

 

(fuzzel, please correct me if you think differently about the VP9-"roadmap"  )

Edited by toxie, 07 February 2014 - 01:08 PM.

[dboyrecords]

I was hoping you'd get back to sounds! Excited to see where this goes!


Edit: there was also talk of integrating bmpr, any traction there?

Edited by dboyrecords, 07 February 2014 - 02:25 PM.

[mukuste]

EDIT: I wonder though how you should replace it.. Just standard "First calculate all triangle normals in a loop, then calculate the vertex normals from that (weighted by the dotproducts of the adjacent triangles??)" maybe?

 

My understanding is that this function should only be used for plane surfaces since it computes a single normal and then applies this normal to all involved vertices. So I would keep it that way. I would only change it to first compute all the vertex normals in the standard way ((v2-v1) x (v0-v1), basically), average them and use this resulting normal for all vertices.

 

 

About the roadmap: My opinion, for what it's worth, is that VP9 should now concentrate mostly on bugfixes and at most small features to finalize the 9 series. The DX9 renderer should soon be at a point where we can use it as a base for further development. In my own interest I would also like it if the rendering code in VP9 is touched as little as possible because it makes it easier for me to keep my DX9 branch in sync. In the end, I will leave the decision how to proceed to the "older" devs.

Edited by mukuste, 07 February 2014 - 02:21 PM.

[fuzzel]

+1 for the roadmap! To be honest, I don't have much time to add any new stuff to VP at the moment. When the main porting is done we should create a VP9 branch and do all the VP10 improvements on the main trunk.

[toxie]

My understanding is that this function should only be used for plane surfaces since it computes a single normal and then applies this normal to all involved vertices. So I would keep it that way. I would only change it to first compute all the vertex normals in the standard way ((v2-v1) x (v0-v1), basically), average them and use this resulting normal for all vertices.

 

True, didn't remember the exact details from that function anymore.. Also good, as it's much simpler then..

 

As for the roadmap: Cool, so agreement all over the place..

(still, please check the PM i sent you guys)

Edited by toxie, 07 February 2014 - 03:06 PM.

[destruk]

Does anyone know when Cupid will be back?  (After college?) - he did have that DX10 table render and player working with vp9 tables.  Maybe he would want to work on the rendering engine for VP10?