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.

Newcomers AppGameKit Corner / "CreateSprite" Vs. "SetSpriteVisible" - Which Is Faster?

Author
Message
TheFallenAngel
6
Years of Service
User Offline
Joined: 13th Feb 2018
Location: Long Island, New York, United States, Earth
Posted: 19th Feb 2018 00:41
Link
Hi,

Trying to get the game to run acceptably on HTML5.
The engine unfortunately is load once/draw once which is a pain.

We are currently loading(CreateSprite) on-demand the playfield colored boxes.
Would loading all these sprites at game start and then using "SetSpriteVisible" be faster?

We contacted official tech support but they are too busy to look at our current code.
Android performance is impressive, HTML5/WebGL is not...

Jesse
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 19th Feb 2018 00:50 Edited at: 19th Feb 2018 00:52
Link
Generally speaking pooling all of your objects will provide the best performance. There is really no downfall to pooling everything and this is what I have always done since the C64 days because it also is the easiest most logical way to go IMO.

Just figure out the maximum # of objects (sprites, etc) that will ever be needed to be active/visible at any one time and pre-create all of those and turn them invisible.

Of course, it could simply be the sheer number of sprites you are trying to display and update that is the issue. In this case then pre-creating them all will not help because it is simply not possible to have so many sprites active and still hit the target FPS whatever it is that you are shooting for.

Anyway, if you don't mind sharing your code I will test on my machine and then take a look and see if I can find the bottleneck.

Without actually seeing your specific code all anyone can do is give generic guidelines.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
TheFallenAngel
6
Years of Service
User Offline
Joined: 13th Feb 2018
Location: Long Island, New York, United States, Earth
Posted: 19th Feb 2018 00:55
Link
Hi,

Just uploaded the entire project onto GitHub:
https://github.com/FallenAngelSoftware/AppGameKit2-SpaceSwap

Any help you could provide would be appreciated!
Thanks...

Jesse
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 19th Feb 2018 01:57 Edited at: 19th Feb 2018 02:10
Link
I went through the code and best as I can tell the following is what is causing your performance issues:

1. You create every sprite needed for every screen in the game but you do not seem to turn any of them invisible and instead rely on sprite depth to make the current active screen appear on top of everything else.
2. Some functions such as DisplayPlayingScreen( ) are creating new sprites every time it is called.

Based on what I saw I recommend...

1. Set all sprites not used for the current screen to be invisible. Set all sprites initially visible on a given screen to be visible when that screen first displays. This should greatly reduce the number of total sprites that are visible but hidden and not even needed to be visible.

2. Move the code that is creating sprites out of your functions such as DisplayPlayingScreen( ) into your Visuals.agc module so these sprites are also created only one time.

I could have missed something and maybe you actually are turning all of the unneeded sprites invisible but I did not find the SetSpriteVisible api method anywhere in the code. There is a lot of code to dig through but that is the gist of what I got from the time I spent looking at it.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
TheFallenAngel
6
Years of Service
User Offline
Joined: 13th Feb 2018
Location: Long Island, New York, United States, Earth
Posted: 19th Feb 2018 12:16
Link
Hi,

Made the changes you suggested, but the FPS did not improve.
(source code is updated on GitHub)

I do delete all sprites before each new screen at the following line:
https://github.com/FallenAngelSoftware/AppGameKit2-SpaceSwap/blob/master/screens.agc#L54

I am starting to think that good FPS on HTML5 in this game is not possible...
Any other thoughts or suggestions?
Thanks!

Jesse
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 20th Feb 2018 04:49 Edited at: 20th Feb 2018 04:57
Link
The only thing I can suggest is go to your main.agc file and in the select ScreenToDisplay that routes control to the appropriate screen control function comment out the DisplayPlayingScreen() line so it looks like this...



Then create an HTML5 build, turn on your FPS stats and start the game. Yes you should end up with a blank playing screen but the important part is does the fps improve significantly or stay basically the same?

If the FPS stays the same and you don't even have any game logic or sprites active for the playing screen then you know the performance issue has to be caused by some other code some other place that is causing the slow down because you have no code running and no sprites displaying for the actual playing screen.

Honestly, there is just too much code to go through it all and follow all of the processing around. You are very familiar with it since you designed and wrote it all so maybe if this test shows there is something else causing the delay you may know where to look.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 20th Feb 2018 15:54 Edited at: 20th Feb 2018 16:41
Link
I forgot to mention if you have not done it yet make a very simple program with only a main loop that displays the fps. Create an HTML5 build and test that. This way you will know what the limit is on your browser on your computer. This is needed so you have a realistic fps target to shoot for in a full game.

If you can only get 28 fps max with a barebones skeleton program in your browser on your machine then it makes sense you will not hit 30 fps with an actual game in your browser on your computer.

Keep in mind HTML5 is much slower than desktop and slower than most cell phones running mobile games. It is not like the days of dedicated plug-ins such as Flash or the Unity web player. Those could provide near desktop performance. When Unity game engine switched web builds from its Unity Web Player plug-in target to HTML5 performance dropped significantly. It is just the way it is.

Different browsers will run certain portions of the HTML5 faster than others will. And even just a couple of years ago only a few web browsers fully supported it.
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Phaelax
DBPro Master
21
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 21st Feb 2018 12:32 Edited at: 21st Feb 2018 12:35
Link
I assume you actually mean javascript, not HTML 5.

Quote: " It is not like the days of dedicated plug-ins such as Flash or the Unity web player"

Thankfully those days are over! Flash was horrible, even though I jumped on the bandwagon when it first came out too.

SetSpriteVisible will always be faster. The data is already loaded at that point, all you're really doing is telling it whether or not to draw it on screen. CreateSprite doesn't take much time, assuming the image used is already loaded. If not, then the delay depends on how large of an image the sprite has to load. Either way, creating/loading content is slower than just showing/hiding what already exists. And since the majority of y our sprites will probably be loaded altogether at some point anyway, may as well just do it all at the beginning. Memory isn't a rare luxury anymore, but it sounds like your clock cycles are.
Tiled TMX Importer V.2
XML Parser V.2
Base64 Encoder/Decoder
Purple Token - Free online hi-score database
Legend of Zelda

"I like offending people, because I think people who get offended should be offended." - Linus Torvalds
Back to top
Profile PM Email Website
GarBenjamin
AGK Developer
7
Years of Service
User Offline
Joined: 30th Nov 2016
Location: USA
Posted: 21st Feb 2018 21:56 Edited at: 21st Feb 2018 21:57
Link
@TheFallenAngel did you try those 2 experiments?

1. Commenting out the GamePlaying state function call
2. Testing barebones loop showing max fps on your browser on your test machine

Curious what you found. Did the fps improve significantly with the GamePlaying state inactive and only a blank game window or did it stay basically the same?

Did the barebones test show you can achieve 30 fps or not?
TI/994a (BASIC) -> C64 (BASIC/PASCAL/ASM/Others) -> Amiga (AMOS/BLITZ/ASM/C/Gamesmith) -> DOS (C/C++/Allegro) -> Windows (C++/C#/Monkey X/GL Basic/Unity/Others)
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-26 03:54:31
Your offset time is: 2024-04-26 03:54:31