29 replies to this topic

[pinball lover]

No, i did not mean to release it with this weird vpinspa thing, i dont know how to rewrite the script either. I am still a noob.
I just saw, that on another Forum, there is this Table released for FP so i wondered, if it is legally allowed to release it as any other legal tables as well.
But it seems, that is more difficult to create this table the same legal way, as it is created as FP Table.

Edited by pinball lover, 25 May 2022 - 12:55 PM.

[wiesshund]

No, i did not mean to release it with this weird vpinspa thing, i dont know how to rewrite the script either. I am still a noob.
I just saw, that on another Forum, there is this Table released for FP so i wondered, if it is legally allowed to release it as any other legal tables as well.
But it seems, that is more difficult to create this table the same way, as it is created as FP Table.

 

More difficult yes, as you can not rely on a ROM for all the logic
impossible though, No.

 

Everyone here was a noob, till they werent (im still a noob)

 

The table would be a great learning experience.

You would get to start from scratch, since you could throw away the entire existing script.

And then build it little by little
Start off by just making flippers work, then add plunger
etc

[jpsalas]

Or just play my Slimer table Which has similar rules And if you change the LUT image you may also get similar graphic colors But I guess the table is old enough now to make a remake in VPX without the ROM or stolen DLL Maybe next year I'll do that

[mrjcrane]

Or just play my Slimer table Which has similar rules And if you change the LUT image you may also get similar graphic colors But I guess the table is old enough now to make a remake in VPX without the ROM or stolen DLL Maybe next year I'll do that

Just curious to ask any of the developers, when you ditch the ROM and rewrite the entire table in VPX script, does anyone seem to notice any major difference in game performance?? Faster? Slower? Scripting Bottlenecks? Issues with nesting? I've not noticed any performance issue with any Script based table, then on ROM based Twilight Zone seems a little weird or jerky sometimes (so I am laying low waiting for VPW or some of the other teams to put TZ on the radar for a refresh).

[jpsalas]

We know that ROM emulation uses some cpu, so an original or EM table, in theory, will always be faster than a ROM based table. But that depends on how the author has made the table, how many timers has he used, or how many images, transparent effects, extra calculations, etc. 

[smaugdragon]

Or just play my Slimer table Which has similar rules And if you change the LUT image you may also get similar graphic colors But I guess the table is old enough now to make a remake in VPX without the ROM or stolen DLL Maybe next year I'll do that

This excites me greatly

[wiesshund]

We know that ROM emulation uses some cpu, so an original or EM table, in theory, will always be faster than a ROM based table. But that depends on how the author has made the table, how many timers has he used, or how many images, transparent effects, extra calculations, etc. 

 

Yes and no
ROM uses some CPU but Pinmame is faster than VBS if you get a fairly complex table

Now depending on what said table is running on, it can be a null argument, unless we venture into the bizarrely complex
but as you touched on, if you get too many timers doing somewhat complex things in VBS you can kill off even the mother of all gaming PC's
VPX cant thread that all out to different cores in a manner that would be helpful to that situation, so you get basically one core playing "lets do all this math at high speed over and over"

 

That said
I have not studied the rules and modes very much in the real ghost busters, but i dont gather from from watching it played, that it is really
much more complex than your slimer, or your deadpool or your diablo, perhaps less complex even and i can play those even on my laptop.

 

[mrjcrane]

For sure JP's slimer is loads of fun, one of my favorites. Makes me wonder if something is possible. JP Mentioned that games using a ROM have the potential to run faster than 100% script based VPX tables. So could it not be possible to build a "simulated rom engine"?, where the VPX script can do part of the work then offload other parts to a ROM engine which executes some kind of binary file, even for fully script driven tables like Slimer? Offload some of the work.

 

What is it that gives the Rom based tables the edge in performance over the script based tables? Is it that it is a compiled binary and can leverage that efficiency?

 

I used to have this idea in VPX that when I "compiled" the script I kept looking for a bin executable to be written somewhere, until I realized script compile really means check for syntax errors. Right, there is no "executable" that is created as a result of compiling? So VPX, script is running in RAM. As table sizes keep growing +100 megs +200 megs with VR rooms, Pup Packs and such that will add demand to the CPU and available Ram .. But we love these new games.

 

I did see Wies is partially answering the question in the previous post.

Edited by mrjcrane, 26 August 2022 - 01:23 AM.

[wiesshund]

For sure JP's slimer is loads of fun, one of my favorites. Makes me wonder if something is possible. JP Mentioned that games using a ROM have the potential to run faster than 100% script based VPX tables. So could it not be possible to build a "simulated rom engine"?, where the VPX script can do part of the work then offload other parts to a ROM engine which executes some kind of binary file, even for fully script driven tables like Slimer? Offload some of the work.

 

What is it that gives the Rom based tables the edge in performance over the script based tables? Is it that it is a compiled binary and can leverage that efficiency?

 

I used to have this idea in VPX that when I "compiled" the script I kept looking for a bin executable to be written somewhere, until I realized script compile really means check for syntax errors. Right, there is no "executable" that is created as a result of compiling? So VPX, script is running in RAM. As table sizes keep growing +100 megs +200 megs with VR rooms, Pup Packs and such that will add demand to the CPU and available Ram .. But we love these new games.

 

I did see Wies is partially answering the question in the previous post.

 

 

ROMs run in a highly efficient IDE and they have no overhead, they know nothing but run this pinball machine
and pinmame simply presents to the ROM, the illusion of the hardware being present, and trasnlates what the ROM asks of it's native hardware
into a request that is valid to PC hardware.

VBS is not highly efficient, it is basicaly feed script into VB engine let engine read script and turn into actual function dragging along the overhead of things that arent needed
and the VB engine itself isnt really designed for high speed
That is not to say that one could not write a VB interpreter that is designed for it, but what exists in windows is not that.

You would have to build one into VPX and have it read script, compile and execute internally, and it would be streamlined and devoid of a lot of unnecessary baggage. 
and that is probably over simplifying, putting in some active threading of various processes would possibly be needed as well to gain full benefit
to thread on various things to at least 4 processors so all the load does not inevitable land on a single cpu core.

If the VPX team had unlimited time and resources, there are a lot of things they could do, none of them fast and none of them easy.

200MB table does not necessarily equate to eating up 200mb more RAM (though 200mb is trivial now days)
most of the 200MB is stuff that will be shuffled off to the video card to deal with, Indie games chew up more resources than VPX really
Pup packs are not so much RAM eating as they are CPU cycle eating, because the content has to be processed in software.
Asking to switch video content fast when it is being done in software is a job, if said video is encoded in 4k it really becomes a big job.

 

As for slimer
the table presents no issues for my laptop that are not directly related to not having a GPU
 

Edited by wiesshund, 26 August 2022 - 02:36 AM.

[mrjcrane]

 

For sure JP's slimer is loads of fun, one of my favorites. Makes me wonder if something is possible. JP Mentioned that games using a ROM have the potential to run faster than 100% script based VPX tables. So could it not be possible to build a "simulated rom engine"?, where the VPX script can do part of the work then offload other parts to a ROM engine which executes some kind of binary file, even for fully script driven tables like Slimer? Offload some of the work.

 

What is it that gives the Rom based tables the edge in performance over the script based tables? Is it that it is a compiled binary and can leverage that efficiency?

 

I used to have this idea in VPX that when I "compiled" the script I kept looking for a bin executable to be written somewhere, until I realized script compile really means check for syntax errors. Right, there is no "executable" that is created as a result of compiling? So VPX, script is running in RAM. As table sizes keep growing +100 megs +200 megs with VR rooms, Pup Packs and such that will add demand to the CPU and available Ram .. But we love these new games.

 

I did see Wies is partially answering the question in the previous post.

 

 

ROMs run in a highly efficient IDE and they have no overhead, they know nothing but run this pinball machine
and pinmame simply presents to the ROM, the illusion of the hardware being present, and trasnlates what the ROM asks of it's native hardware
into a request that is valid to PC hardware.

VBS is not highly efficient, it is basicaly feed script into VB engine let engine read script and turn into actual function dragging along the overhead of things that arent needed
and the VB engine itself isnt really designed for high speed
That is not to say that one could not write a VB interpreter that is designed for it, but what exists in windows is not that.

You would have to build one into VPX and have it read script, compile and execute internally, and it would be streamlined and devoid of a lot of unnecessary baggage. 
and that is probably over simplifying, putting in some active threading of various processes would possibly be needed as well to gain full benefit
to thread on various things to at least 4 processors so all the load does not inevitable land on a single cpu core.

If the VPX team had unlimited time and resources, there are a lot of things they could do, none of them fast and none of them easy.

200MB table does not necessarily equate to eating up 200mb more RAM (though 200mb is trivial now days)
most of the 200MB is stuff that will be shuffled off to the video card to deal with, Indie games chew up more resources than VPX really
Pup packs are not so much RAM eating as they are CPU cycle eating, because the content has to be processed in software.
Asking to switch video content fast when it is being done in software is a job, if said video is encoded in 4k it really becomes a big job.

 

As for slimer
the table presents no issues for my laptop that are not directly related to not having a GPU
 

 

Thanks Wies for taking the time to answer my questions. Great explanation !