Benxamix2
|
|
Posted on: May 04, 2014, 09:18:40 pm |
|
|
Location: Chile Joined: Mar 2012
Posts: 69
|
Hello there, guys. I have a question regarding the ENIGMA funcionality about graphics.
If you find any leak of information, please advice me. For I'm what I have learned from experience and not reading books, I may be wrong in many, many ways...
You see, I've noticed that when you go into a sprite/background properties, there's an indicator called "Memory", next to "Zoom" and "Height". I want to figure out what does it really mean, and what's its impact in the use of computer resources. From deduction, I'm thinking this refers to the amount of video memory usage done by that one graphical resource.
This should tell me that the best method to save VRAM is to avoid huge images. In the case of backgrounds; trying to use tile-able ones (this is my current). For instance, the least video memory-consuming background (besides single colors) would be a 1px-wide gradient. However, repeating the background drawing "screen-width" times should have a negative effect in the processor side; more operations per second.
There's this other method, which would be using more hard drive space and video memory, but as I'm concerned using less processor as well. It's the background image being as big as the screen size. It only needs to be drawn once per frame, but it would relay on more video memory, since it needs to be allocated for a fast read.
These are my conclusions. Can you tell me if I'm right about all of this? Is it really a good idea to keep my backgrounds as reducted as possible? Thanks in advance.
|
|
|
Logged
|
|
|
|
TheExDeus
|
|
Reply #1 Posted on: May 05, 2014, 06:13:30 am |
|
|
Joined: Apr 2008
Posts: 1860
|
However, repeating the background drawing "screen-width" times should have a negative effect in the processor side; more operations per second. You don't need to "repeat" it. If it's a 1px gradient, then you can scale it. Like: draw_sprite_ext(spr_gradient,0,0,0,1,room_height,0,c_white); This will basically stretch your 1px wide gradient to fill the screen in horizontal direction. CPU wise it's not very intensive and the whole rendering is done on GPU, which it's good at. So that is the fastest way to draw a sprite gradient. You could also use draw_rectangle_color() to draw a gradient and it will be even faster (as it doesn't use a texture). These are my conclusions. Can you tell me if I'm right about all of this? Is it really a good idea to keep my backgrounds as reducted as possible? Yes, but only to a point. GPU memory won't really slow you down unless you exceed it. Today you can think minimum 1GB with average of about 1.5GB. With these resources it's not really smart to trying to fit everything in 32x32 pixels. And you are right on how the tiling function now works. GPU's can tile power-of-two textures easily and without any slowdowns or overhead, but sadly backgrounds and sprites can be in any size. So the tiling functions (e.g. draw_backgound_tiled) calculates how many tiles are needed and then "draws" them. This means CPU has a lot more work, but then we can tile images of any size. Rendering is still very fast as that function uses batching - all the tiles are drawn at once. CPU impact is also actually very small compared to any other thing you could do at the same time, so I wouldn't worry about that. So I think you should easily use up to 1024x1024 textures as often as you want. No need to use very small images. Especially when we still don't have texture atlas. Texture atlas is a texture with all your sprites on it. So if you have 10 32x32 sprites, then they would be packed into one 256x64 texture (or something similar in power-of-two size). This means when you render the engine doesn't have to switch textures and break batching (which is slow). We sadly still don't have that as that would require many changes no one is willing to do now.
|
|
|
Logged
|
|
|
|
Goombert
|
|
Reply #2 Posted on: May 05, 2014, 07:59:53 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Yes what Harri said, you are pretty much entirely correct in your understanding Ben.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
|
Goombert
|
|
Reply #5 Posted on: May 07, 2014, 02:01:44 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
I have not paid for that, no.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
|
Goombert
|
|
Reply #8 Posted on: May 10, 2014, 01:34:09 am |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Yes that is correct, but it will not do the default drawing I think it checks to see if the sprite_index sprite placed at x and y fits in the room, but if you add your own draw code it will draw it always.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
|
|
|
Goombert
|
|
Reply #12 Posted on: May 10, 2014, 05:14:44 pm |
|
|
Location: Cappuccino, CA Joined: Jan 2013
Posts: 2993
|
Yes Ben, only when you add the draw event code yourself, and when visible is checked.
|
|
|
Logged
|
I think it was Leonardo da Vinci who once said something along the lines of "If you build the robots, they will make games." or something to that effect.
|
|
|
TheExDeus
|
|
Reply #13 Posted on: May 10, 2014, 07:27:03 pm |
|
|
Joined: Apr 2008
Posts: 1860
|
Is that draw event triggered anytime, even outside the boundaries of the screen? Yes, draw event is triggered always. That is because you can draw anywhere inside the draw event no matter where the instance is located. Like you could put "x = y = -100;" (so it's outside the room), but still draw_sprite(spr,0,10,10) (so draw it 10,10). That is why we cannot optimize that. If you use the default draw event, then we could technically take sprite into account and not draw that, but that is also not done now (I think). It's possible any performance gains would be minimal (the only advantage would be possibly less texture switching as we don't have a texture atlas). But if you draw sprites only at instance positions, then you can use things like instance deactivation to not render things outside view.
|
|
|
Logged
|
|
|
|
|