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

Chris Jacobsen | Fri, 29 May 2015 07:32:58 UTC

> your email client drives me nuts. It appears to be sending HTML-*only*
messages, without a text/plain part. My forum handler detected that, and
tried to make something of it; but that code had a typo, so it crashed
(and generated the delivery failure notification). I have fixd this
error, so please stay with me while I see what happens.
I'm sorry it caused a hassle, but there will probably be others who use HTML-only clients as well.  I have been using yahoo mail.  We certainly don't want thesoftware to crash, so I am glad you fixed this issue.
> I’ll try to, but as I said, I would appreciate help currently more than
review of the code.
If you can post some of the things that need to be done with details, this mightpull some programmers in more easily.  This will especially be true if someonecan "dive in".  If we need to spend a while practicing SFML programs before evertouching TSC, it's a lot less likely we'll be able to find time.
My own time will of course be limited this summer, since I'm trying to savemy Phd status.  I was also really wanting to code a game feature or two, sinceall that I have done is coding standards changes, bug fixes, and config changes for TSC so far.  I may end up doing a game feature first.
If you are able to provide any insight when I try to configure a different IDE in Linuxfor TSC it may help me develop, as well.  I realize you don't use IDE's, but a lotof the configuration boils down to cmake, gdb, make, and g++.  This is a lot of whatwas making me interested in Visual Studio (apart from my use of Windows for schoolrecently).

> This is the only thing that semantically changed, and it changed,
because the old collision system was using OpenGL types all over. There
was no choice than to rewrite that; it works basically the same still,
only that I have replaced a list with a binary tree for performance
reasons. The API looks even similar.
It makes sense from what you described.  I need to learn a little more aboutthis system, though.
-datahead
 


     On Friday, May 29, 2015 3:13 AM, Quintus <…s@q…> wrote:
   

 Hi datahead,

your email client drives me nuts. It appears to be sending HTML-*only*
messages, without a text/plain part. My forum handler detected that, and
tried to make something of it; but that code had a typo, so it crashed
(and generated the delivery failure notification). I have fixd this
error, so please stay with me while I see what happens.

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

No problem.


> 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.

Okay. This is what I think mostly.

> 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?

Yes, this is correct. Only parts that make use of the graphics system,
etc, directly need to be rewritten. Well, maybe some animation timing
issues need us to touch the code a bit itself, but it can be left
untouched mostly I expect.

> 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.

Currently, it cannot run anything complex. If you compile and run it,
you’ll get into a very simple scene where you can barely move. It is way
to go still.

> 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’ll try to, but as I said, I would appreciate help currently more than
review of the code.

> 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.

This is the only thing that semantically changed, and it changed,
because the old collision system was using OpenGL types all over. There
was no choice than to rewrite that; it works basically the same still,
only that I have replaced a list with a binary tree for performance
reasons. The API looks even similar.

> If
> this has already been done, though, it would not make sense to go back
> and strip it out now.

Yes. And then you’d have the OpenGL types again.

Vale,
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