2087 replies to this topic

[mukuste]

Just a suggestion on light objects. If we could just swap textures or have 4 instead of 2 then we could use one light object and still use a fading light routine.

If there were 4 options on one light that would cycle through when an on or off command was called. With the interval determining the time between changes of the faces

 

In DX9, you can already swap textures at will. My problem is how to get legacy tables working properly with the new renderer, without people changing them...

[Slydog43]

Just tried flintstones and table has no lights.  FPS went from 1100 down to 320, but is completely smooth, just no lights. (Not complaining, just pointing out things)

Edited by Slydog43, 13 February 2014 - 01:27 PM.

[toxie]

All the tables that had insane FPS before can potentially be slower now, but the good thing is that they will never show sudden stutter as soon as a lot is happening on the table (multiball, etc), so the FPS should always be pretty much constant. (otherwise please point out which table shows the problem at what point of gameplay, as there might be new bottlenecks appearing now)

[zany]

 

I just have to say it once more.....this is F*KING AMAZING!
Tried the latest(test2) on two computers. First out was my i7 laptop, with really poor nvidia GT425M 1Gb gfx card, 4Gb ram and Win7 64 bit. Most of the newer tables with alot going on, is unplayable with the VP DX7....but runs REALLY good with the DX9 verison.
Next computer was my dual screen arcade computer. A i5 3400GHz, Nvidia GTX660 2Gb, 8Gb ram and Win7 64 bit. Some games did lag and stutter, like Ironman and especially Monster Bash. On Moster Bash(PCKiller) i had an FPS around 40FPS and som horrible lag and stutter with the DX7 version, but with the DX9 i have an FPS of around 1400FPS and an avarage of around 1000. i Played this in windowed fullscreen with B2S on the second display, and DMD on top of the B2S.

On Ironman and Tron Legacy i couldn't see any graphic issues, but a few minor ones on other tables...like some balck spots and lines across.

Mukuste...this is like a dream come true.....and me and as i guess all the others in this community REALLY appreciate all the amazing work you do!!

Keep it up...i cant wait for the next version!!!!

Huge THANX!!!!!

 

im pretty sure you meant to say tables "I" and "T"

 

Of cource i did!

[unclewilly]

I'm not to concerned with legacy support. I'd rather update my tables

[frans]

Cirqus Voltaire Platinum: No lights too.

[jimmyfingers]

@JF:

 

Switching light textures works completely naturally now. All you need to do is set the .OnImage property (or .OffImage, if you wish) to the proper texture name.

 

I haven't worked on the draw order yet, I should probably check that out soon.

 

I had an idea how to fix the overlapping lights for the last compatibility release. Let's say if a light has its state changed in one frame, then we move it to the end of the draw order (at least as far as lights are concerned). Then it will draw last and override the other light textures. I hope this won't cause too many troubles with other draw order issues...

Thanks Mukuste for confirming that information on the lights and I'll do some tests. I like your idea for the compatibility aspect on the lights, but like you say, it depends how the lights would be re-ordered as even without fading lights routines now, even a single light object that is not properly ordered behind an alpha will show some glitches from the alpha ramp (most cases for lights have alphas higher than them considering most are at PF level, but not all - plastics GI, other lights on top of objects). So if the groups of lights for fading or GI8 were re-ordered in realtime, it would almost just have to be amongst themselves only and not alter how they were arranged with the rest of the table objects.

 

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) like the walls have or, as an alterative along the same lines, allow the lights dynamically to be assigned a pure black texture (same might work even easier if possible for setting to a pure black colour - with no image - as already known as working / added in your latest build for the refresh lights). This way the fading lights routine could be quite easily modified to use this technique to completely turn off / invisible / set black the light object that is no longer desired to be in view (we could leverage the black light compatibility code that you've already put in place and just utilize it in an extended fading lights routine). A couple lines in the fading lights sub routine(s) and possibly the initialization areas would be all that's needed per table. This would save a reasonable amount of time otherwise editing all of the objects and current structure per light object / fading light call in the updatelamps routine for a table.  Of course, I imagine that if a way could be found to work around this lights issue without requiring any end user interactions than that would be ideal as there’s still a lot of table to re-publish for the authors or a bunch of end user / script changes.

 

The full screen window mode seems to be working fairly well, however, the ball is still mis-shaped / not round while using this mode (it is stretched out too much vertically / along the table length / Y axis). I'm assuming that at this point the full screen anti-stretch option for real full screen has not been incorporated into the window full screen and is the reason. The other two modes that can be chosen yield undesirable results as well but always have for FS tables with layback settings. Essentially, if the setting is on “Stretch Ball with Table” then that, from my understanding, is the default that existed in VP before any of the Ball aspect ratio options were added, however, it causes the ball to stretch horizontally and look a bit like a football on it’s side.  The “Don’t stretch the Ball”  seems to be yielding the same as the “At Full screen anti-stretch the Ball” as I imagine because the latter is not coded in yet so both do the same effective result (yielding a footballish shaped ball on it’s edge / vertically).  This can be easily seen with the Monster Bash PcKiller version (FS) 2.1 that has seemed to become a focal point for testing.

 

An example for some light and flipper object drawing order issues can be found in the World Cup Soccer ’94 Mod table at the bottom right of the table when running the T.10 LAMP + FLASH diagnostics.  Here is a screen shot with the issues highlighted:

 

 WCS94 Ordering Capture.PNG   449.41KB   22 downloads

 

Here is a screenshot with the issues resolved by reordering the RightFlipper flipper, GIright light, L101 light, and Wall365 wall to all be set to back / draw in back (performed in that order as well):

 

 WCS94 Ordering Capture (Fixed).PNG   446.11KB   21 downloads

 

Here is a link to the table itself:

http://www.vpforums....s&showfile=8929

[mukuste]

It's true that I didn't apply the anti-stretch routines to the windowed fullscreen mode yet. I'll have to have a look at it later.

 

Thanks for the detailed pictures, those will be very helpful in debugging draw order issues.

 

The idea with a "visible" flag for lights is also good. I'll revert to that if my draw order experiments become too messy.

[jpsalas]

I just wanted to add that I'm impress of what you have achieved in converting VP to VP9. I thought the conversion was going to take months of coding.

 

Now I want to explain a little how I made the fading lights using two lights. I used one VP feature in which when you turn on a light it displays on top of any other light which is at the same height level.

So when I turn on a light, it displays on top, showing the on state. Then when I turn off a light it starts to fade and first turns off that light (which still is on top at it shows the first step in fading), then the second light turns on and it moves up, showing the next fading step, and finally this light turns off showing the last fade state.

 

I just wanted to explain this "feature" of VP, that maybe will explain why the fading lights don't work very well.

[frankrizzo2]

If the Taxi version with the spinout problem is the latest Night mod from Aaron and me and you have BMPR lite enabled-> it might be that one of the triggers is not triggering as it should. In that version I had to add a trigger to the ball launch to disable momentum timer when the ball enters the spinner. Otherwise it would spin there forever. It's enabled again when it drops out. That could be one explanation although I don't know how the new rendering could cause that.

 

It seems that my findings with Taxi may be related to FXAA settings and vsync. I will try to do some more testing this evening. I know that I did have some issues with using fxaa. When it was on my frame rate would drop around half (Monster Bash 400 fps fxaa on and 200 with it off) and I also had a lot of micro stutter with fxaa on.

 

I also messed around with v sync settings a little and while it worked fine for the most part, it would add flipper lag into the mix.

Vsync is a lot smoother on dx9 than dx7 from what I can see.

 

I have my playfield running on my gtx460 card and my backglass and dmd running on my 550ti card. I thought that maybe i should be running my dmd or backglass with my playfield card so things can "sync" better with whats going on with the playfield and with the dmd or backglass. I'm just spit-balling but I would like to know if most are running the playfield independent or if they are running it with another monitor.

 

windows xp 32

ddraw 0

gtx460 playfield

gtx550ti backglass dmd

1155 socket i5 

[mukuste]

I fixed the single-pixel line on the AFM beta.

 

 

I ran "A" a second time and this time I get 8007000e in RenderDevice.cpp line 298. 

 

Not really sure what makes them any different from other tables (I tried a lot of them!), but I did try setting the max texture limit to 2048 and it didn't make a difference.   Also just tried 1024, same thing.

 

What I meant by "sharding" is that the playfield looks like it has some broken shards of glass.   

 

 

What version of the Indy table is that? I tried  Indiana Jones FS 1.0.0 by Destruk but couldn't reproduce the issue.

[insx]

I finally got round to testing this (with version 2). I tested with Attack from Mars on my cab and the fps didn't change an awful lot but it has definitely cured the microstutter. Some lamps are stuck on while others won't light and some of the inserts look too bright when they are not lit but I think these are known issues. Oh, and a small horizontal line appeared between the slingshots when I destroyed the saucer and everything was flashing. Very promising!

Edited by insx, 13 February 2014 - 08:41 PM.

[tttttwii]

On my system (Win7 64bit, 4GB, GTX 760 2 GB, Core2Quad 2,87 GHz) this second test version is running faster in ALL tables I ahve tested so far.

 

There are still some artefacts remaining:

- Monsterbash: The blue target right to Frank is disappearing and appearing every 2 secs in some modes of the tables.

- On the apron the kicker cylinder is still displayed (see attacked Safe Cracker apron).

- Flasher artefacts (see attached picture of Safe Cracker (yellow small flasher next to safe).

- On AFM from JP the label (letters) above the plunger are not correctly displayed.

- Taxi (JP Version) - The ball in the eject kicker (upper left) is cut in half (only upper side of ball is displayed).

 

Thanks a lot, this is a major leap for VP!

 

Torsten

Attached Files

•  safecr.png   1.25MB   13 downloads

Edited by tttttwii, 13 February 2014 - 09:05 PM.

[DJRobX]

The Indiana Jones screenshot is from Teppotee's VP 9.2x night mod .  

 

I am running a Nvidia GTX 650ti with 1GB, but on Windows XP.   I usually limit textures to 2048 since I can't see any difference.    In fact, I added a bit of code to my VP to maintain aspect ratio when scaling down textures (2048x4096 texture becomes 1024x2048, instead of 2048x2048, when max 2048 is specified).

if ((pictureHeight > maxTexDim) || (pictureWidth > maxTexDim))
{
         int newWidth = min(pictureWidth,maxTexDim);
         int newHeight = min(pictureHeight,maxTexDim);
         if (m_originalWidth - newWidth > m_originalHeight - newHeight)
         {
             newHeight = min(m_originalHeight * newWidth / m_originalWidth, maxTexDim);
         }
         else
         {
             newWidth = min(m_originalWidth * newHeight / m_originalHeight, maxTexDim);
         }
         dib = FreeImage_Rescale(dib, newWidth, newHeight, FILTER_BILINEAR);
         m_width = newWidth;
         m_height = newHeight;
      }

That said, T 'n A (LOL) both run fine in "unlimited" mode in VP9 dx7 on this system.

Edited by DJRobX, 13 February 2014 - 10:39 PM.

[JohnnyDoe]

Is there any reason why the backglass would have to use more cpu than vpinball?

With the new dx9-version, for example, apollo 13 takes about 8% cpu on my rig. The b2sbackglass-server takes 12%. It just seems excessive.

I know this might not be related to Mukustes work, but maybe someone would chime in anyway.

Edited by JohnnyDoe, 14 February 2014 - 09:13 AM.

[innertwist]

I also have this "sharding" issue when playing Teppotee's VP 9.2x night mod of Indiana Jones.

[mukuste]

Is there any reason why the backglass would have to use more cpu than vpinball?

With the new dx9-version, for example, apollo 13 takes about 8% cpu on my rig. The b2sbackglass-server takes 12%. It just seems excessive.

I know this might not be related to Mukustes work, but maybe someone would chime in anyway.

 

You'll have to take that up with the b2s developer(s) themselves, it must be in their code since VP doesn't do anything related to b2s.

[JohnnyDoe]

 

Is there any reason why the backglass would have to use more cpu than vpinball?

With the new dx9-version, for example, apollo 13 takes about 8% cpu on my rig. The b2sbackglass-server takes 12%. It just seems excessive.

I know this might not be related to Mukustes work, but maybe someone would chime in anyway.

 

You'll have to take that up with the b2s developer(s) themselves, it must be in their code since VP doesn't do anything related to b2s.

 

I was kind of suspecting that. Thanks for the answer.

[mukuste]

As I suspected, the "sharding" in IJ was the same issue as the line on AFM. So that's already fixed, no work there for me

 

Next up, finally fix the kickers so that people will stop pestering me about them

[unclewilly]

Does this mean we will have a dx9 vp9.3 compatibility version soon