Free Allegiance Forums

Hi,

I'd like to upgrade the codebase to C++14[0] to pave the road for a possible linux port[1]. Of course I want to upstream all my changes. Now the question is: will the core developers accept such changes?
Before I get started, is it possible to remove the obsolete projects first? I don't want to spend time to upgrade dead code

[0]: I need to get rid of all Microsoft specific keywords (e.g. WORD, BYTE, DWORD, HRESULT, etc.) and use the standard ones. Next step will be to get rid of TRef&co and use smart pointers, std::function & binders, etc.


[1]: A possible linux/android/mac port is a nice dream, so, please keep in mind that it's not a promise!
There will be needed lots of changes which will take a lot of time, my todo list looks like this:
1. remove all the obsolete
2. upgrade codebase to C++11/14
3. remove the the MS specific pch. On windows it will slow down a little bit the compilation at first time (with a few seconds), but incremental builds will be faster. Without this change we can't have code-completion and other goodies in linux IDEs.
4. use SDL for main loop, input, window management, sound?(OpenAL seems to be better for advance stuff)
4.1 move the windows specific bits into separate files.
5. add Cmake build system (VS2017 seems to support cmake, so we can eventually remove VS2017 projects).
6. port the 3d part to opengl(es)/vulkan?. This will be the hardest part because at first look it seems freeallegiance doesn't use any shaders ...

BogDan wrote:QUOTE (BogDan @ Oct 27 2017, 10:21 AM) Hi,

I'd like to upgrade the codebase to C++14[0] to pave the road for a possible linux port[1]. Of course I want to upstream all my changes. Now the question is: will the core developers accept such changes?
Before I get started, is it possible to remove the obsolete projects first? I don't want to spend time to upgrade dead code

[0]: I need to get rid of all Microsoft specific keywords (e.g. WORD, BYTE, DWORD, HRESULT, etc.) and use the standard ones. Next step will be to get rid of TRef&co and use smart pointers, std::function & binders, etc.


[1]: A possible linux/android/mac port is a nice dream, so, please keep in mind that it's not a promise!
There will be needed lots of changes which will take a lot of time, my todo list looks like this:
1. remove all the obsolete
2. upgrade codebase to C++11/14
3. remove the the MS specific pch. On windows it will slow down a little bit the compilation at first time (with a few seconds), but incremental builds will be faster. Without this change we can't have code-completion and other goodies in linux IDEs.
4. use SDL for main loop, input, window management, sound?(OpenAL seems to be better for advance stuff)
4.1 move the windows specific bits into separate files.
5. add Cmake build system (VS2017 seems to support cmake, so we can eventually remove VS2017 projects).
6. port the 3d part to opengl(es)/vulkan?. This will be the hardest part because at first look it seems freeallegiance doesn't use any shaders ...

HI!

Join us on our discord server and discuss this yourself with our dev team

https://discord.gg/DTMH8S8

Yes, join us on Discord for a more casual chat.

Porting to linux will be a massive effort but something that will be appreciated by quite a few people. Being able to run a linux server would also be very nice, and might make for a more easily reached milestone.

I also have a beta (https://github.com/pvandommelen/Allegia ... esolution2) running on steam right now which touches the rendering pipeline, I plan on merging this into master soon. While working on this I have gained some interest in cutting back the number of rendering code paths that are currently in the engine, that may also help future ports.

1. Yes please. Talk to Backtrak though, he likes having dead DX7 code in the main repository.
2. What do you mean with upgrading the code base to c++11/14? I'm only aware of a problem with std::min/std::max (solved in a local commit that touches the entire project, I'll see about getting that into master after the beta branch is merged).
3. -
4. I'm mostly afraid of how much code it would touch while providing little short term gain. Merging code branches is going to be awful. Not a bad idea though, the current code structure is pretty nonexistent.
5. As a c++ newb I seriously don't understand how the visual studio build system/dependency management can be so awful while being the industry standard(?). No opinion on if things would be better with CMake.
6. Allegiance uses triangles, textures and very basic lighting. I don't think any rendering system would have problems.

I am interested to know if we should recognize you from somewhere though. Coming out of nowhere to spend a lot of time making Allegiance better is great, but unexpected.

Senor NoirSol wrote:QUOTE (Senor NoirSol @ Oct 27 2017, 12:48 PM) HI!

Join us on our discord server and discuss this yourself with our dev team

https://discord.gg/DTMH8S8

I'll drop by tomorrow, thought it will be great if dev team can reply also here, where probably is less volatile.

Rock wrote:QUOTE (Rock @ Oct 27 2017, 04:38 PM) Yes, join us on Discord for a more casual chat.

I'll drop by tomorrow when I'll have more time to chat.

Rock wrote:QUOTE (Rock @ Oct 27 2017, 04:38 PM) Porting to linux will be a massive effort but something that will be appreciated by quite a few people. Being able to run a linux server would also be very nice, and might make for a more easily reached milestone.
...

Yep, there will be quite a lot changes ... I'll add the server to the todo list (at the bottom)


2. Currently the C++ code used in this game is not portable because it's using MS only var types, strings, etc. By " upgrading the code base to c++11/14" I mean to replace all those things with C++11/14 ones. Just to be clear, there will be an incremental upgrade, with standalone atomic patches. I need to upstream all these patches in order to keep my fork in sync with upstream.


4. SDL is needed to have a cross platform code.

5. visual studio build system is used, well, only on windows . CMake is needed to be able to compile and maintain the code on the other platforms.

Rock wrote:QUOTE (Rock @ Oct 27 2017, 04:38 PM) I am interested to know if we should recognize you from somewhere though. Coming out of nowhere to spend a lot of time making Allegiance better is great, but unexpected.

I'm a long term FOSS developer. Why I want to spend time on this project? Well, I read on some site that recently MS changed the license of this game to a more FOSS friendly, and I thought that will be a fun project to work on.

Hi BogDan,

I'm really happy that you've taken an interest in our project! I will be glad to to take in working change sets to the master branch, and I can set you up with a working beta branch as well so that you can get community testers to give your builds a try as you go. Please friend me on Steam so that I can add you to the dev group, and hit us up on Discord with any questions.

Oh and Rock, I don't know what you're talking about, there ain't no Dx7 dead code to be seen anywhere in there... nope nope nope...

Don't be dissin' my Dx7!

Sorry to be late to this topic and Discord is the worst place to discuss anything older than a few days...

BogDan wrote:QUOTE (BogDan @ Oct 27 2017, 09:21 AM) Hi,

I'd like to upgrade the codebase to C++14[0] to pave the road for a possible linux port[1]. Of course I want to upstream all my changes. Now the question is: will the core developers accept such changes?
Before I get started, is it possible to remove the obsolete projects first? I don't want to spend time to upgrade dead code

[0]: I need to get rid of all Microsoft specific keywords (e.g. WORD, BYTE, DWORD, HRESULT, etc.) and use the standard ones. Next step will be to get rid of TRef&co and use smart pointers, std::function & binders, etc.


[1]: A possible linux/android/mac port is a nice dream, so, please keep in mind that it's not a promise!
There will be needed lots of changes which will take a lot of time, my todo list looks like this:
1. remove all the obsolete
2. upgrade codebase to C++11/14
3. remove the the MS specific pch. On windows it will slow down a little bit the compilation at first time (with a few seconds), but incremental builds will be faster. Without this change we can't have code-completion and other goodies in linux IDEs.
4. use SDL for main loop, input, window management, sound?(OpenAL seems to be better for advance stuff)
4.1 move the windows specific bits into separate files.
5. add Cmake build system (VS2017 seems to support cmake, so we can eventually remove VS2017 projects).
6. port the 3d part to opengl(es)/vulkan?. This will be the hardest part because at first look it seems freeallegiance doesn't use any shaders ...

well like I said in a PR comment , I do think it's the backward way to do this.

concerning your todo list:

1. but so far no one started this except me and nothing is in the master branch yet.
2. why upgrade codebase to c++11/14 ?
3&5. this will hurt and eventually add bugs/issues to the IDE 100% of us is using. It's not like VS is not free and/or Alleg code requires the non free VS version.
4. why SDL and not something else ?
6. don't forget the netcode, DirectPlay.

imho, the good approach is to "simplify, simplify, simplify" the current code while keeping it 'Windows only' for now (and VS only for now).
do more "cuts" than "changes". HRESULT, BYTE, DWORD, etc are fine for now. no point changing them, even more if a lot of them will be removed anyway...

Because the start is to remove obsolete stuff like AGC, COM/OLE stuffs, pigs lib and side small tools (mdlc, etc).
Then start removing/replacing "Windows specific" stuff:
- the use of Windows registry
- all com/atl/win32 calls
- DirectPlay (that's a hard one)
- Direct3d (that's an even harder one)

Then and ONLY THEN, we *could* start moving away from VS and start 'thinking' about building on Linux. and Moving to c++11/14 and start refactoring/renaming some old code.
There is no gain trying to 'compile on Linux' while still having registry, ole/com, DirectPlay, Direct3d, etc.. it's a complete waste of time and you'll add bugs and/or consume QA/build time.

Don't get me wrong, I'm all for a 'multi-platform' Alleg that could build & run on many OS but I just don't think this is the good way to do. At least in the 'master upstream' branch. That branch is for short term iteration for current game code. You don't put half baked, mid/long term stuff in the master. What if BogDan goes MIA without finishing what he started ?

I don't know but from what I see being committed to the master branch I'm very worried for the future. This looks like R8 fiasco all over again.
Stick to simple & 'useful for the game' changes. Fixes and changes that can help get new players and keep current ones...
Everything else doesn't belong in the master branch.

Sorry to sound negative but someone has to and I've been there since 1999 and I've seen so many stuff started and never finished or over engineered and completely out of phase with the players needs.

Um wasn't funnyLunkin and/or Turkey working on a Linux project?
Maybe touch base with them.

Definitely not me.