Layer Optimizing Chat
- Thread starter O Ilusionista
- Start date
Damon Caskey
It sends me to another question. Is CPU intensive no matter how much pixels are using the transparent color, or it grows according to how much transparent area the image has? And it's related to the distance between the last pixel and the image border only (red)?
Because some layers will have a lot of transparent area even if the image is trimmed, same as the image below.
It's very good to know, thanks for the info.
It sends me to another question. Is CPU intensive no matter how much pixels are using the transparent color, or it grows according to how much transparent area the image has? And it's related to the distance between the last pixel and the image border only (red)?
Because some layers will have a lot of transparent area even if the image is trimmed, same as the image below.
Kratus,
Pretty much any time an engine (not just OpenBOR) has to handle transparent pixels, it's more CPU intensive than opaque. This is why sprites are always trimmed so close. It's not something you should design your entire level around, but when there's an opportunity to shave something for free, then always do it. In your example, the red area is a must trim. It's not doing anything but wasting CPU power. The green area uses power too, but it's part of the image design, so no big deal.
That said, if I were really trying to wring every last drop of performance out, I'd probably break everything down like this:
Then put them all back as independent layers. You lose some CPU for the layers, but get it right back and a little extra by taking out all that transparent area. Bonus, the memory footprint drops from ~65KB to ~7KB. Double bonus, now you can tinker with the scroll rates to give your level much more depth. I was going to suggest you at least made the parked cars a layer before you asked your question.
DC
Pretty much any time an engine (not just OpenBOR) has to handle transparent pixels, it's more CPU intensive than opaque. This is why sprites are always trimmed so close. It's not something you should design your entire level around, but when there's an opportunity to shave something for free, then always do it. In your example, the red area is a must trim. It's not doing anything but wasting CPU power. The green area uses power too, but it's part of the image design, so no big deal.
That said, if I were really trying to wring every last drop of performance out, I'd probably break everything down like this:
Then put them all back as independent layers. You lose some CPU for the layers, but get it right back and a little extra by taking out all that transparent area. Bonus, the memory footprint drops from ~65KB to ~7KB. Double bonus, now you can tinker with the scroll rates to give your level much more depth. I was going to suggest you at least made the parked cars a layer before you asked your question.
DC
Very good, I'm trying to reduce memory/cpu consumption and your suggestion will help me a lot, I have a ton of non-trimmed images and I will revise all them. Thanks buddyDamon Caskey said:Kratus,
Pretty much any time an engine (not just OpenBOR) has to handle transparent pixels, it's more CPU intensive than opaque. This is why sprites are always trimmed so close. It's not something you should design your entire level around, but when there's an opportunity to shave something for free, then always do it.
Incorrect portion scrubbed by DC: See correction in discussion below.
That said, if I were really trying to wring every last drop of performance out, I'd probably break everything down like this:
Then put them all back as independent layers. You lose some CPU for the layers, but get it right back and a little extra by taking out all that transparent area. Bonus, the memory footprint drops from ~65KB to ~7KB. Double bonus, now you can tinker with the scroll rates to give your level much more depth. I was going to suggest you at least made the parked cars a layer before you asked your question.
DC
I dont know about these theories but when i tested it in practice - size of fglayers with alpha transparenty doesnt matter as much and they eat fps like sumo wrestlers their noodles so theyre the best way to test how fps drops with small changes to their size and amount.
I cut 3 fglayers to be half width from 100%, yet they still slowdown game like if they were 100% size and it did not improve anything.So... conclusion is cutting width wont save you much cpu power.
Unless tested and proved in some demo, id take some trim suggestions with a grain of salt.
But.. amount of fglayers with alpha transparency - that takes a hit, i can have 3, maximum 4-5 when games become unplayable and skips frames so its like 15-20fps at times.Their size dont matter much, happens even with smaller ones.Thats why i suspect alpha and fglayer code is leaking memory.
Whats weird is that it drops frame on dualcore 3.0ghz with the same amount of fglayers as on android with octacore 1.8 which is more powerful.
So you can trim every sprite in library of thousands to save some minimal cpu cycles, but you throw one fglayer with alpha fx and its all thrown out anyway.
You just have to know what to use and whats more taxing, maybe its better to use something else, im using fglayer with alphafx when i have no other choice.
More wasteful things are updatescripts that check too many things at once.Simple transparent colors without alpha effects arent big deal , sure you can trim them just to be satisfied that you did whatever you could to save that cpu cycle but there are other things in engine that will kill the fps lot quicker.
I cut 3 fglayers to be half width from 100%, yet they still slowdown game like if they were 100% size and it did not improve anything.So... conclusion is cutting width wont save you much cpu power.
Unless tested and proved in some demo, id take some trim suggestions with a grain of salt.
But.. amount of fglayers with alpha transparency - that takes a hit, i can have 3, maximum 4-5 when games become unplayable and skips frames so its like 15-20fps at times.Their size dont matter much, happens even with smaller ones.Thats why i suspect alpha and fglayer code is leaking memory.
Whats weird is that it drops frame on dualcore 3.0ghz with the same amount of fglayers as on android with octacore 1.8 which is more powerful.
So you can trim every sprite in library of thousands to save some minimal cpu cycles, but you throw one fglayer with alpha fx and its all thrown out anyway.
You just have to know what to use and whats more taxing, maybe its better to use something else, im using fglayer with alphafx when i have no other choice.
More wasteful things are updatescripts that check too many things at once.Simple transparent colors without alpha effects arent big deal , sure you can trim them just to be satisfied that you did whatever you could to save that cpu cycle but there are other things in engine that will kill the fps lot quicker.
...Splitting of derail from original discussion: ...
All,
First I have to eat some crow. Went back and had another look at the loading routine for levels. I was 100% dead wrong when I said OpenBOR does not trim level layers. Layers are auto trimmed on load just like model sprites. All I can do is apologize for the mistake. What's worse, some of it is my code... derp. Mea culpa.
However, I also 100% stand by transparent pixels being CPU intensive. This isn't some theory I pulled out of my butt. It is absolute fact that transparent pixels cost more power than opaque pixels, no matter what engine you use. You can look this up in any peer reviewed computational reference and verify it with unit tests. Incidentally, I've done the later extensively due to my love of lots and lots of layers and experiments with 3D levels for Lucia's Run. It's not a huge amount, but it can add up quickly depending on your design. Blended pixels like bWWd mentioned are more expensive still, but that's an entirely different discussion.
In practical terms, this means the following (using Kratus level design):
The red area is totally immaterial. OpenBOR will optimize that away as level loads up. The green area is another matter. This image has huge areas of concurrent transparency pixels the engine can't remove on its own. Those cost CPU resources that you can eliminate with minimal effort. Is it worth it? That's just going to depend on design. If it was something like a dither pattern or chain link fence then obviously not. But in this example, I would say yes. You can significantly reduce your CPU cost, your memory footprint, and give yourself more design freedom (scrolling layers) all at once. Why wouldn't you do it?
nsw25
Offsets exist on every frame no matter what, but that's a moot point. Individuality trimming sprites for model frames is always a waste of time. The engine does that for you.
DC
All,
First I have to eat some crow. Went back and had another look at the loading routine for levels. I was 100% dead wrong when I said OpenBOR does not trim level layers. Layers are auto trimmed on load just like model sprites. All I can do is apologize for the mistake. What's worse, some of it is my code... derp. Mea culpa.
However, I also 100% stand by transparent pixels being CPU intensive. This isn't some theory I pulled out of my butt. It is absolute fact that transparent pixels cost more power than opaque pixels, no matter what engine you use. You can look this up in any peer reviewed computational reference and verify it with unit tests. Incidentally, I've done the later extensively due to my love of lots and lots of layers and experiments with 3D levels for Lucia's Run. It's not a huge amount, but it can add up quickly depending on your design. Blended pixels like bWWd mentioned are more expensive still, but that's an entirely different discussion.
In practical terms, this means the following (using Kratus level design):
The red area is totally immaterial. OpenBOR will optimize that away as level loads up. The green area is another matter. This image has huge areas of concurrent transparency pixels the engine can't remove on its own. Those cost CPU resources that you can eliminate with minimal effort. Is it worth it? That's just going to depend on design. If it was something like a dither pattern or chain link fence then obviously not. But in this example, I would say yes. You can significantly reduce your CPU cost, your memory footprint, and give yourself more design freedom (scrolling layers) all at once. Why wouldn't you do it?
nsw25
Offsets exist on every frame no matter what, but that's a moot point. Individuality trimming sprites for model frames is always a waste of time. The engine does that for you.
DC
O Ilusionista
Captain 100K
Thanks for the info. It would be weird if the engine trims all the sprites, minus the stage layers.
The only time I noticed a performance drop with an stage was when I used a 5000px long image with water raster effects.
Cutting each part would be the best idea - its what we do in Mugen, for example - But thanks to how stages graphics are displayed, it could be more complicated to do.
A trick we often do in mugen is to make a image at the same size of the whole stage and then trim it on FFS (which fix the offset for you).
In OpenBOR terms, it would be something like having all fglayers at the same position - with each part on a different image - and let the engine trim it.
So you won't need to care about the axis position, just the Z.
The only time I noticed a performance drop with an stage was when I used a 5000px long image with water raster effects.
Cutting each part would be the best idea - its what we do in Mugen, for example - But thanks to how stages graphics are displayed, it could be more complicated to do.
A trick we often do in mugen is to make a image at the same size of the whole stage and then trim it on FFS (which fix the offset for you).
In OpenBOR terms, it would be something like having all fglayers at the same position - with each part on a different image - and let the engine trim it.
So you won't need to care about the axis position, just the Z.
I remember fglayer code was buggy when kbandressen implemented it and he had to do some fixes, im sure there are some leftovers of that still in the engine
r1967 | kbandressen | 2008-07-20 19:49:11 -0400 (Sun, 20 Jul 2008) | 4 lines
Changed paths:
M /openbor.c
M /openbor.h
M /openborscript.c
M /openborscript.h
M /source/gamelib/font.c
M /source/gamelib/font.h
M /source/gamelib/screen.c
M /source/gamelib/screen.h
M /source/gamelib/screen16.c
M /source/gamelib/screen32.c
New command fglayer.
New script commands for fglayer and text objects added.
Some font code rewritten for text objects.
Watermode 2 added to bglayers.
r1967 | kbandressen | 2008-07-20 19:49:11 -0400 (Sun, 20 Jul 2008) | 4 lines
Changed paths:
M /openbor.c
M /openbor.h
M /openborscript.c
M /openborscript.h
M /source/gamelib/font.c
M /source/gamelib/font.h
M /source/gamelib/screen.c
M /source/gamelib/screen.h
M /source/gamelib/screen16.c
M /source/gamelib/screen32.c
New command fglayer.
New script commands for fglayer and text objects added.
Some font code rewritten for text objects.
Watermode 2 added to bglayers.
Thanks for all clarifications, now I understand better how fglayer works.
To be honest, I never had too many problems with cpu or fps due to layers, but currently I'm trying to reduce the memory usage.
I will do more tests with trimmed images.
bWWd
If I'm not wrong, it was a DC suggestion in an older post.
O_Ilusionista
Maybe it's better than have all objects in the same layer, like the image I posted before.
To be honest, I never had too many problems with cpu or fps due to layers, but currently I'm trying to reduce the memory usage.
I will do more tests with trimmed images.
bWWd
Yeah, it's true. A trick that 's helping me to reduce the impact on the performance is by breaking the script in small parts and running only the necessary at each step.
If I'm not wrong, it was a DC suggestion in an older post.
O_Ilusionista
Thanks, it's a good idea. It's possible to mix yours and DC suggestion, separating the level objects in different layers but using the total level size (or a bit smaller) for all, and let the engine auto trimm all of them instead of doing it manually (once he confirmed that the engine will auto trimm layers on load).
Maybe it's better than have all objects in the same layer, like the image I posted before.