sulix / omnispeak Goto Github PK

I am trying to port omnispeak to the retrofw line of devices.

This is a linux based portable handheld running a MIPS jz4760 processesor.

It uses SDL1 and I am using mipsel-linux-gcc 7.3.0. No issues were present when building this natively for x86 linux using SDL1.

The same build flags are causing very odd video glitches when you are backtracking on the handheld device.

Exactly half the screen becomes glitched. Going into the start menu or going forward fixes the issue.

Screen resolution of device is 320x200, but has an IPU so it can downscale any resolution from 800x600 and below to fit the screen.

Thank you in advance for your responses

A glitch commonly used to finish level 2 early in Keen 6 appears to crash Omnispeak, but only if level 1 has been loaded in the current game.

Steps to reproduce the crash scenario:

1. Start a new game in Keen 6 (1.4 or 1.5 both appear to work).
2. Enter Level 1 (Bloogwater Crossing) either from the world map or by F10+W warping.
3. Exit Level 1 in any way (finish it, die and return to world map, F10+E, or F10+W warp directly to level 2.
4. Enter Level 2 (Guard Post One) either from the world map or by F10+W warp.
5. Immediately at the start of Level 2, hug the right edge of the map (a few pixels off is fine), then Impossible Bullet up, looking down as you fly up to hit the top edge of the map (the trick and expected outcome can be seen in this speedrun at about 0:47)
6. Omnispeak terminates.

Note that if you enter level 2 without first having loaded level 1, the trick works and exits the level as expected.

Additionally, I was able to produce some other weird behavior (e.g. Keen teleporting to a completely unexpected part of level 2 instead of exiting the level) by substituting other levels for level 1 in the steps above, but these seem harder to consistently reproduce and most levels do not trigger a problem.

My guess is that Impossible Bulleting out of bounds in this level ends up reading something out of bounds of level 2's actual map data and runs into data left there by the previously loaded map. The outcome of this is probably different on DOS due to its different memory model, hence the trick reliably exiting the level on DOS vs. having unpredictable outcomes in Omnispeak depending on which level was loaded previously, the dimensions of that level, etc.

Tested with the Windows build from davidgow.net as well as my own win64 and win32 builds (FWIW, the Windows builds in the GitHub artifacts seem to crash upon entering a game for me).

Here is a playloop dump from the crash scenario, but I don't know if it tells you anything useful or manages to capture the frame that triggers the crash.

dumplevel2crash.zip

I see that there are implementation files for Keen 4 and 6, but when I try to run with the corresponding data it crashes. Or do I need a specific version?

Any chance an option to compile with the Nuked OPL3 emulator can be added? This would be accurate than the Dosbox implementation.

https://github.com/nukeykt/Nuked-OPL3

Spun off from #44.

When game data is in place that isn't explicitly the versions in this list...

...this window is displayed:

It would be better to display an error that tells the user that there is a version mismatch for the game data instead 👍

When I start omnispeak, I get this window:

This is what's written to the CLI:

$ omnispeak /gamepath /usr/share/omnispeak/keen4
Parsed 0 config options from "OMNISPK.CFG" over 0 lines
Warning: MM_GetPtr: Failed to alloc block (-1273300583 bytes) with system malloc. Trying to free some space.
MM_GetPtr: Out of Memory!

I built v1.1 from sources from https://github.com/sulix/omnispeak/releases/tag/v1.1. Here's a little information about my system:

• Arch Linux
• glibc 2.35-6
• make 4.3-3
• gcc 12.1.0-2
• cmake 3.23.2-1

Here's how I compiled it:

cmake -B build -S omnispeak-1.1
KEENPATH=/usr/share/omnispeak XDGUSERPATH=1 cmake --build build

I have copied the data/ directory in the archive to /usr/share/omnispeak/keen4, and acquired AUDIO.CK4, EGAGRAPH.CK4, and GAMEMAPS.CK4 from archive.org (which is also in keen4/).

Hi! Found this project, love it, hope to see it flourish. I used to speedrun these games so I thought I'd try out some "glitchy" actions I know of, might help get the behavior as close to the original as possible. I'm using DOSBox for the comparison so it's possible that differences have to do with emulation, but I consider it reliable for most things.

Onto the issue: there are some different behaviors surrounding the wetsuit item in Miragia between original and Omnispeak. These can all be tested by starting a new Keen4 game, warping directly to Miragia (via F10+W cheat), and navigating the level to the wetsuit: they also are reproducible with a save just before interacting with the wetsuit.

1. Wetsuit can be obtained from the ground in original; in Omnispeak, you have to jump in order for the pickup to activate (though I noticed that Keen doesn't visibly leave the ground).
2. Text upon picking up wetsuit displays between Keen portraits in original; in Omnispeak, the text only displays with the first Keen portrait and disappears when the second appears. (Alignment of text also seems off: not sure if this is unique here.)
3. In the original, there's a very short period of time where it's possible to bring up the status screen (the one that appears when you press the Enter key) before the level ending occurs. (In a speedrun context, this is used to override the sound effect of the ending jingle and ends the level faster.) I was unable to get this to work in Omnispeak, though it might be a matter of timing. In the original I would perform this by holding the up and right directional keys on top of Enter in order to buffer inputs for both dialog continuation and to bring up the status screen.

My operating system is Windows 7 64-bit and the Omnispeak version is from the download on the website (presumably v1).

Reported by Roobar here: https://pckf.com/viewtopic.php?p=106644#p106644

We save extra joystick bindings in OMNISPK.CFG, but for keyboard bindings, only those which fit in CONFIG.CKx are saved.

We should support saving / loading keyboard bindings just like joystick ones.

All commits after 05ecc8f are drawing irregularly sized pixels. A few rows are not drawn at the full width. Example.. (I've edited the image to highlight the problematic rows). All commits before this have perfect square pixels.

System info:
Intel i5 3450
NVIDIA Gtx 750 ti 2gb
Driver version 390.116
Xubuntu Linux 18.04

When I compile 05ecc8f using WITH_VULKAN=1, I get square pixels again. However, in the latest commit, using any combination of WITH_OPENGL and WITH_VULKAN, and WITH_SDL2=1 gives me non-square pixels.

When l play the original games in DosBox (gog versions for 4/5, version 1.5 for Keen 6), getting the exact score required (ie exactly 20000, 40000, 80000, etc) triggers a new life to be granted immediately. In Omnispeak if you have the exact score, the new life isn't granted until the next time your score increases.

This is easiest to test in Keen 6 by collecting the pizzas at the top of the BWB level at the start of a new game, which total 20000 points for the first new life. Doing that in the original game triggers a new life, but in Omnispeak it doesn't until you collect some other points.

I'm guessing the fix is changing > to >= on this line.

Aside: That function looks like it will also behave wrong if your score increased enough to trigger two new lives at once, but I don't know of any way for that to happen in practice (and so I have no idea what the behavior of the original games would be in that scenario).

I was wondering, will a software renderer ever be added? Or is OpenGL 2.0 the permanent requirement for Omnispeak?

I'm asking because this would make for a perfect version of Keen: Galaxy on the Wii, i have been using DOSBox but it stutters every couple seconds. CGenius also doesn't offer any instructions for building on linux, and even if it did it's buggy for the three Galaxy engine games.

Compiling a binary under Wii Linux (whenever this gets a sw render) would make this the ultimate way to play Keen on the Wii. This is just a suggestion that would be really good, but it's okay if you can't/don't want to add it, as it could be a very hard task.

Hi, thanks for your great work on this reimplementation. Recently I got curious about the root causes of some of the well-known bugs in Keen Galaxy (Keen 5 door wrong warp, Korath fuse, Impossible Bullet, etc.) and started reverse engineering them. I was pleased to find that Omnispeak faithfully copied the logic behind these bugs and it was a great help in understanding them.

However, I identified one bug from the original games which does not occur in Omnispeak for whatever reason: the Keen 6 eyeball platform camera bug. This can be seen here on YouTube and the steps to reproduce are as follows (I am pretty sure this should work in all versions of Keen 6, but definitely in 1.4):

1. Enter the final Bloog Control Center level of Keen 6
2. Stand on one of the eyeball platforms that hang from the ceiling in some of the last few rooms of the level.
3. Save the game.
4. Load the game. The camera will be showing an entirely different area of the level and will not correctly track Keen until he resets the camera by going through a door.

In Omnispeak, the camera just continues behaving correctly when I try to trigger this bug. My guess is that there is some slightly different platform collision logic triggering this bug in Keen 6 that is missing from Omnispeak but I haven't gotten far enough into disassembling Keen 6 to say.

Do you know why this bug is missing from Omnispeak, or would it be helpful for me to try to trace out the logic in the original Keen 6 EXE and share my findings?

Hi there!

I have just built omnispeak for the first time. Since those EGA games must have been tied to a 70Hz display mode back in the day, I am not surprised that the timing in this engine tries to replicate that (I guess original games ran at 35FPS, since thats an exact divisor for 70. At least Keen 1 did, so...)

However, I see you have a "Fix jerky movement" option which is very promising, since it could let the game run in uncapped FPS mode, where the only speed limit would be SDL2 vsync in SDL2_RenderPresent(). Well, this option does not do anything, and looking at the game logic I fail to see what code does it affect.
So, is it a "dummy" option for now, to be implemented in the future?

NOTE: The game video thread should simply rely on SDL2_RenderPresent() vsync to have a smooth movement, never use internal SDL_Delay() or similar stuff internally. Thats good for game logic if it goes in its own thread, but not for video if you want to get smoot movement synced to physical screen mode.

In level 11 of Keen 5, the game may crash and exit when jumping to collect the vitalins pictured in the first screenshot.

Steps to reproduce the crash:

1. Load Keen 5 and enter level 11 via world map, F10+W cheat, or save file (I have attached a save file for quick testing for this crash)
2. Reach the area around the middle of the map with the vitalins hovering near a switch that opens up a platform causing Keen to drop below
3. Walk right and jump to collect the vitalins
4. Omnispeak crashes, but only occasionally. It has a 50/50 chance of crashing while grabbing the items, the error message in question reads "RF_AddSpriteDraw: No free spots in spritearray"

Tested with the latest Windows artifacts (both 32bit and 64bit) and the 1.0 version hosted on David Gow's website, although the 1.0 version does not display the above error message and instead quits unexpectedly.

SAVEGAM5.zip

Very minor, but I noticed that the /NOCOPY command line arg used here is not documented in the readme

Sometimes — I think when the screen is scrolling quickly downward and to the right — when the screen scrolls off video memory, the SVGA-compatibility relocation of one page can end up with it overlapping with another page. This results in the screen flashing between the two pages, which now show (probably offset) versions of each other.

I've had this happen on both real DOS/EGA (A 486DX2-66 with a Cirrus Logic cl-gd5428 SVGA card), and under DOSBox, but haven't been able to reproduce it reliably enough to be sure any given attempted fix works.

The original games seem to move the offset by FREEEGAMEM (0x10000 - 3*screensize). We've, to date, been moving them to fixed locations one or two screensizes away from the edge.

Note also that there's an inconsistency between the screen size and the buffer size. Hmm…

Would it be OK to remove the copy protection screen from episode 6? Sure, Omnispeak's premise is to be as true as possible to the original, and in this context, it absolutely makes sense to keep the copy protection screen intact, but still ... it's a major nuisance, and we left the "identical look and behavior" territory in favor of convenience already with the in-game graphics menu and extended joystick support.

It would be perfectly fine to make this a compile-time or command line option, and disabled by default, but as it is now, having to consult http://www.shikadi.net/keenwiki/Keen_6:_Aliens_Ate_My_Baby_Sitter!#Actors each time before playing is a little cumbersome :)

(I can do the changes myself and issue a PR if this topic is accepted.)

The files in data/keen6e14 are marked as executable, when they don't need to be:

$ ls -l
total 112
-rwxr-xr-x 1 max max 42785 Dec 15 23:30 ACTION.CK6
-rwxr-xr-x 1 max max    15 Dec 15 23:30 AUDINFOE.CK6
-rwxr-xr-x 1 max max  1024 Dec 15 23:30 AUDIODCT.CK6
-rwxr-xr-x 1 max max   760 Dec 15 23:30 AUDIOHHD.CK6
-rwxr-xr-x 1 max max  1024 Dec 15 23:30 EGADICT.CK6
-rwxr-xr-x 1 max max 16683 Dec 15 23:30 EGAHEAD.CK6
-rwxr-xr-x 1 max max    47 Dec 15 23:30 GFXINFOE.CK6
-rwxr-xr-x 1 max max   402 Dec 15 23:30 MAPHEAD.CK6
-rwxr-xr-x 1 max max 23904 Dec 15 23:30 TILEINFO.CK6

These are also the only files in the data/ directory that are executable 👍

Travis CI is a popular CI with support for wide range of platforms and integrations. I have seen many projects utilise CI to build and deploy those binaries to artifacts placeholders. This would help projects save time on making new releases.

I realise the project is very much around Commander Keen, given that (as I understand it) Bio Menace is based off the Keen 6 engine is it possible add support for Bio Menace?

From the README:

Do you have a link to the patches that are described in the README, and perhaps a short guide on how to create these Keen 6 images?

Hi David

I would like to propose to you the idea of separating keen data and saves files from configurations for each of the games.

Instead of keeping everything in the same directory relative to the binary, it would be nice to keep audio.ck4 and savegame.ck4 in data/keen4 and all configuration files to remain in the same directory as the omnispeak binary.

This will make it a bit easier to transfer data files around.

If you disagree with idea, feel free to close ticket.

After blowing up the QED, the high score list is shown, but the new score is not added to it.

The code for this exists, but is accidentally(?) left commented out:

Steps to reproduce, assuming a case-sensitive file system is in use:

• Let Omnispeak create a new CONFIG.CK5 file.
• Quit Omnispeak and rename CONFIG.CK5 to config.ck5.
• Launch Omnispeak again, then quit, so it overwrites config.ck5.

At this point, the first four bytes of config.ck5 form the string "ck5", rather than "CK5".

Idea for solution: Implement a wrapper around fopen (CK_Cross_fopen?) which handles the case sensitivity issue on its own. In the future, such wrappers can also be useful for loading assets from different paths (say /usr/share/omnispeak and /path/to/some/mod).

I know the intent of Omnispeak is to stay as true to the original as possible, which had a game resolution of 320x200 meant to be played in a 4:3 aspect ratio. I really like the way Omnispeak looks when it scales the game for 4:3 currently. That said, would it be possible to optionally turn on support for a widescreen 16:9 aspect ratio?

Note that I don't mean strictly stretching the 320x200 game resolution to fit a 16:9 screen. Rather, I mean changing the game resolution to 427x200, which will give the correct pixel size when scaled to a 16:9 aspect ratio.

I noticed that in the Controller Configuration, you can map Jump, Pogo and Fire, but you don't have an option to configure "Status". The quicksave/quickload options would be nice too.

Program received signal SIGSEGV, Segmentation fault.
US_CheckParm (parm=0x7fffffffed5e "userpath", strings=strings@entry=0x456720 <vl_parmStrings>) at id_us_1.c:56
56			if (strings[i][0] == '\0')
(gdb) bt
#0  US_CheckParm (parm=0x7fffffffed5e "userpath", strings=strings@entry=0x456720 <vl_parmStrings>)
    at id_us_1.c:56
#1  0x000000000040ff9a in VL_Startup () at id_vl.c:731
#2  0x0000000000432114 in CK_InitGame () at ck_main.c:332
#3  0x00000000004325db in main (argc=6, argv=0x7fffffffeaa8) at ck_main.c:765
(gdb) p i
$1 = 3

The code in US_CheckParm() expects this array to be NULL-terminated, but there is an empty string instead:

When getting game over in Keen6 (and possibly in others), the scroll value is not reset when entering name into the high score. Sometimes this causes that name prompt is misaligned with the scoreboard.

The DOS/EGA renderer is way slower than the original Keen one, which causes problems both on real hardware (it's slow-but-playable on a 486 with a fast VLB card, but nigh unusuable on a 40Mhz 386 with an ISA VGA card), and potentially under DOSBox (where 3000 cycles is way too slow).

There are a few obvious optimisations we can attempt:

1. Actually move the tile buffer into video memory. This will speed up erase blocks and animated tiles, as we can copy 4 bytes at a time.
2. As a result, the tile buffer can scroll properly, rather than being copied around. This should drastically increase scrolling speed, which is the real bottleneck.
3. Write optimised blitters and call them directly. There's a lot of conditional code an indirection to pick both the VL_DOS backend, then check both source and destination surface type.
4. (As a bonus, add optimised 16×16 px aligned tile blitters, which would be much faster for the common case, and a 'scale' blitter or similar for the SW-scroller, which is absurdly slow. Maybe we'd need the scaler compiler, too, but baby steps.)
5. If we split up the functions which write to EGA memory, we can more easily support DJGPP farmem instead of nearmem (slower, but WinNT compatible), and maybe non-SVGA-compat mode wrapping. (The latter may be needed for a scrolling tile buffer anyway).
6. If we're still too slow, we can maybe investigate doing tilebuffer→tilebuffer copies when scrolling on a new tile which is already onscreen. The cache metadata would probably take enough memory and be slow enough to only make this worthwhile on very slow ISA busses, though.

I'm using Keen4 (v1.4) that works with the 1.0 version downloadable from the page. I tried to use a newer build from the CI. So I copied the datafiles from my older Omnispeak dir, got https://github.com/sulix/omnispeak/actions/runs/1162760365 "Windows Build" and neither of the exes (32/64) do anything. (running the exes just quits without message)

Then I tried https://github.com/sulix/omnispeak/actions/runs/1162760374 - "Windows Build (mingw-x86_64-RelWithDebInfo) " also quits without a message. "Windows Build (MSVC-x64-RelWithDebInfo)" Runs the keen4 up to title screen, but then crashes. Looking at it on MSVC debugger reveals it crashes with callstack CAL_HuffExpand/CA_CacheAudioChunk/CA_LoadAllSounds

I understand the CI builds are unstable, but since there isn't any tags for releases, I don't know which version I should use.

I created a couple packages for Arch in the AUR and thought you should know!

• omnispeak: Program and its data from this repo (plus a couple helper scripts)
• omnispeak-data: Game data from GOG packaged for omnispeak

Happy to make changes that better align with the UX you're after!

Feel free to close this issue, too, since there aren't any actionable items here 🙂