yup, kekko is correct. Green image will appear with overlay (although only overlay), but it's sligtly different than before.

I also tested the fullhq patch with .NET 2003 compiler and there are several problems:
- how are the dosbox_openglhq_passX.h files generated? They do not seem to exist when patching...had to copy from configured mingw source.
- "support.h" has to be included for strcasecmp
- <assert.h> has to be included for assert()
- __WIN32__ should be changed to WIN32 (how's it's done in other sources, the compiler does not seem to define __WIN32__ 😁)
- APIENTRY problems (default_malloc(), default_free())....I believe functions should be declared as

return_type APIENTRY function()

at least that's how it's done in some header files, won't compile the way it's done now.
- vs 2003 (even 2005) does not seem to have fmax & fmin 😁. Here's where I gave up, but the files compiled and failed at linking stage.

Also another interesting thing...I assume openglhq already enables hardware hq2x scaling. What if user also sets scaler=hq2x? Will it do "double" hq2x scaling? 🤣 Perhaps there's a better way to do it. My D3D patch loads shaders from external file and uses an extra configuration option (pixelshader=). Perhaps openglhq should do something similar, maybe we could merge the options to something like this:

# output -- What to use for output: surface,overlay,opengl,ddraw,direct3d.
# hwscaler (hwshader...something like this?) -- Use hardware scaling (requires fairly new graphics card). Valid for opengl or direct3d outputs.
# Make sure you also set scaler=normal2x when using hwscaler.
# opengl: none (point? current openglnb mode), bilinear (current opengl mode), hq2x (current openglhq mode)
# direct3d: none, bilinear, scale2x

This might be less confusing then using 3 different output= options for opengl.

403 error is fixed - now the page works.

16-bit mode can't work with output=overlay, as we don't have a colorspace conversion from 16-bit RGB to YUV. As it is, we can't even determine if a given output mode is RGB or YUV. In 8-bit modes this is handled via the palette, but 16 bit doesn't have a palette.

software hq2x and openglhq are completely separate things which only share trigger values. They are reasonably compatible in appearance, so 2x scaling with them should look almost equal. Doing hq2x and openglhq scaling at the same time is a bit pointless (and inefficient), but no bad things will happen. It will look worse than openglhq-only but better than hq2x+opengl.

As for the .net problems: send patches (via pm, for example). I can't test these compilers, but I gladly accept fixes. That APIENTRY thing revolves around calling conventions, which should not be a problem there. A Cut&Paste of the (english!) error messages would be nice to see what's the correct fix.

The headers are generated by a small shell command, sed, and the included hexdump.c program. See Makefile.am for details. If there's a way in .NET to build hexdump and run this automatically, I could extend hexdump.c so that the remaining shell commands are no longer needed and hexdump does the full conversion. I hope you have some patience so we can get this working as smooth as possible. 😉

fmax/fmin should be in math.h, really. They are part of the C99 standard. Perhaps C99 must be enabled separately.

Merging won't work:
opengl and openglnb work on any opengl hardware, even software-opengl without the faintest support for pixel shaders (vmware, for example). Real pixel shaders entered opengl only for those cards that can run openglhq - a quite high requirement. Moreover, openglhq is not just a pixel shader. It is a tricky 3-pass rendering system with strict requirements on bit depth, interpolation (or lack thereof), and texture order. While there is the possibility to replace the three fragment programs (opengl-speak for pixel shaders), I didn't do that in order to get arbitrary effects but to tweak openglhq for special cases/games. It's simply too specialized for a generic solution.

Edited to add: Just by the way, try fractional hwscaling. hwscale=1.5 in windowed mode is my favourite. IIRC, that's beyond the current d3d code's possibilities.

`Moe` wrote:

software hq2x and openglhq are completely separate things which only share trigger values.
<snip>

Yes I agree, but uninformed user might think he needs to set both parameters to get hq2x scaling...

`Moe` wrote:

As for the .net problems: send patches (via pm, for example). I can't test these compilers, but I gladly accept fixes. That APIENTRY thing revolves around calling conventions, which should not be a problem there. A Cut&Paste of the (english!) error messages would be nice to see what's the correct fix.

As I've said...doesn't look that bad, just add the includes and change that define. APIENTRY is fine, but I believe it's in the wrong place, it should be after the return_type...at least .net wants it there. With the default static APIENTRY void*...there are following errors:

sdlopengl.cpp(220) : warning C4518: 'void ' : storage-class or type specifier(s) unexpected here; ignored
sdlopengl.cpp(220) : warning C4230: anachronism used : modifiers/qualifiers interspersed; qualifier ignored
sdlopengl.cpp(220) : error C2165: 'left-side modifier' : cannot modify pointers to data
sdlopengl.cpp(225) : error C2440: 'return' : cannot convert from 'char *' to 'int *'
Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast
sdlopengl.cpp(226) : warning C4508: 'default_malloc' : function should return a value; 'void' return type assumed
sdlopengl.cpp(228) : warning C4518: 'void ' : storage-class or type specifier(s) unexpected here; ignored
sdlopengl.cpp(231) : warning C4508: 'default_free' : function should return a value; 'void' return type assumed

as if the compiler doesn't see the return type. Changing it to static void* APIENTRY compiles fine...since SDL_opengl.h has function prototypes as GLAPI void APIENTRY, I think this should be the correct syntax.

`Moe` wrote:

The headers are generated by a small shell command...

I have no idea how to do this 😕

`Moe` wrote:

fmax/fmin should be in math.h, really. They are part of the C99 standard. Perhaps C99 must be enabled separately.

Well...they're not there 😁. I've searched all headers, all libs...no sign of either fmax or fmin. Looks like MS is not following C99 🤣

`Moe` wrote:

Merging won't work:

Well...perhaps I should rephrase my idea. Modes supporting different hardware scaling algorithms (either the simple point or bilinear sampling or the "advanced" ones) should be implemented as a different option instead of different display modes. I believe this is less confusing for the end user.

D3D should do fractional scaling as well, although currently I do not check the hwscale parameter to see if scaling has to be enabled or not 😉

gulikoza wrote:

`Moe` wrote:

software hq2x and openglhq are completely separate things which only share trigger values.
<snip>

Yes I agree, but uninformed user might think he needs to set both parameters to get hq2x scaling...

Well, combined with your other idea about merging, we get... I don't know what we get. Difficult thing, as sw scalers make sense even with pixel shaders/openglnb/opengl. advmame2x should look nicer with openglhq as well, for those who like the look of advmame. hq2x and d3d pixel shaders make sense. It's really just a few combinations that are a bit useless. I don't call openglhq like hq2x intentionally, do you really think users will associate these two? IMHO they sound different enough, so users will not be mislead.

gulikoza wrote:

`Moe` wrote:

The headers are generated by a small shell command...

I have no idea how to do this 😕

Is there any option in VS .NET to build a program and execute that to generate another source file? I really think there must be, as this is not entirely uncommon.

gulikoza wrote:

`Moe` wrote:

fmax/fmin should be in math.h, really. They are part of the C99 standard. Perhaps C99 must be enabled separately.

Well...they're not there 😁. I've searched all headers, all libs...no sign of either fmax or fmin. Looks like MS is not following C99 🤣

crappy compiler... well, it's not performace critical, so I could make it a macro.

gulikoza wrote:

`Moe` wrote:

Merging won't work:

Well...perhaps I should rephrase my idea. Modes supporting different hardware scaling algorithms (either the simple point or bilinear sampling or the "advanced" ones) should be implemented as a different option instead of different display modes. I believe this is less confusing for the end user.

Do you really think so? Users might be confused why that hq-option doesn't work with d3d, or that their cool pixel shader won't load as an opengl fragment program. We could call it "output_config", then it's more like an abstract device-specific configuration (like midi's config option). Yeah, I probably like that idea:

output=surface has output_config=windib or directx
output=d3d has output_config=<shader filename>
output=opengl has output_config=interpolate, nearest, hq

By the way, I was unable to run my binary on winXP, but on win98 it worked. Funny thing, no idea yet what's wrong. Just be warned 😉

`Moe` wrote:

By the way, I was unable to run my binary on winXP, but on win98 it worked. Funny thing, no idea yet what's wrong. Just be warned 😉

I replaced your zlib.dll v1.2.2.0 with v1.1.4.0 and it works now.

This is awesome 😁 Thanks 😀

I can finally get Battlespire to run in DOSBox thanks to the 16bit support 😀 It's by no means playable, though, as it's horribly slow (1FPS), but it works 😀 Awesome 😎

Yeah...probably combining some scalers could be useful (like openglhq with tv2x) but performance-wise it's totally unrecomended. I doubt openglhq and advmame2x look that much better 😁
Call that option hwscaler (yes, somewhat to similar to hwscale), output_config, just plain config...that is the general idea what I had in mind 😀

As for .NET compiler, I did some research and it seems you can specify a command line to use during build. A build event can be specified as pre-build, pre-link or post-build event. I guess this could be done by making hexdump script it's own project in the solution, making dosbox a dependency on hexdump, then running it as a pre-build event.

Performance-wise, it's not as bad as it may sound. And there are people who prefer the rounded look of advmame. Using advmame + openglhq, they get (for example) 2x advmame scaling, and 2x openglhq on top of that, which will preserve advmames appearance but look better than bilinear interpolation.

Thanks for the tip with zlib.dll, I'll try that.

Regarding hexdump, I'll extend that to do the entire header generation, then you can try your trick with pre-build.

Hey Moe, long time no see.

I had applied your full patch to my version of DOSBox (yes I'm still building just been busy with RealLife TM) and it SegFaults upon loading when using opengl/openglnb.

With the help of Qbix I was able to track down what the problem was (gotta love MinGW)

Here's the crash error and line it crashes on:

1Program received signal SIGSEGV, Segmentation fault.
20x004a4792 in Normal_8_32 (s=0x1d11d70) at render_templates.h:104
3104                     dst[x]=pixel;LC[0][x]=pixel;

Here's the BT of the crash:

1#0  0x004a4792 in Normal_8_32 (s=0x1d11d70) at render_templates.h:104
2#1  0x0048b288 in VGA_DrawPart (lines=399) at vga_draw.cpp:215
3#2  0x0047d972 in PIC_RunQueue () at pic.cpp:428
4#3  0x0040129b in Normal_Loop () at dosbox.cpp:134
5#4  0x00401489 in DOSBOX_RunMachine () at dosbox.cpp:199
6#5  0x0041d035 in CALLBACK_Idle () at callback.cpp:69
7#6  0x004c0791 in INT16_Handler () at bios_keyboard.cpp:392
8#7  0x004013bf in Normal_Loop () at dosbox.cpp:154
9#8  0x00401489 in DOSBOX_RunMachine () at dosbox.cpp:199
10#9  0x0041d205 in CALLBACK_RunRealInt (intnum=22 '\026') at callback.cpp:105
11#10 0x0044f49f in device_CON::Read (this=0x59cdf50, data=0x22eb2b "", 
12    size=0x22e95e) at dev_con.h:63
13#11 0x004502cc in DOS_Device::Read (this=0x59dd120, data=0x22eb2b "", 
14    size=0x22e95e) at dos_devices.cpp:59
15#12 0x00458c36 in DOS_ReadFile (entry=0, data=0x22eb2b "", amount=0x22eb28)
16    at dos_files.cpp:296
17#13 0x004c7a81 in DOS_Shell::InputCommand (this=0x59dd1a0, line=0x22ebe0 "")
18    at shell_misc.cpp:59
19#14 0x004c68cb in DOS_Shell::Run (this=0x59dd1a0) at shell.cpp:279
20#15 0x004c764b in SHELL_Init () at shell.cpp:500
21#16 0x004c265e in Config::StartUp (this=0x22fe00) at setup.cpp:327
22#17 0x0048f88c in SDL_main (argc=1, argv=0x22fe90) at sdlmain.cpp:1155
23#18 0x004cdac0 in console_main (argc=1, argv=0x22fe90)
24    at win32/SDL_win32_main.c:249
25#19 0x004cdc85 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251f00 "", 
26    sw=10) at win32/SDL_win32_main.c:361
27#20 0x004cd5ba in main () at ../../include/mem.h:186

And here is the (p dst) of that line it crashed on:

1(gdb) frame 0
2
3#0  0x004a4792 in Normal_8_32 (s=0x1d11d70) at render_templates.h:104
4104                     dst[x]=pixel;LC[0][x]=pixel;
5
6(gdb) p dst
7
8$3 = (Bit32u *) 0x0

Apparently, dst isn't being allocated yet before it's called which is causing the SegFault.

Greets
~Paladinate~

I tested those two games again (changing of zlib.dll solved the crash). Zork Nemesis looks fine now, D looks much better, but some green dots are still around the screen (with all working outputs).

Priestlyboy: nice to see you back. I know that real-life stuff, otherwise I wouldn't fiddle with hq scaling for 1 1/2 years now 😉

That's a funny bug you have there. It means someone called GFX_OpenGL_StartUpdate before GFX_OpenGL_SetSize was called. Does my binary build work for you (exchanging the zlib1.dll)?

Oh wait - are you using SDL-1.2? In that case it might be a bug in the "fallback" code. Haven't tested SDL-1.2 builds much.

no I'm using SDL1.3.x since I had to exchange my SDL 1.2 (from DB0.63) with the one from SDL_1.3.x to get that part to work. I even tried your SDL.dll same issue which didn't seem to affect it any.

And nope your build doesn't work either. Same faulting issue. But i can't backtrace it since your build is stripped but every output except the opengl ones work for me.

This might be related to the fact I'm using Windows XP? Which you mentioned had some crashing issues earlier, i think.

Greets
~Paladinate~

priestlyboy wrote:

And nope your build doesn't work either. This might be related to the fact I'm using Windows XP? Which you mentioned had some crashing issues earlier, i think.

Did you try to exchange zlib1.dll? I'm using Windows XP too and it helped on my comp.

Jiri, what app is that, and is it freely distributable? It sounds a bit like it's trying to use 15-bit graphics in a 16-bit mode. Or my VESA info struct may be buggy.

Priestly, does http://garni.ch/~jwalt/dosbox-openglhq-win32.zip work for you? That's an earlier build I compiled on XP instead of cross-compiling, and that one definitely works on my XP.

Jiri: Yes I already replaced my zlib1.dll but that only gets around the initiate crash when DOSBox is booting up.
The crash I've been working on is a later crash that happens during the screen SDL_app initilization which it never gets to and falls out of.

I'm downloading your other build 'moe'. I'll let u know.

EDIT: I got the same error. At least it's the same spot.

1Program received signal SIGSEGV, Segmentation fault.
2Normal_8_32 (s=0x1d76d40) at ../../../src/gui/render_templates.h:104
3        in ../../../src/gui/render_templates.h
4Current language:  auto; currently c++
5(gdb) 104       ../../../src/gui/render_templates.h: No such file or directory.

The Backtrack shows this.

1#0  Normal_8_32 (s=0x1d76d40) at ../../../src/gui/render_templates.h:104
2#1  0x0049ce6f in VGA_DrawPart (lines=100)
3    at ../../../src/hardware/vga_draw.cpp:215
4#2  0x0048cc45 in PIC_RunQueue () at ../../../src/hardware/pic.cpp:429
5#3  0x004012a5 in Normal_Loop () at ../../src/dosbox.cpp:123
6#4  0x00401376 in DOSBOX_RunMachine () at ../../src/dosbox.cpp:170
7#5  0x00406419 in CALLBACK_Idle () at ../../../src/cpu/callback.cpp:69
8#6  0x004baa55 in INT16_Handler () at ../../../src/ints/bios_keyboard.cpp:392
9#7  0x004012e5 in Normal_Loop () at ../../src/dosbox.cpp:127
10#8  0x00401376 in DOSBOX_RunMachine () at ../../src/dosbox.cpp:170
11#9  0x00406596 in CALLBACK_RunRealInt (intnum=22)
12    at ../../../src/cpu/callback.cpp:105
13#10 0x00461a11 in device_CON::Read (this=0x4a75880, data=0x22e947 "w,ë\"", 
14    size=0x22e83e) at ../../../src/dos/dev_con.h:63
15#11 0x004623e1 in DOS_Device::Read (this=0x4a84708, data=0x22e947 "w,ë\"", 
16    size=0x22e83e) at ../../../src/dos/dos_devices.cpp:59
17#12 0x0046a40d in DOS_ReadFile (entry=0, data=0x22e947 "w,ë\"", 
18    amount=0x22ea5e) at ../../../src/dos/dos_files.cpp:296
19#13 0x004c4e67 in DOS_Shell::InputCommand (this=0x4a84788, line=0x22ebb0 "")
20    at ../../../include/logging.h:44
21#14 0x004c22f8 in DOS_Shell::Run (this=0x4a84788)
22    at ../../../src/shell/shell.cpp:278
23#15 0x004c1ffb in SHELL_Init () at ../../../src/shell/shell.cpp:501
24#16 0x004a1dfa in SDL_main (argc=1, argv=0x22fe90)
25    at ../../../src/gui/sdlmain.cpp:979
26#17 0x004e0530 in console_main (argc=1, argv=0x22fe90)
27    at win32/SDL_win32_main.c:249
28#18 0x004e06f5 in WinMain (hInst=0x400000, hPrev=0x0, szCmdLine=0x251ef8 "", 
29    sw=10) at win32/SDL_win32_main.c:361
30#19 0x004e002a in main ()
31    at F:/MSYS/mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/bits/basic_string.h:216

And this is with your build. I have no clear idea why this is happening other than what was said earlier about the DST.

Greets
~Paladinate~

What video hardware do you have?

BTW, my last build was thoroughly b0rked, I'm just uploading a new one, testing that the latest changes for VS .NET didn't break anything. Gonna boot XP now to see if it works.

EDIT: The new build works for me, even zlib1.dll is not a problem anymore. Funny thing. But it works.

I wonder why nvidia owners should have problems with opengl output, but fact is, I wasn't able yet to test it there, and opengl code got more complicated. If only I had someone with nvidia hardware to test...

Yeah, I was starting to wonder if my Video Drivers or my hardware just wasn't liking opengl now.

I have a GeForce 4 Ti 4200 with the 76.50 drivers.
Normally this does just fine with any windows games that i've tested it on but with this new patch by ya, moe, it borks opengl in DOSBox for me. Without the patch opengl works ok.

I'm gonna get the latest WHQLed drivers by nVidia now though which are 71.89 for all cards as it seems.

Greets

gulikoza, I'll attach an updated patch, please apply to a clean CVS checkout - it's essentially my binary build in an all-in-one patch. If it works in VS .NET, I will create the usual split patches. I hope I didn't miss anything.

Look at src/gui/Makefile.am to see how the pre-build thing should work:

Two programs are used, hexdump and asciidump. Both take exactly 2 parameters, input file and output file. hexdump is used on dosbox_openglhq_table.dat to produce dosbox_openglhq_table.h, and asciidump is used on dosbox_openglhq_pass?.fp to produce dosbox_openglhq_pass?.h

priestly, I have found someone with recent nvidia hardware, so I'll check it. It might take a week, though.

Hi Moe,
I've added GCC_UNLIKELY macro to dosbox.

(see config.h after a cvs update/autogen.sh/configure)

I use it in pic.cpp.
Can you confirm that I use it correctly ? And you can use it in your patches as well.

Qbix