These are the changes for vs .net projects. It generates the headers and compiles fine. However HOSTCC=@CC_FOR_BUILD@ that you added in this patch does not work mingw 😖

gulikoza, you have to run automake/autoconf/aclocal before building, as I had to modify configure.in. That line (and the configure.in modifications) is needed for cross-compilation.

Qbix, sure, I'll do. From what I see, you use it correctly.

Does anyone who sees crashes with my patch have a Pentium 4 with Hyper Threading? Just checking out my neighbour's laptop (p4/HT, geforce 4), and I get strange behaviour as well, including some crashes.

I ran autogen.sh on my linux box before configuring...don't know, maybe something is messed up on my system so somebody else should check it as well.

Regarding nvidia, I have already fixed on ebug, though I doubt it's the cause of the crashes. Going out sometimes even helps finding people with appropriate hardware willing to help 😉

Regarding HOST_CC, I've taken the configure.in code from libtool, you should find the exact same sequence in config.guess. How does it fail?

The HOSTCC=@CC_FOR_BUILD@ ends up in Makefile, then of course when compiling I get error:

CC_FOR_BUILD@: command not found

I'm using autoconf 2.59 & automake 1.9.4 on my linux box.

Hmm... I guess my configure.in modifications didn't actually make it into the full patch. Seems like I excluded all *.in files 😉 Need to adjust the source to Qbix' CVS changes, then it's another round of build+patch today. I've verified that it works on the above mentioned laptop, and a recent, HQ-capable nvidia card will be tested next week.

Could anyone post a few hi res screenshots of some openglhq scaled graphics. My graphic card doesn't support pixel shaders.

Here goes another round. Attached is the all-in-one-patch for my binary build. As soon as I have been able to solve the reported nvidia crash, I will release them seperated again.

Changes:
- included wd's VS .NET modifications
- temporarily disabled EXT_paletted_texture usage (if no one shows a good reason to keep it, I will drop it - more trouble than it's worth, I think)
- tweaked HQ scaling for even better appearance

I have made two screenshots and uploaded them to the binary build directory: http://garni.ch/Software/dosbox/

The screenshots are made in windowed mode with a hwscale factor of 1.66. The game screen uses normal2x on top, so it is effectively scaled by a factor of 3.33. Integral scaling factors look even better (though due to today's tweaks, the difference isn't that big anymore). EDIT: I've added another screenshot in full-screen mode, total scaling factor: 4.00 (widescreen laptop is cool for retro gaming 😉

Argh, these screenshots are killing me! What a torture to watch the glory of hqX, X>2! Would it not be possible to enable software-hq-any x? Otherwise you are forcing me to by a new graphics card for my desktop. (Or a new notebook, but I guess this would be a bit of an overkill)

Mind you, I'm not doing original hq2x/3x/4x scaling anymore. This patch is even better, IMHO. The basic working principle is the same, but I've improved the algorithm in several ways.

And a box that's powerful enough to do software-only hq4x with enough CPU left for dosbox itself most likely has a graphics card capable of opengl-hq, so there's no strong point. Feel free to code it, send a patch and I'll integrate it 😉

Wow.. It's indeed impressive 😀
Thanks for the screenies.

Heya Moe,
Tried your new patch.. Got something differet this time. Might find it interesting.

An assertion error? Hmm.

Btw, I have output set to opengl but that line is suppose to be defined for only openglhq.

Greets 😀

EDIT:
Adding other debugging info from MinGW

bt
#0 0x77c33d8c in msvcrt!_assert () from C:\windows\system32\msvcrt.dll
#1 0x004a0bcf in GFX_OpenGL_StartUpdate (pixels=@0x1ce5dd4, pitch=@0x1ce5dd8)
at sdlopengl.cpp:910
#2 0x00492301 in GFX_StartUpdate (pixels=@0x1ce5dd4, pitch=@0x1ce5dd8)
at sdlmain.cpp:467
#3 0x00490e74 in RENDER_StartUpdate () at render.cpp:226
#4 0x0048f1b8 in VGA_VerticalTimer (val=0) at vga_draw.cpp:253
#5 0x0047ed05 in PIC_RunQueue () at pic.cpp:428
#6 0x004012a5 in Normal_Loop () at dosbox.cpp:123
#7 0x00401376 in DOSBOX_RunMachine () at dosbox.cpp:170
#8 0x00406479 in CALLBACK_Idle () at callback.cpp:69
#9 0x004acd25 in INT16_Handler () at bios_keyboard.cpp:392
#10 0x004012e5 in Normal_Loop () at dosbox.cpp:127
#11 0x00401376 in DOSBOX_RunMachine () at dosbox.cpp:170
#12 0x004065f6 in CALLBACK_RunRealInt (intnum=22) at callback.cpp:105
#13 0x00453c21 in device_CON::Read (this=0x593db80, data=0x22e947 "w,ë\"",
size=0x22e83e) at dev_con.h:63
#14 0x004545f1 in DOS_Device::Read (this=0x594c900, data=0x22e947 "w,ë\"",
size=0x22e83e) at dos_devices.cpp:59
#15 0x0045c61d in DOS_ReadFile (entry=0, data=0x22e947 "w,ë\"",
amount=0x22ea5e) at dos_files.cpp:296
#16 0x004b7917 in DOS_Shell::InputCommand (this=0x594c980, line=0x22ebb0 "")
at ../../include/logging.h:44
#17 0x004b4e08 in DOS_Shell::Run (this=0x594c980) at shell.cpp:279
#18 0x004b4b0b in SHELL_Init () at shell.cpp:502
#19 0x00493fd8 in SDL_main (argc=1, argv=0x22fe90) at sdlmain.cpp:981
#20 0x004be1f0 in console_main (argc=1, argv=0x22fe90)
at win32/SDL_win32_main.c:249
#21 0x004be3b5 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251eff "",
sw=10) at win32/SDL_win32_main.c:361
#22 0x004bdcea 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

frame 1

#1 0x004a0bcf in GFX_OpenGL_StartUpdate (pixels=@0x1ce5dd4, pitch=@0x1ce5dd8)
at sdlopengl.cpp:910
910 assert(opengl.framebufs[opengl.current_buffer] != NULL);

p opengl.framebufs
$4 = {0x81e0000, 0x0}

p opengl.current_buffer
$1 = 1

I hope this helps more.

I put the assertion there to catch the suspected error as soon as possible 😀

And indeed, your backtrace is of great value:

p opengl.framebufs
$4 = {0x81e0000, 0x0}

That Can't Happen(tm). Well, it did. If you have the patience, I will upload two new versions for you to try. Want to experiment with two things. Expect them in a few minutes in my usual upload location. EDIT: I think I found and fixed the bug. So there's a new binary build, and I expect it to work. Please test and tell me how it went.

By the way, the assert is not just for openglhq. It's #ifdef'ef for the case it's being compiled with SDL-1.2. If the user has SDL-1.3 and chooses opengl, it is still supposed to be reached, so that's just fine.

Where does one get SDL 1.3? I'm using what I thought was the latest CVS, and its sdl-config reports v1.2.9

Ha ha, moe, I love ya man. It works 😀.
Great job.

I do have some weirdness going from window to fullscreen it only happens on and off though.
It's another SegFault SDL that occurs on the transfer from Window to Fullscreen.
I'm also getting crazy crashes just running programs. Most likely SegFaults but I need the patch Lol.

If I had your new patch I could give it a go on doing more debugging.

Greets.

EDIT:

@HunterZ : It's a "stable" branch of SDL that is only available through their CVS checkout system. The head or trunk of SDL is 1.2.x and can be unstable especially for compiling it.

Here's the patch, all-in-one version again. Will do the separated patches in the next days. Did you try opengl-hq mode? Does it look as expected (see screenshots)?

moe, do you think it would be difficult to re-implement the window resize?

priestlyboy: Interesting. How do I check out the 1.3 branch code?

Also, are you saying that 1.2 is unstable or that 1.3 is unstable? I can compile the 1.2 CVS without problems most of the time (Icculus committed some patches that broke it the other day, but I emailed him and he fixed it)

moe: What is that game you're taking screenshots of?

@HunterZ: use cvs co -r branch_1_3_x SDL12

Thanks! I'll try that.

I found a 4-year-old slashdot post saying that 1.3 was going to be largely rewritten and that a stable release would come out in late 2002. Obviously things didn't work out that way...

EDIT: Got a compile error for src/video/wincommon/SDL_wingl.c. Said there is an #endif without #if on line 232. I commented out that #endif and it compiled, but I don't know whether that is the correct fix.

Still compiling the rest... (MinGW32/MSYS w/DirectX and NASM installed)