State of the SFML port
by Quintus
Hi everyone,
today I completed my work on the sfml-port-input branch. For the first
time in our SFML porting efforts I was able to actually compile, run,
and play the game. I successfully finished lvl_1.
The sfml-port-input branch has now been merged into feature-sfml-port2,
which thereby now contains a roughly playable version of TSC mostly
ported to SFML. The port still has its issues, but I think the largest
part now has been moved over. The biggest thing remaining is the porting
of the audio system from SDL_mixer to SFML’s audio module, but thanks to
kirbyfan there is a PR available for that already[1] which will
drastically simplyfy things. If I have a correct view on the topic, it
is possible for us to wipe the SDL1 dependency from the codebase after
merging kirbyfan’s audio PR.
The SFML port in feature-sfml-port2 is, as outlined, roughly
playable. It has some issues we now need to tackle:
1. Mouse button input doesn’t work. You have to navigate the game with
the keyboard, including menus.
2. Graphical glitch with blue arrows in the HUD and everywhere points
should occur. This is probably due to an unported call to
glPixelStorei() in video.cpp[2] that I don’t know how to
handle. datahead, Luiji, would be nice if one of you OpenGL people can
take a look at that and estimate what that line intended to do (and even
better, fix the problem).
There are probably numerous further issues that I haven’t spot by simply
running through lvl_1. Please compile and test feature-sfml-port2 now,
and even more important, please contribute to it. The lengthy part of
the SFML porting should be over now, so let’s finish this.
Before starting the game, move away or delete your
~/.config/tsc/config.xml file. SFML doesn’t understand the SDL
key codes (obviously) and you would be unable to input anything with
your keyboard. Deleting that file causes the game to recreate it with
the default values (jump = s, fire/iceballs = space, etc.).
If you run ArchLinux or another rolling release distribution, beware
issue #500[3]. There is an incompatibility between our old CEGUI version
and the newest version of freetype2. This doesn’t specifically affect
the feature-sfml-port2 branch, but also devel and all versions of TSC
and probably even SMC alike. The issue tracker contains a workaround for
the problem.
Let’s work on completing the move to SFML. Happy coding!
Valete,
Quintus
[1]: https://github.com/Secretchronicles/TSC/pull/488
[2]: https://github.com/Secretchronicles/TSC/blob/f1a7838e6265ac2fb154ec24cfea...
[3]: https://github.com/Secretchronicles/TSC/issues/500
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
2 years, 11 months
Do we use sprite sheets at all?
by datahead
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.
3 years
Status of SFML video port of TSC
by Quintus
Hi all,
based on datahead’s suggestion I have retried the SFML port now with the
goal to keep as much of the current architecture as possible. This has
resulted in creation of a new branch in Git named “feature-sfml-port2”,
which is the main development branch for the SFML port now.
Today I have had success with porting video.cpp to SFML. The
implementation still has its rough edges (and uses some poor code), but
it works. The results are in the “sfml-port-video” branch (which is a
branch based off “feature-sfml-port2”). That branch has removed all
calls to SDL_Image in video.cpp and replaced them with use of SFML’s
sf::Image class instead. It also throws out SDL’s window management and
instead uses SFML’s sf::Window, so it was possible to reduce
initialisation of SDL to SDL_Mixer only. Luckily, as you all know,
kirbyfan has already filed a PR to wipe out SDL_Mixer from our codebase
as well.
What remains is input handling, i.e. handling of keyboard and joystick
events. The current “feature-sfml-port2” branch has input handling
commented out in the mainloop, so you can’t input anything into the game
window. This is what I’m up to do next.
On the video side, while the implementation I provide in the
“sfml-port-video” branch (which, as you probably already guessed, I have
already merged into “feature-sfml-port2”) does work basically, it is
completely untested and I’m pretty sure it doesn’t support fullscreen or
even mode switching, simply because the game input is missing still so
it is impossible to test. I also can’t remember changing any code
related to mode switching in video.cpp, so I guess this is hidden in the
menu source code files and it is likely that there are still calls to
SDL there.
If you wish to try it out, get a copy of the “sfml-port-video” branch
(or the current “feature-sfml-port2”, they are equal currently) and
compile and run it. You can’t interact with the game, but you can see
that it can successfully load graphics.
As a sidenote, I find it astonishing that SDL’ſ “pixels” pointer and
SFML’s sf::Image::getPixelsPtr() return pixels in the same format
appearently. I had severe worries that I had to write conversion
routines…
Valete,
Quintus
--
#!/sbin/quintus
Blog: http://www.guelkerdev.de
GnuPG key: F1D8799FBCC8BC4F
3 years, 2 months
