Skip to main content

User login

What is OpenID?
  • Log in using OpenID
  • Cancel OpenID login
  • Create new account
  • Request new password
Register
  • Home
  • Browse
    • 2D Art
    • 3D Art
    • Concept Art
    • Textures
    • Music
    • Sound Effects
    • Documents
    • Featured Tutorials
  • Submit Art
  • Collect
    • My Collections
    • Art Collections
  • Forums
  • FAQ
  • Leaderboards
    • All Time
      • Total Points
      • Comments
      • Favorites (All)
      • Favorites (2D)
      • Favorites (3D)
      • Favorites (Concept Art)
      • Favorites (Music)
      • Favorites (Sound)
      • Favorites (Textures)
    • Weekly
      • Total Points
      • Comments
      • Favorites (All)
      • Favorites (2D)
      • Favorites (3D)
      • Favorites (Concept Art)
      • Favorites (Music)
      • Favorites (Sound)
      • Favorites (Textures)
  • ❤ Donate
FLARE [ARCHIVED]

Huge number of render calls

Serj
Saturday, May 24, 2014 - 13:53

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.

Attachments: 
Preview
screen.png screen.png 395.4 Kb [2 download(s)]
Preview
debug.png debug.png 85.6 Kb [2 download(s)]
  • Log in or register to post comments
withthelove
joined 11 years 4 months ago
Sunday, May 25, 2014 - 10:09
withthelove's picture

 

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/

  • Log in or register to post comments
Serj
joined 11 years 2 days ago
Sunday, May 25, 2014 - 10:49

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

  • Log in or register to post comments
Serj
joined 11 years 2 days ago
Sunday, May 25, 2014 - 10:49

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

  • Log in or register to post comments
Stefan Beller
joined 13 years 1 month ago
Sunday, May 25, 2014 - 11:21

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.

 

 

  • Log in or register to post comments
Stefan Beller
joined 13 years 1 month ago
Sunday, May 25, 2014 - 11:22

This issue can also be found at

https://github.com/clintbellanger/flare-engine/issues/1084

 

  • Log in or register to post comments
Serj
joined 11 years 2 days ago
Sunday, May 25, 2014 - 11:35

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.

 

 

  • Log in or register to post comments
Stefan Beller
joined 13 years 1 month ago
Sunday, May 25, 2014 - 11:55

I cannot reproduce that

  • Log in or register to post comments
Serj
joined 11 years 2 days ago
Sunday, May 25, 2014 - 12:06

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)

 

  • Log in or register to post comments
Serj
joined 11 years 2 days ago
Sunday, May 25, 2014 - 12:41

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 

  • Log in or register to post comments
Serj
joined 11 years 2 days ago
Sunday, May 25, 2014 - 15:06

Yep, that is so.

I checked release and it does not stun or freeze.

Seems like VS debug is the reason.

  • Log in or register to post comments
Serj
joined 11 years 2 days ago
Monday, May 26, 2014 - 22:33

If you have ideas how to remove the rather large safety margin off screen for the oversized tiles, feel free to share.

How about to determine max tile's size inside Map::load(std::string fname) while parsing bg layer ?

  • Log in or register to post comments