Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Terrain Layers  (Read 9087 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Terrain Layers
« Reply #15 on: January 29, 2015, 08:05:50 am »
Quote
Rebuilding a vertex array is pretty quick. It would be slow to clear it and push back each vertex each time
No, because it is based on std::vector, which doesn't free its internal memory when you clear it. So once you've reached the maximum size, no more allocation and deallocation happen, all you do is to copy elements.
Laurent Gomila - SFML developer

Mörkö

  • Jr. Member
  • **
  • Posts: 96
    • View Profile
Re: AW: Terrain Layers
« Reply #16 on: January 29, 2015, 09:15:50 am »
Thus if you want just one draw call, you'll have to add everything to ond vertex array and you need to sort and arrange the vertices the order they need to be drawn in.

What about something like this:

1. Update every entity position
2. Sort entities based on Z component
3. Iterate entities, concatenating their personal vertex array into a single array
4. Draw vertices

?

Ztormi

  • Jr. Member
  • **
  • Posts: 71
  • Web developer by day. Game developer by night.
    • View Profile
Re: Terrain Layers
« Reply #17 on: January 29, 2015, 10:32:32 am »

If I understand you right Ztormi, you would suggest a vertex array that covers the whole area the player can see? But if I move to one side, this would mean a rebuild of the whole array. Or did you have something else in mind?


No, I meant you forget the chunks and just draw the whole map, layer by layer.

Like Jesper Juhl mentioned, the method of updating and keeping track of your drawable items is probably more perfomance intensive operation than drawing itself.

Logic would go like this:

Sprite refers to a drawable object which's position is not tied into a tile.

- I have two classes, World, Renderer
- World notifies Renderer when tile is changed
- World notifies Renderer when sprite is created
- World notifies Renderer when sprite is changed
- World notifies Renderer when sprite is destroyed
- Renderer has two vertexarrays, tilelayer and spritelayer
- On draw, both vertexarrays are drawn in correct order

Tilelayer vertex array is really straightforward. However, the vertex array containing sprites is a bit trickier. For this to make sense, I scratched up an example. I use sfml.net with C# because that's how I roll.

Sprites:
(click to show/hide)

Renderer:
(click to show/hide)

Notice a problem here?

Every time we remove object from MappedVertexArray we'll have to rearrange all the vertices. Again, referring to Jesper Juhl's post, you'll have to profile if this approach is worth it. Or would it be faster to just have a list of sprites in screen and draw them one by one.



« Last Edit: January 29, 2015, 01:08:54 pm by Ztormi »

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10820
    • View Profile
    • development blog
    • Email
Re: Terrain Layers
« Reply #18 on: January 29, 2015, 10:40:32 am »
1. Update every entity position
2. Sort entities based on Z component
3. Iterate entities, concatenating their personal vertex array into a single array
4. Draw vertices
Might work. It's just if one layer never changes and has always the same z ordering, you'll spend some time moving vertices around which might take longer than a simple draw call. ;)

No, I meant you forget the chunks and just draw the whole map, layer by layer.
Chunking can be okay/nesecary. I mean if your field of view is 100th of the whole map, you really don't want to draw everything, but instead chunk things up and only use the chunks around the players position.

Anyways, it's really not much use to discuss all the possible micro optimizations. Just go with the approach that seems the easiest to you and start optimizing once you actually get performance issues. Some principles to keep in mind:
KISS: Keep It Simple Stupid
YAGNI: You Ain’t Gonna Need It
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Ztormi

  • Jr. Member
  • **
  • Posts: 71
  • Web developer by day. Game developer by night.
    • View Profile
Re: Terrain Layers
« Reply #19 on: January 29, 2015, 10:50:47 am »

Chunking can be okay/nesecary. I mean if your field of view is 100th of the whole map, you really don't want to draw everything, but instead chunk things up and only use the chunks around the players position.


Well sure, I'd probably chunk the tilemap after I notice considerable performance problems with drawing.

Edit:

If you do have a working solution for drawing tilemap with chunks, just use it. But the point is, I don't think it's worth the hassle to try to figure out generic solution on how to stuff all the objects into single vertex array. Rather just split the rendering into logical components (ie. tilemap,sceneries, animated entities).
« Last Edit: January 29, 2015, 01:05:13 pm by Ztormi »

Hapax

  • Hero Member
  • *****
  • Posts: 3351
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Terrain Layers
« Reply #20 on: January 29, 2015, 04:12:17 pm »
Quote
Rebuilding a vertex array is pretty quick. It would be slow to clear it and push back each vertex each time
No, because it is based on std::vector, which doesn't free its internal memory when you clear it. So once you've reached the maximum size, no more allocation and deallocation happen, all you do is to copy elements.
Ah right. It wasn't the clearing that I was thinking would be slow; it was the pushing back. I guess if it's already been allocated, the creation and pushing of an element wouldn't be slow.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*

stulleman

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: Terrain Layers
« Reply #21 on: January 29, 2015, 07:06:24 pm »
I've had performance issues already without chunking.
With Chunks of 16x16 and a map of 60x60 chunks (to get roughly 100km2) it is inevitable to chunk my terrain.
I have a working chunking system but (because of the reason of this thread) I need to modify this system.
The best solution that fits my needs would be from hapax.
I'll have something like a view class that holds n vertex arrays for each layer and chunks modifying this array.
I hope to get some results soon to share my experiences.