$12256 / $11500
Hi.
I want to thank you first for such amazing project.
And here is question
I added a render counter, it increments when SDLRenderDevice::render(Sprite*) and SDLRenderDevice::render(Renderable*) are called
And it set back to 0 on SDLRenderDevice::commitFrame.
Take a look at the picture it is a frame when render called 2513 times!
It is a map next to town, when u go up.
Also i have over 1500 render calls mostly on each camera point at the town.
I tested on 640 x 480.
This website's content is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
that part of the code is obscured, but if I had to guess your getting 1 render call per map tile.
Depending on the map size and number layers that can add up very quickly.
Not a big issue if using a classic 2D blitting API, but if using a modern 3D api, probably would want to use some manner of batching to cut the number of render calls down.
https://withthelove.itch.io/
Man, i have 640x480
Tile's size is 128x32
75 tiles needed to cover the screen.
2513 and 75, i think it is a huge difference
Man, i have 640x480
Tile's size is 128x32
75 tiles needed to cover the screen.
2513 and 75, i think it is a huge difference
the problem is with oversized tiles, such as a tower (8x10 tiles iirc), so if there is a tower near the visible part of the screen we still want to render it as its origin may be at some x,y coordinate but it's drawing to x+8 as well, and as we're currently not dealing with each side on its own, the engine also assumes at x-8.
The actual screen is 640x480, which divided by tilesize (64x32) is 10x15 = 150.
As we only shift by half a tile when going up or down, we need to multiply by 2: 10x15x2=300.
Now we add the oversized tiles:So we need to add 2x8 and 2x10 to the sides:
(10 + 2x8) x (15 x2 + 2x10) = 1300.
The observed 2450 calls seems to have uncovered a bug, which was fixed in
https://github.com/clintbellanger/flare-engine/commit/5752afd17cffaed2c5...
Now you'd only see 1300 instead. (which is still a lot compared to 300)
If you have ideas how to remove the rather large safety margin off screen for the oversized tiles, feel free to share.
This issue can also be found at
https://github.com/clintbellanger/flare-engine/issues/1084
Thanx for answering!
I already removed x2 multiplier )
But i didn't do this.
j = upperleft.y - tset.max_size_y/2 + tset.max_size_x;
Ill apply the whole fix.
Thanx alot again!
++
I tried to edit mineshaft_longsword.txt
Multiplied all enemygroups by 4
Was
[enemygroup]
type=miner
location=15,12,19,6
level=1,1
number=10,12
After edit:
[enemygroup]
type=miner
location=15,12,19,6
level=1,1
number=40,48
And when i came to all groups of enemies game just freeze and does not respond to input at all
i came to void GameStatePlay::logic()
and i commented that line hazards->logic();
and game went just fine (hehe i mean no freeze).
So hazards->logic() it causing game to freeze on large enemies groups.
I cannot reproduce that
try to replace 3 enemygroups inmineshaft_longsword.txt
with this
[enemygroup]
type=miner
location=11,22,4,10
level=1,1
number=45,40
[enemygroup]
type=miner
location=15,12,19,6
level=1,1
number=40,42
[enemygroup]
type=miner
location=36,12,15,13
level=1,1
number=41,45
Run the game and come to mines, come close to all three groups (close enough when zombie's try to attack you)
I tried that from debug, and it just stun's the game
May be debug is the reason, but i have very good hardware(i7 3630QM @ 2.4GHz and 16 GB of ram), so it shouldnt
Yep, that is so.
I checked release and it does not stun or freeze.
Seems like VS debug is the reason.
How about to determine max tile's size inside Map::load(std::string fname) while parsing bg layer ?