Separation of logics and graphics

[Nexus]

Hi, up to now i let my objects derive from sf::Sprite. Like this, it was easy to iterate through containers and just write App.Draw(...) using the implicit conversion to base class Sprite.

Now I thought a stricter separation between the game logics (object's positions, velocities, further information like hitpoints, and so on) and graphics (the used image, color, source rect, ...) wouldn't be bad. Even though sf::Sprite is described as small, lightweight class, its size is 132 bytes. And besides of that it contains a lot of unused information (see next passage).

An example is a 2-dimensional sequencial container of tiles. The tiles' position is already given by their index in the container, so using a sprite would double the information. If there are 4 different tile types, it is sufficient for each tile to save the according type - like that, the source rect doesn't have to be changed for each tile. Many variables do not differ between the single elements. The same would be if I used sf::Sprite as an aggregate.

What do you think about this design? I consider it being more abstract and making changes and maintenance of the code easier. Is it a great loss of performance to create each frame lots of new sprites?

[Wizzard]

That's actually what I do for my Entity class and for the tiles of my Map class in my prototype of a side-scrolling game.

[Nexus]

Thanks for your answer. You certainly mean the design of separation between graphics and logics, dont you? (I ask because "That" is not very clear)

By the way, I am programming a side-scrolling tile-based game, too - a jump'n'run. I have already done similar things before, but this is the first time I really bear design matters in mind...

[MrQuizzles]

I've had a few adventures in program design because of this very topic while working on my game. I decided that I would make the engine as if I was only making the engine and then passing it off to another programmer (who also happened to be me) to use it to make a game. Naturally, I built it with a separation between logic and graphics since the second programmer should never have to interface with SFML, and the design of the whole thing relies on the extendability of certain objects.

I decided that an easy way to render things was to create a sprite for each entity each frame, and I found that the approach could create performance problems if you're using a very lot of them. It's about the easiest thing you could set up while keeping a separation between graphics and logic, but it's not the best way of doing it.

I've got an Athlon X2 5200+, and I could have around 2,400 of them being created and destroyed at 60 frames a second while using only a little over half of my CPU power. If you don't have a lot of entities, then, although it's not the most efficient method, it won't create any problems.

The part I didn't like about it, though, was how it made me put a lot of data into my entities, which also made the constructors take around 11 arguments, which can be a bit of a pain to work with.



That didn't fit my desires entirely, though, as it limited me to one sprite per entity, and, as mentioned before, it's not really efficient. What I'm doing now is creating a structure that allows me to control and render a group of sprites as a single entity and allow it to be referenced by a unique name. Load it once before it's used, then just put it in a tree of sorts and search out your desired sprite sets each time an entity is created, returning a pointer to be kept inside the entity it's being associated with.

Searching a tree for an object containing sprites once when an item is created rather than creating a sprite every time an item is rendered is definitely more efficient, and the use of pointers to reference the stored sprites lets you cut down on memory use. It also allows you to reduce the amount of graphical information your entities need to contain, which also makes their constructors simpler.

This is the best solution I have come up with for this problem.

[Nexus]

Okay, thanks for your advice.

I think I won't have loads of sprites on my screen at the same time, so creating them every frame shouldn't be a big problem (at least not in near future). But the way you handle it now seems to me very efficient, too. You just have to change the sprite's position and maybe rotation every frame, but the sprite itsself isn't created again.

Probably I won't use this system right now, but I will keep it in mind. I guess changing the design from the first to the second option won't break up the whole code. Once I've separated graphics and logics, I think it's easy to be flexible.

[Wizzard]

It would be interesting to see a benchmark comparing the time in nanoseconds it takes when using 1000000 sprites to draw 1000000 things and when using 1000 sprites to draw 1000000 things that store their own position.

The memory used when using 1000000 sprites is 132 megabytes and the memory used when using 1000 sprites is 8.132 megabytes (including positions for each thing).

[T.T.H.]

You just have to change the sprite's position and maybe rotation every frame, but the sprite itsself isn't created again.

That's pretty much the same as I do:

- load all images at startup
- create all sprites at startup
- set scale of all sprites at startup and whenever it needs to be changed (e.x. zooming in/out)
- set position of sprite and render sprite for every sprite of every object in every frame

Works fine, FPS way in the hundreds.

But on the other hand my number of sprites being drawn every frame is not yet in "interesting" ranges yet where performance problems might arise.