git clone https://gitlab.com/KilgoreTroutMaskReplicant/1oom.gitYep, get this on GitHub! :)I guess I have to. It will take a while; I have no account and hold some contempt at the platform. Meanwhile, elaboration on step 2: the IDA files (http://s000.tinyupload.com/index.php?file_id=74509813743672485250)
BTW, is it called project1oom, because you're reversing MOO1 -> 1OOM ?Yes.
Fist error, in comp.h `MAX3` is probably not properly defined.It should be unused and subject for removal.
Do the same with Master of Magic, and half of the internet will suck you off.
Do the same with Master of Magic, and half of the internet will suck you off.Tempting, but there's plenty of work left with this one. Besides, "1mom" sounds both normal and suspicious.
Tempting, but there's plenty of work left with this one. Besides, "1mom" sounds both normal and suspicious.
Curious what your process is for picking this apart, as there is not much documentation in using IDA this way.The process:
Last I tried I only managed to figure out some LBXs, can trade notes if you need.Thanks for the offer. I have them sorted out now, but doc/format_lbx.txt patches are welcome.
One thing that seems to be missing is the the status of the project. Is the game playable by now already? What are the goals for the next milestones/builds?The game should be fully playable. I will whip up a roadmap at some point. I plan to make monthly releases focusing on debugging the whole mess. With that said...
Also, as someone who is on linux and is too lazy to compile stuff, any chance you can make a snap/appimage autobuilder?Sorry, I have no idea what those are and am too lazy to find out.
Sorry, I have no idea what those are and am too lazy to find out.
They're pre-packaged universal linux build systems, essentially. OpenXcom uses this to distribute linux nightlies, and IMO the best thing since sliced bread on linux.Does it bundle the used libraries? In any case, smells a bit too much like exe+dll->zip solution that Windows folks take for granted. Running random binaries from the net always seemed weird to me and my brand of sliced bread is Gentoo...
Aside from that, you'll have my testing support on this one, once I manage to compile the bloody thing. It's been more than 10 years since I last played MoO 1, however, so it aint gonna exactly be an expert opinion though ;DThanks for the support. Ask if there is any compiling trouble. I'm from the "play for 1 day every 3 years" group. Never beat the game on Impossible...
I would recommend you to get some extra help at https://forum.freegamedev.net/, since you have a lot of people who work on FLOSS going about there.Visibility would be beneficial, although I don't really need more coders at this point; most bug fixes need to refer to the disassembly.
If you can whip up a few more screenshots and maybe a video I could write an article about it for the frontpage (it's been ages since it was last updated, but they still do get views).Screenshots: sure. Video? Nope, don't have the software or experience for it. I do appreciate more PR but fucking suck at it. ;)
Does it bundle the used libraries? In any case, smells a bit too much like exe+dll->zip solution that Windows folks take for granted. Running random binaries from the net always seemed weird to me and my brand of sliced bread is Gentoo...
I understand that compiling can be tedious in most platforms. In Linux, it's a few commands given in INSTALL. Perhaps one wishes not to have gcc & friends eating HDD space. Still it baffles my puny brain.
Thanks for the support. Ask if there is any compiling trouble. I'm from the "play for 1 day every 3 years" group. Never beat the game on Impossible...
Visibility would be beneficial, although I don't really need more coders at this point; most bug fixes need to refer to the disassembly.
Screenshots: sure. Video? Nope, don't have the software or experience for it. I do appreciate more PR but fucking suck at it. ;)
Maintaining packages can be tedious, but for the sake of dissemination and visibility, it helps a lot to have precompiled binaries, especially now that snap/appimage allow you to to distribute universal builds.I reluctantly agree. I will link to any binaries in the home page (see first post) but will not attempt to make any. I did have a mingw32 cross compiling setup once but am too lazy to set such up again.
You really need to launch a proper project webpage for this though, because this project deserves a proper home and discussion forums!I admit that taking advantage of openxcom is a bit... skeevy? But I have no experience in creating either. Umm.., patches welcome...?
I have little experience working with IDA, if that, I can help with general questions.I feel this skips step 0: deteriming the "known" file formats. Consider disassembilng libz vs. naming a function "zip_uncompress" based on the parameter and surrouding code. Otherwise your post is spot-on.
Here is my plan for reversing games.
1. Defining text strings, renaming functions according to text strings.
I would say that at least Windows builds will be essential for more visibility, because Windows users don't know/don't want to use a compiler,Sad but true, hence my request.
and at least 80% of your future playerbase will be runningFTFY. Also: sad but true.WindowsAndroid.
And don't feel bad for promoting your stuff in OXC forums. if anything the word should be spread in more places!There are 2 related threads in reddit. I tried to push my
For windows build I suggest mxc, couple of people there use it t ocreate binaries for public, only drawback is that require linux to setup it.Cool, a cross compiler + libs builder. Seems very useful. If it supports libsamplerate then setting up for 1oom should be really simple. I will stick with providing the source code.
I feel this skips step 0: deteriming the "known" file formats. Consider disassembilng libz vs. naming a function "zip_uncompress" based on the parameter and surrouding code. Otherwise your post is spot-on.
Reported a game crashing bug and a small compiling issue on github.Thanks!
Further suggestion: create a Freenode IRC channel in order to initiate discussion and report issues more promptlyI agree that IRC is quite good for that. Unfortunately it does not fit my workflow. I'm online only for brief periods between development bursts.
There are 2 related threads in reddit. I tried to push myYour IP is in a lot of public hitlists so I wonder what you or your neighbors have been up to. :Pshitwarezmerchandise elsewere but have been met with either IP blocks or "links to illegal content". So thanks to SupSuper! I promise to fuck off if someone sets up the platform. ;) IOW, spread the word.
For windows build I suggest mxc, couple of people there use it t ocreate binaries for public, only drawback is that require linux to setup it.I second the recommendation for mxe (http://mxe.cc/), we've been using it for the Git Builder and it works great. I'll look into making some Windows binaries.
By build follow this file (with some info about setup): https://github.com/Yankes/OpenXcom/blob/OpenXcomExtended/src/Makefile.mxe
Your IP is in a lot of public hitlists so I wonder what you or your neighbors have been up to. :PThat's Tor for you. Pursuing anonymity is important wether you are searching for jpegs of Dolores Haze, staging a coup or reversing 25 year old games.
https://osgameclones.com/ will probably be interested.Nice! I will notify them, thanks.
Any reason you used SDL1.2 instead of SDL2 though?1. Familiarity and having some code ready for borrowing.
Note that simultaneous builds for both (and more) were always in the plan. Someone just needs to implement src/hw/sdl/2. My focus is on bug genocide.Looking at your code show that is indeed nearly drop in replacement, one file to change and rest of code base use fixed interface.
Looking at your code show that is indeed nearly drop in replacement, one file to change and rest of code base use fixed interface.I expect the difficult part to be configure.ac. The video code could probably be copy/pasted from Chocolate Doom 3.0 as it is also aspect ratio corrected 320x200.
I would suggest using gitter chat then. It can be linked to a regular IRC channel along the project's github, and it logsand highlights messages directed at you.I do not agree with their terms of service. Thanks again for the bug reports!
Here's a Windows build if anyone wants to try it, just drop it in your MOO1 folder. For some reason audio doesn't seem to be working on Windows.Wow, thanks! Merged. I'll see what wine says about the EXEs, but I doubt I can help with the audio issue (unless it's the complete lack of SDL_mixer).
Sent you a pull request with the fixes I had to do: https://github.com/KilgoreTroutMaskReplicant/1oom/pull/5
The problem was MXE uses static libs by default, which your autoconf doesn't handle. You need to use `pkg-config --libs --static SDL_mixer` to catch all the SDL_mixer dependencies, just -lSDL_mixer won't do.
Shared libs would probably be more efficient, but that's beyond the scope of my meager "I just wanna play this on Windows" effort. :P
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
`1oom_classic_sdl1` and `1oom_classic_sdl2` work and have sound
btw change name of readme from your "relese" because it conflict with file with same name from GoG version of MOO1
you should probably add `ls` to console version (and pad support too :D ) 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
What is "pad support"?system console vs game console :>
system console vs game console :>
For music, main menu and landing screen have it. It look its work same as dosbox version.
Finally managed to set up a win32 cross compiler. Thanks for the MXE suggestion!SDL1.2 exe works fine for me but SDL2 exe doesn't even start. ???
Problem is that I can not test the binaries. Running in wine gives no music (same for SupSuper's exes) and I have no 32 bit GL libs (or something) so sdl1 is software only and sdl2 crashes on start.
If you use Windows, please grab the attached zip and report how it works. Comparisons on sdl1 vs. sdl2 would be interesting too.
SDL1.2 exe works fine for me but SDL2 exe doesn't even start. ???
Music plays fine. I'm guessing it doesn't work on Wine because it's MIDI, which uses a proprietary driver for playback on Windows.
Once you need more testers, I'd suggest posting a Windows build on the GOG and Steam forums for the original game, you're sure to get a lot ofvictimsplayers. :)
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.
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?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.
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).
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.I set option (1). Config in attachment.
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?
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.
I set option (1). Config in attachment.
... so has anyone gotten the DOS version to work, audio or not?DOS version doesn't work for me, either executable just gives me the message "Load error: no DPMI - Get csdpmi*b.zip".
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:
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.
Otherwise you will just have to convince someone very generous.
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. :)
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.
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.
Posted on Steam too. Doesn't seem to have done much, but here's hoping.
Is always "printf" hack to find bug cause, this could track variables and see where is difference.
Sorry, but how do I install this?
Sorry, but how do I install this?Just extract to your MOO1 folder. You need to get v0.3 first though: https://github.com/KilgoreTroutMaskReplicant/1oom/releases/tag/v0.3
There is no readme in the zip
Great that you find clue what cause this bug.
Bugs like this are pain in ass, I today spend whole day in work trying find bug in my c# code that only happens on other peoples computers and not on my. After asking of couple of people to test it I manage to find that bug was in datapick control that read current windows locale and if value is "wrong" do not show any date at all.
I have no account and hold some contempt at [GitHub].
1oom has moved to GitLab: project (https://gitlab.com/KilgoreTroutMaskReplicant/1oom), git (https://gitlab.com/KilgoreTroutMaskReplicant/1oom.git), homepage (https://kilgoretroutmaskreplicant.gitlab.io/plain-html)
It was moved to GitLab due to the fact that GitHub was purchased by Microsoft.
../../../src/game/game_ai_classic.c:3751:28: error: ‘p2’ undeclared (first use in this function); did you mean ‘p1’?
e1->diplo_type[p2] = 0;
One wonders who would buy GitLab next.please don't let it be facebook
btw it doesn't build:
please don't let it be facebook
Now that any goodwill this project may have gathered has been demolished by the avenue move, I guess it's back to tinyupload on the next offensive buyout.
Well, once upon a time I ran an SVN server for the UFO2000.
I guess it's back to self-hosting repos. Any way one slices the orange, there has to be some place where for example my buildfarm is to get the source code from.
Not that much of a step, it's not like the forums, or my builds aren't self-hosted.
Any particular builds (OS/arch) you'd like automated?
Merging SVN branches sure was a pain.I garbed last version and crashes with mouse stops. Tested without sound.
.... is this an offer to provide automatic builds and host them? If so, then yay!
I believe the win32/SDL1 is the only one that really matters. Folks using Linux should be able to build this easily enough (and make install is not required), although a snap package has been asked for. Still haven't got a word on if the DOS version crash fix worked, so I'll keep ignoring it.
So the answer is win32/SDL1 but I wouldn't turn down other builds.
I garbed last version and crashes with mouse stops. Tested without sound.
I mean, I do not have crash anymore when I move mouse on edges of screen. Last version work fine, at least without sound (because I do not test with it enabled).
error: LBX: space.lbx invalid id 57 >= 57
error: opening file 'v11.lbx'!
game_ai_classic.c: In function ‘game_ai_classic_turn_p1_front’:
game_ai_classic.c:287:70: warning: array subscript is above array bounds [-Warray-bounds]
if (ait->tbl_front_planet[i] == ait->tbl_front_planet[j]) {
~~~~~~~~~~~~~~~~~~~~~^~~
game_ai_classic.c:294:73: warning: array subscript is above array bounds [-Warray-bounds]
ait->tbl_front_relation[j] = ait->tbl_front_relation[j + 1];
~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~
game_ai_classic.c:295:69: warning: array subscript is above array bounds [-Warray-bounds]
ait->tbl_front_planet[j] = ait->tbl_front_planet[j + 1];
~~~~~~~~~~~~~~~~~~~~~^~~~~~~
game_ai_classic.c: In function ‘game_battle_ai_target1’:
game_ai_classic.c:2764:13: warning: ‘tblxy[0]’ may be used uninitialized in this function [-Wmaybe-uninitialized]
uint8_t tblxy[1];
fmt_mus.c: In function ‘xmid_convert_evnt’:
fmt_mus.c:150:32: warning: variable ‘b’ set but not used [-Wunused-but-set-variable]
uint8_t c, b;
^
mv -f .deps/util.Tpo .deps/util.Po
fmt_sfx.c: In function ‘fmt_sfx_convert_voc’:
fmt_sfx.c:257:30: warning: variable ‘marker’ set but not used [-Wunused-but-set-variable]
uint16_t marker;
^~~~~~
gcc -DHAVE_CONFIG_H -I. -I../src/os/unix -I../src -g -O3 -Wall -Wno-inline -Wstrict-prototypes -MT pbxdump.o -MD -MP -MF .deps/pbxdump.Tpo -c -o pbxdump.o pbxdump.c
fmt_sfx.c:271:30: warning: variable ‘repeatnum’ set but not used [-Wunused-but-set-variable]
uint16_t repeatnum;
^~~~~~~~~
fmt_sfx.c:170:32: warning: variable ‘ctype’ set but not used [-Wunused-but-set-variable]
uint8_t b, block_type, ctype = 0, stereo = 0, sr;
^~~~~
fmt_sfx.c:170:17: warning: variable ‘b’ set but not used [-Wunused-but-set-variable]
uint8_t b, block_type, ctype = 0, stereo = 0, sr;
lbxview.c: In function ‘drawscreen_inlbx’:
lbxview.c:286:56: warning: ‘%x’ directive writing between 1 and 4 bytes into a region of size between 0 and 20 [-Wformat-overflow=]
sprintf(linebuf, "%ix%i f:%i/%i(%i)%c (%x)(%x)(%x) if:%i fmt:%i | %i %i",
^~
lbxview.c:286:26: note: directive argument in the range [0, 65535]
sprintf(linebuf, "%ix%i f:%i/%i(%i)%c (%x)(%x)(%x) if:%i fmt:%i | %i %i",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lbxview.c:286:26: note: directive argument in the range [0, 255]
lbxview.c:286:26: note: directive argument in the range [0, 255]
In file included from /usr/include/stdio.h:862:0,
from lbxview.c:3:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 41 and 96 bytes into a destination of size 41
return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
lbxview.c:295:62: warning: ‘__builtin___sprintf_chk’ may write a terminating nul past the end of the destination [-Wformat-overflow=]
sprintf(linebuf, "pal o:%x do:%x f:%i n:%i (%02x)",
^
In file included from /usr/include/stdio.h:862:0,
from lbxview.c:3:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: note: ‘__builtin___sprintf_chk’ output between 26 and 42 bytes into a destination of size 41
return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Here goes a build: https://lxnt.wtf/oxem/#/1oom
only problem it doesn't work, the *sdl1.exes just quit silently, and the cmdline exe complains about too few entries in diplomat.lbx
EDIT: okay, works with v1.3 data files. might be helpful to spit an error message to mention that.
Also, some warnings:
But not the sdl1-win32 version, hmm. cmdline one works tho
First of all: Yay! Thanks a lot!
Please name set the version part of the files according to "git describe --tags" to reduce confusion between 7z name and what is shown in 1oom_log.txt and the main menu (if uiextra is enabled).
Can I put that URL on the homepage?
No problem, and I fixed the file names
Is win32 still broken? Anything on 1oom_log.txt? I'll try it in wine later.
It doesn't write anything to 1oom_log.txt. Must be silently quitting somewhere before the first logwrite.
error: initialising SDL_mixer (48000 Hz, slice 2048): DirectSoundCreate: No audio device found
Yeah, well the -nogl did it.
You know, I'd consider dropping sdl1 support. I looked into the mess the GL support there is and ewww.. You really want to waste your time supporting it?
This is suboptimal, it should continue without sound.
EDIT: and also ./ui/classic/uiclassic.c:382 should rely not on opt_audio_enabled but on audio_initialized
Weird that it didn't get to write any log, the video init should come way later. Maybe the log needs more flushing.
Do the sdl1 binaries I have released work with -gl?
#0 0x0051cff0 in SDL_LowerBlit_REAL (src=0x13bb780,
srcrect=0x76a4f8 <video+24>, dst=0x0, dstrect=0x76a4f8 <video+24>)
at src/video/SDL_surface.c:592
#1 0x004a6ad6 in video_update () at hwsdl2_video.c:210
#2 0x004a6f58 in hw_video_set_palette (num=256, first=0,
pal=0x76a554 <video+116> "") at ../../../../src/hw/sdl/hwsdl_video.c:40
#3 hw_video_refresh_palette () at ../../../../src/hw/sdl/hwsdl_video.c:40
#4 hw_video_init (w=<optimized out>, h=<optimized out>) at hwsdl2_video.c:493
#5 0x00463458 in ui_late_init () at uiclassic.c:342
#6 0x0040f2a2 in main_do () at game.c:506
#7 0x0040b6d7 in main_1oom (argc=2, argv=0x13b1688) at main.c:81
#8 0x004a4575 in SDL_main (argc=argc@entry=2, argv=argv@entry=0x13b1688)
at hwsdl2.c:210
#9 0x004d8fb4 in main_utf8 (argv=0x13b1688, argc=2)
at src/main/windows/SDL_windows_main.c:126
#10 main_getcmdline () at src/main/windows/SDL_windows_main.c:159
#11 0x004d90c5 in WinMain@16 (hInst=0x400000, hPrev=hPrev@entry=0x0,
szCmdLine=0x15c418f "-noaudio", sw=10)
at src/main/windows/SDL_windows_main.c:202
I use sdl1 so it's not getting dropped. So far 100% of Windows test reports have stated that sdl1 works but only 50% that sdl2 does. (Sample size being 2...)
As for a waste of time: have you noticed there's Allegro 4 support?
I do not care much which SDL version the Windows users have to deal with. For the v0.x releases I will build both.
No. I consider this a fatal error. There is -noaudio for playing without sound.
See above. Also, I do not plan to expand the hw/ API with the latter.
What happens is that the pixelformat for the window is RGB565 under RDP, but for some reason SDL_PixelFormatEnumToMasks() in video_sw_set() returns 'Unknown pixel format' for it, and then rgbabuffer is NULL, and all goes down from there.
sdl2 builds reject -gl/-nogl flags and die silently (when running under MSYS2 gdb one can notice an error message, but no logs written). The above backtrace is for a run with -noaudio only.
sdl1 builds with -noaudio -gl over RDP: a window opens with white background; nothing else happens.
Your decision, man. It was only a suggestion.
(also I thought allegro is for the dos version).
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.
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
Care to elaborate? The sdl2 mouse code is a bit weird since using mouse events destroyed the performance.
Done.
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.
Cool. Send a PR/MR/whatever when ready.
I hope you have noticed the Ctrl-Esc shortcut and have not been wresting with mice to escape.
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.
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.
- gitversion=`$GIT describe --tags`
+ gitversion=`$GIT -C $srcdir describe --tags`
Done<untested hypothesis>
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>
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.
I've reverted the ignore-mouse-motion commit, and even when spamming the log with events, it does not slow down noticeably.
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.
<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.
Still, RDP makes testing on windows that much simpler, and I'd appreciate an option to disable relative mouse mode.
you should probably add `ls` to console version (and pad support too :D ) 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
v [RANGE] [+DIST] [FILTERS]
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.
I did not test this, end even never try using this function, but I except this could avoid most problems.
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.
Side effect:
Arrows keys do not working in RDP, but as it do not work now ether so we do not lose any thing.
One small tweak.
When you hold left button on production scroll (like SHIP, IND or DEF) and move mouse outside it, game still should adjust value to max or min.
Currently if you too fast move mouse (without releasing button) it will skip last step.
Dear Windows user,
If you know how to compile 1oom on Windows or are planning to find out, please consider documenting the setup process for a "How to compile on Windows" article for the 1oom homepage.
Last nitpicking, when you press mouse down on scroll and move mouse out and release it then mouse click is triggered on spot where you move mouse.
Aside from that, last version work lot better when you fix last scroll quirk.
Ahem, between mxe and autoconf it should be fairly straightforward. Or did you mean the unholy mess named VS?
Unfortunately click-on-release is original behaviour. The related code is hairy and I'm not sure if it can be fixed without rewriting a lot of code and introducing a slew of new bugs."Last nitpicking", if it can't be change then its fine.
As outlined in HACKING this project is autotools only. I'm thinking of Joe Q. Mooexpert who wants to tinker a bit with the AI code but has never compiled anything. A nice "download this, install that, type ./configure" guide would come handy for poor Joe. I'm half temped to write one myself with the first steps being "install Linux and MXE"... I wouldn't know where to start on Windows, and I doubt Joe would either.If you're only gonna support autotools, then the only option is installing the Linux tools on Windows (eg. MSYS or WSL), at which point the steps are the same as Linux. :P All roads lead to Rome.
If you're only gonna support autotools, then the only option is installing the Linux tools on Windows (eg. MSYS or WSL), at which point the steps are the same as Linux. :P All roads lead to Rome.
If you want to use SDL1:
aptitude install libsdl1.2-dev libsdl-mixer1.2-dev
Does either of those come with Debian-derived packaging system?
install http://www.msys2.org/
run the mingw32 version
/bin/pacman -Syuu
- close shell window as per instructions
/bin/pacman -S git autoconf automake gcc mingw32/mingw-w64-i686-SDL_image pacman -S mingw32/mingw-w64-i686-readline
git clone https://gitlab.com/KilgoreTroutMaskReplicant/1oom.git
cd 1oom
autoreconf -fi
./configure
(it fails)
make
(hopefully)
export LDFLAGS=-L/mingw64/lib/
export CFLAGS=-I/mingw64/include
MSYS2 has pacman (from Arch Linux)
What I tried is:
But then it did not found -lmingw32 and an hour of head-bashing the wall didn't make it work, so at this point it'd be simpler to just fire up a linux VM (for me)
gcc
mingw32/mingw-w64-i686-SDL
./configure
gcc
SDL
./configure
mingw32/mingw-w64-i686-gcc
mingw32/mingw-w64-i686-SDL
./configure --host=i686-w64-mingw
pacman -S mingw-w64-i686-toolchain mingw-w64-i686-SDL mingw-w64-i686-SDL_mixer mingw-w64-i686-libsamplerate3. Install the build tools:pacman -S git autoconf automake make4. Close the shell and launch MSYS2 MinGW 32-bit (or 64-bit respectively) to set up the environment variables.git clone https://gitlab.com/KilgoreTroutMaskReplicant/1oom.git
cd 1oom
autoreconf -fi
./configure
make
Works fine here. Here's what I did:
Btw Kilgore you need to clean up those unused warnings. :P
pacman -S mingw-w64-i686-SDL2 mingw-w64-i686-SDL2_mixer
And it all does run modulo problems with finding the .dlls. I suggest you incorporate a static build option and make it default for msys2 builds otherwise it'll be no end of confusion about copying dlls and stuff.Well static linking is kinda inefficient when you've got 10 EXEs... don't know how to integrate it into automake, but you could easily write a separate script to copy them for you: https://blog.rubenwardy.com/2018/05/07/mingw-copy-dlls/
And it all does run modulo problems with finding the .dlls. I suggest you incorporate a static build option and make it default for msys2 builds otherwise it'll be no end of confusion about copying dlls and stuff.
--- a/configure.ac
+++ b/configure.ac
@@ -189,10 +189,10 @@ if test x"$enable_hwsdl1" != "xno"; then
HW_SDL1_LIBS="$SDL1_LIBS"
elif test x"$sdl_config" != "xno"; then
HW_SDL1_CFLAGS="$CFLAGS `$sdl_config --cflags`"
- HW_SDL1_LIBS="`$sdl_config --libs`"
+ HW_SDL1_LIBS="`$sdl_config --static-libs`"
elif $pkg_config --exists sdl; then
HW_SDL1_CFLAGS="$CFLAGS `$pkg_config --cflags sdl`"
- HW_SDL1_LIBS="`$pkg_config --libs sdl`"
+ HW_SDL1_LIBS="`$pkg_config --libs --static sdl`"
else
HW_SDL1_LIBS="-lSDL"
fi
@@ -223,7 +223,7 @@ if test x"$enable_hwsdl1" != "xno"; then
if test x"$SDL1MIXER_LIBS" != "x"; then
HW_SDL1_LIBS="$HW_SDL1_LIBS $SDL1MIXER_LIBS"
elif $pkg_config --exists SDL_mixer; then
- HW_SDL1_LIBS="`$pkg_config --libs SDL_mixer`"
+ HW_SDL1_LIBS="`$pkg_config --static --libs SDL_mixer`"
else
HW_SDL1_LIBS="$HW_SDL1_LIBS -lSDL_mixer"
fi
LDFLAGS=-static ./configure --disable-hwsdl1audio
../configure LDFLAGS="-static" \
SDL1_CFLAGS="`sdl-config --cflags`" \
SDL1_LIBS="`sdl-config --static-libs`" \
SDL1MIXER_LIBS="-lblahblah"
should work without the patch. I'd rather not document that.But the sound isn't that critical for AI development.
As for the DLL set, previously I just copied the all the *.dll files from $MSYS2_INSTALL_DIR/mingw32/bin to the MOO1 data dir because I'm lazy like that. (substitute mingw64 for 64bit builds).
The reason I asked about "src/1oom_classic_sdl1" in specific was the remote possibility that the dynamic linker can somehow find the dlls when run in MSYS. I guess "nope" is the answer.If you run it from inside MSYS, it will find the DLLs in the search paths automatically, but you can only run command-line apps from MSYS (so the command-line 1oom will work, but not the classic 1oom).
I've written the howto with running the exes within MSYS in mind. Given "make -j 3 && src/1oom_..." and command history, who would prefer copying the exe somewhere else and running it via other means?
If you run it from inside MSYS, it will find the DLLs in the search paths automatically, but you can only run command-line apps from MSYS (so the command-line 1oom will work, but not the classic 1oom).
... fuck. Did not expect that. Taking down link from index.html and waiting for patches...Nothing's broken. :) To clarify:
Nothing's broken. :) To clarify:
- If you run the .exe's directly from the MSYS shell, then you don't need to copy the DLLs, as it will use the shell search path (with the caveat that only the command-line version will work inside a shell).
- If you run the .exe's directly in Windows, then you need to copy the DLLs, since it will use the Windows search path.
void game_planet_destroy(struct game_s *g, uint8_t planet_i)
{
planet_t *p = &(g->planet[planet_i]);
/* ... */
p->rebels = 0;
p->unrest = 0;
p->reserve = 0;
p->prev_owner = p->owner;
/* ... */
}
And what it looks like in the disassembled v1.3 EXE:game_planet_destroy proc far
var_2 = word ptr -2
planet_i = word ptr 6
push bp
mov bp, sp
sub sp, 2
push si
push di
mov cx, [bp+planet_i]
...
mov ax, cx
mov dx, size struc_planet
imul dx
les bx, planet_data_segoffs
add bx, ax
mov es:[bx+struc_planet.rebels], 0
mov ax, cx
mov dx, size struc_planet
imul dx
les bx, planet_data_segoffs
add bx, ax
mov es:[bx+struc_planet.unrest], 0
mov ax, cx
mov dx, size struc_planet
imul dx
les bx, planet_data_segoffs
add bx, ax
mov word ptr es:[bx+(struc_planet.reserve+2)], 0
mov word ptr es:[bx+struc_planet.reserve], 0
mov ax, cx
mov dx, size struc_planet
imul dx
les bx, planet_data_segoffs
add bx, ax
mov ax, es:[bx+struc_planet.owner]
push ax
mov ax, cx
mov dx, size struc_planet
imul dx
les bx, planet_data_segoffs
add bx, ax
pop ax
mov es:[bx+struc_planet.prev_owner], ax
...
That's right: every time a planet (or, well, anything) is read or written to, the address is recalculated. The EXEs could be shrunk down to less than 50% size. Picture wading through about 770 kB of that garbage and that's my life for most of the 6 months before v0.1.date,version,total,src,game,classic,cmdline,sdl,sdl1,sdl2,alleg,alleg4,dos,win,unix
2017-10-14,vnone,0,0,0,0,0,0,0,0,0,0,0,0,0
2017-11-14,v0.0,2568,896,1641,0,0,0,31,0,0,0,0,0,0
2017-12-14,v0.0-39-gfa00f4b,18204,6046,4437,5742,436,822,490,0,0,0,0,84,147
2018-01-14,v0.0-68-geb03567,30847,6430,8729,13628,436,871,522,0,0,0,0,84,147
2018-02-14,v0.0-96-ge0d2c60,39674,7821,13539,16124,537,878,544,0,0,0,0,84,147
2018-03-14,v0.0-117-g62059b7,49070,8692,18103,19964,633,878,544,0,0,0,0,90,166
2018-04-14,v0.1,57149,9359,23802,21570,723,900,539,0,0,0,0,90,166
2018-05-14,v0.2-55-g681cf86,62852,11419,24160,21694,2816,808,751,908,0,0,0,121,175
2018-06-14,v0.4-38-g5a9834d,67158,12274,25015,22068,3349,1075,816,987,648,453,148,137,188
2018-07-14,v0.5-67-gbe8d753,70168,12438,26229,22477,4216,1196,951,1063,662,463,148,137,188
2018-08-14,v0.6-46-g1ca378e,74222,13502,26696,22794,6315,1209,982,1066,675,467,162,152,202
2018-09-14,v0.8-14-g94ab478,74707,13534,27055,22890,6279,1209,995,1087,675,467,162,152,202
2018-10-14,v0.9-10-gdb25388,75508,13537,27143,23597,6284,1201,994,1094,675,467,162,152,202
2018-11-14,v1.0,75746,13537,27187,23791,6284,1201,994,1094,675,467,162,152,202