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 / [SOLVED] How fast ?

Author
Message
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 6th Jul 2020 07:30
What would be faster on the draw calls?

3 rendertoimage which covers the entire screen?
Aka 3 sprites which renders 60 sprites into it and not cleaning them only if needed
Or lets say 60 "pure" sprites?
Nadav "Haliop" Rosenberg
Lets make the world great forever.

The author of this post has marked a post as an answer.

Go to answer

Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 6th Jul 2020 11:06
Try it and see.
Let us all know your results.
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 6th Jul 2020 13:02
Yeah will do. Thought maybe someone already done so.
Nadav "Haliop" Rosenberg
Lets make the world great forever.
janbo
15
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 6th Jul 2020 16:13
My guess is, If the 3 sprites need transparency they will be slower than just drawing 60 sprites.
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 6th Jul 2020 17:21
Ok, but what about
Calling only 3 sprites each time to draw.

Rather then 60 calls?

Nadav "Haliop" Rosenberg
Lets make the world great forever.
Scraggle
Moderator
20
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 6th Jul 2020 21:38
I refer you to my previous post.

You asked the question 14 hours ago and still have no answer. It would take two minutes to do the check yourself.
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 7th Jul 2020 09:56 Edited at: 7th Jul 2020 10:10
This post has been marked by the post author as the answer.
Edit : Real time 20100 sprites in classic : 10fps.
3 rendered images classic: 270- 300 fps.

Studio , 20100 rt sprites : 60-80 fps.
3 RENDERED IMAGES : 270 - 300 FPS.

Ok so i made the test.

20100 sprites with alpha, concludes in 10 fps on my machine.

20100 sprites (the same) rendered into 3 render images concludes in 278 fps.

Yep, was right thinking of it.

As it has the same principle as mentioned the other day in the Particle Editor thread.

If you set a one million cloud particle into one particle emitter you will get more draw calls then just one sprite that cover the screen and just represent the animation of million cloud particles "baked" into a sprite sheet or even individual high res images but presented in only one sprite.

So Draw Calls Matters.

Project is attached it is very simple.

Scruggle, a thought, of a simple inBox agk feature for this method for all static sprites, 3D objects in screen, with a few commands to.turn it on or.off , will increase everyone FPS.

Really, 10 fps to 300 fps. (Just for static stuff) once it gets dynamic, then you need to draw that dynamic sprite over and over every frame. How ever, if for example there id an elaborate menu that only one button gets dynamic if toy hover or touch it, you will sure to save a decent amount of drawingTime and battery where it comes to Mobile devices. Which will.let you make alot of other stuff in the app or.in general.


Think of it as LOD to huge enviorments, as long as the player camera view did.not change so.much, the entire scenery can be loaded once then use a "sprite" or."quad"
Instead of.making all the trees to Card Board the entire scene in the distance can be carboarded. This could also lead to some kind of tesselation even for 2d stuff, as a simple render to image function can change its rendering resolution. Making a fake res tesselation for all 2D stuff and 3D also...
Nadav "Haliop" Rosenberg
Lets make the world great forever.
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 7th Jul 2020 09:56 Edited at: 7th Jul 2020 10:18
Project Video.

Edit: Video attached.

https://youtu.be/OP9VGhc_25A



Nadav "Haliop" Rosenberg
Lets make the world great forever.
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 8th Jul 2020 05:47 Edited at: 8th Jul 2020 05:49
I just saw this. Yeah in my retro game fantasy computer framework I handle the tiles for the tilemaps using this same method.
There can be 3 layers and each layer in 256x144 resolution needs 627 8x8 sprites (576 to cover screen but need extra row and col to support scrolling).
Instead of having 1,881 sprites on screen just for the map layers I thought it just made sense to prerender to layer images and then use only 3 sprites to display them all.
Of course, also being sure your sprites are using the same imagesheet reduces your draw calls but in this case (yours and mine) .

I tried to optimize the framework with drawcalls and such in mind.
This is from the sample game project... 3 tile map layers... in this case they are 16x16 tiles so would take 170 sprites per layer (supporting scrolling) x 3 layers = 510 sprites.
And then Another 40 or 50 sprites for the stats at top, player, enemies, missiles, etc. So roughly 550+ sprites would be needed.
Instead the map layers end up being 3 full screen sprites, the back layer is set to opaque.

And the total SpriteDrawCalls is only 7.


I am just sharing this info to say it seems to work very well doing things this way. I have made a few different game projects now in the framework and even in html5 they run well on my laptop anyway.
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 9th Jul 2020 04:47
Yeah i love this approach.
It is awesome.

I have actually tried it a few years ago but in 3d with grass objects.

I made some land and i really wanted it to be extremely grassy so i have added about 100000 grass, plants, etc objects on to that land and rendered them from back to front in a few layers. And as long as i did not moved the camera, i got solid fps, for 100000 high res randomised plants and grass .

In 3D is much a problem cause of camera. But in 2D it should not be a problem and should save tons of battery for mobile gaming.

And now you mentioned HTML5 and that is really incredible .
Nadav "Haliop" Rosenberg
Lets make the world great forever.
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 9th Jul 2020 09:28
1. GetImage is the slowest command of them all.
2. When you use renderToImage you do not need Sync() after it you need it only once and the main loop (preferably at the -1 line of your loop)
3. We are basically talking about "static sprites" such as tiles for 2d landscape or clouds in the background that does not move at all, or maybe a chest of treasure where until the player does not open it, it has no self animation.

So lets say you have one hundred clouds at your scenery which are not "self" moving at all, you have 100 draw calls for each cloud.
But if you draw all the clouds at startup with render to image, then you cab use one big sprite for all of those clouds then you can one delete those cloud sprites or just hide them.

But static is not fun right?
So why not divide those 100 cloud sprites into some render to images ?

Then you tween those renderToImage sprites.
So you now for the example have 20 clouds on each renderImage Sprite, one is moving a bit right, one is moving a bit up others to other direction which will simulate moving clouds and prefred to be used with AppGameKit built on tweens.

So now, you have only 5 draw calls instead of 100 draw calls.

You need to think what you are going to use it.
For example for a player character with animation it wont reduce the draw calls, because it probably have some animations. And you need to draw it every animation frame. But if you have like 100 characters that are just the crowd like in Street Fighter (search for it if you dont know it) , these crowd characters are positioned in the same place and do not move however they do have animations each with its own individual animation but it is just crowd it has no interference in any kind with your game. There for instead of 100 crowd characters each with 30 frames of animations, you can render to image all of them for 30 times, each render to image is a frame of animation, then you get 1 sprite , 1 draw call, but, the frame of it is different every timeToAnimation you choose.


So the first option with clouds, 100 clouds sprites, is drawn only 5 times per frame.

And the Crowds are one draw call for 100 character
Where SetSpriteImage(crowdSprite,CrowdRenders[currentCrowdAnim] is placed in every frame, while you cycle the animations with inc currentCrowdAnim and when it gets to the last animation frame you start over with a simple if statement.
Nadav "Haliop" Rosenberg
Lets make the world great forever.
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 9th Jul 2020 12:37 Edited at: 9th Jul 2020 12:37
Exactly. You can draw all the tiles into one big image then draw only it.

And scroll it rather then the tiles.

Edit: would be nice to know how much fps gained on your app by doing so.
Nadav "Haliop" Rosenberg
Lets make the world great forever.
haliop787
4
Years of Service
User Offline
Joined: 22nd Mar 2020
Playing: With reality.
Posted: 9th Jul 2020 19:46
Cool. How much was it without it ?
Nadav "Haliop" Rosenberg
Lets make the world great forever.

Login to post a reply

Server time is: 2024-04-19 06:34:43
Your offset time is: 2024-04-19 06:34:43