Beta 16

[Ryan Routon]

honestly I have no idea, our emulation code guy would have to comment on that.

 

[Timelord]

Ryan you've fixed RBioN performance on the N10!

Edit: Well nearly, it was smooth for a minute before it dropped to 30fps.

Exactly Carl.

The ASUS TF700, like the Nexus 10 suffers from fill in issues due to screen pixel size. These tablets may seem like they have bleeding edge processors, but have "issues" that are similar to older hardware. TPA "hits the hardware" pretty darn hard.

Thank you Ryan, it seems that 16B is better for those who have this "issue".

Timelord ....

 

[trachea]

Cactus Canyon: Doing a weak plunge (so that the ball rolls back to the plunger) causes the camera to move to normal table view. This means you can no longer see the plunger, but you can still plunge the ball.

Stuttering issue: I was testing on Cactus Canyon. The newest beta played OK for 15 minutes or so, but then it froze completely for 10-20 seconds before resuming at a choppy framerate (I'm guessing ~10 fps). Normal framerate can be restored only by pausing and resuming. The periodic choppy framerate is nothing new (it's been an issue for a year now), but the 10-20 second freeze has never occurred before this beta.

DEVICE: Verizon, Samsung Galaxy S3, Jelly Bean (4.1.2)

 

[superballs]

Cactus Canyon: Doing a weak plunge (so that the ball rolls back to the plunger) causes the camera to move to normal table view. This means you can no longer see the plunger, but you can still plunge the ball.

Stuttering issue: I was testing on Cactus Canyon. The newest beta played OK for 15 minutes or so, but then it froze completely for 10-20 seconds before resuming at a choppy framerate (I'm guessing ~10 fps). Normal framerate can be restored only by pausing and resuming. The periodic choppy framerate is nothing new (it's been an issue for a year now), but the 10-20 second freeze has never occurred before this beta.

DEVICE: Verizon, Samsung Galaxy S3, Jelly Bean (4.1.2)

I'm finding that a lot of the time this happens now, pausing and resuming will result in a loss of the UI (pause and camera buttons) and then it's a matter of time before the app just quits.

 

[superballs]

BLACK HOLE BALL THROUGH FLIPPERS:

Platforms: All
Occurrence: 100%

This has been happening since the day of release. I've taken some time to get it on video slowed to make it visible. This particularly was on the Note2, but I can recreate it on every platform I have.

 

[switch3flip]

Cactus Canyon: Doing a weak plunge (so that the ball rolls back to the plunger) causes the camera to move to normal table view. This means you can no longer see the plunger, but you can still plunge the ball.

Stuttering issue: I was testing on Cactus Canyon. The newest beta played OK for 15 minutes or so, but then it froze completely for 10-20 seconds before resuming at a choppy framerate (I'm guessing ~10 fps). Normal framerate can be restored only by pausing and resuming. The periodic choppy framerate is nothing new (it's been an issue for a year now), but the 10-20 second freeze has never occurred before this beta.

DEVICE: Verizon, Samsung Galaxy S3, Jelly Bean (4.1.2)

The weak plunge camera thing has been there since cc came out, nothing beta 16 specific.

I also use the s3 and you might already know this but the sudden stuttering usually occurs when you recieve incoming notifications, messages and stuff like that while playing. Turn device to offline mode of some sorts (data transferring,flight mode etc) then if you beat highscore just pause, roll down window and turn data transferring on, or hold the powet button and then turn of flight mode. Resume game and your highscore will upload.

The 15 second pause I've never experienced though.

 

[sellenoff]

I can't explain why HD would/should perform any worse or better than RBION. Both use the same exact whitestar emulated hardware and emulation code. The only difference could be that the actual ROM code just "does more" in RBION and is thus sucking up performance compared to Harley. James made a few tweaks to optimize the emulator for iOS, perhaps Ryan, you should do the same if you didn't already. Not sure how much extra frames he got out of it. Didn't sound like a ton.

As to why Whitestar games in general are way slower than the other emulated platforms is due to having to emulate TWO cpu chips running together instead of one, so you basically halve performance. So devices that are running more than 50% taxed with 1 cpu will have trouble with 2. I've tried to think of ways to improve this situation often, but haven't come up with a workable solution.

honestly I have no idea, our emulation code guy would have to comment on that.

 

[Carl Spiby]

I can't explain why HD would/should perform any worse or better than RBION. Both use the same exact whitestar emulated hardware and emulation code. The only difference could be that the actual ROM code just "does more" in RBION and is thus sucking up performance compared to Harley. James made a few tweaks to optimize the emulator for iOS, perhaps Ryan, you should do the same if you didn't already. Not sure how much extra frames he got out of it. Didn't sound like a ton.

As to why Whitestar games in general are way slower than the other emulated platforms is due to having to emulate TWO cpu chips running together instead of one, so you basically halve performance. So devices that are running more than 50% taxed with 1 cpu will have trouble with 2. I've tried to think of ways to improve this situation often, but haven't come up with a workable solution.

Does performance not improve with multicore CPUs?

 

[sellenoff]

I assume you mean multi-core cpu on the device running the game.
Depends on how the game engine itself is written ( i.e., is it using threads that can be offloaded to another cpu ). I don't know enough about the engine itself to say how much performance would improve. One would assume it could, but I don't know.

Does performance not improve with multicore CPUs?

 

[netizen]

There needs to be a specific coding to take advantage of multi-cores. In essence internal parallel processing.

Geeky nerd stuff

more cores mean more cache, which means the memory controllers will already be "completely overwhelmed" while developers try to utilize their GPUs which--at the same time--utilizes the same controller. In a system which has integrated graphics, the memory controller will not be able to feed the GPU which would in turn have a negative impact on the system's responsiveness

http://www.zdnet.com/lack-of-software-expertise-dampens-multicore-use-2062300778/

 

[Ryan Routon]

Thanks Steve =) Good to see you in here. We experimented early on with putting the emulator on a different thread but we had timing issues unfortunately.

 

[sellenoff]

You're welcome. Got lucky really, just happened to notice your comment while looking for a different post, otherwise I'd probably have missed it. In the future if you need a question answered, just shoot an email for me to check out the forum post, since I don't usually have that much time to read here despite wanting to.

 

[netizen]

Will there be another build to test/check the issues with pro mode on both tables, or is that going through internal testing?

 

[jaredmorgs]

Just stumbled across this PAPA vid of Flight 2000. A easily consumable 5 minute play that seems to highlight many of the game features nicely.

http://pinball.org/videos/gameplay-videos/flight-2000/

I was looking to see how the drop targets behave in this game, because I was getting a feeling that they had the same problem with reset-delay (that is there is almost zero reset delay) as Gorgar does.

I'm on the fence to be honest. The timing seems pretty much right, with the tendency to be a bit quicker on TPA. The drops on the TPA version seem to reset in a microsecond compared to an order of milliseconds.

What do you all think about drop-target reset time (probably a trivial issue, but just curious to see if I'm imagining it or not)?

One thing I did notice from that video is that the bonus count seems to be slower in the PAPA video than in TPA (or is it just me?). If this is the case, does that have something to do with the CPU clock timing implemented in TPA for this emulation?

 

[jaredmorgs]

BLACK HOLE BALL THROUGH FLIPPERS:

Platforms: All
Occurrence: 100%

This has been happening since the day of release. I've taken some time to get it on video slowed to make it visible. This particularly was on the Note2, but I can recreate it on every platform I have.

Great work on capturing that behavior on film !

Perhaps there is an issue with TPA and the collision detection on the rear surfaces of flippers. I would imagine that except for a few games (Twilight Zone's Upper Right flipper springs to mind where IRL you can trap a ball behind the flipper), the game engine would not be looking for contact on the backside of a flipper bat.

 

[switch3flip]

Flight 2000:
The instructions say extra ball is awarded automatically at 500.000 and 850.000, but I never get one at 500.000 and don't think I get one at 850.000 either but not sure, at that point I had already collected three. Think I got one at 700.000. Although two extra balls for points seems quite pointless as 3 extra balls are maximum per game, as you're supposed to get extra balls for collecting the multiball extra ball activation and special for spelling blastoff second time.

A different bug that happened while playing flight 2000:
I plunge the ball and camera stays i plunge view and puts two more balls out, which I plunge and suddenly I'm playing multiball in plunge view! When changing views the plunger view changed. Took a screen shot but don't have attachment permissions. Well all it shows is game in plunge mode where you see cabinet and coin door and a ball on table and one ball on it's way up from plunger. Could email it if necessary.

S3, 4.1.2

 

[netizen]

I have only gotten extra balls from blastoff, specials and the multiball extraball activation.

Or at least these are the only ones that stood out :-/

 

[netizen]

Just stumbled across this PAPA vid of Flight 2000. A easily consumable 5 minute play that seems to highlight many of the game features nicely.

http://pinball.org/videos/gameplay-videos/flight-2000/

I was looking to see how the drop targets behave in this game, because I was getting a feeling that they had the same problem with reset-delay (that is there is almost zero reset delay) as Gorgar does.

I'm on the fence to be honest. The timing seems pretty much right, with the tendency to be a bit quicker on TPA. The drops on the TPA version seem to reset in a microsecond compared to an order of milliseconds.

What do you all think about drop-target reset time (probably a trivial issue, but just curious to see if I'm imagining it or not)?

The drops seem to have the usual slightly slower than TPA response speed, but I see that the slings aren't nearly as powerful on the actual machine as they seem to be in the TPA emulation.

 

[Stuart Webster]

Flight 2000:
The instructions say extra ball is awarded automatically at 500.000 and 850.000, but I never get one at 500.000 and don't think I get one at 850.000 either but not sure, at that point I had already collected three. Think I got one at 700.000. Although two extra balls for points seems quite pointless as 3 extra balls are maximum per game, as you're supposed to get extra balls for collecting the multiball extra ball activation and special for spelling blastoff second time.

The instructions for the table should have been updated to say 750,000 and 1,500,000 accordingly last Friday. Try redownloading the table file; if that doesn't fix it, Ryan might need to upload the updated instructions.

 

[Baron Rubik]

but I see that the slings aren't nearly as powerful on the actual machine as they seem to be in the TPA emulation.

Going off video footage (never played a real one) the slings seem too powerful.

I noticed the same thing in Whirlwind though (not quite to the same extent though), so is this bobby's preferred tune setup now?