Author Topic: Reversing to Orion - project 1oom  (Read 55400 times)

Offline Kilgore T.M. Replicant

  • Colonel
  • ****
  • Posts: 100
  • Mangia!
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #75 on: June 17, 2018, 12:51:12 pm »
Well, once upon a time I ran an SVN server for the UFO2000.

Merging SVN branches sure was a pain.

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?

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

Offline Yankes

  • Commander
  • *****
  • Posts: 3192
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #76 on: June 17, 2018, 01:57:24 pm »
Merging SVN branches sure was a pain.

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

Offline Kilgore T.M. Replicant

  • Colonel
  • ****
  • Posts: 100
  • Mangia!
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #77 on: June 18, 2018, 02:04:26 am »
I garbed last version and crashes with mouse stops. Tested without sound.

...? The mouse crashing stopped? It crashes when the mouse stops? I do not understand. Just answer this: does the latest DOS version crash?

Offline Yankes

  • Commander
  • *****
  • Posts: 3192
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #78 on: June 18, 2018, 07:17:34 pm »
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).

Offline Kilgore T.M. Replicant

  • Colonel
  • ****
  • Posts: 100
  • Mangia!
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #79 on: June 18, 2018, 07:55:38 pm »
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).

Thanks for testing and clarifying. The DOS port lives to see another release.

Offline Stoddard

  • Colonel
  • ****
  • Posts: 485
  • in a fey mood
    • View Profile
    • Linux builds & stuff
Re: Reversing to Orion - project 1oom
« Reply #80 on: June 23, 2018, 03:51:54 pm »
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: the linux build complains:

Code: [Select]
error: LBX: space.lbx invalid id 57 >= 57
error: opening file 'v11.lbx'!

this all with data files from myabandonware.com


Also, some warnings:

Code: [Select]
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 ());
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


EDIT: okay, works with v1.3 data files. might be helpful to spit an error message to mention that.
But not the sdl1-win32 version, hmm. cmdline one works tho


EDIT: sprintf at lbxview.c:286 crashes for me every time. a kludge of     char linebuf[100500]; helps a bit
« Last Edit: June 23, 2018, 05:09:50 pm by Stoddard »

Offline Kilgore T.M. Replicant

  • Colonel
  • ****
  • Posts: 100
  • Mangia!
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #81 on: June 24, 2018, 07:08:14 am »
Here goes a build:  https://lxnt.wtf/oxem/#/1oom

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?

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.

The md5sums are listed in doc/lbxmd5.txt. Good idea on the error message.

Also, some warnings:

Thanks, will take a look.

But not the sdl1-win32 version, hmm. cmdline one works tho

Can't help much with win32 testing...

Offline Stoddard

  • Colonel
  • ****
  • Posts: 485
  • in a fey mood
    • View Profile
    • Linux builds & stuff
Re: Reversing to Orion - project 1oom
« Reply #82 on: June 24, 2018, 05:49:44 pm »
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


Offline Kilgore T.M. Replicant

  • Colonel
  • ****
  • Posts: 100
  • Mangia!
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #83 on: June 24, 2018, 06:51:06 pm »
No problem, and I fixed the file names

Thanks. Added to OP and homepage.

Fixed the lbxview buffer size and added a check for V11.LBX and a suitable error message. The unused vars in fmt_*.c are used in debug builds (--enable-modebug) and I'd rather not add ifdefs around the declarations. The array bounds warning in game_ai_classic.c baffles me; clearly the index i is bound to same limits as j but it only complains about the latter.

Is win32 still broken? Anything on 1oom_log.txt? I'll try it in wine later.

Offline Stoddard

  • Colonel
  • ****
  • Posts: 485
  • in a fey mood
    • View Profile
    • Linux builds & stuff
Re: Reversing to Orion - project 1oom
« Reply #84 on: June 24, 2018, 10:17:36 pm »

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.

I can't for the life of me install wine at my 18.04 box, and running stuff under gdb in native win32 is kind of seriously hampered by the fact that there seems to not be an i686 gdb built for MSYS2. Looks like I'll have to dig out an x64 box, there should be a couple or three old ones somewhere in the lair.

Offline Kilgore T.M. Replicant

  • Colonel
  • ****
  • Posts: 100
  • Mangia!
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #85 on: June 25, 2018, 08:06:55 am »
It doesn't write anything to 1oom_log.txt. Must be silently quitting somewhere before the first logwrite.

Tried with "wine 1oom_classic_sdl1 -nogl" on Debian stable wine, seemed to work OK. Can't test without -nogl due to missing 32-bit graphics drivers. Not much of a test but hey, have a datapoint.

Do the win32 binaries I have released work on your box?

Offline Stoddard

  • Colonel
  • ****
  • Posts: 485
  • in a fey mood
    • View Profile
    • Linux builds & stuff
Re: Reversing to Orion - project 1oom
« Reply #86 on: June 25, 2018, 11:15:30 am »
Yeah, well the -nogl did it.

I'll take a look into SDL1/2 init code, I've got tons of that boilerplate in my other projects.


EDIT:

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?

Running sdl1/sdl2 builds under RDP (no GL, no sound, but hey it should still run) makes it quit with

Code: [Select]
error: initialising SDL_mixer (48000 Hz, slice 2048): DirectSoundCreate: No audio device found

src/hw/sdl/hwsdl_audio.c:111

This is suboptimal, it should continue without sound.

Suggest just returning 0 instead of -1 from  hw_audio_init() in case any Mix_* function fails.

EDIT: and also ./ui/classic/uiclassic.c:382 should rely not on opt_audio_enabled but on audio_initialized


« Last Edit: June 25, 2018, 03:33:21 pm by Stoddard »

Offline Kilgore T.M. Replicant

  • Colonel
  • ****
  • Posts: 100
  • Mangia!
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #87 on: June 26, 2018, 04:55:57 am »
Yeah, well the -nogl did it.

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?

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?

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.

This is suboptimal, it should continue without sound.

No. I consider this a fatal error. There is -noaudio for playing without sound.

EDIT: and also ./ui/classic/uiclassic.c:382 should rely not on opt_audio_enabled but on audio_initialized

See above. Also, I do not plan to expand the hw/ API with the latter.

Offline Stoddard

  • Colonel
  • ****
  • Posts: 485
  • in a fey mood
    • View Profile
    • Linux builds & stuff
Re: Reversing to Orion - project 1oom
« Reply #88 on: June 26, 2018, 02:38:32 pm »
Weird that it didn't get to write any log, the video init should come way later. Maybe the log needs more flushing.

Strange, yeah.

Quote
Do the sdl1 binaries I have released work with -gl?

system: win7 embedded standard x64, nvidia gt218

all binaries work.

system: same, but via RDP:

-noaudio -nogl:  sdl1 builds work; sdl2 builds: your silently quits, mine crashes:

Spoiler:
Code: [Select]
#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

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.


Quote
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.

Your decision, man. It was only a suggestion.
(also I thought allegro is for the dos version).

Offline Kilgore T.M. Replicant

  • Colonel
  • ****
  • Posts: 100
  • Mangia!
    • View Profile
Re: Reversing to Orion - project 1oom
« Reply #89 on: June 27, 2018, 05:31:40 am »
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.

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.

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.

-gl/-nogl are sdl1 only, sdl2 does not use OpenGL direcly but uses the SDL2 API instead.

The log file is opened after reading the cmdline args so it missing in this case is normal (although not necessarily user-friendly).

sdl1 builds with -noaudio -gl over RDP: a window opens with white background; nothing else happens.

Must be the 16b thing. Thanks for testing!

Your decision, man. It was only a suggestion.

Don't take my terse refusals the wrong way. I do appreciate suggestions, but can be rather blunt when explaining why I've chosen not to implement them.

(also I thought allegro is for the dos version).

Quite right, but
1) there is nothing stopping to build that hw/ for other OSs
2) the DOS version is a perverse curiosity that has eaten way too much of my time already