Re: [tsc-devel] 2.0.0 release and SFML branch

Chris Jacobsen | Fri, 29 May 2015 03:57:57 UTC

Sorry for the slow response.  I have been very busy for a while.

I think I agree that option 1 (Continue merging “devel” into “feature-sfml-port”, but discard any changes to the lowlevel files.) makes sense.  If someone fixed/enhanced something low level in devel, those changes would then need to be redone ultimately, if necessary, in the sfml branch.
I would have assumed changes to high level components such as pip enemy code in devel will not have to be redone in the sfml branch, correct?  If this is is not true, I may consider only working out of the sfml branch to avoid causing excessive rework.  If the SFML branch cannot run the game, this may effectively nix the option I listed above and basically put a freeze on adding new features to the game for now, until the SFML port is done.

I think you had said earlier that these changes use some sub-branches.  I know they're at least as complex as Brian Vanderburg's animation changes were, when he was told to use sub-branches.  If no one else will feasibly be able to review your changes, it probably does not matter, but more sub-branch usage might be good.
I would have suggested not changing features such as the object collision system in this set of changes.  The object collision system should not have to change in order to change how the game renders; it may have been better to do these changes as a separate effort.  If this has already been done, though, it would not make sense to go back and strip it out now.
-datahead
  


     On Thursday, May 28, 2015 6:52 AM, Quintus <…s@q…> wrote:
   

 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