Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Studio Chat / Optimization Tips i have found in my years of coding.

Author
Message
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 27th Jul 2020 07:44 Edited at: 6th Aug 2020 21:37
Link
Edit: this was miss understood, let me show you 2 videos of the first snippet presented here.

Normal


Simple method that everyone can use to create some madness and fun. With 3-4 lines of code.



From time to time ill upload a little code snippet that just makes everything runs faster with that lowering battery consumption.

I would really appreciate if forum knights will share their own code optimizations i think members will enjoy this. And also create a small game "Optimize it" not for the glory but for thinking out of the box to make code more efficient and clean.

But if we would think of points received from achieving goals and faster frame rate for the exact same OnScreen result. I would actually start at 100 points and try to keep it rather then counting from 0 to top.

So, a few years ago o have found a neat way to manipulate memblocks by one pixel at a time, then i moved to 2 , 4, 8 , 16 and so on... Eventually i got to a point where 1000 memblock images are running on the same 3D plane in just matter of seconds.

It makes you think how much of "good" architecture can manipulate the tools you already own in order to jump or lead a head of competition that said with the same tools the competition uses.

It is a fun and exciting journey to achieve something you can achieve in a simplier way but make it better so from that point on it will always be better.

So for the first snippet :
"How will i make everything faster in the simplest matter"

You have a game.
You have everything set, its all good, everything works.
And it runs on decent 60 fps.
But battery consumption is a bit much.

What will you do?
The....
Simple Sync Counter.


A simple.sync counter makes any game no matter the kind, to swallow.less battery on any mobile device and can work for any "Stable" Fps chosen by developer or user.




Thats it.

So the game is set to 60 fps.
But it actually draws in to screen once every 2 loop cycles.
So you dont really get 60 fps you actually get a fake 30/60 fps.

And everything is extremlly faster yet battery consumption is half way down.

What!?
Try It and see for yourself
Btw, if you use tweens make sure to correct them to drawTime etc.
Nadav "Haliop" Rosenberg
Lets make the world great forever.
Back to top
Profile PM
PSY
Developer
7
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 27th Jul 2020 14:32
Link
So the sync rate is set to 60, but you sync only every 2 loops.
Why not set the sync rate to 30 in the first place? Everything will look the same, and the game will even draws less power compared to your method.




PSY LABS Games
Coders don't die, they just gosub without return
Back to top
Profile PM Website
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 27th Jul 2020 16:09
Link
Maybe this post should be called “Crazy coding ideas to avoid”?
Back to top
Profile PM Email
hendron
8
Years of Service
User Offline
Joined: 20th Dec 2015
Location:
Posted: 27th Jul 2020 17:00 Edited at: 27th Jul 2020 17:01
Link
Quote: "So the game is set to 60 fps.
But it actually draws in to screen once every 2 loop cycles.
So you dont really get 60 fps you actually get a fake 30/60 fps."


That's incorrect. Setting your sync rate to 60 does not limit your loop speed to 60 times per second unless you actually call Sync() every loop cycle. Your snippet is updating your game logic twice every frame (so effectively 120 times per second if your sync rate is set to 60), which I would think would use more battery power, not less.
Back to top
Profile PM
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 27th Jul 2020 17:13
Link
So.
Haha thats funny.
But still all of your gpu shader stuff runs on 60 fps while drawing on fake 30 that is why it seams that everything is faster more reliable to use cross platform, so reducing the the amount of time to redraw to screen it is like not cleaning your screen yet running on higher frame rate.

You get the results of animation running smoother than if it was running on 30 fps and still it actually saves you battery and time to process.

You get smoother logic , gravity (wierd stuff there) and physics in general.

Really you should try it.

What if on pc you would setSyncRate(0.0,0)
But you set the CounterTimes to 10.

So you get 500 fps but show It on 50 fps. Its a good technic for rendering stuff .
And you can always decide to increase the timesCounter making the scene you are in much more intense like a "fps garbage from the screen" made out of the blink effect of lowering and increasing the syncCounterTimes.

Sorry this was miss understood and simplified.
Nadav "Haliop" Rosenberg
Lets make the world great forever.
Back to top
Profile PM
Jack
19
Years of Service
User Offline
Joined: 4th Oct 2004
Location: [Germany]
Posted: 27th Jul 2020 17:39
Link
But I have two computers, a new one and an old one.
But the virtual software is running with diffrent speeds on both machines unless you use a timer based approch

Back to top
Profile PM Email Website
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 27th Jul 2020 17:53
Link
Its always time based approach as you want it cross platform.

So physics times.based, is running on 60 fps but showing them on 30 and you can play with it.

Its a really unique trick.

As mentioned above the idea of it running at 120 instead of 60 is missunderstood cause it is time based, maybe the tweens and physics are acting like 120 or double the fps, which is not really right and not really wrong.

So lets say its like "Smoothing" effect, where logic runs faster then drawing it to screen.

No matter what you use sync or render , its not to fasten the tween but to smooth their transitions.

Higher Fps physics shown on lesser FPS made cross platform easier in order to keep things smooth. Cause if i draw every 60 fps, the actually rendering has a high usage of the cpu..

I might not explaining it well , i would not posted with out some testing, ...
Nadav "Haliop" Rosenberg
Lets make the world great forever.
Back to top
Profile PM
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 27th Jul 2020 19:37 Edited at: 27th Jul 2020 19:52
Link
While, this is based on the experience you made with your games and devices, It's not the best solution or could even make thinks even harder to debug and getting the right speed of sprites, objects or animations.
If you put a print(str(ScreenFPS())) into the loop you see its still draws with 60 fps but executes the stuff outside of the if statement more than once...
I guess you actually want to incorporate GetFrameTime() into your speed calculations to Make stuff the exact same speed on different devices...like jack mentioned.

Don't be disappointed, but take this positive.
Post more and we will help you out if needed
Back to top
Profile PM Email Website
PSY
Developer
7
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 27th Jul 2020 19:54 Edited at: 27th Jul 2020 19:58
Link
I used a similar trick once in a Particle System.
The particles would only be processed every 2nd frame, so the particle calculation and rendering wouldn't slow down the main code too much, depending on the hardware.

BUT ofc, it didn't smoothen anything at all. Quite the contrary.
When your code runs at 60fps, and you render each frame, everything is smooth.
When your code runs at 60fps, and you only render every 2nd frame, everything is half as smooth, because you have to maintain the speed, but instead of moving a sprite say 1 pixel, you have to move it 2 pixels, because you only have half the frames for rendering.

Your code can't smoothen anything, because you have LESS FRAMES for rendering. It's as simple as that. More frames means your objects, sprites etc can be rendered at more positions within a given time frame, resulting in a smoother movement.

NEVERTHELESS, your code is useful when you need massive calculations without having to maintain a high fps rate for rendering, like a chess game.
Your logic runs at full fps, while the rendering is only done at like 15 fps, so the logis isn't slowed down.


About battery consumption:
Running logic at 60fps and rendering at 30fps sure consumes more power than running everything at 30fps.
And 30 rendering fps are 30 rendering fps. There's nothing more or less smooth, no matter how fast the logic runs.
You have to move objects from A to B and you have 30 frames per second to do so. Period.

(edit) As Janbo already mentioned, please take this as constructive feedback. There are many situations where your code can be useful!

PSY


PSY LABS Games
Coders don't die, they just gosub without return
Back to top
Profile PM Website
basicFanatic
6
Years of Service
User Offline
Joined: 7th Jun 2017
Location:
Posted: 28th Jul 2020 00:52 Edited at: 28th Jul 2020 00:52
Link
PSY wrote: "Your code can't smoothen anything, because you have LESS FRAMES for rendering. It's as simple as that."


I don't know if that's true, actually. I mean, the extra calculation could keep a bullet from "jumping over" an object that was supposed to stop it.

I don't know the digital mechanics a play when we move stuff about in AGK. But generally, I would think that the more cycles per second, the more precise the simulation.
Back to top
Profile PM
blink0k
Moderator
11
Years of Service
User Offline
Joined: 22nd Feb 2013
Location: the land of oz
Posted: 28th Jul 2020 01:26
Link
1. From @Santiago : Use a simple mesh for shadows

2. When creating sprites/objects for groups make the id a fixed value prefixed by a number that identifies the type.
So when creating NPC sprites you could make their id's 3000, 3001, 3002 etc. Then use the (id-3000) as an index into the array that stores NPC data so you don't have to do table lookups

3. Always pass arrays/types by ref
Back to top
Profile PM
basicFanatic
6
Years of Service
User Offline
Joined: 7th Jun 2017
Location:
Posted: 28th Jul 2020 11:10 Edited at: 28th Jul 2020 11:28
Link
My game A Dream of Amber runs at setVsync(1) for the fast-paced gameplay, but uses SetSyncRate( 12, 0 ) for the menu.
Back to top
Profile PM
PSY
Developer
7
Years of Service
User Offline
Joined: 3rd Jul 2016
Location: Laniakea Supercluster
Posted: 29th Jul 2020 21:09
Link
Quote: "I don't know if that's true, actually. I mean, the extra calculation could keep a bullet from "jumping over" an object that was supposed to stop it.
I don't know the digital mechanics a play when we move stuff about in AGK. But generally, I would think that the more cycles per second, the more precise the simulation."


Sorry, I didn't express myself very clearly.
I was talking only about actual GFX.
With physics, you're right when it comes to glitching through objects etc.







PSY LABS Games
Coders don't die, they just gosub without return
Back to top
Profile PM Website
Back to top

Login to post a reply

Server time is: 2024-04-19 09:08:11
Your offset time is: 2024-04-19 09:08:11