1394 replies to this topic

[Themer]

No it isn't recreated yet, because it currently is impossible without the addition of thousands of walls. The ROMs are available though. This is the reason why moveable walls / collidable primitives would be such an interesting addition. Because it is an arcade machine (not a pinball machine), you won't find it on the IPDB. It can be found on the The Arcade Flyer Archive. Another game which could be recreated with this functionality is Stevenson & Lovett's Conveyor which can be found at Arcade History.

[Argo]

I've tried the rev571 and the crash problem is still there. It seems slower too. My OS is w7 ultimate 64bit.

Edited by Argo, 11 May 2013 - 05:49 PM.

[jpsalas]

I've tried the rev571 and the crash problem is still there. It seems slower too. My OS is w7 ultimate 64bit.

Yes, the same crash here. My OS is also Win 7 x64 but the Pro versjon (more or less the same). I use a Nvidia GTX 680, latest drivers.

[Hyper]

I use a Nvidia GTX 680, latest drivers.

 

That's a bad ass videocard you have got there.

[toxie]

572 kinda reverts the issues introduced with 570..

[evilantal]

Last night, I was going through some takes on the 569 version and came across a few that gave me problems. Lost in Sp ace would just crash outright, without the table ever showing. Maverick (and one other table I can't remember now sadly) gave me some graphics corruption. There was a black field over about a third of the table running diagonal in the top right. Are these known issues? Verstuurd van mijn Transformer met Tapatalk

[toxie]

not really, so thanks for reporting.. could you please test which revision crashes first to simplify the tracking for us?

[jpsalas]

I don't know about those tables, but I'll take a look at them and I'll see if there is any special object that may trigger the error. I'm building NBA using the rev569, and for now it looks very stable and no graphic errors, but the table is not ready and wothout script, so I can't see the animations or flashers. But so you may get the idea of how the flashers look with the VP916 options, here you have a screen shot of the table:

 

 

and without compression:

 

Edited by jpsalas, 12 May 2013 - 08:13 AM.

[jpsalas]

I only tried Lost in Space 1.02 FS, and it works with rev532, but rev533 onwards just crashes before the table starts (standard Windows error: Vpinball... has stopped working)

[unclewilly]

hey jp. What options are checked for the flasher alpha ramps. I havent had time to check all the new features.

I don't know about those tables, but I'll take a look at them and I'll see if there is any special object that may trigger the error. I'm building NBA using the rev569, and for now it looks very stable and no graphic errors, but the table is not ready and wothout script, so I can't see the animations or flashers. But so you may get the idea of how the flashers look with the VP916 options, here you have a screen shot of the table:
 

[img]http://www.vpforums.org/public/style_images/VPForums/attachicon.gif[/img] NBA_VP916_flasher_demo.jpg
 
and without compression:
 
[img]http://www.vpforums.org/public/style_images/VPForums/attachicon.gif[/img] NBA_VP916_flasher_demo.zip

[Horrible]

rev570 gives me the error "Visual Pinball 9.1.6 rv570 has stopped working" during the game

 

Yes, the same happens to me when I try to run the table or a few seconds/minutes after I run any of my latest tables, some crash to the desktop ina few seconds after they started, other take 1 minute or so. I haven't found a pattern as why this happens (it crashes with my latest MM, Star Wars, Sopranos). Rev 569 works fine. I have been using it several hours building my new table. And everything seems to work fine.

 

as for the light state off/no lighting: maybe you can explain a bit more: why are for fading lights both states (on/off) used for the fade and not just the on state?

 

Well, that's how I made the fading lights I used two lights, and the fading uses 4 states. The first light have the states off and a "little on", and the second light has the "more on" and the on states. Why I used only two lights? Mostly to save cpu. In VP when you turn on a light it will move on top of the other lights, and I don't know if it is a bug or it was meant to be like this, but it is a feature I have used But if a light is already on you need to turn it off and on if you want it to move to the top and be visible. So if I used 4 lights, then I'll need to turn off and on each light for each step of the fading, that's 8 changes in the light states. By using two lights I get away with just one change per fading step. I guess with the newer cpus this doesn't matter so much anymore

 

Anyway the new tables will use leds So no need for fading hahaha.

 

Rev 571 gives me the same errors, 569 works fine

[jpsalas]

I only checked the Additive Alpha Bl.on the flasher ramps. I still haven't checked the new general illumination/ambient options.

 

 

hey jp. What options are checked for the flasher alpha ramps. I havent had time to check all the new features.

[jpsalas]

Thanks for the rev572. That fixed the crash error on the latest tables, but still there is the same crash on some older tables which happens on all versions after 532. But still I haven't found what can cause that crash.

[toxie]

Thanks JP! Will look into it soon.. In 533 fuzzel introduced the vertex buffers for ramps, so I guess it has to do with that..

[jpsalas]

Yes, it the ramps, but I don't know why it happens with this table (Lost in Space 1.02 FS) where all the ramps are quite normal ones. I have removed all the ramps one by one, and when only a few were left then the table worked. I have other tables with more ramps and they work quite well with rev572, so I haven't a clue about what can be wrong with those ramps that trigger that error. After removing several ramps the table started and I saw a redraw error were many triangles were drawn on the screen, as you can see in the screenshot. I don't know how many tables may be affected, but the newer ones seem to work fine.

 

Edited by jpsalas, 13 May 2013 - 04:40 PM.

[luvthatapex]

I just tried the new ROBOT with rev 572 and the graphic tearing problem is back. There is no tearing with rev 570 and this table.

 

 

Attached Files

•  tearing.jpg   138.44KB   55 downloads

Edited by luvthatapex, 13 May 2013 - 04:56 PM.

[Wimpie3]

Is the "overflow on line 0" error corrected in this version? I'm running XP64 and this error turns up at random moments during gameplay.

[jimmyfingers]

Toxie, did you need any more explanation as to why the light objects need the option to turn off the lightsources effects / darkening after JPs explanation of how / why the fading lights are done that way? Ultimately, even though the lights may be able to be recoded / redone to not to use that technique (“a” partially on images on the second light objects “off” image texture mapping), like JP says, there's a performance potential but mainly, as far as the lightsources settings go, probably 95% of the tables use that technique and every one of them would need a lighting overhaul to work with the lightsources and changes to likely hundreds of objects and lot’s of code required unless there is an option to disable for the off image of a light as well (or simply not use light sources which seems to defeat the purpose of development efforts on it or let them be darkened which also seems not moving forward in helping VP lighting as lights should be at least the same intensity if not brighter when the table darkens – at least relatively in appearance - but not darker).

 

Maybe the best thing to do is simply have a global option to disable the light source effects on all light objects within a table, but then allow you to override that global setting on any specific object itself (as otherwise we'll be selecting hundreds of light objects to change that setting (even if you add the off image lightsources disabling as well) whereas the vast majority would be turned off anyway – so global off as the starting point would be best).  Most table creators / artists are accustomed to manually drawing the lighting levels anyway for plastics, PFs, and lamps for their respective lighting levels (off, b, a, and on) so any manipulation of lighting could still continue in this way for light objects / PFs and plastics using light objects and the lightsources options used for general darkening / spot lighting of every other type of table object.

 

It seems you've got some other bugs and higher priority items going on but as far as the lightsources options working / being used effectively, let us know if you need any other descriptions or help with ideas or testing.  By the way, the latest version (572( is working now with the alpha ramps / flashers lighting levels being untouched with disabling that “Additive Alpha BI.” option you added / referred to (so that parts great).  Again, thanks, for working on all this stuff for VP and obviously this lightsources option is a bit more like icing on the cake so don’t stress yourself out over it when there’s other things like crashes and bugs going on.

[fuzzel]

Please try rev 574 it should fix the crash on tables like Lost In Space and the tearing problem too (hopefully )

[toxie]

@jimmyfingers: i would actually rather go for having fading lights natively in the core, instead of having to have these evil hacks that also put some burden on the CPU and makes the scripting more complicated, too.. the question is just on how to do it.. I guess it would be some special light type that allows for blending between off and on via script or would be something more simple like a "time to full off" and "time to full on" better? (at least it would most likely be simpler to implement)

These lights then would be rendered "per frame", similar to how primitives and alpha ramps work..

 

Does that make sense? I would basically (in theory) expose two more parameters (the two "times", maybe in milliseconds), maybe also some blending curves (linear, quadratic, sine, etc) to steer the blend between on/off, and then these lights would simply be automatically do the fading whenever the light changes from on to off or off to on..

 

@all: so bugwise we're good currently? or are there still open issues (except for the crash(es) on very old video cards)?