Orbiter Space Flight Simulator is now open source

So space flight is much closer to sky diving than to air flight.

Basically shoot upwards until you get an encounter, speed up until it auto slows you down near the Mun, then kill velocity to fall in and land.

Grossly and hilariously inefficient but actually easier to perform than the "correct" way (and typically faster in player-time).

I was once asked to describe KSP and the best answer I could come up with is: "It's a game about speeding up and slowing down".

The base game is workable but it really depends on 3rd party addons to do your planning and calculations and have somewhere to take off from and something to fly and somewhere to fly to.

The 3rd party addons were often FOSS licensed and despite much noise about the glories of FOSS, never got much public help, typically. A 100 dev sized project benefits greatly if a 10 dev company releases it under a FOSS license and 500 people step forward to help. A 2 dev sized project where nobody steps up to help the original dev for some decades doesn't benefit much from FOSS despite in theory "it could have happened".

There was a fear that the game being only playable with 3rd party mods, and FOSS being famous for forking, the overall project would die if the overworked single individual 3rd party devs were smacked with having to work against uncountable forked versions the 3rd party devs may have never seen or even have hardware to run (like a port to a phone maybe). The whole project can only move as fast as the slowest dev if its only usable in toto as a flotilla. Its not a game with DLC, its more like a API with a huge collection of compatible software that'll only remain compatible if nothing changes.

If you're familiar with minecraft or rimworld or similar heavily modded games, imagine if you took "everything" out of those games and put it all into addons such that they were essentially unplayable without the addons. Like imagine if vanilla MC didn't have mobs or tools or blocks, it just rendered steve in an empty 3d world.

So if FOSS didn't supercharge development, it would be useless to the overall project because pragmatically nothing happened despite the relicensing work, and if it did supercharge development, it would kill the project by wiping out the 3rd party devs whom are very handwavy the limiting factor.

Ironically as "complete" or "finished" software the core project doesn't or didn't need devs anyway. The "cool stuff" all happened in mods and addons. Want a new MFD? That's an addon. Want a new vehicle? That's an addon. Want a new system, like the complete model of an electrical system for some Mars thing I remember a decade ago? That's an addon. Want new planets and solar systems and stations and satellites? That's an addon. The base system is kind of a a window manager (yes I know its not "a window manager" per C++ code, but I mean conceptually it herds the cats of addons so they don't step on each other and generally cooperate and render to the screen). The base system needs significant development as the graphics APIs are two decades out of date, but for two decades there wasn't much to do that wasn't being done in mods anyway.

If everything is an addon its not clear what the base system could evolve into anyway. You could add multiplayer and commo, but that's best done in an addon. You could add mission video recording but that's best done by the video card and OS. I guess you could tidy up some addon API issues causing mass incompatibility issues so would it be worth it?

Much as the author originally feared, a dozen or two posts into the forum FOSS announcement and there's already talk about branches and forks and competing strategies for conversion to 64 bit that'll kill the 3rd party addons and mods that made the game usable, so the FOSS announcement is probably more an announcement of the death of the project than some kind of rebirth.

The only difference is that they would be obligated to release the source code. Given that the list of folk who can compile for consoles is very limited, this would not be an existential burden for them.

Indeed, even if they targeted a common development platform, like a PC or Mac, they would still be able to offer lots of value, and easily sell copies if there was a market for that. The vast majority of players would happily pay $49 for a compiled version of the game rather than go to the effort of compiling themselves.

In other words, the GPL and MIT licenses are orthogonal to making money - making money selling compiled GPL programs is not hard - assuming the program has some value to someone.

Counterpoint, many companies won't allow GPL software even if eventually it'd be open sourced again.

I personally wouldn't mind a for sale version of this game updated to run on my phone. Even if it's 15$ or so. Without a profit motive the number of people who would bother to continue development is much lower.

Your also free to fork it , make the ultimate version and GPL it

Now DXVK does not support DX7, but a quick search found dgVoodoo2, which does emulate DX7 under DX11. Maybe that or a similar library can be used as a stepping stone.

Regarding porting legacy apps to 64bit, the most problems i've seen were concerning old libraries (on Windows). That usually requires replacing old libraries with new a version, and fixing includes. I've seen only a handful of bugs arising purely from 32bit vs 64bit differences.

Having no knowledge of the code, I imagine if you have a functioning graphics layer, most of the work would happen on the underlying physics models and high level drawing/scene APIs, not directly interfacing with DX.

What I'm sure you were getting at is a proper conversion to DX9 making use of the shader based pipeline.

That said, looking at the code I don't think porting to proper shader based DirectX would be terribly difficult for anybody experienced in setting up directx in a shader based pipeline. Nothing looks too fancy.

Of course it could be made more complicated by actually making use of shaders to improve over the fixed function design, but that is not required for an initial port.