2087 replies to this topic

[The Loafer]

Just to add on the "menu on exit" issue, sometimes it works, sometimes it doesn't, at least on my system. I've seen it pop up when doing an alt-tab so its there, It just seems to be stuck under the displayed table.

[koadic]

I just experienced an issue where VP froze and I COULD NOT exit the program regardless of what I tried. I couldn't use the task manager to kill the exe because I would immediately lose focus, alt-f4 wouldn't work... ultimately I had to go to the 'Start' screen in Windows 8 (where I could get focus) and then restart the computer.

And to shed some light to the above questions regarding JF's statements...

The fading lights routine uses at least 2 light objects for 4 (or more) light states... Full on, full off, and at least 2 intermediate states of dimming. A single light isn't used because they are not dynamic in the same way that ramps/flashers are where the image can be switched on the fly, they need to be stacked so more than 2 separate states can be used.

As far as refresh lights and anything else that is 'pure black' (0/0/0), these should be rendered invisible... while probably not extremely common, I am sure there are instances where 'pure black' is used on items where sections should be invisible, even if the transparency color isn't set to pure black in the image manager.

[jimmyfingers]

Ah, jimmyfingers, I'm glad you showed up, I think you're my man here. I really need a crash course on the finer details of VP9 table creation so that I could emulate them better. So I have a couple of questions for you or anyone else who has that kind of arcane knowledge:

 

*) I understand from your explanations that the commonly used fading lights routine used several lights placed on top of each other, of which one at a time was "triggered" by changing its state so that it would render its texture. Is that correct? If so, just so that I understand better, why was that approach chosen over an approach where a single light object has its texture swapped out as needed? I'm afraid that the multiple lights approach might be a tad difficult to emulate in the new renderer since now every object is rendered every frame. But I'll think about it and see if I can figure something out.

 

*) Refresh lights: I finally begin to understand how they are used. Basically, they are fully black (and therefore, in the old renderer at least, invisible) objects whose only purpose is to tell the engine to refresh the area they cover; is this correct? I take it this was needed because many objects would not automatically refresh when, e.g., their texture was changed? And the later introduced TriggerSingleUpdate and kin served to address this purpose in a more direct way? Let me propose a workaround. Since in the new renderer, there is no more region system and everything is rendered every frame anyway, no manual update mechanism is needed. Therefore, my heuristic is the following: if a light is pure black AND it has no Off texture AND it has no On texture, do not render this light at all. Would this, in your opinion, take care of the majority of such update lights? I tried this heuristic and it seemed to completely fix the render issues on Airborne and AFM at least.

 

*) You mention other black objects besides lights. Were black objects of any other type than lights commonly exploited? Any examples?

 

*) You often mention "GI". Does that refer to "global illumination", as I would expect? And what exactly is its meaning in VP9 terms? I will check the Indy 500 table, thanks for the reference.

 

*) You mention apparent draw order problems with alpha ramps/flashers. Could you give me an example?

 

*) Ball border: that is very well possible. I'll have to defer that until more pressing issues are sorting out.

 

I'll need a bit more time to absorb all the information in your PM and get to test the table, but thank you already for all the in-depth information! It's immensely helpful.

 

All right, here goes some attempts to answer / explain

 

You are correct in your assumption about the “triggered” light object and that whatever one was last updated (off or on image) would be the one displayed; The two light idea came out from earlier table developers and uses 4 images from On, a, b, than finally off;  The reason that that approach was chosen was because, until now at least, light based images could not be swapped.  If now a light object image can be swapped that will hugely help for fading routines and even the same for GI8.  Essentially, all multiple lights on top of each other that you will encounter are going to be because of the pre-rendered aspects of the light objects and what ways seemed to work with the last man standing sort of approach to how the refreshes worked.

 

Refresh lights, you are correct in your understanding of both the black light refresh and the alternative ramp.triggersingleupdate (although both have their advantages and disadvantages). As to your proposition, if everything now is updated instantly / every frame than we should indeed no longer require any of the black refresh;  I won’t get into why this technique can / was still be better from all my tests (at least with forced AA) than any currently used with VP and is seemingly going to be moot anyway with DX9 / full per frame rendering of every element. 

 

In JPs Scared Stiff (or the GI8 Mod I did) he made the bone flippers in a certain way and, from what I recall, leveraged pure black coloured flippers which became invisible yet collidable.  Not totally sure at the moment of some more examples, except that of course the pure black colouring in a texture itself will really need to remain as there are a number of elements that rely on that VP default over the years (more than just setting the transparent colour in the texture manager).  Pure black being the 0,0,0 RGB setting.  It’s used also in tables where playfield GI lights are drawn with the light inserts blackened with this pure black level so that it did not obstruct the “real” lamps / light objects underneath (that’s a trick I discovered when first working on GI8 tables, however, I use a different more solid approach now that doesn’t rely on the pure black inserts being overlayed on table PF / GI images.  But regardless of that nuance, pure black detected in textures should still be transparent and from what I can tell at the moment it looks like it is (at least texture mapping vs. object wise).

 

GI is “General Illumination” and is simply the bulbs that provide the general lighting up of the playfield and plastics;  Earlier tables had only static GI but with the SS and DMD tables GI became more dynamic ranging from the full playfield going off and on for events to the modern WPC that use 3 sections and 8 levels of intensity (GI8 tables utilize this information available from pinmame via the GICallback2 function).  In my opinion and certainly with the classic old EMs the GI and effects (warmth) of the lighting are a huge part of trying to reproduce the look of a pinball table and to me part of the allure of a pinball machine in general (hmmm maybe allure is to strong of a word for pinball …lol);  As far as VP9 terms it’s not really any different than what it’s doing in real life except for, and a big “but” here, how it’s implemented – this is exactly why us lighting fanatics are really hoping your work yields great things as faking the GI over the years can be both incomplete in it’s effects and / or super time consuming and complex to try and mimic the shadows, multiple objects interactions, and warmth / coolness aspects of reflected, refracted, or projected light rays.

 

The “draw order” issues are when alpha ramps are used and no correctly set at the right “draw in front” / “draw in back” ordering matching to their actual heights defined in the ramp objects top and bottom “height” value fields.  Basically you would get glitches or blocked out areas if a flasher that is lower in the draw order, yet higher in actual table dimensions.  The appearance of this seemed to be going on in my AFM GI8 RC1 table (that’s the one I sent you the link for) and is an example I would most recommend you checking out.  However, it maybe part of a by product of the issues with the light objects combined with the alpha ramps.  The table is completely fine in VP 9.2 or 9.2.1.  You can reproduce a traditional alpha ramp drawing order issue pretty easily using the default table in 9.2 or 9.2.1 – just create two ramps, apply a texture (might want to import a flasher as a test), set to alpha, stagger them a little in the editor, make one higher than the other, than set the higher one to actually have the draw order lower (click on and set to “draw in back”).

 

Hope I've answered your questions decently enough and helped to shed some light on these things.

[boiydiego]

would like to play with fullscreen , tested in windowd mode monster bash runs before 48fps now 500fps so thats realy great but when could whe play in fullscreen mode ? thx for the great work you are doing !!

Edited by boiydiego, 09 February 2014 - 10:34 PM.

[bmiki75]

Fantastic job tested many table also in full scrren with ddraw=0, i have a problem with world cup soccer last release it give me "Call to DrawIndexedPrimitiveVB has too many indices. Use an index buffer." Then Fatal error HRESULT 88760888 at RenderDevice_dx9.cpp:213 thann exit VP

[mukuste]

Fantastic job tested many table also in full scrren with ddraw=0, i have a problem with world cup soccer last release it give me "Call to DrawIndexedPrimitiveVB has too many indices. Use an index buffer." Then Fatal error HRESULT 88760888 at RenderDevice_dx9.cpp:213 thann exit VP

 

Ah yes, I know about that one, sorry that I didn't mention it. Basically, if the table geometry is too complicated, it will overflow the dynamic index buffer. This will be fixed in time when that routine sets up its own index buffer.

 

In short, stay calm and wait for a later release.

[bmiki75]

 

Fantastic job tested many table also in full scrren with ddraw=0, i have a problem with world cup soccer last release it give me "Call to DrawIndexedPrimitiveVB has too many indices. Use an index buffer." Then Fatal error HRESULT 88760888 at RenderDevice_dx9.cpp:213 thann exit VP

 

Ah yes, I know about that one, sorry that I didn't mention it. Basically, if the table geometry is too complicated, it will overflow the dynamic index buffer. This will be fixed in time when that routine sets up its own index buffer.

 

In short, stay calm and wait for a later release.

 

Thanks a lot for your great work on DX9.

Just a little question how it work on Win 8 Tablet ? Touch screen is supported ?

I want to buy an asus t100 to play on tablet.

[mfuegemann]

Hi mukuste,

 

thank You for Your effort. This project looks very promising!

Some minor drawbacks I found were

- missing text decals

- Text Boxes not working

- kicker holes seem to shine through walls.

- I am not able to show the framerate (F11).

- quitting a game is sometimes not possible, I had to use Alt-F4 or the task manager

 

Win7 64, GTX560

 

Regards

Michael

[mukuste]

 

 

Fantastic job tested many table also in full scrren with ddraw=0, i have a problem with world cup soccer last release it give me "Call to DrawIndexedPrimitiveVB has too many indices. Use an index buffer." Then Fatal error HRESULT 88760888 at RenderDevice_dx9.cpp:213 thann exit VP

 

Ah yes, I know about that one, sorry that I didn't mention it. Basically, if the table geometry is too complicated, it will overflow the dynamic index buffer. This will be fixed in time when that routine sets up its own index buffer.

 

In short, stay calm and wait for a later release.

 

Thanks a lot for your great work on DX9.

Just a little question how it work on Win 8 Tablet ? Touch screen is supported ?

I want to buy an asus t100 to play on tablet.

 

 

To be honest I don't know, but someone else reported problems with a tablet at this point. I don't have one myself, but I think at least one other dev does, so I'm confident the problems will be ironed out before long.

[DHogsett]

Im sure you are aware, but there are some tables that will load up fullscreen without the "DDraw = 0" trick, one being Airborne, it will load up but it will not play. I was fiddiling around with some other tables and got a script error when trying to run NBA Fastbreak from fullscreen at line 65 which was: Controller.Run GetPlayerHWnd 

 

Anytime a table calls that, and most of them do, is when full screen will not work, the reason Airborne works it never has GetPlayerHWnd (which I have no idea what that is, but I am assuming someone with scripting knowledge can tell you.) If you comment that line out of any table you can get it to load into full screen but you cannot get it to start a game. 

 

I'll keep play-testing tables and report anything weird I see.

[The Loafer]

would like to play with fullscreen , tested in windowd mode monster bash runs before 48fps now 500fps so thats realy great but when could whe play in fullscreen mode ? thx for the great work you are doing !!

 

1 - Ensure you are not running a db2s

2 - Ensure you set the DDRAW = 0 for this table in the VPinmame section of the registry

3 - In some cases, ensure the script indicates HIDDEN = 0, not = 1

Edited by The Loafer, 10 February 2014 - 12:44 AM.

[mukuste]

@DHogsett: Interesting find. "Controller.Run" seems to be just the main startup function of VPM, which explains why the tables don't work when you remove that line... but what I do not understand at all is how Airborne can work without calling that. I can only assume that the Capcom emulation works somehow differently from the other manufacturers.

[The Loafer]

Final update of the weekend for me, then its work, work, work!

 

Ok, so aside from performance issues, one of the reasons for wanting a DX9 VP was to enable Anti-Aliasing in win7, as it didn't work very well.  Because this is a tech demo, I really wanted to focus on nothing extra, just getting testing done.

 

But as a last kick at the can, I figured "why not?".  My expectations considering the lack of optimization was "will look sharper but with performance hit".  I was wrong, it looks sharper all right, beautiful floppers, sharper playfield/objects (to me anyway) but... performance was unaffected, everything was still perfectly smooth.

 

So I went to the NVidia panel and turned EVERYTHING on.  I mean Anisotropic filtering at 16X, FXAA on, Setting @ 32XCSAA, transparency at 8X supersample, blah, blah, blah... everything!  Its quite possible I've enable some settings that fight other settings, I have no friggin idea LOL.   Whatever, its a test, so I went back into VP, loaded up BSD (which works with the db2s btw, so some do work) and voila... same result, perfectly smooth.  Actually that's not completely true, on the first ball once it's plunged and the ball is about to enter the top lanes, there's a half a sec drop in frame rate and that was it, after that it was fine. Even got multiball going, no problem, perfectly smooth.

 

This is troubling.  Aside from the odd issues such as lights that don't light up and a couple of tiny glitches that's already been identified by other testers (and these are expected as per your initial post mukuste), it outperforms the vp9.2.1 with everything I'm throwing at it.  This "demo", I'm considering using as my default player, even with the bugs.   Obviously those bugs could become annoying sooner rather than later but that's just where my head-space is right now, quite the "high" you've created with your release Mukuste

 

So have I considered using this as a main player because it just looks prettier?  Nope, I think I mentioned it earlier but let me re-iterate it, the flipper response on my PC is improved on the more demanding tables (which incidentally are the more popular ones eheh).  I don't think its my imagination, no doubt because the simulation doesn't have to play "catch up" there is a flipper response improvement (lessened issue in VP9.2.1 with the DDRAW = 0 setting but still, this build performs better).

 

SO won't say thanks again, that's plainly clear. But for me, this test has been more than just a demo of what may come, but rather what I should expect sometime in the not too distant future. 

 

Now, I finally get why the heck so many wouldn't want to get away from XP...    With XP support expiring soon, your timing is impeccable sir!

[jimmyfingers]

@ The Loafer - you didn't notice any flickering with nVidia AA enabled in the control panel?  I tried AA too as I was curious and things do look great, but the ball disappears as it seems there's some type of flicker / refresh issue and this can even be seen with just the default / template table.  Can notice issues on the flippers towards the bottom of the base as well.  I tried on two systems and with Desktop Composition Disabled checked off as well as cleared.  It's pretty quick and easy to reproduce and as I'm yet encouraged by AA in general and your report seemingly not having any problem with AA, it definitely has problems at a fairly basic level on the two system I've tested (specs. already posted earlier).

 

I was going to mention the AA issues (and also how nice some of the things now look with the DX9 AA - no black lines, for instance) but had initially decided to wait a bit and was going to ask whether he really wanted any feedback on that regard yet.  I do totally agree though that a big part, I though / wished at least, of the DX9 port would be to get proper functioning AA.  From what I saw with how it looks, if the blinking / flickering can be resolved, it's going to look really sweet and hopefully the gap between those few that currently use nVidia AA and those that don't will grow very small if / when a DX9 full port can be completed.

[The Loafer]

On the tables I've tried, the ball NEVER flickered once. I wouldn't be able to play full games if the ball flickers and I have, no problem at all.  Some lights don't seem to work but I don't think that's because of AA, it has to do with the current state of this tech demo.  Try BSD, that one played perfectly, I can also show all the options I've enabled. I did not set them as global options.

 

BTW, I think I have "disable visual themes" on the tech beta exe, did you try that?

[jimmyfingers]

@ The Loafer - I bet that you have FXAA turned on via nVidia Control Panel.  Try turning that off and using just regular AA options and if you're on Windows 7, you should see the issues I describe (I did try a number of other options including the disable visual themes and it's only with FXAA set on, and presumably overriding the other AA settings, that there is no flicker). 

 

FXAA is o.k. and seems to not have the haze like with 9.2 since these very latest drivers have allowed the FXAA to finally work in Windows 7, however, it still has a bit of bluriness but still seems even a bit better in that department too from previous FXAA tests (I suppose the DX9 asept is helping the FXAA function even better and is good timing considering it's just started working for Windows 7)

[The Loafer]

Jimmy:  That is correct, through the NVidia panel.  Mukuste already stated in his first post the Tech Beta's AA did not work.  But previously the NVidia panel solution did not work well either, for me anyway and it would be one heck of a performance hit even with its poor support.

 

Perhaps you missed it but In my original post above, I stated "So I went to the Nvidia panel and turned EVERYTHING on...".   Sorry if you misunderstood Jimmy.

 

Yep there's lots of good timing here, looking forward to further updates.

[mukuste]

That's interesting news about the AA, I hadn't tried it. When I said AA didn't work, I meant that I disabled the built-in options in VP for AA, but I would actually expect the driver-forced AA features to work a bit better than before. That said, at least in my NV Control Panel, it seems I can only enable FXAA, so it would be interesting to know what kind of AA exactly you guys were testing.

 

MSAA will probably be simple to enable in this renderer. What we should also be able to do soon, using shaders, is supporting such things as FXAA and SMAA natively. No timeline on this currently.

 

One thing about the flippers I didn't mention before: the old engine used to pre-render the flipper in a few different positions and then use whatever pre-rendered image was closest to the true flipper position. The new renderer truly renders the flipper at its actual angle every frame. I also had the feeling that this contributes to a more responsive flipper feeling when I made this change.

[Sir Cheddar]

I share the feeling that the DX9 test plays better, but for me the ddraw setting of vPinMame seems to be part of the problem. VP9 plays better too while ddraw is disabled.

So I went ahead disabled ddraw for all tables which don't need a special DMD position. To stretch the DMD display I followed the advice in the thread here.and set up a custom screen resolution.

Many goats gave their lives to help me find a resolution that fits nicely.

The DX9 test version still plays better then VP9 with ddraw=0 but it seems rendering vPinMame with DirectDraw on VP9 has an impact.

[jimmyfingers]

Jimmy:  That is correct, through the NVidia panel.  Mukuste already stated in his first post the Tech Beta's AA did not work.  But previously the NVidia panel solution did not work well either, for me anyway and it would be one heck of a performance hit even with its poor support.

 

Perhaps you missed it but In my original post above, I stated "So I went to the Nvidia panel and turned EVERYTHING on...".   Sorry if you misunderstood Jimmy.

 

Yep there's lots of good timing here, looking forward to further updates.

Yes, I saw and read mukuste's comments about the nuances of this release (I go to great details in my release notes and respect and read others).  I simply refer to the nVidia panel to be clear and detailed in my description of what exact settings I’m referring to and especially because it’s just recently that the nVidia panel actually does something with respect to FXAA.  And in this case what it does is indeed work but also appears to mask the issues of using regular AA without FXAA also set to on.

 

I don’t believe I misunderstood anything and again read and absorbed what you wrote about “everything on”, however, you wrote that in a manner that appeared as if you went back to the settings and cranked everything up.  You had already described how good everything looked to you and obviously couldn’t be from the native VP AA / FXAA options for reasons as already understood by both of us (i.e. that you were already testing it before the “everything on” stage), which is why I was still focusing on the likeliness and suggesting that you had FXAA on during all your tests / the whole time.

 

What is not helping potential misunderstanding on these AA issues is that at this point, when I think I’ve given a pretty clear picture of what to try / test to reproduce the graphical issues that I believe you and other Windows 7 users will experience with nVidia forced AA, there still isn’t an answer forthcoming from you if indeed the FXAA being definitively turned off and leaving the standard AA on actually changes your experience or at least perception about this “problem” (nuances already described above). 

 

It seems you and I shouldn’t talk about anti-aliasing as it never seems to go well and is rife with misperception.  Last time, it was not mine either.

 

Sorry, but I’m kinda getting frustrated with people suggesting lately what I missed when there’s reasons and examples in their own demos or descriptions that makes things unclear and / or conflicting (Unity 3D thread with two or three pieces of lighting on the table actually doing any ROM controlled GI and the table image being in a permanent lit texture style right underneath the same so called great example).  I’d argue that my posts and releases depict pretty well how detailed I am. I know you’re a decent guy loaf, but it’s doubly annoying to me right now to still not get the clear picture from you on this particular element (FXAA / regular AA deal) after what I’ve just tried to describe, yet be the one that supposedly is not reading things from either Mukuste’s or your posts.

 

Bottom line is I believe you are inaccurate in your “all clear” / greenlighting assertion about AA and although it’s totally the early stages of this DX9 build (i.e. not really expecting it to be working) inaccurate feedback I certainly feel is more likely to hinder progress than help it.   Suggesting we not be allowed to save any tables / testing we may do also I felt was another assertion that was a potential hindrance and I was just as outspoken about that as you may find I am here.

That's interesting news about the AA, I hadn't tried it. When I said AA didn't work, I meant that I disabled the built-in options in VP for AA, but I would actually expect the driver-forced AA features to work a bit better than before. That said, at least in my NV Control Panel, it seems I can only enable FXAA, so it would be interesting to know what kind of AA exactly you guys were testing.

 

MSAA will probably be simple to enable in this renderer. What we should also be able to do soon, using shaders, is supporting such things as FXAA and SMAA natively. No timeline on this currently.

 

One thing about the flippers I didn't mention before: the old engine used to pre-render the flipper in a few different positions and then use whatever pre-rendered image was closest to the true flipper position. The new renderer truly renders the flipper at its actual angle every frame. I also had the feeling that this contributes to a more responsive flipper feeling when I made this change.

Here is a capture of the nVidia Control panel options of the only two fields I needed to change from default values to get the ball flickering issue on even the template / basic new table with the current build (I mention above that this was produced with various settings for running the executable as well as corroborated on a second Windows 7 system):

 

 AA settings Capture.PNG   100.18KB   20 downloads

 

Here is also a capture of my VP preferences (while testing this version at least):

 

 DX9 VP settings Capture.PNG   42.2KB   20 downloads

 

 

Edited by jimmyfingers, 10 February 2014 - 07:22 AM.