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 / What slows the program down?

Author
Message
gameangel147
6
Years of Service
User Offline
Joined: 2nd Dec 2012
Location:
Posted: 23rd May 2016 02:29
Hi, so I'm migrating over to AppGameKit from DBP, and I can see that this program runs a bit faster. I was wondering what slows this program down?

I just learned how to add more files to a project, and I like to use multiple files to keep code organized, but will just adding another file slow it down? As in will the program waste time accessing another file? Before I used multiple files because one long file seemed to really slow it down, so with AppGameKit, is it better to have one, long file or many, smaller files?

And if I could get a list of everything that slows the program down, so that I can avoid them, that would be appreciated.

One last thing, were Booleans removed in AppGameKit?

Thanks for your time,

-gameangel147
Dybing
8
Years of Service
User Offline
Joined: 12th Sep 2011
Location: Bergen, Norway
Posted: 23rd May 2016 08:18
If you're thinking about having several tabs open - each a different file that you use #include to be part of your program, then no, it won't slow you down. All the files get collated and then compiled together as if it were one big file. I do the same thing, spread my functions out over a plethora of tabs depending on what they do. To keep stuff well organized

I don't know of anything that is particularly slow in AGC - with the possible exception of loading in video-files. How fast or slow your code is, would depend quite a bit on how efficient your code is. As for Booleans, they're not a type in AGK. You have integers, floats and strings. No setting of signed bit or bit-length.
BatVink
Moderator
16
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 23rd May 2016 08:48
If you are coming from DBPro, you can bring your experience of good/bad coding with you. I have found that it is very similar in terms of what performs well and what doesn't. For example, getting an image from the screen is one of the slower processes.
Overall, AppGameKit is more efficient than DBPro. And make sure you check out arrays and types. You can now have arrays in types, and arrays in arrays
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Van B
Moderator
17
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 23rd May 2016 14:04
As far as graphics are concerned, layers of alpha transparency can cause real slowdown, especially on Android devices.

Really though, the answer to 'What slows a program down?' is EVERYTHING! - every command has to be processed and they all take time, so the best way to have a fast program is to have an efficient program. That doesn't mean efficient or convenient for you. In the old days, experienced assembly programmers would sometimes make code as efficient as it could possibly be (within memory restrictions usually). Like if you have 10 distance checks, you would typically make a function and pass the 2 sets of coordinates for example, and SQRT the result and pass it back, that way you only need 1 function, and can call it from anywhere. But that's not what is efficient for your project... the most efficient and fastest way would be to calculate the SQRT for each case, no functions, no passing, parsing or checking of parameters. Of course, that's not really practical for most projects, unless it's there to show how fast things can be... the point is that it's good to be aware of calculations that eat up time, like SQRT, and consider ways of making them faster - do you even need SQRT for everything... Do you need to check distances every single frame... if you only need to check something 1 in 10 frames, then that means that bit of code is 10 times faster.

I mean, sticking with SQRT as an example, you might use that as a check between several enemy sprites, several bullets, the player... the number of checks becomes exponential, if you don't put a leash on it, it will slow your project down... so what else can you use to reduce the checks. These things are not hugely apparent without experience... people often assume that their game is so straightforward that there's no gains to be made in improving internal efficiency - those people did not have to program on 8-Bits and 16-Bits - hell some of the things we had to do just to avoid the slowdown when checking SIN() would make your hair curl

Comparing strings can be slow, it's always good to consider parsing your own arrays and using bytecodes when you can, so instead of having IF Enemy.Name="Pennywise", have IF Enemy.NameID=24, or use a constant (IF Enemy.NameID=#PennyWise). Comparing 2 byte values is quick, comparing text values is slow - especially if you rely on them a lot.

Look for the code that is used hundreds or thousands of times, that's where the meaningful gains can be made - keep recursive function code down to a minimum, try and avoid any IF conditions that you might not need... use the appropriate variable types... break down condition checks - remember that IF A=1 AND B=1 AND C=1 is 3 checks, all 3 are checked even if A=0... if you check A, B and C on separate lines then it can skip past them to the ENDIF instead of parsing them. The more layers of abstraction you're behind, the more impact these things have, and really Tier1 AppGameKit is abstracted a lot.
gameangel147
6
Years of Service
User Offline
Joined: 2nd Dec 2012
Location:
Posted: 24th May 2016 03:33
Thank you guys for all of those answers. They were all helpful and I appreciate it.

My last question for now is: Were booleans removed in AppGameKit?

I tried to declare them but it wasn't recognized, and it feels like overkill using an Integer when all I need is a 1 or a 0 for a flag.
BatVink
Moderator
16
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 24th May 2016 10:22
Quote: "Were booleans removed in AppGameKit?"


Yes. I don't know why but maybe it was related to cross-platform compatibility. Bear in mind that most commands have to work on many platforms.
There are also some raw commands that only work on Windows.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Quidquid latine dictum sit, altum sonatur
TutCity is being rebuilt
Van B
Moderator
17
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 24th May 2016 10:33
Bools might be a good example though. In terms of AppGameKit, processing a single bit might be slower than processing a single byte - because the system would have to go between binary and numeric forms. Maybe best to consider AppGameKit as an interpreted language - and they much prefer to deal in bytes, bytes are efficient for them because it means they just deal with variable ID's, changing a byte variable wouldn't need much internal code - but changing a single bit in a byte variable would need more, and the leftover 7 bits are redundant, so I can see why they might not have been too fussy about dropping Booleans.

A byte uses 8 times as much memory as a bool, theoretically, but I'd be very surprised if any modern programming language actually stored a bool as a bit, they'll be stored as bytes I imagine, so the only benefit in them would be how quickly they can be checked, and that would be about the same as checking a byte.... memory is cheap after all.

Personally, and this is just me - but I hate Booleans... every time I use them I end up needing 1 extra state, usually a transition state, like 0 for false, 1 for true, then 2 for 'set to true', so I can tell when something is being changed for the first time - set enemy death variable to 2, next loop find the 2, set death variable to 1, and spawn lots of blood particles. Even the simplest of examples, GameRunning = true or GameRunning=false.... now pause the game... and you might find using a byte and having a third, fourth etc state helps deal with these things logically. I would set constants or globals for True=1, False=0 etc, and use that instead, it gives you full control that way.... Transition=2, Null=255... whatever you need, might need, don't know you need yet, can be added easily.
gameangel147
6
Years of Service
User Offline
Joined: 2nd Dec 2012
Location:
Posted: 27th May 2016 01:29
I never thought about it like that. I suppose have more than just two states for a variables can come in real handy.

Thanks again you two, you've helped me a lot.
hakimfullmetal
4
Years of Service
User Offline
Joined: 17th Feb 2015
Location:
Posted: 28th May 2016 08:18 Edited at: 28th May 2016 08:18
In DBPro, the performance killer that I found:
- TEXT and PRINT commands are real performance killer.
- When you have object number >1000, any object-creating command after 1000 will slow the program down
- Any networking command
Glad to hear nobody found anything similar to these in AGK.

Or is there?

Login to post a reply

Server time is: 2019-11-17 20:59:31
Your offset time is: 2019-11-17 20:59:31