They were all good, but I think one of my favourites was Keen Dreams with the giant potato monster at the end.
I think I eventually managed to get floppies with the full versions of most of Apogee's catalog through various friends/acquaintances.
"They just can't wrap their head around the fact that someone might build something because they like building things."
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.
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.
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).
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.
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.
It's just less fun.
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.
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.
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 =)
If that's the case, it should be trivial to re-implement the rendering in SDL or something.
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öé&<
I guess the server sharted and that was the result? Haha.
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?)
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.
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.
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.