Stable release 1.25 is available

AlchimiaStudios

Getting animation slow downs on older devices, is animation playback tied directly to fps now?

CodeWizard

@AlchimiaStudios Sort of, yes. When FPS drops due to a frame (or several) taking too long, we have to do something with that lost time. Our current implementation does two things with lost time:

1. If the lost time is <= 4 frames, we simulate it and skip rendering. That's stutter.
2. If the lost time is >= 5 frames, we simulate the first 4 and drop the rest. That's slow motion.

Here's the relevant function in our engine for your review:

-- how many seconds between simulation steps
local simulationStepLength = 1/60
local simulationStepLengthMS = floor(simulationStepLength * 100000) / 100

-- how many steps can we simulate in a single advance call?
local maxStepsPerAdvance = 4

function advanceSimulation(dt)
    -- how many whole steps have we taken this update?
    local stepsAdvanced = floor(dt / simulationStepLength + 0.5)

    if stepsAdvanced < 1 then
        NativeDebugTrace("gs_sim:", "Called too quickly.", floor(dt * 100000) / 100, "ms", "<", simulationStepLengthMS, "ms")
    else
        -- cap how many steps we'll simulate in one advance call
        if stepsAdvanced > maxStepsPerAdvance then
            NativeDebugTrace("gs_sim:", "Capping elapsed time.  Lost", stepsAdvanced - maxStepsPerAdvance, "frames.")
            stepsAdvanced = maxStepsPerAdvance
        end

        if stepsAdvanced > 1 then
            NativeDebugTrace("gs_sim:", "Skipped", stepsAdvanced-1, "render frame(s).")
        end

        -- advance each step
        for step=1,stepsAdvanced,1 do
            game:evaluate(simulationStepLength)
        end
    end

    -- handle lost game time so that game.time is equal to real time
    lostTime = dt - (stepsAdvanced * simulationStepLength)

    if lostTime > 0 then
        game:advanceTime(lostTime)
    end

    -- draw the scene
    render()
end

The implementation could possibly be improved by being adaptive in how many frames we simulate without rendering in slow cases. So, instead of capping the maxStepsPerAdvance to 4, we'd keep simulating until we're out of real time to catch up. I almost implemented that but chose to keep it simple to avoid more complexity and potential breaking cases.

The engine used to simply do this:

game:evaluate(dt)

The problem with that is that physics-based games require a fixed delta time (dt) for each frame. Otherwise they can become unstable and all hell breaks loose. And this can occur with small variations in delta time. This became particularly obvious when we implemented custom collision shapes -- objects were easily getting stuck to each other due to our variable delta time on each frame.

You might think that simulating all the delta time in simulationStepLength increments would be the right solution. And, you're right for thinking that. Except when simulating one step takes longer than a single step. In that case you'll never catch up with real time and your game will just lock up.

I'll take a quick stab at an adaptive "catch up" implementation and see how it helps @Icebox's game. I'll guess it's going to help quite a bit.

Jeffm2

Do the custom fonts work for HTML5?

Icebox

@CodeWizard said:
1. If the lost time is <= 4 frames, we simulate it and skip rendering. That's stutter.
2. If the lost time is >= 5 frames, we simulate the first 4 and drop the rest. That's slow motion.

Here's the relevant function in our engine for your review:

-- how many seconds between simulation steps
local simulationStepLength = 1/60
local simulationStepLengthMS = floor(simulationStepLength * 100000) / 100

-- how many steps can we simulate in a single advance call?
local maxStepsPerAdvance = 4
  
function advanceSimulation(dt)
    -- how many whole steps have we taken this update?
    local stepsAdvanced = floor(dt / simulationStepLength + 0.5)

    if stepsAdvanced < 1 then
        NativeDebugTrace("gs_sim:", "Called too quickly.", floor(dt * 100000) / 100, "ms", "<", simulationStepLengthMS, "ms")
    else
        -- cap how many steps we'll simulate in one advance call
        if stepsAdvanced > maxStepsPerAdvance then
            NativeDebugTrace("gs_sim:", "Capping elapsed time.  Lost", stepsAdvanced - maxStepsPerAdvance, "frames.")
            stepsAdvanced = maxStepsPerAdvance
        end

        if stepsAdvanced > 1 then
            NativeDebugTrace("gs_sim:", "Skipped", stepsAdvanced-1, "render frame(s).")
        end

        -- advance each step
        for step=1,stepsAdvanced,1 do
            game:evaluate(simulationStepLength)
        end
    end

    -- handle lost game time so that game.time is equal to real time
    lostTime = dt - (stepsAdvanced * simulationStepLength)

    if lostTime > 0 then
        game:advanceTime(lostTime)
    end

    -- draw the scene
    render()
end

This is when i feel lucky i chose gamesalad instead of coding

pinkio75

i've added the video rewards it works fine on my Kindle but i've saw the videos only for two times...

-Timo-

Awesome!! great work GS team!

Hopscotch

@pinkio75

your fill rate, or availability of serve-able ads, is dependent on a few things. Here are some:

• the territory of the player. Advertisers favor certain countries, therefore, some countries have very low ad inventory.
• the ad provider tries to match suitable ads to your app. This includes demographic and category. It may be that at certain times the inventory is low for your criteria.
• the performance of you app plays a role over time. This can also cause the ad provider to deliver less, or less attractive, ads to your game.
• some ad providers (not sure about CB) also have a warm up period, where they first gather statistics or trends about your app, before they serve any ads.

I promised @GeorgeGS I would "follow up" with him regarding a function to check if a rewarded video is available, before offering the option to a player, now that 1.25 is out.

Also, remember, there is a limit to the amount of RV ads a player gets served per app per day. This is 20 in the case of CB, unless you set the limit even lower.

Franto

@Lost_Oasis_Games Thank you, I hope I was of some help. I'm @Fradnor in the test group by the way. I'm sure you knew that already though {I apologize for being redundant.} : I

@CodeWizard After reading that, would a viable solution be to have "game:evaluate(dt)" a selectable choice for those that forego custom collisions and shapes?

I mean, if it's possible to program. For example, as an "else" or "otherwise" to a boolean that can be checked in the creator. "If Custom Collisions is True, then run the new 1.25 function, else, if False, then run "game:evaluate(dt)".

At least, that way, it's a quick fix for people updating their older games that might have been made with poor architecture or are too heavy for the new function.

I'm not a real programmer, so I don't know if it's possible to implement it without causing further lag. Or instead, perhaps from within the creator itself, have it ship out a different set of code based on the "customcollision" boolean, that way, instead of using "else", it will just simple run "game:evaluate(dt)" or the new set of the function based on the export values from the creator itself.

pinkio75

@Hopscotch said:
@pinkio75

your fill rate, or availability of serve-able ads, is dependent on a few things. Here are some:

• the territory of the player. Advertisers favor certain countries, therefore, some countries have very low ad inventory.
• the ad provider tries to match suitable ads to your app. This includes demographic and category. It may be that at certain times the inventory is low for your criteria.
• the performance of you app plays a role over time. This can also cause the ad provider to deliver less, or less attractive, ads to your game.
• some ad providers (not sure about CB) also have a warm up period, where they first gather statistics or trends about your app, before they serve any ads. I promised @GeorgeGS I would "follow up" with him regarding a function to check if a rewarded video is available, before offering the option to a player, now that 1.25 is out.

Also, remember, there is a limit to the amount of RV ads a player gets served per app per day. This is 20 in the case of CB, unless you set the limit even lower.

Honestly i not sure about your reply... i mean with other engines Video Rewards or Interstitials show every time... with GS there are delays limit like ChartBoost Interstitials...

The_Gamesalad_Guru

@pinkio75 said:

@Hopscotch said:
@pinkio75

your fill rate, or availability of serve-able ads, is dependent on a few things. Here are some:

• the territory of the player. Advertisers favor certain countries, therefore, some countries have very low ad inventory.
• the ad provider tries to match suitable ads to your app. This includes demographic and category. It may be that at certain times the inventory is low for your criteria.
• the performance of you app plays a role over time. This can also cause the ad provider to deliver less, or less attractive, ads to your game.
• some ad providers (not sure about CB) also have a warm up period, where they first gather statistics or trends about your app, before they serve any ads. I promised @GeorgeGS I would "follow up" with him regarding a function to check if a rewarded video is available, before offering the option to a player, now that 1.25 is out.

Also, remember, there is a limit to the amount of RV ads a player gets served per app per day. This is 20 in the case of CB, unless you set the limit even lower.

Honestly i not sure about your reply... i mean with other engines Video Rewards or Interstitials show every time... with GS there are delays limit like ChartBoost Interstitials...

Charboost will only give you 20 videos a day period and some regins do not support video ads.

pinkio75

@Lost_Oasis_Games said:

@pinkio75 said:

@Hopscotch said:
@pinkio75

your fill rate, or availability of serve-able ads, is dependent on a few things. Here are some:

• the territory of the player. Advertisers favor certain countries, therefore, some countries have very low ad inventory.
• the ad provider tries to match suitable ads to your app. This includes demographic and category. It may be that at certain times the inventory is low for your criteria.
• the performance of you app plays a role over time. This can also cause the ad provider to deliver less, or less attractive, ads to your game.
• some ad providers (not sure about CB) also have a warm up period, where they first gather statistics or trends about your app, before they serve any ads. I promised @GeorgeGS I would "follow up" with him regarding a function to check if a rewarded video is available, before offering the option to a player, now that 1.25 is out.

Also, remember, there is a limit to the amount of RV ads a player gets served per app per day. This is 20 in the case of CB, unless you set the limit even lower.

Honestly i not sure about your reply... i mean with other engines Video Rewards or Interstitials show every time... with GS there are delays limit like ChartBoost Interstitials...

Charboost will only give you 20 videos a day period and some regins do not support video ads.

Could you please tell me when you've read this information?

The_Gamesalad_Guru

@pinkio75 said:

@Lost_Oasis_Games said:

@pinkio75 said:

@Hopscotch said:
@pinkio75

your fill rate, or availability of serve-able ads, is dependent on a few things. Here are some:

• the territory of the player. Advertisers favor certain countries, therefore, some countries have very low ad inventory.
• the ad provider tries to match suitable ads to your app. This includes demographic and category. It may be that at certain times the inventory is low for your criteria.
• the performance of you app plays a role over time. This can also cause the ad provider to deliver less, or less attractive, ads to your game.
• some ad providers (not sure about CB) also have a warm up period, where they first gather statistics or trends about your app, before they serve any ads. I promised @GeorgeGS I would "follow up" with him regarding a function to check if a rewarded video is available, before offering the option to a player, now that 1.25 is out.

Also, remember, there is a limit to the amount of RV ads a player gets served per app per day. This is 20 in the case of CB, unless you set the limit even lower.

Honestly i not sure about your reply... i mean with other engines Video Rewards or Interstitials show every time... with GS there are delays limit like ChartBoost Interstitials...

Charboost will only give you 20 videos a day period and some regins do not support video ads.

Could you please tell me when you've read this information?

No offense but a quick google search and I found the info. Scroll part way down and you will see it in bold. https://answers.chartboost.com/hc/en-us/articles/201220275-Chartboost-Video

From site

"
The maximum number of rewarded and interstitial video impressions that a user can receive per day, per publishing app is 20."

Hopscotch

@pinkio75 said:
Honestly i not sure about your reply... i mean with other engines Video Rewards or Interstitials show every time... with GS there are delays limit like ChartBoost Interstitials...

When you code it yourself, you cache a video, get confirmation that a video is ready, and only then offer a "Watch Video" button to the user. If they click the option, the video is already to play.

There is not unlimited inventory of rewarded videos, as mentioned above, you will run into situations where there is no video available.

I am not sure about the details of how GS implemented the ad call, but if there is no caching happening, then latency may also cause a video not to show.

pinkio75

don't worry you not offend me but i havent find this info

AlchimiaStudios

@CodeWizard I see. The adaptive system sounds promising. Let me know if you guys need a second project to test on.

I also was wondering about a possibility for 30 fps cap (frame steps at 1/30 for a "low" settings or just divding relevant math by 2.) Not sure how well that would work with the physics engine and the rest of the engine though.

For now i'll work on optimizations and see what I can get. Since were making an RPG there is plenty of terribly inefficient systems in place from the old way of doing custom fonts that I need to gut out, among other things.

pinkio75

@Hopscotch said:

@pinkio75 said:
Honestly i not sure about your reply... i mean with other engines Video Rewards or Interstitials show every time... with GS there are delays limit like ChartBoost Interstitials...

When you code it yourself, you cache a video, get confirmation that a video is ready, and only then offer a "Watch Video" button to the user. If they click the option, the video is already to play.

There is not unlimited inventory of rewarded videos, as mentioned above, you will run into situations where there is no video available.

I am not sure about the details of how GS implemented the ad call, but if there is no caching happening, then latency may also cause a video not to show.

ok how i can show the video rewards button only if this is available? thanks in adv

Hopscotch

@pinkio75 said:
ok how i can show the video rewards button only if this is available? thanks in adv

Good point, this is the crucial question I raised with @GeorgeGS

The_Gamesalad_Guru

@pinkio75 said:

@Hopscotch said:

@pinkio75 said:
Honestly i not sure about your reply... i mean with other engines Video Rewards or Interstitials show every time... with GS there are delays limit like ChartBoost Interstitials...

When you code it yourself, you cache a video, get confirmation that a video is ready, and only then offer a "Watch Video" button to the user. If they click the option, the video is already to play.

There is not unlimited inventory of rewarded videos, as mentioned above, you will run into situations where there is no video available.

I am not sure about the details of how GS implemented the ad call, but if there is no caching happening, then latency may also cause a video not to show.

ok how i can show the video rewards button only if this is available? thanks in adv

You can't that's @Hopscotch 's point

pinkio75

ok thanks guy for these info

jay2dx

Praise the GameSalad GODS finaly this is ours A MASSIVE WELL DONE GS TEAM i knew renewing my GS last month was worth it I had total faith in you guys, rite now back to the pinball JAM! and making, hopefully a great game thank you again guys, and also a MASSIVE thank you to all the beta testers helping out, as an ex sony playstation games tester of 10 years I feel your pain!!!

mshuraih

will we be able to use admob banner and interstitial in the same project or still limited on one of the two

adent42

@Jeffm2 Yes-ish. The way the systems render is a bit different, so you'll likely see some artifact/weirdness in fancier fonts, but custom fonts will render in HTML5.

The other thing to note is that if you're using the "Standard" fonts in the dropdown, those won't save with your file (since GameSalad already has a copy). This means if you're manually uploading games for publishing, they won't work. You'll need to actually use the in tool publishing.

myke66

I am getting much better performance on Android with my game, and all of the odd logic issues seem to be resolved. No bugs to report yet. Windows Creator testing on Droid Trubo

skott

Have anyone tried this new build with OS El Capitan? I'm about to update OS but not sure. Is it working on El Capitan?

Icebox

@skott works well for me ! I dont think there are any problems

skott

@Icebox said:
@skott works well for me ! I dont think there are any problems

Great, i will update

jay2dx

same no problems on el capitan

Nabbo (ReflectiveByte)

@CodeWizard nice work to GS team fixing the shuttering issue.. it seems great but I noticed very few issues.. i will go through my logic and check what's going on..

GeorgeGS

One thing to watch for in 1.25+ is how you spawn actors.

Before 1.25 the code that updates actors would count how many there were and then update that many by their index in the list. The problem with this is spawning a new actor makes that list bigger, so depending on which front/back layer/actor option you use you get different behavior.

For actors spawned behind the current actor (back of layer/actor) the new actor would not be updated until the next frame and it would stop the actor at the front of the layer from being updated that frame.

For actors spawned in front of the current actor the new actor would be updated, would be out of sync with physics, and it would stop the actor at the front of the layer from being updated that frame.

For actors spawned at the front of the layer the new actor would not be updated that frame, but since they are at the end of the list they wouldn't stop other actors from being updated.

If you spawn more than one actor a frame it just makes things more inconsistent.

In 1.25+ all actors that already existed are updated and any new actors are not updated until the next frame to be consistent and keep them in sync with physics.

We tested this in many projects and didn't see any issues, but any spawned actors counting on that first frame update happening immediately might need to be tweaked to make sure their initial state is what you want.

Hopscotch

@GeorgeGS,

In 1.25+ all actors that already existed are updated and any new actors are not updated until the next frame to be consistent and keep them in sync with physics.

do they get drawn to the scene in the frame they get spawned though?
It seems not, and have not seen issues with this yet.