VOGONS

Common searches


Reply 60 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 61 of 145, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

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.

Ieremiou
----------
Helping Debug DOSBox.

Reply 62 of 145, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

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.

Last edited by priestlyboy on 2005-04-25, 02:49. Edited 1 time in total.

Ieremiou
----------
Helping Debug DOSBox.

Reply 63 of 145, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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

Reply 64 of 145, by Freddo

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 65 of 145, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

@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:

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

Reply 66 of 145, by `Moe`

User metadata
Rank Oldbie
Rank
Oldbie

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?

Reply 68 of 145, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

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.

Ieremiou
----------
Helping Debug DOSBox.

Reply 69 of 145, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

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

#0  Normal_8_32 (s=0x1ce2d50) at render_templates.h:96
#1 0x0048f02f in VGA_DrawPart (lines=100) at vga_draw.cpp:215
#2 0x0047ecf5 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 0x00406479 in CALLBACK_Idle () at callback.cpp:69
#6 0x004acc75 in INT16_Handler () at bios_keyboard.cpp:392
#7 0x004012e5 in Normal_Loop () at dosbox.cpp:127
#8 0x00401376 in DOSBOX_RunMachine () at dosbox.cpp:170
#9 0x004065f6 in CALLBACK_RunRealInt (intnum=22) at callback.cpp:105
#10 0x00453c21 in device_CON::Read (this=0x4935af8, data=0x22e947 "\b,ë\"",
size=0x22e83e) at dev_con.h:63
#11 0x004545f1 in DOS_Device::Read (this=0x49448a8, data=0x22e947 "\b,ë\"",
size=0x22e83e) at dos_devices.cpp:59
#12 0x0045c61d in DOS_ReadFile (entry=0, data=0x22e947 "\b,ë\"",
amount=0x22ea5e) at dos_files.cpp:296
#13 0x004b7867 in DOS_Shell::InputCommand (this=0x4944928, line=0x22ebb0 "")
at ../../include/logging.h:44
#14 0x004b4d58 in DOS_Shell::Run (this=0x4944928) at shell.cpp:279
#15 0x004b4a5b in SHELL_Init () at shell.cpp:502
#16 0x00493fc8 in SDL_main (argc=1, argv=0x22fe90) at sdlmain.cpp:981
#17 0x004be140 in console_main (argc=1, argv=0x22fe90)
at win32/SDL_win32_main.c:249
#18 0x004be305 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251eff "",
sw=10) at win32/SDL_win32_main.c:361
#19 0x004bdc3a 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=0x1ce2d50) at render_templates.h:96
96 dst[x]=pixel;LC[0][x]=pixel;

(gdb) p dst

No symbol "dst" in current context.

(gdb) p pixel

$2 = 4278190248

(gdb) p LC

No symbol "LC" in current context.

(gdb) frame 1

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

(gdb) p RENDER_DrawLine

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

(gdb) p data

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

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

(gdb) bt

#0  Normal_8_32 (s=0x1928098) at render_templates.h:96
#1 0x0048f02f in VGA_DrawPart (lines=50) at vga_draw.cpp:215
#2 0x0047ecf5 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 0x004b75c9 in DOS_Shell::Execute (this=0x4944950, name=0x22da10 "sierra",
args=0x22ebb6 "") at shell_misc.cpp:454
#7 0x004bb725 in DOS_Shell::DoCommand (this=0x4944950, line=0x22ebb0 "sierra")
at shell_cmds.cpp:116
#8 0x004b3bae in DOS_Shell::ParseLine (this=0x4944950, line=0x22ebb0 "sierra")
at shell.cpp:209
#9 0x004b4d70 in DOS_Shell::Run (this=0x4944950) at shell.cpp:280
#10 0x004b4a5b in SHELL_Init () at shell.cpp:502
#11 0x00493fc8 in SDL_main (argc=1, argv=0x22fe90) at sdlmain.cpp:981
#12 0x004be140 in console_main (argc=1, argv=0x22fe90)
at win32/SDL_win32_main.c:249
#13 0x004be305 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251eff "",
sw=10) at win32/SDL_win32_main.c:361
#14 0x004bdc3a 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

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:

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 2076.0xed0]
DX5_CloseAudio (this=0x2c94688) at SDL_dx5audio.c:407
407 IDirectSoundBuffer_Release(mixbuf);
(gdb) bt
#0 DX5_CloseAudio (this=0x2c94688) at SDL_dx5audio.c:407
#1 0x6ac82426 in SDL_AudioQuit () at SDL_audio.c:592
#2 0x6ac813d6 in SDL_QuitSubSystem (flags=65535) at SDL.c:200
#3 0x6ac81472 in SDL_Quit () at SDL.c:223
#4 0x77c37a86 in msvcrt!_initterm () from C:\windows\system32\msvcrt.dll
#5 0x77c37b0d in msvcrt!_cexit () from C:\windows\system32\msvcrt.dll
#6 0x00000000 in ?? () from
#7 0x00352320 in ?? ()
#8 0x77c1ea7c in msvcrt!__initenv () from C:\windows\system32\msvcrt.dll
#9 0x77f5b42c in ntdll!LdrSetAppCompatDllRedirectionCallback () from ntdll.dll
#10 0x77c10000 in ?? ()
#11 0x00000000 in ?? () from
#12 0x00000001 in ?? ()
#13 0x00352320 in ?? ()
#14 0x00000000 in ?? () from
#15 0x00352490 in ?? ()
#16 0x0386eb74 in ?? ()
#17 0x77f62864 in ntdll!NlsMbCodePageTag () from ntdll.dll
#18 0x77c1e94f in msvcrt!__initenv () from C:\windows\system32\msvcrt.dll
(gdb) Previous frame inner to this frame (corrupt stack?)
(gdb) frame 0
#0 DX5_CloseAudio (this=0x2c94688) at SDL_dx5audio.c:407
407 IDirectSoundBuffer_Release(mixbuf);
(gdb) p IDirectSoundBuffer_Release
No symbol "IDirectSoundBuffer_Release" in current context.
(gdb) p mixbuf
No symbol "mixbuf" in current context.
(gdb) frame 1
#1 0x6ac82426 in SDL_AudioQuit () at SDL_audio.c:592
592 audio->CloseAudio(audio);
(gdb) p audio
$1 = (SDL_AudioDevice *) 0x2c94688
(gdb) p CloseAudio
No symbol "CloseAudio" in current context.
(gdb) frame 2
#2 0x6ac813d6 in SDL_QuitSubSystem (flags=65535) at SDL.c:200
200 SDL_AudioQuit();
(gdb) p SDL_AudioQuit
$2 = {void (void)} 0x6ac823c0 <SDL_AudioQuit>
(gdb) frame 3
#3 0x6ac81472 in SDL_Quit () at SDL.c:223
223 SDL_QuitSubSystem(SDL_INIT_EVERYTHING);
(gdb) p SDL_QuitSubSystem
$3 = {void (Uint32)} 0x6ac81380 <SDL_QuitSubSystem>
p SDL_INIT_EVERYTHING
No symbol "SDL_INIT_EVERYTHING" in current context.

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

Attachments

  • Filename
    ROUND.ZIP
    File size
    25.4 KiB
    Downloads
    57 downloads
    File comment
    Does not crash with the patch.
    File license
    Fair use/fair dealing exception

Reply 71 of 145, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

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

Ieremiou
----------
Helping Debug DOSBox.

Reply 72 of 145, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 73 of 145, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

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.

Ieremiou
----------
Helping Debug DOSBox.

Reply 75 of 145, by priestlyboy

User metadata
Rank Oldbie
Rank
Oldbie

It returns with this

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

Ieremiou
----------
Helping Debug DOSBox.

Reply 76 of 145, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 79 of 145, by kekko

User metadata
Rank Oldbie
Rank
Oldbie

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

Attachments

  • Filename
    vesapatch.diff
    File size
    1.16 KiB
    Downloads
    69 downloads
    File license
    Fair use/fair dealing exception