2087 replies to this topic

[kiwi]

Me too, I have trouble capturing the screen, sometimes it works.
I have noticed that there are darker areas, the sides of the hole seems there are some oil stains,
something similar happens also on target.
When I can capture the right screen , every time that I start rendering the result changes, I will post some pictures.

 

Thanks

 

Max

The sides of the holes are made with walls, occasionally there are also spots in the three central target
At the top of the image, the plastics as seen in VP920, below lacks transparency between the plastic of the left and the middle.
The bulbs are made with the bumper, are off instead of being turned on.
The triangular shape, is often very visible.

XP and ATI HD 5770 with the latest drivers available for this card.

 

 

Thanks

 

Max

[toxie]

@BananaBoat: Works with both for me (soundblaster pci128 & onboard). There were always problems though with the sound-output of VPM (crackles, noise, etc), so you're not the first to experience this. :/

Try experimenting with different sample rates (note that you have to set this for -each- game that you test!), f.e. 31250 (for Williams/Bally), 24242 (for Stern/Sega/Data East) 44100, 64000, 96000.

 

This is all weird, i know, but so far i couldn't substantially improve this in the VPM source myself.

Edited by toxie, 27 February 2014 - 10:31 AM.

[BananaBoat]

Toxie, how do i set it for each table? The only option i found was in the VPinMame -> setup.exe global settings.

[arngrim]

f6 during a game and you can set it per table

[The Loafer]

Side question, does anyone know why the sound on medival madness and AFM sometimes crackle?Sent from my HTC_PN071 using Tapatalk

Ensure you don't have the volume so high, on some pcs within VPM, don't go over 24 I think within the dmd menu.

[BananaBoat]

Loader: yep that fixed it. Thanks

Sent from my HTC_PN071 using Tapatalk

[mukuste]

(double post because forum acted up)

Edited by mukuste, 28 February 2014 - 10:26 PM.

[mukuste]

 

With some further tweaking I managed to find a set of depth bias values which seems to work well on the few problematic tables I tested, including JF's new test. I'm still kind of unhappy because I don't quite understand the reasons for these troubles, but at least it's a fix for now.

I found the core issue with the two tables that apparently predicated the changes with this depth bias aspect in the first place (between version test5a and test6) that has lead to all the new issues with near table level walls, ramps, and lights residing on either of them (.1-1.2 range).  Both Seawitch and Blackout FS versions were about 4 years old and had no FOV / layback settings.  I could resolve the inserts / lights issues on both in just a matter of seconds using the previous build (test5a), in which the errors were initially reported, by opening the table and simply entering a value for the FOV moving it from zero to something non-zero.  A value of .2 fixed the issues with both tables and yielded no change in it's appearance otherwise.  

 

[...]

 

 

Thank you JF, the influence of the FOV parameter is an important discovery.

 

This whole thing took me hours to figure out, but here's the story: setting FOV to zero should actually switch to orthographic projection (instead of perspective projection). Unfortunately this is not implemented in VP right now, so it fudges it by setting the FOV very low instead (0.01 is the current lower limit). This basically works, but in order to have such a narrow FOV, the camera needs to be extremely far away from the table. Having such small FOV is basically equivalent to having a super-super-telephoto lens on your camera, if you know something about photography. So the camera is moved so far away from the table that floating point accuracy begins to degrade, which means that the Z-buffer precision suffers, and we get Z fighting. This then necessitates an increase in the depth bias value to make lights still show over the table.

 

All this is compounded by the fact that the routine which is supposed to fit the camera to the table is hopelessly bugged. Have you ever noticed how, if you rotate your table sidewards for a FS view, the centering and scaling of the camera is completely off and you have to adjust it manually by the scale and offset parameters? This is why. Then there's the horrible layback parameter, which was obviously hacked in after the fact and causes all kinds of problems in its own right, one of them being that it's not taken into account by this camera fitting routine. So again you need to do manual fitting of the camera. All of this also produces wrong values for the near and far Z planes, which messes with the Z buffer.

 

This camera fitting routine will be fixed in VP10, but I can't do this now because it will break the positioning of all old tables.

 

Sorry for the rant there, but it was kind of painful to trudge through all this. Anyway, to return to the depth bias issue itself: I don't know if you misread my previous post, but there I stated that I found a way to make (seemingly) all tables render correctly, including your recent test for the depth bias issues, so I don't understand why you argue quite so vehemently for the reverting of this change to the Test5a status. Let me be perfectly clear here: depth bias was already in Test5a, just with a different value, and it is absolutely necessary to render lights correctly. There may have been a misunderstanding that this was a new addition to Test6, when in fact I only increased the value (probably excessively so).

 

So what I propose for now is increasing the minimum allowed FOV in the source code from 0.01 to 1.0 or another more reasonable value. This should mitigate the accuracy problems and allow us to use smaller depth bias values also on these tables. The proper fix would be to implement orthographic projection, which I tried and works well but again breaks compatibility with the camera settings, so has to wait for VP10 unless I find a workaround there.

 

I did change the depth bias for Barracora, but only on decals, not on lights, and only AFTER Test6. Decals are, by definition, textures which are overlaid over an existing surface at the same height. If the engine can't render them correctly, then it is broken, and moving the decals manually to a higher plane is not a fix, it's a workaround for a broken feature and shouldn't be necessary. So we do have to take this into account. If, however, the FOV was also 0 on Barracora, which I haven't checked yet, then again the FOV increase will help matters and we can relax the depth bias parameter again.

 

I'm a bit confused about your assertion that rendering glitches on existing tables shouldn't be fixed at the source code level when you yourself have been a major proponent of 100% compatibility with VP9 tables previously. If I had taken the stance you recommend now from the beginning, then fading lights and GI textures still wouldn't work on 90% of VP9 tables and I would be working on VP10 instead. Again to be clear, the new changes I made now should allow compatibility both with old tables like Seawitch and your new depth bias test table, so I hope that everybody can be happy.

[fuzzel]

what about adding a second camera option to the backdrop settings, like a checkbox or something? So you could add the new camera functionalty and tables could use them but older tables won't need an update.

[toxie]

indeed..

 

as for the future: ideally we would have something kinda what BAM does, so trying to auto-fit each camera/table to a preset (cab, desktop, etc, with varying settings (like TV rotation/slope)) for maximum immersion and minimum manual fiddling per table (currently its insane as you need to tweak each table by hand to match your setup, and all that by using the completely strange VP transformation pipeline).

@mukuste: i don't know if you ever looked at what BAM does for FP, but you should if not.    (and rave is pretty open about sharing his code)

[DJRobX]

What dll exactly is missing? Installing DX 9.0c and rebooting should definitely fix that, weird it doesn't work for you.

 

On my system I had to run the DirectX 9.0c installation twice.  The first time, it installed DX 9.0c and needed a reboot.   On the second run, it installed the progressive (month/year) updates which had the needed "_43" .dll.

 

Also, make sure to follow this link:

 

http://www.microsoft...ails.aspx?id=35

 

if you google for DirectX 9.0c like I did the first time, you end up here

 

http://www.microsoft...s.aspx?id=34429

 

This installer doesn't apply the updates.  

Edited by DJRobX, 27 February 2014 - 04:54 PM.

[gogo69]

is it still helpful to post "bugs" here ?

test6: on starship troopers a lot of black

http://www.bilder-up...-1393522988.jpg

StarshipTroopers_VP920_FlasherMOD_5.6.vpt

Edited by gogo69, 27 February 2014 - 05:50 PM.

[Swisslizard]

Thanks DJRobX!

 

I used the second link from your post for my DirectX installation. Will try the other one asap. Hope this will fix the problem.

 

Thanks for pinting out the difference!

Edited by Swisslizard, 27 February 2014 - 06:43 PM.

[mukuste]

what about adding a second camera option to the backdrop settings, like a checkbox or something? So you could add the new camera functionalty and tables could use them but older tables won't need an update.

 

It's possible if you want. I will commit the fixed code under a VP10 define, and you can play with it if you want.

 

 

indeed..

 

as for the future: ideally we would have something kinda what BAM does, so trying to auto-fit each camera/table to a preset (cab, desktop, etc, with varying settings (like TV rotation/slope)) for maximum immersion and minimum manual fiddling per table (currently its insane as you need to tweak each table by hand to match your setup, and all that by using the completely strange VP transformation pipeline).

@mukuste: i don't know if you ever looked at what BAM does for FP, but you should if not.    (and rave is pretty open about sharing his code)

 

I've never used it since I didn't really like FP when I tried it, but as far as I know it does the headtracking stuff? That sounds pretty cool. Anything else I should know about?

[fuzzel]

BAM is a nice FP hack. It automaticaly creates a correct cabinet orientation of the playfield/backglass. No need to tweak each table manually. BAM can also apply a few shader updates to enhance lighting/filtering and you can tweak the physics by applying an extra phyiscs xml file for each table.

[toxie]

the main cool feature in my opinion is that it sets up a camera matrix to match kind of exactly the perspective that you need to give the illusion that the table is 'inside the cabinet'..

so all the stuff that is kinda whacky in VP (layback, etc) is done 'right' there, and almost fully automatic.. the headtracking/3D is a cool bonus, but i never got around to actually make it work on my cab..

[jimmyfingers]

 

...Anyway, to return to the depth bias issue itself: I don't know if you misread my previous post, but there I stated that I found a way to make (seemingly) all tables render correctly, including your recent test for the depth bias issues, so I don't understand why you argue quite so vehemently for the reverting of this change to the Test5a status. Let me be perfectly clear here: depth bias was already in Test5a, just with a different value, and it is absolutely necessary to render lights correctly. There may have been a misunderstanding that this was a new addition to Test6, when in fact I only increased the value (probably excessively so).

 

My points / recommendation came from the aspect that, in both your previous post and even here in this one, you still sounded unsure about the results even with the latest values / depth bias changes yielding a full fix for all tables with issues related to it (“seemingly” being a key word used that adds doubt).  I quoted your previous post and specifically that part in my reply and as such don’t think I really misread it at all but, as I say, it appeared to have uncertainty.  With discovering that this entire path taken may not have needed doing / modifying from the initial values / depth bias system used in test5a, now that the key and quick fix at a table level for these two very old tables was discovered, it seemed reasonable to undo the changes and not potentially be treating new problems arising from altering it vs. returning to an arguably more solid ground (al beit with having a small but totally reasonable table edit involved).  I didn’t think this was only a new addition to test6 but the previous instated configuration yielded much less issues if you are to add up the net tables and elements affected.   You’re obviously very talented in IT as a developer and as much as I’m only an IT systems engineer, when I discover a problem, that lead me to go in one direction, that ends up being explainable afterward and resulted in an angle l didn’t have to take, I revert back to the previous decision point as to not introduce more variables than needed (that approach has generally served me well).  The two tables in question and their incredibly quick and simple fix are negligible in this equation.  However, if you feel you can fix it all and be totally sure, than do whatever you think best.  I think there are arguments to be made for my recommendation but you’re running the show so we can’t really do anything about it if you don’t agree and can only hope that we don’t find later on some manifestation of this that may have been avoided by reverting and accepting the minimal and arguably beneficial changes to the tables themselves (I don’t know anyone who really wouldn’t prefer a FS table with layback view added vs. these old ones that are all one angle with what is now considered very old / dated looking flippers).

 

 

...

I'm a bit confused about your assertion that rendering glitches on existing tables shouldn't be fixed at the source code level when you yourself have been a major proponent of 100% compatibility with VP9 tables previously. If I had taken the stance you recommend now from the beginning, then fading lights and GI textures still wouldn't work on 90% of VP9 tables and I would be working on VP10 instead. Again to be clear, the new changes I made now should allow compatibility both with old tables like Seawitch and your new depth bias test table, so I hope that everybody can be happy.

 

 

Common man… this is an inequitable and overly simplified version of what I was referring to and have actually demonstrated previously in this very thread with various comments about accepting minor table changes being needed / an acceptable outcome (even welcoming them if they were simply available at all in some reasonable way).  Some things completely need your doing in code like the new ordering (adding the primitives for example to the equation) as you’ve removed any author ability to manage it - fair enough as to your reasons but as such we are totally dependent on you and your code changes if we are ever hopeful to run VP9_DX9 without ordering issues.   My assertion was not as generic as you paraphrase it to be, but in regard to not changing source code for issues with a small number, or in this case, 2 (very old) tables that have an extremely easy table adjustment as a work-around (literally a matter of seconds and 3 mouse clicks / key presses).   It was also in the context of these specific changes with the depth bias for a small number of tables in turn affecting / creating actually more issues with a larger number of tables (I never recommended fixing the fading lights natively in the code at the expense of other /new bugs).   And even further I was comparing something that could be fixed at least in some way vs. something that might not be resolvable by the author at all.  My exact wording from my previous post was “I think we have to be careful of cases where simple table fixes are being missed in lieu of first / early reports of "bugs" and "issues" resulting in changes to the code affecting possibly many more tables and in ways where any type of table level fix for these new / resultant issues may not exist at all.”

 

This is unfair to compare to the fading lights routine compatibility discussions, where I was actually the first one to point out that it is used on probably 90-95% of all tables and needed extra consideration in this regard, where it would have taken huge amounts of time and effort to edit at a table level (50-100 light objects to select / delete, editing 50-100 fading lights routine calls in the updatelamps sub, various other table scripting changes to use image swapping now available on the light objects).   We’re talking a difference of between literally seconds for Seawitch and Blackout vs. at least an hour or two for each table to redo fading lights issues if not resolved via source code.  Not at all apples to apples here and as one IT professional to another I think this logical dissimilarity is apparent.

 

I’ve never said anything about 100% compatibility and in fact in this very thread I’ve described and demonstrated situations that I felt would be reasonable work-arounds:  Most recently the black transparent colour table based updates to resolve the GI / black insert issues only a few pages back – First two sentences in Post #756 (http://www.vpforums....=38#entry256671) “For any tables with the black inserts problem.  This is something that is fairly easy to fix and may remain as the permanent way to resolve if my understanding is correct on the pure black of old "trick" vs. the updated way to handle texture transparency colours.”.  Also, back when we were discussing the fading lights problems I suggested a new flag / option to disable a light so that one could possibly update a table much more easily by not having to adjust / delete the extra light objects or all the calls in the updatelamps routine and just focus on actually an update to the couple related fading sub-routines themselves – Post #347  --2nd paragraph (http://www.vpforums....=18#entry254900) “Another idea I had that might work decently regarding the lights and yield only minimal changes to an existing table for compatibility would be to enable a function to make the light object not visible (both off and on images)….. A couple lines in the fading lights sub routine(s) and possibly the initialization areas would be all that's needed per table.”   This stance was still accepting a potential table change if necessary and trying to help with ideas to at least greatly minimize the time and effort to do so should a permanent code based resolution not be possible.

 

Table based work-arounds have always been a consideration and I've openly discussed the concept, but it’s been about considering whether a “reasonable” and simple / quick fix is feasible combined with the amount of tables affected and requiring it balanced with ultimately whether or not it can be resolved in code and how those changes may relate to creating more issues / having regression in the current level of total aspects of compatibility.  All things considered, this line that “If I had taken the stance you recommend now from the beginning, then fading lights and GI textures still wouldn't work on 90% of VP9 tables and I would be working on VP10 instead” is a real kick in the crotch and is just so inaccurate to my real “stance” and one which is clearly demonstrated.  I’ve gone to great effort to detail bugs and explain what I can even to the point of creating test tables and to be sighted as someone who’s stance would have done a disservice to this process otherwise is disheartening and I think quite unfair.

 

I admit I may be passionate, even pushy, about some of this and with the aspects and direction of the VP9_DX9 build, but it comes from someone that has a tone of experience and ability to find, demonstrate, and navigate various issues with VP (I would challenge anyone to have provided as many screenshots, explanations, and test tables as I have) and from which I feel  I could provide some very useful information that could help in considerable ways regarding issues that may be widespread even if subtle at times (or even missed entirely by others).  We’re on the edge of finally having something I personally have highly desired for years (a VP that runs without stutter during any table event and has supported / working AA) and that would make the thousands of hours in total I’ve spent over the last few years - mostly spent in projects to give something back to the community - be much more worth while – certainly more than it’s felt at times.   As I’ve mentioned before, protecting all author’s investment in time and table development I think is hugely important / respectable but this does not preclude minor updates by the end user or the author as part of that sentiment – it’s more about whether they have a reasonable and / or simple means to actually fix issues that arise.

 

I hope you can work out all the bugs / get to a minimal table change scenario and see it through to the end so that we eventually get to a fully functioning / rendering issue free VP9_DX9 release.

 

On another note I have some information and findings that may help the AA flashing bug if you’re interested but I don’t want to tie up this thread any more at this point than I already have.

Edited by jimmyfingers, 27 February 2014 - 10:45 PM.

[mukuste]

To cut this whole discussion short, I worked around the bugs in the FitCamera routine by doing a second pass afterwards where I compute the correct near and far Z plane, which takes a lot of pressure off the depth buffer. In addition to limiting the FOV to 1.0 at a minimum, this seems to have effectively eliminated all cases of Z fighting.

 

JF: Sorry for any inadvertent kicking of crotches I may have done. I was genuinely surprised at what seemed a change of heart, but understand now where you're coming from. And yes, I do hugely appreciate your detailed bug reports and test cases. If you have anything to contribute to the AA issue, then I'm sure toxie in particular would be happy to hear it, and I see no reason not to do it in this thread.

[BananaBoat]

And from an end user perspective I'm sure I speak for all when i say all efforts made by all involved is greatly appreciated and for me personally that's a massive understatement. Please keep up the great work!

Sent from my HTC_PN071 using Tapatalk

[IPJball]

Thank you Mukuste! You fixing z fighting will work great with Funhouse!

Thanks!