kekko, yes it would be difficult. I've thought about it myself, but it would be messy at least. I won't forget the suggestion as I'd like that too. just don't count on it being done 😉

HunterZ: x-com ufo defense, it's my primary test case as it has many true borders and some areas that should be smoothed, which makes some borders really hard to get right. It also shows many unavoidable limitations.

And your fix in SDL-1.3 is correct.

Okay here we go.. seems to be something that happened earlier on the first time I tried this. But we DO get DOSBox to the shell, which is nice. 😁 Just some games are causing crashes with it.

NOTE: GeForce 4s don't support the openglhq method. At least not mine.

(gdb) bt
#0 Normal_8_32 (s=0x19a8098) at render_templates.h:96
#1 0x0048f03f in VGA_DrawPart (lines=120) at vga_draw.cpp:215
#2 0x0047ed05 in PIC_RunQueue () at pic.cpp:428
#3 0x004012a5 in Normal_Loop () at dosbox.cpp:123
#4 0x00401376 in DOSBOX_RunMachine () at dosbox.cpp:170
#5 0x004065f6 in CALLBACK_RunRealInt (intnum=33) at callback.cpp:105
#6 0x004b75d9 in DOS_Shell::Execute (this=0x594c980, name=0x22da10 "setup",
args=0x22ebb5 "") at shell_misc.cpp:454
#7 0x004bb735 in DOS_Shell::DoCommand (this=0x594c980, line=0x22ebb0 "setup")
at shell_cmds.cpp:116
#8 0x004b3bbe in DOS_Shell::ParseLine (this=0x594c980, line=0x22ebb0 "setup")
at shell.cpp:209
#9 0x004b4d80 in DOS_Shell::Run (this=0x594c980) at shell.cpp:280
#10 0x004b4a6b in SHELL_Init () at shell.cpp:502
#11 0x00493fd8 in SDL_main (argc=1, argv=0x22fe90) at sdlmain.cpp:981
#12 0x004be150 in console_main (argc=1, argv=0x22fe90)
at win32/SDL_win32_main.c:249
#13 0x004be315 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251eff "",
sw=10) at win32/SDL_win32_main.c:361
#14 0x004bdc4a in main ()
at f:/msys/1.0/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_string.h:216
(gdb) frame 0
#0 Normal_8_32 (s=0x19a8098) at render_templates.h:96
96 dst[x]=pixel;LC[0][x]=pixel;
(gdb) frame 1
#1 0x0048f03f in VGA_DrawPart (lines=120) at vga_draw.cpp:215
215 RENDER_DrawLine(data);
(gdb) p RENDER_DrawLine
$6 = 0x49b740 <Normal_8_32(void const*)>
(gdb) p data
$7 = (Bit8u *) 0xff000000 <Address 0xff000000 out of bounds>
(gdb) p dst
No symbol "dst" in current context.
(gdb) p x
$8 = 119
(gdb) p pixel
$9 = 4278190080
(gdb) p LC
No symbol "LC" in current context.

Seems like a problem with both LC and dst now.

Might be OFF-Topic but seems important:

You know I think SDL1.3.x is unstable. I have a program that works in regular SDL 1.2.x but not in SDL 1.3.x.
It's the Dr. Sbaitso program. It's strange but true.
And It's not DOSBox either because the line it crashes at in the DOSBox Sourcecode hasn't been changed since 0.63 was released and my last unoffical "official" build using DB0.63 released sourcecode in Janurary works and it uses SDL 1.2.8. But using the exact same sourcecode with SDL1.3.x it crashes horribly.

EDIT: Btw, your adlib patch snuck back into the full patch again Moe.

SDL 1.3 seems to be running fine for me so far, although I've only been using DOSBox to play Wizardry 6 lately (an EGA game from the 286 era).

I still can't get hardware overlays to work, despite uncommenting #USE_DIRECTX_OVERLAY or whatever it's called in src/video/windx5/SDL_dx5yuv.c; of course, the only way I can tell for sure that it's not working is by seeing if the ATI Overlay menu is active.

I should play with Moe's OpenGL stuff instead of fiddling with overlays and hardware DirectDraw surfaces probably...

priestlyboy wrote:

NOTE: GeForce 4s don't support the openglhq method. At least not mine.

`Moe` wrote:

You need a Geforce 5600/Radeon 9500 class video card, or newer. If your hardware isn't sufficient, you'll automatically get regular opengl output, sorry.

@priestlyboy: I believe this is `Moe`s full patch as in all his patches together (openglhq+hq2x+vesa16+adlib+speed+addkey...huh, did I forget something? 😁)

@HunterZ: I think the exact fix is in SDL_dx5video.c:

1@@ -1461,7 +1461,7 @@
2 			}
3 		}
4 		dd_surface3 = NULL;
5-#if 0 /* FIXME: enable this when SDL consistently reports lost surfaces */
6+#if 1 /* FIXME: enable this when SDL consistently reports lost surfaces */
7 		if ( (flags & SDL_HWSURFACE) == SDL_HWSURFACE ) {
8 			video->flags |= SDL_HWSURFACE;
9 		} else {

Indeed, with "all-in-one" I meant all the patches I did, not just the render/scaler ones. And right, GF4 don't have ARB_fragment_program, it's only available in the 5000 series.

priestly, can you tell me which games crash, and can you "p dst" in frame 0? (you did "frame 1" last, which gdb remembers further down) Also, is the crash reliably reproducable?

gulikoza: Yeah I made that change too, but I think it's actually related to hardware DirectDraw surfaces and not hardware overlays *shrug*

About the crashing with Sbaitso. I found out that it was not an issue with SDL or Moe's patch but an issue with EMS being set to false. Causing DOSBox to either hang or crash running Dr. Sbaitso.

The program can be found this thread.

So yeah, 🤣, I redid my compiler and now i can strip debug info properly without Windows crashing strip which was odd. So yeah back to the debugging the patch.

Strange I can't strip -d SDL.dll for SDL1.3.x (stripe.exe crashes) but i can strip the one for SDL1.2.x and the any other DLLs (as long as they were built with MinGW) just fine. So I'll just steal yours for the time being MOE. 🤣.

Anyways, I don't have to do any game in particular cause it happens even when switching from window to fullscreen. Exactly the same. sometimes it works, sometimes it crashes.

(gdb) bt

1#0  Normal_8_32 (s=0x1ce2d50) at render_templates.h:96
2#1  0x0048f02f in VGA_DrawPart (lines=100) at vga_draw.cpp:215
3#2  0x0047ecf5 in PIC_RunQueue () at pic.cpp:428
4#3  0x004012a5 in Normal_Loop () at dosbox.cpp:123
5#4  0x00401376 in DOSBOX_RunMachine () at dosbox.cpp:170
6#5  0x00406479 in CALLBACK_Idle () at callback.cpp:69
7#6  0x004acc75 in INT16_Handler () at bios_keyboard.cpp:392
8#7  0x004012e5 in Normal_Loop () at dosbox.cpp:127
9#8  0x00401376 in DOSBOX_RunMachine () at dosbox.cpp:170
10#9  0x004065f6 in CALLBACK_RunRealInt (intnum=22) at callback.cpp:105
11#10 0x00453c21 in device_CON::Read (this=0x4935af8, data=0x22e947 "\b,ë\"", 
12    size=0x22e83e) at dev_con.h:63
13#11 0x004545f1 in DOS_Device::Read (this=0x49448a8, data=0x22e947 "\b,ë\"", 
14    size=0x22e83e) at dos_devices.cpp:59
15#12 0x0045c61d in DOS_ReadFile (entry=0, data=0x22e947 "\b,ë\"", 
16    amount=0x22ea5e) at dos_files.cpp:296
17#13 0x004b7867 in DOS_Shell::InputCommand (this=0x4944928, line=0x22ebb0 "")
18    at ../../include/logging.h:44
19#14 0x004b4d58 in DOS_Shell::Run (this=0x4944928) at shell.cpp:279
20#15 0x004b4a5b in SHELL_Init () at shell.cpp:502
21#16 0x00493fc8 in SDL_main (argc=1, argv=0x22fe90) at sdlmain.cpp:981
22#17 0x004be140 in console_main (argc=1, argv=0x22fe90)
23    at win32/SDL_win32_main.c:249
24#18 0x004be305 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251eff "", 
25    sw=10) at win32/SDL_win32_main.c:361
26#19 0x004bdc3a in main ()
27    at f:/msys/1.0/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_string.h:216

(gdb) frame 0

1#0  Normal_8_32 (s=0x1ce2d50) at render_templates.h:96
296                      dst[x]=pixel;LC[0][x]=pixel;

(gdb) p dst

1No symbol "dst" in current context.

(gdb) p pixel

1$2 = 4278190248

(gdb) p LC

1No symbol "LC" in current context.

(gdb) frame 1

1#1  0x0048f02f in VGA_DrawPart (lines=100) at vga_draw.cpp:215
2215                     RENDER_DrawLine(data);

(gdb) p RENDER_DrawLine

1$3 = 0x49b730 <Normal_8_32(void const*)>

(gdb) p data

1$4 = (Bit8u *) 0xff0000a8 <Address 0xff0000a8 out of bounds>

It seems to be exactly the same as my previous report and All I had to do is go from window to fullscreen using ALT+ENTER. It seems to be random. I'm not sure why but here's all i can give. It's like it has troubles when redrawing the screen.

Um, it would seem to crash on any game so far, Ultima6/7/8, X-COM, Star Trek: Final Unity, still testing others, etc.

Hmm, it doesn't crash when using the "Dr. SBAITSO" or "Round 42" games. It seems to effect major games but not minor stuff.

Hmm, King Quest 6 CD version doesn't crash.. until after the Sierra Logo. But what's weird is when i run it through GDB it crashes almost immediately with the almost the same error report.

1Program received signal SIGSEGV, Segmentation fault.
2Normal_8_32 (s=0x1928098) at render_templates.h:96
396                      dst[x]=pixel;LC[0][x]=pixel;
4Current language:  auto; currently c++

(gdb) bt

1#0  Normal_8_32 (s=0x1928098) at render_templates.h:96
2#1  0x0048f02f in VGA_DrawPart (lines=50) at vga_draw.cpp:215
3#2  0x0047ecf5 in PIC_RunQueue () at pic.cpp:428
4#3  0x004012a5 in Normal_Loop () at dosbox.cpp:123
5#4  0x00401376 in DOSBOX_RunMachine () at dosbox.cpp:170
6#5  0x004065f6 in CALLBACK_RunRealInt (intnum=33) at callback.cpp:105
7#6  0x004b75c9 in DOS_Shell::Execute (this=0x4944950, name=0x22da10 "sierra", 
8    args=0x22ebb6 "") at shell_misc.cpp:454
9#7  0x004bb725 in DOS_Shell::DoCommand (this=0x4944950, line=0x22ebb0 "sierra")
10    at shell_cmds.cpp:116
11#8  0x004b3bae in DOS_Shell::ParseLine (this=0x4944950, line=0x22ebb0 "sierra")
12    at shell.cpp:209
13#9  0x004b4d70 in DOS_Shell::Run (this=0x4944950) at shell.cpp:280
14#10 0x004b4a5b in SHELL_Init () at shell.cpp:502
15#11 0x00493fc8 in SDL_main (argc=1, argv=0x22fe90) at sdlmain.cpp:981
16#12 0x004be140 in console_main (argc=1, argv=0x22fe90)
17    at win32/SDL_win32_main.c:249
18#13 0x004be305 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251eff "", 
19    sw=10) at win32/SDL_win32_main.c:361
20#14 0x004bdc3a in main ()
21    at f:/msys/1.0/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_string.h:216

Not sure what to make of this. I can reproduce it everytime. If you need more info just ask. Frames 0 and 1 are exactly the same in info as the previous report.

Found something maybe? Got Beneath a Steelsky (original CD version) to run then suddenly it crashes. Sometimes it runs and often it won't and crash to the my often reported spot. If it doesn't crash there it crashes later in-game.

Here's the Report:

1Program received signal SIGSEGV, Segmentation fault.
2[Switching to thread 2076.0xed0]
3DX5_CloseAudio (this=0x2c94688) at SDL_dx5audio.c:407
4407                             IDirectSoundBuffer_Release(mixbuf);
5(gdb) bt
6#0  DX5_CloseAudio (this=0x2c94688) at SDL_dx5audio.c:407
7#1  0x6ac82426 in SDL_AudioQuit () at SDL_audio.c:592
8#2  0x6ac813d6 in SDL_QuitSubSystem (flags=65535) at SDL.c:200
9#3  0x6ac81472 in SDL_Quit () at SDL.c:223
10#4  0x77c37a86 in msvcrt!_initterm () from C:\windows\system32\msvcrt.dll
11#5  0x77c37b0d in msvcrt!_cexit () from C:\windows\system32\msvcrt.dll
12#6  0x00000000 in ?? () from 
13#7  0x00352320 in ?? ()
14#8  0x77c1ea7c in msvcrt!__initenv () from C:\windows\system32\msvcrt.dll
15#9  0x77f5b42c in ntdll!LdrSetAppCompatDllRedirectionCallback () from ntdll.dll
16#10 0x77c10000 in ?? ()
17#11 0x00000000 in ?? () from 
18#12 0x00000001 in ?? ()
19#13 0x00352320 in ?? ()
20#14 0x00000000 in ?? () from 
21#15 0x00352490 in ?? ()
22#16 0x0386eb74 in ?? ()
23#17 0x77f62864 in ntdll!NlsMbCodePageTag () from ntdll.dll
24#18 0x77c1e94f in msvcrt!__initenv () from C:\windows\system32\msvcrt.dll
25(gdb) Previous frame inner to this frame (corrupt stack?)

1(gdb) frame 0
2#0  DX5_CloseAudio (this=0x2c94688) at SDL_dx5audio.c:407
3407                             IDirectSoundBuffer_Release(mixbuf);
4(gdb) p IDirectSoundBuffer_Release
5No symbol "IDirectSoundBuffer_Release" in current context.
6(gdb) p mixbuf
7No symbol "mixbuf" in current context.

1(gdb) frame 1
2#1  0x6ac82426 in SDL_AudioQuit () at SDL_audio.c:592
3592                             audio->CloseAudio(audio);
4(gdb) p audio
5$1 = (SDL_AudioDevice *) 0x2c94688
6(gdb) p CloseAudio
7No symbol "CloseAudio" in current context.

1(gdb) frame 2
2#2  0x6ac813d6 in SDL_QuitSubSystem (flags=65535) at SDL.c:200
3200                     SDL_AudioQuit();
4(gdb) p SDL_AudioQuit
5$2 = {void (void)} 0x6ac823c0 <SDL_AudioQuit>

1(gdb) frame 3
2#3  0x6ac81472 in SDL_Quit () at SDL.c:223
3223             SDL_QuitSubSystem(SDL_INIT_EVERYTHING);
4(gdb) p SDL_QuitSubSystem
5$3 = {void (Uint32)} 0x6ac81380 <SDL_QuitSubSystem>
6p SDL_INIT_EVERYTHING
7No symbol "SDL_INIT_EVERYTHING" in current context.

No idea if this has any basis on the patch but here you go.

@priestlyboy: my strip.exe also crashes on any sdl lib 😖. And Cygwin strip as well. However just running strip sdl.dll works.

@Gulikoza, yes, I know it's weird. It must be an issue with the binutils from MinGW. I'm not sure though. And it happens that same for me as well as I can strip sdl.dll fully but I can't strip -d sdl.dll. Yet I can strip -d anything else just not the SDL from SDL1.3.x.

*chuckles* I just had an idea...I'll see if it works.

I run strip -s on SDL.dll and dosbox.exe in /usr/local/bin after building them.

I made the mistake of running strip -s on all files in my SDL12/src directory (I think), which broke things pretty good and confused the hell out of me.

Never had strip crash on me though. Could be because I'm using the latest stuff available on SourceForge (binutils 2.15.94-20050118-1, win32api-3.2, nasm-0.98.39-win32, mingw-3.2.0-rc-3, msys-1.0.11-2004.04.30-1, and msysdtk-1.0.1). I should also mention that in my near-25-years of using computers, I have found few software packages more confusing to download and install than MinGW/MSYS.

strip and strip -s are the same but strip -d is different and it will crash on stripping SDL.dll. It has at least for me. I don't have the later binutils because I got some other errors with other projects with the candidate version.

I recommend using the current versions of the tools and the snapshots of msys but not the candidates.

It's confusing because there aren't many people maintining the package system and it's only up to date in spurts.

priestly, what does Scaler_DstWrite contain? (0x0 I fear. I just don't know why 😉 )

It returns with this

1(gdb) p Scaler_DstWrite
2$1 = (Bit8u *) 0x3f000 <Address 0x3f000 out of bounds>

priestlyboy: You're right - it crashes on me with -d too, but according to this page -s strips everything, while -d strips only debugging info. Seems strange that stripping more data doesn't cause a crash when stripping less data does, or am I wrong about -s vs. -d?

About the binutils and other packages: I guess I'm lucky that I don't have many problems, but maybe it's because I only build DOSBox and SDL with it at the moment.

Moe: I downloded your latest bin's but they dont seem to include the config file. Where can I get a config file with the required settings?

-Blade FireLight

You'll find how to generate a config file in the DOSBox readme.

moe, i made a little patch to fix my vbe2 problems with quake.
give it a look if you want: