VIDEO Patch for pixel-perfect scaling (SDL1)

[Yesterplay80]

Nah, it's just the dot, not the two new lines, forget what I said. Just remove it and it will be fine.

Code: Select all

-   Pbool->Set_help("Do aspect correction, if your output method doesn't support scaling this can slow things down!.");
+   Pbool->Set_help("Do aspect correction, if your output method doesn't support scaling this can slow things down!");

[Ant_222]

This one just corrects a typo, quite harmless.

[Yesterplay80]

r4147 (and possibly the following revisions) once again breaks compatibility with your patch because of the changes it introduces in sdlmain.cpp.

[Ant_222]

I will try to merge the changes at this weekend.

[Yesterplay80]

I will try to merge the changes at this weekend.

Thanks! I tried to mege the changes into my modified patch, too, but I always got a malformed patch in a line I didn't even touch.

[Ant_222]

Thanks! I tried to mege the changes into my modified patch, too, but I always got a malformed patch in a line I didn't even touch.

Does svn merge work for you? I was going to try it.

[Ant_222]

Please, test the attached patch with the latest SVN revision of DOSBox.

[Yesterplay80]

It applied and compiled without errors, looking good here!

[Ant_222]

It applied and compiled without errors, looking good here! :happy:

Excellent, thank for testing.

[aaronp]

On Linux, if I try this myself either by applying it manually or compiling ECE, dosbox crashes when I use the new outputs. But it seems to work fine if I just use the ECE binary. Is this a problem any of you have run into? I thought maybe it didn't like some of my CFLAGS, but no, it has the same issue with a clean ./configure && make.

[Ant_222]

On Linux, if I try this myself either by applying it manually or compiling ECE, dosbox crashes when I use the new outputs. But it seems to work fine if I just use the ECE binary.

The ECE binary with the new outputs? Then maybe we should ask YP which version of my patch ECE currently contains...

Is this a problem any of you have run into?

Not I, but I do not have *nix and am using MinGW-32 with GCC 4.9.3.

I thought maybe it didn't like some of my CFLAGS, but no, it has the same issue with a clean ./configure && make.

Could you perhaps re-try with my version of GCC, or simply with some other version? Also please post a config file with which you have the crashes. EDIT: Try enabling fullscreen mode in the config file.

[aaronp]

I say it "crashes", but if I run it through GDB it is actually closing normally, so there is no stack trace. I'll step through it and see if I can find anything.

Code: Select all

[sdl]
fullscreen=true
fulldouble=false
fullresolution=desktop
windowresolution=original
output=surfacepp
autolock=true
sensitivity=100
waitonerror=true
priority=higher,normal
mapperfile=mapper-SVN.map
usescancodes=true

[dosbox]
language=
machine=svga_s3
captures=/data/Pictures
memsize=16

[render]
frameskip=0
aspect=true
scaler=none

[cpu]
core=auto
cputype=auto
cycles=auto
cycleup=10
cycledown=20


[Ant_222]

I have failed to reproduce the problem with your config and plain SVN DOSBox with my patch alone.

I say it "crashes", but if I run it through GDB it is actually closing normally, so there is no stack trace. I'll step through it and see if I can find anything.

Thank you very much for your help.

[Yesterplay80]

And I failed to reproduce it under my Linux VM and the current ECE binary as well. DOSBox starts just fine, I can enter commands (as you can see), can start a game, close a game and exit DOSBox without errors.

Bildschirmfoto vom 2018-09-20 16-43-29.png

I'm using the latest patch, pixel-perfect-alpha14-4157, btw.

[pantercat]

I also have problems with surfacepp. The last version that has worked well for me is ece r4132. I'm running debian testing and these are the versions that I have tested.

output=surfacepp -> dosbox ece r4132 -> ok
-> dosbox ece r4133 to r4140 -> not tested
-> dosbox ece r4141, r4157, r4160, r4162 -> dosbox just closes

output=opengl -> always ok

[Ant_222]

Well, I have to start from something. Is there a way to redirect the log output to a file to see what it is in it?

[aaronp]

There's nothing in the logs. It's weird, and I suspect it may be compiler-specific. With the latest GCC, at some point the application just returns zero, and I haven't been able to figure out where or how (might be my lack of familiarity with c++)

However, compiled with clang, I do get a segfault with the following stacktrace:

Code: Select all

#0  0x0000000000000000 in ?? ()
#1  0x00000000004feb5c in GFX_StartUpdate (pixels=@0x351b220: 0x0, pitch=<error reading variable>) at sdlmain.cpp:1437
#2  0x000000000050ad3d in RENDER_StartUpdate () at render.cpp:171
#3  0x00000000004d375f in VGA_VerticalTimer () at vga_draw.cpp:838
#4  0x00000000004ca178 in PIC_RunQueue () at pic.cpp:486
#5  0x000000000040a041 in Normal_Loop () at dosbox.cpp:136
#6  0x000000000040a0b6 in DOSBOX_RunMachine () at dosbox.cpp:320
#7  0x000000000040fe88 in CALLBACK_RunRealInt (intnum=<optimized out>) at callback.cpp:105
#8  0x0000000000492d12 in device_CON::Read (this=0x3574680, data=0x7fffffffc5c7 " ", size=0x7fffffffc596) at ./dev_con.h:64
#9  0x00000000004961f5 in DOS_ReadFile (entry=<optimized out>, data=0x7fffffffc5c7 " ", amount=0x7fffffffc64e, fcb=<optimized out>) at dos_files.cpp:385
#10 0x00000000005f0452 in DOS_Shell::InputCommand (this=0x35185b0, line=0x7fffffffc7e0 "") at shell_misc.cpp:55
#11 0x00000000005e82cc in DOS_Shell::Run (this=0x35185b0) at shell.cpp:343
#12 0x00000000005e8c80 in SHELL_Init () at shell.cpp:750
#13 0x0000000000501d34 in main (argc=<optimized out>, argv=<optimized out>) at sdlmain.cpp:2585


If I step through it with gdb using the clang build, it appears to segfault immediately upon returning from ssImageToScreen.

Hold on! I'm typing this as a go. I did find something that works with GCC 8! There is a missing return statement in ssStartUpdate in sdlmain.cpp. Adding the return there fixes the crash with gcc, but it still crashes with the segfault with clang. Here is an updated patch with the gcc fix.

[Ant_222]

If I step through it with gdb using the clang build, it appears to segfault immediately upon returning from ssImageToScreen.

Could that be due to the old K&R style declaration with empty parenthesis instead of (void)?

Hold on! I'm typing this as a go. I did find something that works with GCC 8! There is a missing return statement in ssStartUpdate in sdlmain.cpp. Adding the return there fixes the crash with gcc, but it still crashes with the segfault with clang. Here is an updated patch with the gcc fix.

Thanks! Updated patch uploaded.

[aaronp]

On second look, the fix seems to be working for clang as well. Sorry, I've got dosbox sources in a couple different places. Must have gotten confused about which one I was looking at.

[Ant_222]

On second look, the fix seems to be working for clang as well. Sorry, I've got dosbox sources in a couple different places. Must have gotten confused about which one I was looking at.

No problem, and many thanks for debugging. Will you please test the latest patch for r4163 from the title post of the thread?