• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

What is faster?

G

gamedev513

Guest
Hey everyone,

Which of the following would be more efficient with respect to FPS and game speed and/or memory?
A) Creating a surface and drawing a single large background tile (i.e. background image 640 x 180)
B) Creating a surface and drawing multiple tiles to fill background (i.e. background image of 25 x 180)
C) Just draw the single background to the room via draw_background() code within the Draw event of an object.

Thanks!
 

Yal

🐧 *penguin noises*
GMC Elder
Definitely C. Still one draw call like in A, which is faster, plus you get no dynamic resource creation overhead and use less VRAM.
 
A

amusudan

Guest
Definitely C. Still one draw call like in A, which is faster, plus you get no dynamic resource creation overhead and use less VRAM.
Thanks for clarifying that, as I was not 100% sure :)
 

Yal

🐧 *penguin noises*
GMC Elder
You said "with a grain of salt," if you know davve from the old GMC forums him and I were talking yesterday and he used that term so. Ok :p
It's actually not a Swedish term - it's an English one.
upload_2016-7-20_23-59-26.png
We didn't have access to native salt sources in old times since the Baltic Sea has naturally sweet water and there are no deserts in Sweden, so the expression is imported... and we exclusively use the 'pinch' variety. (A purely Swedish idoim would be "One taketh what one hav'th, said Caisa Warg", a satirical remark about a celebrity chef we had a few hundred years ago)


Anyway, we have already strayed too far off-topic, and I'm neither going to promote nor tolerate taking the topic of my language any further...
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Why not TEST them and find out? I mean, it's not a tough thing to test, it would improve your understanding of how GMS works, and you might actually learn something? There is a debug module for a reason... seriously accepting someone else's word for something you can quickly and easily check strikes me as lazy. So, why not test your proposed solutions and then you tell us which is better? ;)
 
G

gamedev513

Guest
Good point...I did test them all out however they all seem to be fairly equal (i.e., in regards to FPS and memory usage). Logically though, I figured it would require less memory for the game to render a single draw_background versus drawing multiple tiles on a surface. I could be totally wrong though.
 

Hyomoto

Member
As far as I can tell, the logic and math used to draw something to the screen take longer than the draw calls themselves. I've been working on a tiling engine for my own amusement and when it comes to drawing 10,000 tiles to the screen, the repeat loops and position math take about ten times longer than the draw calls. So honestly, when it comes to speed, your background call probably won't turn out to be a valuable well to tap for savings, even if it's wildly inefficient. If anything, you can make more headway caching results and simplifying equations. When it comes to memory, if that turns out to be an issue you'd also make more headway using a lower resolution background than finding new ways to draw it. The biggest source of inefficiency would be having an image larger than the texture page it resides on since it would have to stitch it together when drawing.
 
G

gamedev513

Guest
As far as I can tell, the logic and math used to draw something to the screen take longer than the draw calls themselves. I've been working on a tiling engine for my own amusement and when it comes to drawing 10,000 tiles to the screen, the repeat loops and position math take about ten times longer than the draw calls. So honestly, when it comes to speed, your background call probably won't turn out to be a valuable well to tap for savings, even if it's wildly inefficient. If anything, you can make more headway caching results and simplifying equations. When it comes to memory, if that turns out to be an issue you'd also make more headway using a lower resolution background than finding new ways to draw it. The biggest source of inefficiency would be having an image larger than the texture page it resides on since it would have to stitch it together when drawing.

Thanks for the advice. I do agree with what you're saying. I will give it a shot
 
Top