11:21 a.m.
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
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.
The discussion recently came up for Super Tux -
https://github.com/SuperTux/supertux/issues/183
I was just curious if we were using sprite sheets ourselves. I've not seen any
reference to them, though I may not have dug deep enough to verify this yet.
--
Sent by Chessboard.
2:30 p.m.
datahead <automailer(a)forum.secretchronicles.de> writes:
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
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
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
4:25 p.m.
-----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 <automailer(a)forum.secretchronicles.de> writes:
> Post via forum by datahead <cjj_009@xxxxxxxxxx>: 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-----
7:44 a.m.
Post via forum by Bugsbane <piers@xxxxxxxxxx>:
I'd just like to add to this that using sprite sheets raises the level of knowledge
required by new contributing artists. Many people who know how to use Inkscape don't
know what a sprite sheet is, and for those who do, especially those looking to create
something new instead of modify something that exists, they're not going to know
things like the acceptable document and sprite dimensions.
For more complex graphics (such as the Aarmy Senior boss I'm working on) it also
raises the computing horsepower needed as you need to be opening a file with all of the
animation frames at once rather than just one. Generally this isn't likely to be much
of an issue, as most graphics are fairly simple and most people have fairly powerful
computers, relative to Inkscape requirements. Even on my 8 core, 16gb ram machine though,
on some files I still get slowdown (especially where there are large numbers of highly
blurred objects).
For me personally it doesn't create too much of an issue as I already have a workflow
that is similar to how spritesheets are created, and I understand the technical
restrictions. For new contributors and people working on low end machines though, this
could be an issue in some cases.
--
Sent by Chessboard.
9:02 a.m.
Bugsbane <automailer(a)forum.secretchronicles.de> writes:
Post via forum by Bugsbane <piers@xxxxxxxxxx>:
I'd just like to add to this that using sprite sheets raises the level
of knowledge required by new contributing artists.
This is an interesting aspect I have not considered before. Given the
only minor performance improvements (see Luiji’s posting) I think the
usability for new users plays an important role we should not neglect.
they're not going to know things like
the acceptable document and sprite dimensions.
We already have some style and size restrictions on the graphics (like
the power-of-two boundaries), so I guess adding yet another one will not
make that much of a difference.
Btw. did you ever get around to completing the TSC styleguide?
it also raises the computing horsepower needed as you need to be
opening a file with all of the animation frames at once rather than
just one.
Yeah. I have yet to experience this problem with TSC graphics, but I
have seen Inkscape eating quite a bit of my RAM and computing power at
other places, notably when editing OpenStreetMap maps rendered by Mapnik
to SVG. It makes working with the file really unpleasant and requires a
lot of patience when you can watch Inkscape rendering the SVG piece by
piece.
In case anyone is interested, I have a 4-core machine with 12 GiB of
RAM.
Vale,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
10:44 p.m.
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
[quote]I'd just like to add to this that using sprite sheets raises the level of
knowledge required by new contributing artists.[/quote]
I honestly don't think the concept would be too hard for new artists. It's also a
staple of 2D platforming design.
Some people probably would mess up the dimensions of the sprites in the sheet (much like
people use the wrong branch when filing PR's), requiring rework sometimes. This sort
of thing is inevitable with about any procedure that must be exactly followed.
[quote]For more complex graphics (such as the Aarmy Senior boss I'm working on) it
also raises the computing horsepower needed as you need to be opening a file with all of
the animation frames at once rather than just one. Generally this isn't likely to be
much of an issue, as most graphics are fairly simple and most people have fairly powerful
computers, relative to Inkscape requirements.[/quote]
The benefit of saving processing when the game is run by players tends to outweigh this,
though the team has come to the conclusion that the savings aren't enough to warrant
the code architecture changes required for this.
I'd still be interested in getting more opinions from more programmers out there on
this question. Grimshaw seemed to agree with Luiji, though it's always good to
explore possibilities.
--
Sent by Chessboard.
7:51 p.m.
datahead <automailer(a)forum.secretchronicles.de> writes:
I'd still be interested in getting more opinions from more
programmers
out there on this question. Grimshaw seemed to agree with Luiji,
though it's always good to explore possibilities.
I find that TSC current system works well enough, and thus see no need
to change it. Given the amount of important open tickets on the tracker,
I don’t think we should spend our time on rewriting something that
currently already functions.
Vale,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
8:01 p.m.
Post via forum by datahead <cjj_009@xxxxxxxxxx>:
[quote]I find that TSC current system works well enough, and thus see no need
to change it. Given the amount of important open tickets on the tracker,
I don’t think we should spend our time on rewriting something that
currently already functions.[/quote]
I said the team found it would not be worth the effort for the code architecture changes.
Given that we have general performance issues, it still can be good to see what more
people think, in case they challenge our assumptions. There is a good chance we will not
find contradictory information, but it is good to keep an open mind.
--
Sent by Chessboard.
1856
days inactive
1947
days old
tsc-devel@lists.secretchronicles.org
7 comments
4 participants
participants (4)
-
Bugsbane -
datahead
-
Luiji Maryo -
Quintus