Omnispeak – A Commander Keen Reimplementation | Hacker News Reader

Omnispeak – A Commander Keen Reimplementation

davidgow.net

151 pointsrocky113855 comments

Even though the second Keen trilogy had richer graphics, I really loved the first Keen trilogy for the gameplay. The jumps and movement felt so much more physical. Keen would make this tiny pause as if winding up for a jump each time he jumped. The later Keen just did big floaty isometric jumps that didn't have the same snap. That said, I loved and played every single one of those games.

They were super cute. Boy genius builds a space ship powered by a car battery, fuelled by your parents wine and .. yea I forgot all the other things you had to collect in the first one.

They were all good, but I think one of my favourites was Keen Dreams with the giant potato monster at the end.

The Bean-with-Bacon Megarocket was fueled by Dad's Everclear, as I recall, and propelled with the vacuum cleaner.

Yep, and you needed the car battery and the joystick.

agreed, the first keen trilogy was right up there with prince of persia in terms of gameplay

He's bending his knees before the jump. I could never get the timing right in that game, though :(

I absolutely hated the pause when I was a kid. Nintendo got it right; there should be immediate feedback from pushing a button.

I found that jump mechanic very frustrating, but mostly because I could never time it perfectly!

Oh man, I loved the keen games. As a young lad in the UK, it always frustrated me how hard buying the full version of shareware software was - the buy screens always had US address/phone numbers for purchasing, and back in the early 90s convincing one's parents of the legitimacy of such a weird foreign transaction was no easy task.

I think I eventually managed to get floppies with the full versions of most of Apogee's catalog through various friends/acquaintances.

Ha, True! The strangest thing was that you could often buy games on floppies at the stores but they were almost always shareware, with just a single level to play. Never did we get original games, at least, not in the stores. Floppies were traded like crazy, legal games just didn't seem to be available back then. (At least here in the Netherlands, in the early 90's)

Even worse in South Africa! I only got to play the shareware versions as a kid from floppies included with (I think) Computer Shopper magazines, which my dad used to buy.

Holy smokes!! Commander Keen takes me back to when I first discovered hacking, clear back in the early/mid 90s. I actually met a good hacker friend of mine on a completely different continent on a train. He was playing Commander Keen on a laptop and playing the music super loud. I recognized it and introduced myself. That was almost fifteen years ago and we still work on projects together!

I'm sorry if I seem a little obtuse here, but... why? If you need the files from the actual game, and the actual game comes with the tools to run it (i.e. DOSBox), what is the benefit, or in fact the real purpose, of this project as-is?

To quote Mark Zuckerberg (about Hollywood and "The Social Network"):

"They just can't wrap their head around the fact that someone might build something because they like building things."

I'll take a native implementation over an emulated one any day.

Being intentionally obtuse here, that raises a simple question. Why not dual-boot into FreeDOS and play from there?

Then I can't be on discord and yell at my friends how cool this native re-implementation of Keen is.

Dosbox is slow; you need a relatively powerful computer to run most things. That also means it's not really something that you want to run on battery for a long time.

Even if that weren't true, I find value in documenting the old file formats and having readable implementations of the games that used them. From the point of view of the developer, it can be incredibly satisfying to see the functionality come together, and to get a picture of how things were done 25 years ago.

Thank you for putting it this way. I think the documentation's been done and released by the Apogee/Id guys, though - but I can understand someone else just wanting to be able to mess around with it. But I will say that I've never had any problems with DOSBox, personally speaking; even in terms of battery life.

Implementing the game is a good proof of the documentation ;-)

I'm obviously biased in favor of efforts like this. Part of the reason is that I'm going through another DOS game with a disassembler and trying to understand, document, and reimplement the game engine (it's going glacially; I'm no reverse-engineering expert, and I don't have much experience in assembly). To me, it's a fun subject for a hobby. And I don't like that a game that would run on a 25MHz 386 natively won't run at full speed in Dosbox in a computer built 10 years after the game's release (or on my various ARM machines, a modded game console, etc). Something feels "wrong" about that. I have the same feeling about the game being unmodifiable. I've seen how much came out from the open-sourcing of various id engines, and it would be great to see modifications, enhancements, and remixes of the other classics, too.

Is there a word for that deep realization of your mortality and existence; almost pain, that comes nostalgia?

https://en.wikipedia.org/wiki/Saudade

Nice!

It looks very cool! How does it compare to Commander Genius? http://clonekeenplus.sourceforge.net

I kept running into bugs while using Commander Genius (even before entering the first level, I managed to get Billy stuck "behind" the map. This one feels exactly like I remember.

Pretty funny that you mention that. You should know that a lot of Omnispeak Code is in Commander Genius. Not sure what version you tested, but you should take another look. Also the developers were part of the CG team.

> Omnispeak requires a computer with OpenGL 2.0 support

That is the strangest requirement. I could see requiring OpenGL 3.1+ Core for someone who really wants to use a GPU (despite how unnecessary that would be) and thinks that glBegin is Teh Devil. I could see requiring OpenGL 1.1 for someone who still wants to use the GPU but doesn't want to bother with GLSL or any of the later more complex APIs.

But why OpenGL 2.0? I could see it if the games needed some special effects or something through GLSL, but all Keen games do is basically blitting pixels around (and from a quick glance at github, all the pixel shader code in the source does is to draw the bound texture, nothing else), so they don't need that (nor the code does anything more than that).

OpenGL 2.0 was released over 10 years ago. Why is this requirement a problem?

Anything that is supposed to work should be tested, I can see why people don't want to test against more-than-10-years old APIs.

On one hand, I can see that too. On the other, it would be cool to have the Keen games as an option on something like a little ARM computer, and if what the other commenter said is true, and the game's just blitting a bitmap into a texture and displaying that, there are plenty of libraries to let you do that, while providing a number of different backends. Let the library figure out the actual API to use.

On the third hand...it would probably be super-simple to just port the thing to SDL2. And that might be a fun, short project =)

Because it's unnecessary, and precludes it from running on fun platforms otherwise fully capable of it - like the Zipit Z2 I am currently hacking on (which come to think of it is probably even fast enough to run the original inside Dosbox).

It's just less fun.

I think I still have one of those with an Emacs 23 install.

Watch out you don't leave it on the charger too long with a battery in it. The charge limiter is lacking or nonexistent, and the battery will overheat and swell.

Go into the Makefile. Set "WITH_SDL2=1" to 0. It'll compile with the software-based SDL1.2 backend instead. Runs perfectly on my BBB (actually, I don't have sound plugged in, and I keep seeing ALSA buffer underrun messages, so the audio's probably "blech", but the game itself feels great.

Granted, I think the ZZ2's CPU is like 1/4 the speed. On the other hand, the BBB doesn't seem well-suited to anything graphical.

It just strikes me as weird because it doesn't really need anything more than OpenGL 1.1 (assuming you want to use the GPU). When i see games require versions of OpenGL greater than 1.x but do not have any fancy functionality, it is usually because they want to use OpenGL Core. This isn't the case here, so i wondered why.

> all the pixel shader code in the source does is to draw the bound texture, nothing else

If that's the case, it should be trivial to re-implement the rendering in SDL or something.

> But why OpenGL 2.0?

Good news! After looking at the code for a bit, there's an SDL1.2 backend (disabled by default) that allows for software rendering. The game runs wonderfully on the Beaglebone Black sitting next to me.

Wow, takes me back to the BBS days of 28.8. Good times.

This link leads to an HTML full of garbage data that automatically downloads for me. What am I missing?

It does that if I try to visit it in Pale Moon or Chrome on Windows, but loaded just fine in Firefox on my phone.

Same. I was using Chrome on Windows

This is old so I guess it was probably a momentary problem for me, but it works fine in Vivaldi 1.8.770.25 on Windows for me.

Yep, it worked fine when I got home, a few hours later. There was a while where it was "wonky".

The header looked fine, the body started like this: <body>^_<8b>^H^C¥XÛrÛ8^R}¶¾¢<87>^OñLE"}M%^N]¯¥x<q¢<94>í©ÔÖÖ^Vdb$Ê$Á^E@Ë<9a><9a><87>ù<88>ýÂý<92>= r7;<89>3µ~<90>%^BÝèËéÓ="" Æ?<8c>&ç·<9f>?<8d>)we1ìÅü<

Oddly, there was random entified data in there:  ^V[^P¿8û0þpöé&<

That's... absolutely bizarre, I've never seen anything like that before. Garbled characters, but the hex in chevrons I've never seen, that combined with an intact body and html entities too...

I guess the server sharted and that was the result? Haha.

The hex is just the way that the editor chose to display it. I think it's just random-seeming binary data.

How does the copyright work with a Re-implementation?

The dev is just re-implementing the game engine. I think the Ep4 game files only included because it was a shareware release.

Still, I'm not entirely sure what the legal ground for the engine here is. It goes back to the whole issue with formats like mp3s/H264 (If you write a decoder entirely from scratch; do you still have to pay party x?)

I think the answer to the mp3/h.264 question today is yes, you do have to pay party X. The payment is for the license of the spec, I believe, and not the implementation.

for the patent you mean? if you didn't read it use the spec, but did a black box reverse engineering of the format, you'd still have to pay for the patent.

While it's (obviously) not a full endorsement from a legal standpoint, Carmack retweeted his announcement.

Does "historical preservation" count as fair use?

No.

It depends - e.g. it could count as fair use e.g. within a museum exhibit or for preservation on your own hardware; but it wouldn't count as fair use for distributing it to others or making available to public.

Partly, I think it matters where the information for the implementation came from. Clean-room reverse engineering would be the safest (one team disassembles the binaries and writes a spec for their behavior, a completely separate team implements an engine from the spec, having never seen any aspect of the original code).

The more chance you give someone to claim that your work is directly derived from theirs, the better their chances if they take you to court.

In this case it wouldn't really matter. From a copyright perspective, he might as well as copy the source code line for line. Wouldn't matter if the guy created it on a desert island having never heard of the original game and claimed it all a coincidence. It still infringes the copyright in the character, story, graphics, etc. But if the game is shareware or the code is, then it's fair game.

Just like I can't reverse engineer a Harry Potter novel from watching the movies and claim immunity from copyright.

People using cleanrooms are not worried about copyright, they're worried (primarily) about violating NDAs or license agreements. They have to prove that the engineers figured out everything on their own. Especially important when the thing you're copying is from a company that you may have had NDAs or license agreements with in the past. Or employ engineers who may have worked at the competitor and have trade secret knowledge in their head. You may end up with similarities of implementation, but have the clean room logs to back up your story. Even a clean room won't protect you from patent infringement if you end up with an infringing technology.

> It still infringes the copyright in the character, story, graphics, etc. But if the game is shareware or the code is, then it's fair game.

What? No, I'm talking about the engine, not any of the art/text/music. I'm assuming that someone would purchase the game and basically replace the main program binary; the replacement engine would use the original, copyrighted game assets, but would never be distributed along with the engine.

> Even a clean room won't protect you from patent infringement if you end up with an infringing technology.

That ought to be safe, with the game that the post is about.

amazing

Reply on news.ycombinator.com