> 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).
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.
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).
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.
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 =)
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.
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).