source code found?

[Levellass]

The fact that they don't care about Keen at all should make them apt to dish out the goods, but corporate mentality says "HURR GOTTA PROTECT MUH IP THAT I'M TOTALLY NOT USING CUZ PROFIT AND STUFF DURR"
Makes me sick.
When I grow up, I vow never to become a corporation. >:

Actually I've noticed that attitude among several keeners. (Looking at YOU KeenRush! Release the patches!)


I personally think that it's simply an issue of least risk. If you DO anything there's an attached risk, even if you don't know what it is. If there's no pressing need for the company to do anything, why bother? You never know how it might come back to bite you. You can see this all over the place, even in the face of massive fan demand. (Not mentioning any names here...)

[Keening_Product]

Maybe we have iD all wrong? Maybe the delay is because they're painstakingly going through the code, annotating each line to help us better understand it when they release it with their new, updated level editor.

[StupidBunny]

"We need that source code as a base for our ongoing project, 'The Universe is Toast!' Coming Christmas 2092"

[NY00123]

While it won't change anything, I'd still quote a post of mine from the same topic on duke4.net:

*** Quoted post begins here ***

Although the following come from 2010, it may still be interesting to refer to the following posts on Bethesda's blogs at the least (note that regional restrictions may be applied):

- A post from December of 2010, remembering Commander Keen after 20 years: http://www.bethblog.com/2010/12/14/reme ... ars-later/
- An earlier post from March 2010; There isn't a lot which is written, and it's more of a link to an article on RockPaperShotgun (http://www.rockpapershotgun.com/2010/03 ... nder-keen/), but it's still a reference to the Commander Genius project which was done: http://www.bethblog.com/2010/03/30/new- ... is-genius/. Truly, it is mistakenly named a "mod" in the post. That may simply be a mix-up with these VGA(-like) graphics (which may be unmaintained these days).

[guynietoren]

Not a complete rewrite. But yeah the GUI and such would need an update. We could finally do away with DosBox. I'm sure a lot could just be merged with the CG code. I'm sure having the exact code for physics, enemy AI and such would speed up a lot of guess work.

[NY00123]

A bit late, but here is a comment from George Broussard on the topic which I've just found: https://twitter.com/georgeb3dr/status/4 ... 7694344192

The comment itself for reference:

I'm sorry Commander Keen is in limbo now. Always thought that would have been an ideal console/mascot franchise like Jak&Daxter or Mario.

[NY00123]

[If any moderator thinks my two posts should be merged, I have no problem with that.]

As for the ability to take advantage of any original engine, as well as Commander Genius, I'd tell what I know at the least, from the work on Chocolate Keen.
- First, we're talking about 16-bit code, with a segment addressing model, which is surely different from the way it's done on many of today's commonly used platforms. Of course it's not impossible to port, since we've already gotten ports of Wolfenstein 3D and Spear of Destiny (for a few examples).
- Furthermore, anything to do with direct access to hardware, DOS interrupts and the like needs to be modified and/or replaced. Again, not impossible as shown by ports of Wolf3D.
- In fact, it seems like Wolf3D and Keen 4-6 share very similar, if not identical, sound code (and maybe also common input code).
- While I'm not familiar with most of the Commander Genius codebase, on the one hand, it is mostly a rewrite not based on original codes directly, so there are major differences between Commander Genius and vanilla Keen codes.
- On the other hand, code can surely be shared. It is the case that Chocolate Keen takes advantage of uncompression routines found in Commander Genius (possibly with minor/syntactic modifications). Similarly, Commander Genius has some amount of code from the Omnispeak project in use (not sure how much and which code, though).

[Paramultart]

I think double-posting can be appropriate in the case of long, informative posts, or in the case of bumping an old thread.

Of course, there are certain mods who would be inclined to disagree...

[Levellass]

I honestly don't think it matters that much, who here really cares?

[Paramultart]

... I can think of one person.

[Malvineous]

For what it's worth, as someone who ported Xargon from DOS to Linux/Windows, it can be easy or hard depending entirely on how the code is structured.

For well written games, there are usually a set of functions that deal with the hardware directly, so you only have to replace these with modern equivalents and the game will work on another platform. But in reality there are other things that even programmers don't normally think about. For example, with Xargon:

• Any code loading or saving files (saved games, levels, graphics, etc.) assumed integers were 16-bit and all values were little endian. These all have to be rewritten to load the structures field by field in a platform neutral way. It is possible to change "int" to "short" to quickly make the code work, but then it only works on little-endian (Intel) systems - it won't run on ARM systems like tablets.
• Some code relies on integer wraparound. 32767+1 = -32768 for example. Trying to find all these variables and changing them to the correct type (int to short for example) can be quite a lot of effort.
• Because DOS gave you full control of the hardware, some games accidentally wrote into random memory locations due to various bugs (typically reading or writing past the end of an array.) Under DOS nothing was using that memory so nothing bad happened, but today this is a security risk so when it happens your program crashes. Finding and fixing these bugs can take a while.
• The segment:offset memory model wasn't actually a problem because the game was simple enough that this was all handled by the compiler.

I think porting Keen would not be too much of a challenge, especially as NY says, sound and other code has probably already been ported in other games which would save quite a bit of effort.

[lemm]

I'm pretty sure it's not really about protecting the IP. It's because they don't want to spent any working time at all on thinking about releasing the source, since working time is money.

Yeah, but some guy already has the source in a zip file. They just need to take 5 minutes to send out a permissory email.

[Levellass]

[*]Because DOS gave you full control of the hardware, some games accidentally wrote into random memory locations due to various bugs (typically reading or writing past the end of an array.) Under DOS nothing was using that memory so nothing bad happened, but today this is a security risk so when it happens your program crashes. Finding and fixing these bugs can take a while..

Aaah yes, classic, classic stuff. I know of a program that only worked because it overwrote itself somehow.

[Keening_Product]

How many legal hoops need to be jumped through to release something as OS or to change IP ownership? It could well be iD is planning to sell Tom Hall the rights for some symbolic amount but needs to draft the legal documents first and hasn't got around to that yet.

Now to play Malv's Xargon port...

[NY00123]

For what it's worth, as someone who ported Xargon from DOS to Linux/Windows, it can be easy or hard depending entirely on how the code is structured.

For well written games, there are usually a set of functions that deal with the hardware directly, so you only have to replace these with modern equivalents and the game will work on another platform. But in reality there are other things that even programmers don't normally think about. For example, with Xargon:

• Any code loading or saving files (saved games, levels, graphics, etc.) assumed integers were 16-bit and all values were little endian. These all have to be rewritten to load the structures field by field in a platform neutral way. It is possible to change "int" to "short" to quickly make the code work, but then it only works on little-endian (Intel) systems - it won't run on ARM systems like tablets.
• Some code relies on integer wraparound. 32767+1 = -32768 for example. Trying to find all these variables and changing them to the correct type (int to short for example) can be quite a lot of effort.

These points surely apply. It may be just me, but I think that when such code is ported to multiple platforms, it's really better to use types with fixed sizes like int32_t or uint16_t, rather than anything such as short or long.
Considering file handling, one non-portable operation is a read/write of a struct. Even if endianness isn't a problem at all, the actual size of a struct may be a bit larger than you think (a compiler magic, more or less).

• Because DOS gave you full control of the hardware, some games accidentally wrote into random memory locations due to various bugs (typically reading or writing past the end of an array.) Under DOS nothing was using that memory so nothing bad happened, but today this is a security risk so when it happens your program crashes. Finding and fixing these bugs can take a while.

That is surely a lot of fun. As someone wrote in your website, even while playing the game in DOS you may spot some strange behaviors like corrupted saved game names. I surely saw a few of these at the least back then.
If anybody is curious to know, it does look like Keen 1-3 doesn't suffer from such errors so much, although they do exist!

I'm pretty sure it's not really about protecting the IP. It's because they don't want to spent any working time at all on thinking about releasing the source, since working time is money.

Yeah, but some guy already has the source in a zip file. They just need to take 5 minutes to send out a permissory email.

It may seem to be the case, but as mentioned before it's not necessarily so simple. At least one lawyer may need to make a code audit in order to ensure that nothing bad occurs in the legal sense. What happened before the release of the Doom 3 source code (with an application of a patent) is a good example.