Reversing to Orion - project 1oom

[Stoddard]

16b color is currently unsupported. I don't have an easy way to test it so I won't attempt to fix it. Patches welcome.

Here - https://gitlab.com/StoddardOXC/1oom/commit/1043353804aee6f9837d50164e1face7638e5b22

sdl2 only.  16/15 bpp now works. 24 bpp also works, but I didn't look if it didn't work before.

BUT! 8bpp still crashes (yes, RDP has that mode). But I'm not going into that.


EDIT: also the mouse is crazy  over rdp/vnc. But whatever.

 

[Kilgore T.M. Replicant]

Here - https://gitlab.com/StoddardOXC/1oom/commit/1043353804aee6f9837d50164e1face7638e5b22

sdl2 only.  16/15 bpp now works. 24 bpp also works, but I didn't look if it didn't work before.

Thanks! Small issues before merging:
- use log_error for the error messages
- die using exit(EXIT_FAILURE)
- use if (x == NULL) as the arguably superior (NULL == x) is not used elsewhere

BUT! 8bpp still crashes (yes, RDP has that mode). But I'm not going into that.

Wise decision. Let sdl1 handle the low end. Speaking of which, I guess I have to fix 15/16/24b for it now.

EDIT: also the mouse is crazy  over rdp/vnc. But whatever.

Care to elaborate? The sdl2 mouse code is a bit weird since using mouse events destroyed the performance.

[Stoddard]

Thanks! Small issues before merging:
- use log_error for the error messages
- die using exit(EXIT_FAILURE)
- use if (x == NULL) as the arguably superior (NULL == x) is not used elsewhere

Done.

Care to elaborate? The sdl2 mouse code is a bit weird since using mouse events destroyed the performance.

It looks like the mouse movement is multiplied by a factor of 50-100, even outside the game window. So it's completely unusable, and even closing the game from the main menu is quite a challenge.

Besides, what was the problem with the mouse events? I never heard or seen such a problem.

[Kilgore T.M. Replicant]

Done.

Cool. Send a PR/MR/whatever when ready.

It looks like the mouse movement is multiplied by a factor of 50-100, even outside the game window. So it's completely unusable, and even closing the game from the main menu is quite a challenge.

Hmm. A bug report appeared also stating problems with the sdl2 mouse movement. At least I know the wall I will be bashing my head against for the next few days.

I hope you have noticed the Ctrl-Esc shortcut and have not been wresting with mice to escape.

Besides, what was the problem with the mouse events? I never heard or seen such a problem.

Looking at the main menu and moving the mouse by some tens of pixels resulted in the animation freezing for about a second while the mouse crawled to the new position. Apparently the mouse events filled the event queue and everything ground down to a halt. Perhaps this only happens with high DPI mice.

I found the disable mouse motion events solution by googling but can't find it again. Commit 189fa32597f724c3ca0ad1e1adc42532c243d6d0 has the fix.

EDIT: Pushed sdl1 15/16/24bpp support. Test results on 15/16/24bpp setups would be helpful.

[Stoddard]

Cool. Send a PR/MR/whatever when ready.

Done

I hope you have noticed the Ctrl-Esc shortcut and have not been wresting with mice to escape.

For me, ctrl-shift-esc to task manager and then keyboard-killing the process works somewhat over RDP (ubuntu/remmina)

Hmm. A bug report appeared also stating problems with the sdl2 mouse movement. At least I know the wall I will be bashing my head against for the next few days.

Looking at the main menu and moving the mouse by some tens of pixels resulted in the animation freezing for about a second while the mouse crawled to the new position. Apparently the mouse events filled the event queue and everything ground down to a halt. Perhaps this only happens with high DPI mice.

I've reverted the ignore-mouse-motion commit, and even when spamming the log with events, it does not slow down noticeably. Still, the values I get when over RDP are insane:

Spoiler:

Code: [Select]

SDL_MOUSEMOTION abs 0 239 rel -102 0
SDL_MOUSEMOTION abs 0 239 rel -103 0
SDL_MOUSEMOTION abs 0 239 rel -256 0
SDL_MOUSEMOTION abs 0 239 rel -153 0
SDL_MOUSEMOTION abs 0 239 rel -154 0
SDL_MOUSEMOTION abs 0 171 rel -307 -68
SDL_MOUSEMOTION abs 0 171 rel -205 0
SDL_MOUSEMOTION abs 0 171 rel -205 0
SDL_MOUSEMOTION abs 0 171 rel -460 0
SDL_MOUSEMOTION abs 0 171 rel -359 0
SDL_MOUSEMOTION abs 0 171 rel -153 0
SDL_MOUSEMOTION abs 0 34 rel -512 -137
SDL_MOUSEMOTION abs 0 0 rel -717 -273
SDL_MOUSEMOTION abs 0 0 rel -256 -136
SDL_MOUSEMOTION abs 0 0 rel -256 -69
SDL_MOUSEMOTION abs 0 0 rel -410 -273


EDIT: Pushed sdl1 15/16/24bpp support. Test results on 15/16/24bpp setups would be helpful.

Works for me.


EDIT: minor nit in configure.ac:

Code: [Select]

-    gitversion=`$GIT describe --tags`
+    gitversion=`$GIT -C $srcdir describe --tags`

for out-of-tree builds.

[Yankes]

Done

For me, ctrl-shift-esc to task manager and then keyboard-killing the process works somewhat over RDP (ubuntu/remmina)


I've reverted the ignore-mouse-motion commit, and even when spamming the log with events, it does not slow down noticeably. Still, the values I get when over RDP are insane:

<untested hypothesis>
Because it RDP "fault":
a) RDP move mouse cursor to you real mouse cursor position
b) 1oom always center mouse cursor

Problem is that your real cursor is not moved. Then what happens? Both things fight where position should be, 1oom to center or RDP to your real cursor.
</untested hypothesis>

[Stoddard]

<untested hypothesis>
Because it RDP "fault":
a) RDP move mouse cursor to you real mouse cursor position
b) 1oom always center mouse cursor

Problem is that your real cursor is not moved. Then what happens? Both things fight where position should be, 1oom to center or RDP to your real cursor.
</untested hypothesis>

You know what?  I commented out the SDL_SetRelativeMouseMode() call and the madness went away. As in that the game became playable. I'm not sure why it's even needed, since this isn't a 3d-shooter.

Sure, this isn't a solution, just a band-aid. The actual bug is somewhere in rdp/directinput/sdl2/whatever interaction of course.
Still, RDP makes testing on windows that much simpler, and I'd appreciate an option to disable relative mouse mode.

PS.  OXCE+ doesn't have this problem either. It's SDL1, granted, but the 1oom sdl1 build does have erratic mouse, although not as bad as sdl2 one.

[Yankes]

I only connected dots, I could be right or it could be wrong, bu your change show that I guess right.

OXC could have this problem too, try middle click map scroll, IIRC it use relative mouse mode.

[Stoddard]

I only connected dots, I could be right or it could be wrong, bu your change show that I guess right.

Yeah, sorry for the tone, Yankes. I was too irritated by this mouse crap for two days.

Certainly the problem is in the relative mouse mode vs RDP/VNC.

Still for a game like MOO1 which does not have a use for a relative mode afaik, it's strange to insist on it, then build an absolute mode on top of that. I guess that's the origins of the code showing through.

EDIT:

OXC could have this problem too, try middle click map scroll, IIRC it use relative mouse mode.

OXCE+ sure doesn't  use relative mode for the battlescape middle-button scroll. Geoscape does, though, but it's fully usable if a bit too sensitive. A bit.

[Kilgore T.M. Replicant]

I've reverted the ignore-mouse-motion commit, and even when spamming the log with events, it does not slow down noticeably.

Maybe it's this stupid high DPI gaming mouse I have.

Works for me.

Thanks for testing!

EDIT: minor nit in configure.ac:

Code: [Select]

-    gitversion=`$GIT describe --tags`
+    gitversion=`$GIT -C $srcdir describe --tags`

for out-of-tree builds.

Good catch. I guess same goes for src/version.sh.

<untested hypothesis>

Nice!

You know what?  I commented out the SDL_SetRelativeMouseMode() call and the madness went away. As in that the game became playable. I'm not sure why it's even needed, since this isn't a 3d-shooter.

Thanks for the detective work. I'll try to get rid of the relative mouse mode. Also appears in bug #25.

The calls are there because sdl2 is a quick hack based on sdl1. I'm not an expert on either SDL. Sorry for the inconvenience.

EDIT: after some testing and recollecting...

1oom mouse usage is not absolute. Removing SDL_SetRelativeMouseMode is not a solution. Try commenting it out and:
1. Start/continue game
2. Move cursor over Next turn
3. Press cursor left to move to Game
4. Move back to Next turn using the mouse
5. Repeat from step 3 until mouse stops moving right

I can't see anything in the SDL mouse API that would allow what the MOO1 UI needs and RDP/VNC works with. Ideas?

Still, RDP makes testing on windows that much simpler, and I'd appreciate an option to disable relative mouse mode.

I assume this is even with the shortcomings. I'll reluctantly add an option for it. EDIT 2: Done: -norelmouse, SDL2 only.

[Kilgore T.M. Replicant]

1oom v0.5 has been released. Changes:
    - support mouse wheel for lists, sliders and zooming
    - add -uiextra for enabling extra UI features, notably:
        * new New Game screen with opponent selection (including AI/player)
        * planetary governor for less micro (click on name to enable/disable)
    - SDL: support 15/16/24 bpp
    - added documentation on differences to v1.3
    - some improvements from the unofficial patch v1.40m have been implemented
    - add Classic+ AI with small fixes, some from v1.40m
    - about 100 bugs fixed, notably:
        * the AI should now provide a worthy challenge
        * space combat works as it should
        * fixed many crashes
    - added doc/pbxin_fixbugs.txt for optional bug fixes
    - last and least: the "No Events" text overlay is implemented

Source code: https://gitlab.com/KilgoreTroutMaskReplicant/1oom
Binaries: https://gitlab.com/KilgoreTroutMaskReplicant/1oom/tags/v0.5
Homepage: https://kilgoretroutmaskreplicant.gitlab.io/plain-html/
Development builds: https://lxnt.wtf/oxem/#/1oom

HELP WANTED!

The project has reached a point where the game is fully playable, not crashing all the time and actually fighting back.

Many of the undoubtedly remaining bugs will need MOO1 expertise to spot. If you can beat MOO1 on impossible (which the project maintainer has yet to do) then please give this a whirl and report any oddities you encounter.

Late game saves with (near) max tech and huge fleets would be very helpful in debugging overflows. If/when you have some, please send them along.

Big endian hardware test results would be interesting.

[Kilgore T.M. Replicant]

you should probably add `ls` to console version (and pad support too ) because I do not see way to find all available planets, something like that:

Code: [Select]

lp [planet_name [max_dist]]       list all planets, if you add name it will sort by distance ascending, you can limit max distance
lf [planet_name [max_dist]]       list all fleets, if you add name it will sort by distance ascending, you can limit max distance


Several hundred commits later:

Code: [Select]

v [RANGE] [+DIST] [FILTERS]

Good things come to those who wait.

[Yankes]

btw mouse problems, over all if I understand correctly problem is that cursor keys can move mouse too, then what if you use `SDL_WarpMouseInWindow` when you use cursors? This teoricaly could keep both in sync.

[Kilgore T.M. Replicant]

btw mouse problems, over all if I understand correctly problem is that cursor keys can move mouse too, then what if you use `SDL_WarpMouseInWindow` when you use cursors? This teoricaly could keep both in sync.

The cursor is also moved automatically on some other occasions (usually setting it on a Continue button).

Isn't the problem with relative mouse mode that on VNC/RDP such warping does not work? I won't attempt a fix that I can neither test nor be sure if it would help any.

[Yankes]

I did not test this, end even never try using this function, but I except this could avoid most problems.

Right now when using SDL relative mouse need move real mouse to center, and you use only relative motion to move display cursor around.
If you do not do this and you use keyboard arrow keys then real mouse and display cursors go out of sync.
This have drawback of that RDP always can overwrite mouse position this make SDL and RDP fight each other.

Now we change approach.

Instead of relative we use absolute mouse position. SDL do not move mouse anywhere only read its position.
If you press keyboard arrow key then and only then SDL move real mouse to expected position, this will keep real mouse and display cursors in sync.
When you did this with RDP then it again move mouse but now SDL do not try move it again. Fight is over because SDL give up without fight.

Side effect:

Arrows keys do not working in RDP, but as it do not work now ether so we do not lose any thing.


Again this is not tested, I could even misunderstood how `SDL_WarpMouseInWindow` work, but if I guess it right it should work as described.