Reversing to Orion - project 1oom

[Yankes]

dos console version look working, and graphic version do not (tested using DosBox from GoG MoO). Any mouse click crash game.

another bug in console version `s s +10` does not work as advertised.

[Kilgore T.M. Replicant]

dos console version look working, and graphic version do not (tested using DosBox from GoG MoO). Any mouse click crash game.

Worked for me on Debian DOSBox. Try with -noaudio and link to and/or PM me your dosbox conf file. I won't spend much more time on that port.

another bug in console version `s s +10` does not work as advertised.

I will take a look when I get the "write ad-hoc parser" itch again. I'd be happy if someone rewrote all of src/ui/cmdline/.

edit:

Open dosbox-*.conf, find the "sbtype=" line and change it to "sbtype=sb16".  (What is it currently?) Code that works with sbpro2 and sbpro1 is now up in GitHub. Older sb models remain broken, but now produce an error message and exit. I have no interest in debugging Allegro sound drivers.

"s s +10" adds 10 to the slider value displayed after SHIP. The bug must be in the help text. I don't know what you expected.

[Kilgore T.M. Replicant]

1oom v0.3 has been released. Changes:
    - new HW libraries: SDL2 and Allegro 4
    - new OS: MSDOS
    - win32 version now actually compiles
    - numerous bugs fixed
    - a log file is written by default
    - cmdline UI has emerged but is not fully playable yet
    - pkg-config support added for easier compiling
    - saveconv supports text input for debugging

Source code: https://github.com/KilgoreTroutMaskReplicant/1oom
Binaries: https://github.com/KilgoreTroutMaskReplicant/1oom/releases/tag/v0.3
Homepage: https://kilgoretroutmaskreplicant.github.io/1oom/

HELP WANTED!

The code still needs a lot of testing; play it and yell if it breaks! When it does, make a copy of 1oom_save8.bin pass it along the bug report.

[Yankes]

One semi bug in SDL1 version, it always grab mouse and center it, because you can't easy alt-tab or move window around because of this.

[Kilgore T.M. Replicant]

One semi bug in SDL1 version, it always grab mouse and center it, because you can't easy alt-tab or move window around because of this.

It shouldn't grab the mouse when it starts in windowed mode. Does middle click or Ctrl-F10 not release the mouse?

[Yankes]

It shouldn't grab the mouse when it starts in windowed mode. Does middle click or Ctrl-F10 not release the mouse?

Right, this is correct, simply when I start game and click on it, and it will gab mouse automatically (that I did not notice before). And them I had problem that I described.
Overall I think best would be when game loose focus it should do action from `Ctrl-F10` too. Because otherwise every time cursor is over game windows (even it is in background) it will center cursor to window. With `Ctrl-F10` it release mouse and stop move it around, that I would except when I do alt tab.


btw I see I forget to post answer to your previous question, nosond work better and problem with `s s +10` is probably more with console than parsing, when I type `s s 10<up><backspace><backspace><backspace>+10` it will not work correctly, overall cursors are not handled in expected way and probably is not fault of your code.
For new bugs your last dos version crash when you move cursor to top edge of screen and overall crash when click (no sound set in dosbox config).

[Kilgore T.M. Replicant]

Right, this is correct, simply when I start game and click on it, and it will gab mouse automatically (that I did not notice before). And them I had problem that I described.

So what was the problem? When the mouse (or rather, the input) is grabbed, Alt-tab should not be possible. Middle click or Ctrl-F10 and you should be able to move/resize the window and alt-tab as normal.

Overall I think best would be when game loose focus it should do action from `Ctrl-F10` too. Because otherwise every time cursor is over game windows (even it is in background) it will center cursor to window. With `Ctrl-F10` it release mouse and stop move it around, that I would except when I do alt tab.

I agree. I don't see how the game would lose focus while the input is grabbed but then I run a rather minimalist UI... it's probably some SDL event I'm not handling properly. I will take a look. Thanks for the report!

btw I see I forget to post answer to your previous question, nosond work better and problem with `s s +10` is probably more with console than parsing, when I type `s s 10<up><backspace><backspace><backspace>+10` it will not work correctly, overall cursors are not handled in expected way and probably is not fault of your code.

The code supports readline which supports cursor key handling, but the win32 build was built without it. I'll see if I can add it easily in the next version. What still baffles me is how I was supposed to infer this from your message.

For new bugs your last dos version crash when you move cursor to top edge of screen and overall crash when click (no sound set in dosbox config).

Hmm, I'll test the mouse edge thing.

Note that the following things are not equivalent:
1. setting nosound=true in dosbox conf
2. setting sbtype=none in dosbox conf
3. running 1classic with -noaudio
4. turning off your speakers

Option 3 should fix the crash if it is sound related. Setting sbtype=sb16 should work as well.

What is sbtype set to in GoG MOO1?

[Yankes]

The code supports readline which supports cursor key handling, but the win32 build was built without it. I'll see if I can add it easily in the next version. What still baffles me is how I was supposed to infer this from your message.

You can't, fist I thought that syntax is incorrect (I repeat this couple of times and I do not know how I manage to repeat this bugged sequence without realizing it), and after your reply I tried this again and it worked. Then I start examining this again and find what exactly cause this bug.

Hmm, I'll test the mouse edge thing.

Note that the following things are not equivalent:
1. setting nosound=true in dosbox conf
2. setting sbtype=none in dosbox conf
3. running 1classic with -noaudio
4. turning off your speakers

Option 3 should fix the crash if it is sound related. Setting sbtype=sb16 should work as well.

What is sbtype set to in GoG MOO1?

I set option (1). Config in attachment.

[Kilgore T.M. Replicant]

You can't, fist I thought that syntax is incorrect (I repeat this couple of times and I do not know how I manage to repeat this bugged sequence without realizing it), and after your reply I tried this again and it worked. Then I start examining this again and find what exactly cause this bug.

Ah, OK. I will try to get the next binaries to behave better.

I set option (1). Config in attachment.

Thanks. Now please do option 3 (1classic -noaudio) and tell if it fixes the crashing. Options 1 and 4 are equally effective.

I tried to make the DOS version crash by moving the mouse to edges. Never does that for me. I did add some new related code on git; no new binaries yet.

This may be silly question, but... are you actually running this via DOSbox? Does Windows allow running 32bit DOS programs without it these days?

The SDL versions were indeed not releasing the mouse grab when losing focus. Turns out SDL2 allows alt-tab while input is grabbed... learn something every day. Both SDL1 and SDL2 (hopefully) fixed on git, binaries will follow some day.

... speaking of which, nightly builds would be cool but I have no idea how to set those up. Tips and/or webspace welcome.

[Kilgore T.M. Replicant]

... so has anyone gotten the DOS version to work, audio or not?

Here's some untested binaries. Now with -uiscale N for the sharp eyed and readline for the typists.

The project could use some almost-nightly builds. I'd need some "latest builds" directory to point at in the homepage. The builds would be made and uploaded manually by me. If you have some tens of megabytes of webspace (and bandwidth) to spare and want to help out, please contact me.

(EDIT: ancient build removed)

[SupSuper]

... so has anyone gotten the DOS version to work, audio or not?

Here's some untested binaries. Now with -uiscale N for the sharp eyed and readline for the typists.

The project could use some almost-nightly builds. I'd need some "latest builds" directory to point at in the homepage. The builds would be made and uploaded manually by me. If you have some tens of megabytes of webspace (and bandwidth) to spare and want to help out, please contact me.

DOS version doesn't work for me, either executable just gives me the message "Load error: no DPMI - Get csdpmi*b.zip".

As for autobuilder, I would suggest looking into CI, there are a bunch of free solutions though I don't know any that fit your exact case:
- Travis - Linux machines, you can easily just feed it your GitHub and make and they will build/test/deploy whatever you want, but I doubt they're set up for cross-building Windows executables.
- Appveyor - Windows machines, but they only build Visual Studio projects.

Otherwise you will just have to convince someone very generous. If you build them yourself, can't you just store them on GitHub Pages? Might have to eventually purge them from Git history to avoid bloating it with old builds.

[Kilgore T.M. Replicant]

DOS version doesn't work for me, either executable just gives me the message "Load error: no DPMI - Get csdpmi*b.zip".

Was this from the zip in the previous post? If so, then it's the missing cwsdpmi.exe which is (or should be?) included in the v0.3 release (and available elsewhere). I better include it in these builds too.

As for autobuilder, I would suggest looking into CI, there are a bunch of free solutions though I don't know any that fit your exact case:

Thanks, but I doubt they fit. I gather DOS cross compiles are rare these days. My problem is not building them, but hosting.

If you build them yourself, can't you just store them on GitHub Pages? Might have to eventually purge them from Git history to avoid bloating it with old builds.

Storing binary zips in git repos is all kinds of wrong.

Otherwise you will just have to convince someone very generous.

The best way for me to do this is to STFU and get back to coding.

Oh and thanks for the GoG PR. Here's to hoping your estimates in victim luring power are accurate.

[SupSuper]

Was this from the zip in the previous post? If so, then it's the missing cwsdpmi.exe which is (or should be?) included in the v0.3 release (and available elsewhere). I better include it in these builds too.

Ah sorry, forum attachments aren't the easiest way to track builds.
Game works fine now (with and without sound) but I'm getting the same issue as Yankes, touching the screen edge crashes the game. Tried on DOSBox 0.74, Daum build and X build.

If it helps, I'm running the game by just copying your files directly into the MOO1 folder.

Oh and thanks for the GoG PR. Here's to hoping your estimates in victim luring power are accurate.

Posted on Steam too. Doesn't seem to have done much, but here's hoping.

[Kilgore T.M. Replicant]

Game works fine now (with and without sound) but I'm getting the same issue as Yankes, touching the screen edge crashes the game. Tried on DOSBox 0.74, Daum build and X build.

Thanks for testing. I can't reproduce the crash on the Debian stable DOSBox (also 0.74). The mouse coords on the recent builds are limited both via Allegro and in 1oom code. I can't fathom where the problem lies. I guess the next step would be hunting down the source for the version you use, but I think I've wasted enough time on the DOS version as is.

Posted on Steam too. Doesn't seem to have done much, but here's hoping.

Thanks! Meanwhile, I'll continue to abuse the forum attachments.

(EDIT: stopped abusing forum attachments)

[Yankes]

Is always "printf" hack to find bug cause, this could track variables and see where is difference.