Re: [tsc-devel] 2.0.0 release and SFML branch
Quintus |
Thu, 28 May 2015 10:51:58 UTC
If nobody dares to discuss the issue, I will just continue working on
the SFML branch. It is enough work for sure; after the 2.0.0 release
there will be no changes to `devel' until the SFML port has been
completed by me.
Valete,
Quintus
Quintus <…s@q…> writes:
> 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