[tsc-devel] 2.0.0 release and SFML branch

Quintus | Tue, 19 May 2015 22:29:09 UTC

Hi everyone,

as I have noted in IRC occasionally the work on the SFML port is much
more than I expected it to be. My original goal of completing the SFML
transition before the 2.0.0 final release has become pretty unreachable
and I’m thus unsure on how to proceed, which is why I’d like to ask for
some opinions from the rest of the team.

                           I. Releasing 2.0.0

Ticket #97 is mostly done thanks to kirbyfan’s great piece of music. It
just needs a last review if really all the Mario remix music is gone
from the game, which when completed will leave us with #406 as the last
ticket opened. I have mostly completed my private tasks that were
blocking me during the last weeks, and I think what remains can safely
be done in parallel to any work I can do on TSC. Therefore, I think I’m
able to take up on #406 in the next few days and create minified
versions of the pipes for the world map.

I’d thus welcome it if you all gave a quick glance over TSC’s existing
music collection and see if we overlooked some Mario music. I hope not,
but you never know.

As soon as I have completed work on #406 I’m going to publish the first
Release Candidate of Version 2.0.0. We are, again, behind our release
plan and we really need to finally do something.

                    II. State of the SFML transition

I have completely thrown out the lowlevel OpenGL stuff in the
“feature-sfml-port” branch in the repository and rewrote several
integral parts of the game from ground up. When you run it it still
looks fairly minimal, but I am confident that there isn’t too much
missing to reapply the upper half of the code on the new ground I coded
with SFML.

The drawing basics work in that branch. As announced, I have implemented
that by employing a scene-based programming model that replaces the
rather confusing who-draws-what in original TSC code. The class
hierarchy is now clearly structured, with cActor at the top and several
more and more specialised classes below that, where cAnimatedActor
additionally inherits from simpletoon’s animation file parser. I have
also reworked the collision system to work in a structured way that
makes it foreseeable which actor will receive the collision by filtering
any emitted collision against a binary tree of existing UID<->collision
mappings so that double collisions cannot happen. This system will make
the problem outlined in tickets #372 and #373 impossible.

Although images can be successfully loaded from simpletoon’s animation
system (which I had to adapt slightly as the OpenGL-based code needed to
be swapped out), an actual animation system that _changes_ the loaded
images is not yet implemented. The entire input handling, which
previously was done by SDL1, is also still missing and the music system
only has a debugging implementation I used to test if I can play any
sound files at all.

The scene-based model currently contains a bare mainmenu scene without
any functionality other than a start button and a debugging level
scene. Once the animation and image loading system is fully implemented
in SFML, the existing level XML loader can directly be attached to have
working levels, similar for worlds. There still need to be scenes for
in-game menues and the option screen.

In all of this, it is possible to keep the compatibility with the
existing level files in case you wonder. The entire SFML thing is only
about the underlying code structures, thus it is technically possible to
introduce the SFML backend even in the 2.x series.

              III. Consequences for the development of TSC

We are going to release the longstanding 2.0.0 soon as outlined
above. It is however unfortunate that the SFML port can’t be finished
before, as in its current state (see II. above) it is pretty much
impossible to properly merge further development in the “devel” branch
into “feature-sfml-port”. The code for the lowlevel things has so
dramtically changed that files like levelplayer.cpp or sprite.cpp have
been completey rewritten, and any fixes or improvements to the code in
“devel” will not be portable to “feature-sfml-port” when they affect
these lowlevel stuff. The problem is that TSC’s previous architecture
was not really cleanly separated, and changes in more highlevel areas
will most likely cause changes in the lowlevel files as well, with the
latter being not really applicable to the SFML port.

Thus we have to decide how we should continue. I see the following
options:

1. Continue merging “devel” into “feature-sfml-port”, but discard any
   changes to the lowlevel files.
2. Do not merge “devel” into “feature-sfml-port” in the future and
   reconsider things when the SFML port is done.
3. Depart the SFML port from the 2.x series and treat it as the
   beginning of the 3.x series.
4. Concentrate all development efforts on the SFML port and halt any
   other development in “devel” until it is completed.

I personally favour option 1), in the hope, that I am able to quickly
reach a point that will allow me to merge the “feature-sfml-port” branch
back into “devel” again. Once that point is reached the problem
vanishes, and I hope it is reached before the “devel” branch evolves
far.

If things go more complicated than expected, I suggest to follow option
4). That is, not only me, but all of us shall work on the SFML port to
get it done as quickly as possible.

If any of you has further options to consider, please speak up. With the
2.0.0 release immediately in front and thus the likelihood of an
increased development momentum I deemed it useful to gave an overview of
the SFML porting problems. To summarize the problem in a single
sentence, the complex changes made in the SFML port will come into
conflict with further changes in the “devel” branch, and we need to
decide how to manage the upcoming development efforts it we are not
intending to multiply our work by parts of the team working on
incompatible systems each.

Valete,
Quintus

-- 
Blog: http://www.quintilianus.eu

I will reject HTML emails.     | Ich akzeptiere keine HTML-Nachrichten.
                               |
Use GnuPG for mail encryption: | GnuPG für Mail-Verschlüsselung:
https://www.gnupg.org          | https://de.wikipedia.org/wiki/GnuPG
My key fingerprint:            | Mein Schlüsselabdruck:
B1FE 958E D5E8 468E AA20       | B1FE 958E D5E8 468E AA20
8F4B F1D8 799F BCC8 BC4F       | 8F4B F1D8 799F BCC8 BC4F