Post via forum by datahead <cjj_009@xxxxxxxxxx>: xet7 said: [quote] Hi, is work is divided to more branches, does that increase complexity in merging code? It's possible that I start full time work soon, but I'll anyway participate on my free time what I can, read irclogs etc. BR, xet7 [/quote] If multiple people were working on the original effort, we would have used multiple branches anyways. In the new effort, we could either have multiple people contribute to one of the bulleted points above at the same time or choose different subefforts that are not likely to conflict much (and that can be tested separately). @xet7, your mail did not post to the forum. Did you use text for the format? -- Sent by Chessboard.

To clarify on what datahead has said already. Yes, this means basically starting the SFML port from anew, now with a more structured approach. I repeat here what I said earlier in IRC to datahead: I have no problem with my work on it being superseded like this. We should make the best possible development decision. datahead <automailer(a)forum.secretchronicles.de&gt; writes: Yes, that’s how things work with Git. I however do not think that we need to “maintain” these old branches then separately in the sense of working on them. They will just stick around with nobody committing on them, being barely for reference. Thus they create no additional work. I am short on time right now, and will reply more detailed later. Sometimes Chessboard still has problems with some emails. Probably my LMTP implementation has a bug. It will result in one of these “bouncing messages” topics later on then. Valete, Quintus -- #!/sbin/quintus Blog: http://www.guelkerdev.de GnuPG key: F1D8799FBCC8BC4F

datahead <automailer(a)forum.secretchronicles.de&gt; writes: I took a look at the current OpenGL/SDL rendering implementation in core/main.cpp and video/video.cpp. Well. I think there is not much else possible than wiping both files, since they contain a lot of OpenGL- and SDL-specific code. Trying to preserve the API of pVideo is going to destroy the well thought-out API of SFML. Trying to shoehorn it into the existing pVideo API might prove rather complicated. I would appreciate it if someone else could look at those files and post how they think about this. This[1] for example is unportable and will need to be removed, and all the code that corresponds with the BPP, which is a lot in that method. What do these[2] lines do? Something with OpenGL supposedly, but SFML has its own instructions on how to combine it with OpenGL[3]. cVideo::Init_Video() is a terrible method by the way, it is much, much to long and makes it impossible to get an overview of what it actually does. cVideo::Init_OpenGL()[4] seems to be superflous with SFML also, and likewise all the other Init_* methods, aren’t they? How is Test_Video() supposed to work with SFML[5]? Make_GL_Context_Current() and Make_GL_Context_Inactive()[6] are going to interfer with SFML’s own managing most likely. Then there are render requests[7]; something I can make neither head nor tail of. I can’t think of any way to incorpate this with SFML, but grepping through the code it seems they are used at several places. There are many more examples like this; they are so tailored towards raw OpenGL and some of SDL’s API design specifics that maintaining the cVideo API with SFML will take a lot of work, and video.cpp needs to be rewritten from scratch during that course anyway. It seems that OpenGL works by some global state of the program somehow, which appears to me like broken design and is totally incompatible with SFML’s object-oriented API. cVideo makes a shot at trying to wrap OpenGL’s API into something usable, but unfortunately, SFML does this as well, and it does it fairly differently. Given this I will likely not be of much help in trying to maintain the current API. It appears to me that just redoing it from scratch is easier than trying to keep existing stuff around as far as possible. Feel free to argue differently, but please familiarise yourself with how rendering is done currently in OpenGL/SDL TSC before doing so. core/main.cpp and video/video.cpp are the files you need to look at for this. Valete, Quintus [1]: https://github.com/Secretchronicles/TSC/blob/devel/tsc/src/video/video.cp... [2]: https://github.com/Secretchronicles/TSC/blob/devel/tsc/src/video/video.cp... [3]: http://www.sfml-dev.org/tutorials/2.3/window-opengl.php [4]: https://github.com/Secretchronicles/TSC/blob/devel/tsc/src/video/video.cp... [5]: https://github.com/Secretchronicles/TSC/blob/devel/tsc/src/video/video.cp... [6]: https://github.com/Secretchronicles/TSC/blob/devel/tsc/src/video/video.cp... [7]: https://github.com/Secretchronicles/TSC/blob/devel/tsc/src/video/renderer... -- #!/sbin/quintus Blog: http://www.guelkerdev.de GnuPG key: F1D8799FBCC8BC4F

Post via forum by datahead <cjj_009@xxxxxxxxxx>: No, I have not really looked into the graphics stack. I've increased my focus a bit on the game I'm developing of my own, since I have a lot of stake in it. If you wish to abandon my suggestion to start over because I have not been available much the last couple weeks, this is your right. Regardless of who codes it, I still think it would be best to restrategize as I outlined above and separate the architecture changes from the the SFML porting. This will reduce the risk of bugs, make it simpler for newcomers to join the effort, and allow for a more understandable git history. We would of course want to break each of these phases up into subtasks of their own, worked distinctly. I could resume looking at SFML tutorials and the existing OpenGL code, but it could be some weeks before I have a suggestion. As I've always said, I cannot make promises on deliverables or end dates if tasks are completed (no promises at all). If you must just make a decision now, this is fine. [quote] Especially it is necessary to have an opinion about how feasable it is to hijack the cVideo class and replace its inner contents with SFML instead of OpenGL/SDL. Doing so would speed up our SFML porting efforts, but it is an abuse of SFML’s nicely designed API. [/quote] Generally speaking, I would argue for something that maintains the original SMC-style architecture as closely as feasible, using SFML as if it had a global state, even if it is poor usage of SFML. A better architecture would then be devised in the subsequent architecture phase of the project. If shoehorning it this way is guaranteed to be more complicated just to get things to work, then, yes, we must rearchitect this layer of code in order to comply with SFML standards now. It also depends on just how complicated the architecture changes you were suggesting for the rendering layer are. I just hoped to avoid something anywhere near as complicated as the actor or scene manager changes we originally started. Of course, I am not "really" qualified to offer advice, as noted above. -- Sent by Chessboard.