Re: [tsc-devel] Do we use sprite sheets at all?

Luiji Maryo | Thu, 29 Oct 2015 16:25:27 UTC

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I remember back when this came up in the SMC days. It largely has to
do with the fact that FluXy didn't see how the performance improvement
would exist. At the time, I didn't understand OpenGL too well, so I
didn't know either.

Technically, the great benefit a sheet would have is that you could
signal the processor once for every texture ever needed and only ever
rely on one texture coordinate system, and that'd reduce the
information we have to pipe to the GPU.

However, I'm not sure if I'd recommend this for TSC. For one, it seems
like a pretty bad case of premature optimization, and it would require
quite a bit of work to get the engine to use it. We also have to be
more strict about graphics dimensions so that they could be tiled in a
way that doesn't leave too many gaps, as the gaps would waste VRAM.

If we *did* ever implement this, I'd advise continuing with the
current disk format and having the TSC executable create the sprite
sheet dynamically. This way, people could dynamically add new graphics
in their level extensions and they'd still end up in the same sprite
sheet with no extra work from them.

In the past I've experimented with the performance between sprite
sheets and individual graphics via Allegro[1]. I found I could render
a large number more tiles with it, but at the same time I found that
simply rendering only the tiles that were actually on screen was far
sufficient to achieve good performance. Unless we have a HUGE amount
of tiles on screen at any one time, this isn't particularly important.

Note that if particle effects come in mind that they are the same
texture anyway and that we can achieve the same performance benefits
for individual particle emitters just by calling glBindTexture only
when necessary.

[1] http://liballeg.org/a5docs/5.0.11/graphics.html#al_hold_bitmap_drawi
ng

On 10/29/2015 10:30 AM, Quintus wrote:
> datahead <…r@f…> writes:
>> Post via forum by datahead <…9@x…>: Do we use
>> sprite sheets at all?  This basically means we would place an
>> entire set of sprites into one image and have that loaded from
>> the file system all at once.  It would then use the coordinates
>> on the image texture in order to properly render the sprites at 
>> runtime. This tends to help with performance.
> 
> Currently, we only use sprite sheets (which I know as “tilesets” or
> “tile maps” or even “tile atlas”) for the GUI system, because 
> that’s how CEGUI requires its graphical input for styling the GUI 
> widgets. Everything in-game uses separate files. However, before 
> you draw a conclusion from that, consider we are using a caching 
> mechanism that only loads the sprite from a file once per level. 
> That is, if you have 500 “Door Yellow” sprites in a level, the 
> actual graphics file is loaded from the disk only once for the 
> first door found in the XML. Every further access to this graphic 
> will result in the already cached texture being returned from the 
> resource manager.
> 
> I think we can achieve much greater performance improvements by 
> preloading all sublevels or even all levels on a world map in 
> separate threads.
> 
> Vale, Quintus
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWMkh3AAoJEHndR5mZinm6qUgP/RoDQf3bU79ckQIGX+6nhV3L
KwCJvLS1fnABtQqdGFMieegco9HgloWFYitJY225ViiiqDzDLkTzfTH1rRMipw+e
xPxIyRGJGUJmAbOUtZ/Gktxuvw5H3DKcaQ0f78vFlixjhL0vKnPCBr+4UrwCyEJh
ae95zucAETR5WEiHoTYC7N4xDwmb3b+MeToFuq1xaV4pJOV/vijivBiGiecHKt+u
bzsCXa8b9wwMRozj86idPiSsSTtPC+GGpJYCp1deRAa2oW3pW18ab55P2yX8SLM4
YS9DYKFA8Q4nBUs7Q06wSymti7n+vg8O+zDPEOTicWgkMtsces9x0/NF5PDA+oq9
d8K8EiujF1EQvNo936/gaoX42haqvXDQrw4Gwd8GK1kyRv42Vb62b2rif65uWaKL
8ZPoBC3iTpxbhZUmUn39qm48384OEsKDmvEZfeT2uM0ZwMVjHEVLBLgSt0t60tZP
gGqmoE+jEH1KfjHfev6pbM1coEENB4iiCfh3C1t8VY4nj3YCK3cdoTjhNF/iiVb2
irg9nvtq5TkJc+m84hIXfdEj2FPONqbVexukY9VYfIx8IfnYjOoln8EdveUx52hT
x4AGFqk5zaFL6nO6zwt2l70gnmi83g072Z/ptDrBxFLL/8MGAJ6N8V7ZK97SILbs
SOQH7+ee0r64k0Jg1/I3
=ILEr
-----END PGP SIGNATURE-----