Free Allegiance!

factoid · Post by **factoid** » Wed Mar 05, 2014 12:24 am

UPDATE: Git repository is now live. I have the core igc object files compiling, and am now in the process of unit testing a shared library
UPDATE x2: Engine repository is now live, contains an mdl asset decompiler and ship model viewer
https://github.com/Factoid/alleg-core
https://github.com/Factoid/free-allegiance

About 2 months ago I started missing Allegiance a lot, even though I still don't have a lot of time to fly regulairly. I work and game mostly in Ubuntu these days, so the lack of a linux client also hurts a little. So what started out as a though experement and a little bit of exploratory hacking has turned into what I hope will be the start of a new chapter for the software. To date I have written an asset decompiler which converts the allegiance mdl files into open formats (obj, png, json, etc..) for use by a yet unwritten client, though I also have an MDL viewer which renders the results of my decompiler app, it's proof of concept, but it works.

Right now I'm in the process of updating the IGC libraries to C++11. So I'm about half way done resolving the syntax issues of moving the code away from MS centric stuff, but once it actually compiles into a dll I'll have build a testing framework to make sure it actually still works the same as the classic allegiance.

At that point, we'll have a cross-platform version of the game's mechanics and physics engine. The next step would be to build a new network layer, which if done right, might allow us to replace the dplay libraries from alleg and get the current clients talking to a cross platform server, while development on an openGL based client continues.

The end goal is to build a GPL engine that can play classic alleg, making use of modern tools and frameworks to reduce the amount of stuff we have to manage, and to hopefully make the project easier for new developers to get inovlved in. If we ever got around to implementing "allegiance 2" from the ground up using that engine, we'd have a completely free allegiance at that point. But this is all about two weeks worth of two weeks worth of work.

I plan to get what I have properly split up and licenced so that my modified IGC code (MSR-SSL) and everything else (GPL or LGPL) can live in separate repositories, but once that's done I'll get them on github so that people can get involved or watch the train wreck unfold.

I ultimately want the work I'm doing to complement what's been done by the community thus far, but I think many of us know that the dependance on DirectX 9, COM, and ATL really makes the project a royal pain to work with. These technologies won't be around much longer, so I would like to bring the source into the modern age while we have the chance.

Also, C++11 is so damn awesome. Takes so much of the pain out of type safety.

factoid · Post by **factoid** » Fri Mar 07, 2014 7:10 pm

While working on the IGC port (39 of 40 object files generating... I came across this)

In the event that the original writer is still kicking around, and looking for the solution.

Code: Select all

    // I know there is a better way (using math) please show me how! (i forget)
    if(itoken==0)
        return c_pbm1;
    if(itoken==1)
        return c_pbm2;
    if(itoken==2)
        return c_pbm3;
    if(itoken==3)
        return c_pbm4;
    if(itoken==4)
        return c_pbm5;
    if(itoken==5)
        return c_pbm6;
    if(itoken==6)
        return c_pbm7;
    if(itoken==7)
        return c_pbm8;
    if(itoken==8)
        return c_pbm9;
    if(itoken==9)
        return c_pbm10;
    if(itoken==10)
        return c_pbm11;
    if(itoken==11)
        return c_pbm12;
    if(itoken==12)
        return c_pbm13;
    if(itoken==13)
        return c_pbm14;
    if(itoken==14)
        return c_pbm15;
    if(itoken==15)
        return c_pbm16;

Here's how you do it...

Code: Select all

  return 1 << itoken;

Post by **Papsmear** » Sun Mar 09, 2014 12:37 pm

factoid wrote:QUOTE (factoid @ Mar 4 2014, 08:24 PM) UPDATE: Git repository is now live. I have the core igc object files compiling, and am now in the process of unit testing a shared library
https://github.com/Factoid/alleg-core

About 2 months ago I started missing Allegiance a lot, even though I still don't have a lot of time to fly regulairly. I work and game mostly in Ubuntu these days, so the lack of a linux client also hurts a little. So what started out as a though experement and a little bit of exploratory hacking has turned into what I hope will be the start of a new chapter for the software. To date I have written an asset decompiler which converts the allegiance mdl files into open formats (obj, png, json, etc..) for use by a yet unwritten client, though I also have an MDL viewer which renders the results of my decompiler app, it's proof of concept, but it works.

Right now I'm in the process of updating the IGC libraries to C++11. So I'm about half way done resolving the syntax issues of moving the code away from MS centric stuff, but once it actually compiles into a dll I'll have build a testing framework to make sure it actually still works the same as the classic allegiance.

At that point, we'll have a cross-platform version of the game's mechanics and physics engine. The next step would be to build a new network layer, which if done right, might allow us to replace the dplay libraries from alleg and get the current clients talking to a cross platform server, while development on an openGL based client continues.

The end goal is to build a GPL engine that can play classic alleg, making use of modern tools and frameworks to reduce the amount of stuff we have to manage, and to hopefully make the project easier for new developers to get inovlved in. If we ever got around to implementing "allegiance 2" from the ground up using that engine, we'd have a completely free allegiance at that point. But this is all about two weeks worth of two weeks worth of work.

I plan to get what I have properly split up and licenced so that my modified IGC code (MSR-SSL) and everything else (GPL or LGPL) can live in separate repositories, but once that's done I'll get them on github so that people can get involved or watch the train wreck unfold.

I ultimately want the work I'm doing to complement what's been done by the community thus far, but I think many of us know that the dependance on DirectX 9, COM, and ATL really makes the project a royal pain to work with. These technologies won't be around much longer, so I would like to bring the source into the modern age while we have the chance.

Also, C++11 is so damn awesome. Takes so much of the pain out of type safety.

Factoid,

There was a conversation on Mumble last night about what you have been doing and it sounded awesome, so I came looking to see if you had posted anything about your work and found this thread.
I just wanted to say thank you for what you are doing myself, other devs and the community as a whole will be forever in your debt.

Paps

PS: I didn't realize you were a Cannuck?

factoid · Post by **factoid** » Sun Mar 09, 2014 1:43 pm

Thanks for the support, long way to go, but I desperately want a linux client so I can play on my laptop, and I see this game as culturally significant and worth preserving. Hopefully that'll be enough motivation to keep me going until the end, or until it's far enough along that people can carry it on. If there are any other devs left, I would encourage them to grab a copy of the code.

Also, if anyone who's experienced with the current alleg code has any opportunity to get it building with some version of VC2013, I believe it has enough C++11 features that we'd stand a chance of merging my changes back into the main trunk.

UPDATE: Fixed the outstanding linker references. Was able to compile an application which links against libigc.so, instantiates a CMissionIGC object and shuts down. Next order of business is to load a core without crashing and confirm the data is good.

factoid · Post by **factoid** » Wed Mar 12, 2014 5:30 am

Feels a bit weird posting updates rather than edits without anyone else in the thread. My apologies if that bugs anyone.

Loading of cc_14 is successful, though it's not setting the ammo object. It's fairly significant that this much is working, though I'm trying to vet that all the data is loading correctly. First steps have been taken however, and I'm confident that things will fall quickly into place.

Post by **Dome** » Wed Mar 12, 2014 8:49 am

factoid wrote:QUOTE (factoid @ Mar 11 2014, 10:30 PM) Feels a bit weird posting updates rather than edits without anyone else in the thread. My apologies if that bugs anyone.

Loading of cc_14 is successful, though it's not setting the ammo object. It's fairly significant that this much is working, though I'm trying to vet that all the data is loading correctly. First steps have been taken however, and I'm confident that things will fall quickly into place.

absolutely incredible that so much has been done and is working.

Factoid you are awesome.

Thank you!

doofus · Post by **doofus** » Wed Mar 12, 2014 10:10 am

factoid wrote:QUOTE (factoid @ Mar 12 2014, 05:30 AM) Feels a bit weird posting updates rather than edits without anyone else in the thread. My apologies if that bugs anyone.

There's probably a few lurkers like me popping in and reading this, so keep going!

_xJammer_ · Post by **_xJammer_** » Wed Mar 12, 2014 11:22 am

How much re-writing would alleg's IGCs require to interface with the rest of the engine btw?

P.S. Currently it appears that 2 projects have spawned at approximately the same time:
Factoid's - aiming to re-use much of the allegiance code as a kick-start, focusing on GPL code
Djole + Co - aim is to have a clean clone of allegiance, with no MS code to start with, focused on simplifying modding (game logic done in text-editable lua) and keeping the engine code closed, permitting to commercialise/put it on Steam/kickstart/etc. (GPLing the code at any step when the team decides to seize development)

We have considered working together, but as the initial goals seem to be drastically different, it did not seem worthwhile to merge the projects.
Hopefully at least one of the project succeeds

factoid · Post by **factoid** » Wed Mar 12, 2014 12:02 pm

Not completely sure, but I think all that's required of an engine to interface with a mission object is to implement the IsiteIGC interface. But I don't mean to downplay the amount of work that represents. But it was nice of MS to provide such a clear interface for any client/server.

raumvogel · Post by **raumvogel** » Wed Mar 12, 2014 2:05 pm

doofus wrote:QUOTE (doofus @ Mar 12 2014, 06:10 AM) There's probably a few lurkers like me popping in and reading this, so keep going!

I'm with you.This is fantastic.It's good to know so many others realize this is the best game there is wether you've ever played it or not!
I noticed on the beta that there is a raumcore

developed by Turkey III that has a auto command feature installed.It's going to help the imbalance caused by newb commanders that want to play being discouraged when they get constantly stomped by experienced commanders.
I hope 2014 is the year that this game has a total revival to insure that it never dies.

Thank you to all the devs that are making this happen!