wonder if someone could point out what I'm doing wrong. I'm compiling on Ubuntu 16.04. Most of the errors so far I was able to fix, but this I'm not sure how:

1In file included from voodoo_opengl.h:33:0,
2                 from voodoo_opengl.cpp:28:
3voodoo_vogl.h:28:34: error: ‘void (* glActiveTextureARB)(GLenum)’ redeclared as different kind of symbol
4 extern PFNGLACTIVETEXTUREARBPROC glActiveTextureARB;
5                                  ^
6In file included from /usr/include/SDL/SDL_opengl.h:46:0,
7                 from voodoo_vogl.h:24,
8                 from voodoo_opengl.h:33,
9                 from voodoo_opengl.cpp:28:
10/usr/include/GL/gl.h:1971:23: note: previous declaration ‘void glActiveTextureARB(GLenum)’
11 GLAPI void GLAPIENTRY glActiveTextureARB(GLenum texture);
12                       ^
13In file included from voodoo_opengl.h:33:0,
14                 from voodoo_opengl.cpp:28:
15voodoo_vogl.h:29:36: error: ‘void (* glMultiTexCoord4fARB)(GLenum, GLfloat, GLfloat, GLfloat, GLfloat)’ redeclared as different kind of symbol
16 extern PFNGLMULTITEXCOORD4FARBPROC glMultiTexCoord4fARB;
17                                    ^
18In file included from /usr/include/SDL/SDL_opengl.h:46:0,
19                 from voodoo_vogl.h:24,
20                 from voodoo_opengl.h:33,
21                 from voodoo_opengl.cpp:28:
22/usr/include/GL/gl.h:1999:23: note: previous declaration ‘void glMultiTexCoord4fARB(GLenum, GLfloat, GLfloat, GLfloat, GLfloat)’
23 GLAPI void GLAPIENTRY glMultiTexCoord4fARB(GLenum target, GLfloat s, GLfloat t, GLfloat r, GLfloat q);
24                       ^
25In file included from voodoo_opengl.h:33:0,
26                 from voodoo_opengl.cpp:28:
27voodoo_vogl.h:30:37: error: ‘void (* glMultiTexCoord4fvARB)(GLenum, const GLfloat*)’ redeclared as different kind of symbol
28 extern PFNGLMULTITEXCOORD4FVARBPROC glMultiTexCoord4fvARB;
29                                     ^
30In file included from /usr/include/SDL/SDL_opengl.h:46:0,
31                 from voodoo_vogl.h:24,
32                 from voodoo_opengl.h:33,
33                 from voodoo_opengl.cpp:28:
34/usr/include/GL/gl.h:2000:23: note: previous declaration ‘void glMultiTexCoord4fvARB(GLenum, const GLfloat*)’
35 GLAPI void GLAPIENTRY glMultiTexCoord4fvARB(GLenum target, const GLfloat *v);
36                       ^
37In file included from voodoo_opengl.h:33:0,
38                 from voodoo_emu.cpp:81:
39voodoo_vogl.h:28:34: error: ‘void (* glActiveTextureARB)(GLenum)’ redeclared as different kind of symbol
40 extern PFNGLACTIVETEXTUREARBPROC glActiveTextureARB;
41                                  ^
42In file included from /usr/include/SDL/SDL_opengl.h:46:0,
43                 from voodoo_vogl.h:24,
44                 from voodoo_opengl.h:33,
45                 from voodoo_emu.cpp:81:
46/usr/include/GL/gl.h:1971:23: note: previous declaration ‘void glActiveTextureARB(GLenum)’
47 GLAPI void GLAPIENTRY glActiveTextureARB(GLenum texture);
48                       ^
49In file included from voodoo_opengl.h:33:0,
50                 from voodoo_emu.cpp:81:
51voodoo_vogl.h:29:36: error: ‘void (* glMultiTexCoord4fARB)(GLenum, GLfloat, GLfloat, GLfloat, GLfloat)’ redeclared as different kind of symbol
52 extern PFNGLMULTITEXCOORD4FARBPROC glMultiTexCoord4fARB;
53                                    ^
54In file included from /usr/include/SDL/SDL_opengl.h:46:0,
55                 from voodoo_vogl.h:24,
56                 from voodoo_opengl.h:33,
57                 from voodoo_emu.cpp:81:
58/usr/include/GL/gl.h:1999:23: note: previous declaration ‘void glMultiTexCoord4fARB(GLenum, GLfloat, GLfloat, GLfloat, GLfloat)’
59 GLAPI void GLAPIENTRY glMultiTexCoord4fARB(GLenum target, GLfloat s, GLfloat t,
60                       ^

61In file included from voodoo_opengl.h:33:0,
62                 from voodoo_emu.cpp:81:
63voodoo_vogl.h:30:37: error: ‘void (* glMultiTexCoord4fvARB)(GLenum, const GLfloat*)’ redeclared as different kind of symbol
64 extern PFNGLMULTITEXCOORD4FVARBPROC glMultiTexCoord4fvARB;
65                                     ^
66In file included from /usr/include/SDL/SDL_opengl.h:46:0,
67                 from voodoo_vogl.h:24,
68                 from voodoo_opengl.h:33,
69                 from voodoo_emu.cpp:81:
70/usr/include/GL/gl.h:2000:23: note: previous declaration ‘void glMultiTexCoord4fvARB(GLenum, const GLfloat*)’
71 GLAPI void GLAPIENTRY glMultiTexCoord4fvARB(GLenum target, const GLfloat *v);
72                       ^
73voodoo_emu.cpp: In function ‘void init_fbi(voodoo_state*, fbi_state*, int)’:
74voodoo_emu.cpp:566:14: error: ‘FALSE’ was not declared in this scope
75  f->vblank = FALSE;
76              ^
77voodoo_emu.cpp: In function ‘UINT32 register_r(UINT32)’:
78voodoo_emu.cpp:2784:25: error: ‘TRUE’ was not declared in this scope
79    update_statistics(v, TRUE);
80                         ^
81Makefile:438: recipe for target 'voodoo_opengl.o' failed
82make[4]: *** [voodoo_opengl.o] Error 1
83make[4]: *** Waiting for unfinished jobs....
84Makefile:438: recipe for target 'voodoo_emu.o' failed
85make[4]: *** [voodoo_emu.o] Error 1
86mv -f .deps/dbopl.Tpo .deps/dbopl.Po
87make[4]: Leaving directory '/home/user001/src/dosboxece/src/hardware'
88Makefile:458: recipe for target 'all-recursive' failed
89make[3]: *** [all-recursive] Error 1
90make[3]: Leaving directory '/home/user001/src/dosboxece/src/hardware'
91Makefile:436: recipe for target 'all-recursive' failed
92make[2]: *** [all-recursive] Error 1
93make[2]: Leaving directory '/home/user001/src/dosboxece/src'
94Makefile:377: recipe for target 'all-recursive' failed
95make[1]: *** [all-recursive] Error 1
96make[1]: Leaving directory '/home/user001/src/dosboxece'
97Makefile:318: recipe for target 'all' failed
98make: *** [all] Error 2

The voodoo patch included in this build doesn't work for Linux, because of some differences between OpenGL for Windows and the one for Linux that are beyond my comprehension. There is another patch that works for linux, though: VIDEO - 3dfx voodoo emulation (SDL1)

Yesterplay80 wrote:

The voodoo patch included in this build doesn't work for Linux, because of some differences between OpenGL for Windows and the one for Linux that are beyond my comprehension. There is another patch that works for linux, though: VIDEO - 3dfx voodoo emulation (SDL1)

is there a way to compile without the voodoo patch

Not without rebuilding the entire code with all the other patches, which partially would have to be changed as well because they all are build upon another.

Yesterplay80 wrote:

The voodoo patch included in this build doesn't work for Linux, because of some differences between OpenGL for Windows and the one for Linux that are beyond my comprehension.

Maybe it is worth while seek help of the maintainer of that patch?

Yesterplay80 wrote:

The voodoo patch included in this build doesn't work for Linux, because of some differences between OpenGL for Windows and the one for Linux that are beyond my comprehension. There is another patch that works for linux, though: VIDEO - 3dfx voodoo emulation (SDL1)

It seems that the patch is no longer capable of being merged with the current branch 😢 😕

Do you plan add regular the OpenGL shader part to your builds? I seen a old version "DOSBox r4006 ECE (with GLSL shader)"
and please, dont hardcode the path to the user/appdata/dosbox/. You can add a Shader main path in the Dosbox.conf. 😀

Marty2dos wrote:

Do you plan add regular the OpenGL shader part to your builds? I seen a old version "DOSBox r4006 ECE (with GLSL shader)"

No, I prefer going with the pixel perfect patch and both patches together doesn't work.

Yesterplay80 wrote:

No, I prefer going with the pixel perfect patch and both patches together doesn't work.

Classic DOS games are the last thing I should use a pixel shader for. On the other hand, with some help and patience I could re-implement my patch as a pixel shader. On the third hand, however, built-in hardware scaling in SDL 2.0 is the best way to go. Edit: It has support for integer scaling factors.

Hey Yesterplay, I downloaded the most recent version of ECE and I get the following error:

"The code execution cannot proceed because libfluidsynth.dll was not found. Reinstalling the program may fix this problem."

lukeman3000 wrote:

Hey Yesterplay, I downloaded the most recent version of ECE and I get the following error:

"The code execution cannot proceed because libfluidsynth.dll was not found. Reinstalling the program may fix this problem."

Sorry about that, the file actually was missing from the folder that gets zipped and uploaded, I fixed this. And here's the missing file:

Ant_222 wrote:

On the other hand, with some help and patience I could re-implement my patch as a pixel shader.

That could be an alternative, if performance wouldn't suffer this could kill two birds with one stone.

I have a Win98 image that official Dosbox 0.74 boots fine from, but the latest version of Dosbox ECE can't boot it. I use the following lines in both cases:

imgmount 2 windows98.img -size 512,63,255,522 -t hdd -fs none
boot -l C

Dosbox 0.74 mounts and boots perfectly. ECE mounts the image and gives the message "Drive number 2 mounted as windows98.img". But with the boot command it returns "Error loading operating system. Setup cannot continue."

What am I doing wrong ?

Probably don't mix it. Install anew with ECE

Dominus wrote:

Probably don't mix it. Install anew with ECE

Can't do that because ECE fails to assign a drive letter to the image.
"imgmount c windows98.img -size 512,63,255,522 -t hdd" returns: "Can't create drive from file". While with "imgmount 2" it mounts ok, when I give a letter I see this error (probably the same problem I see in this thread: "Can't create drive from file")

The same with any new hdd image I create (with other dosbox versions since ECE doesn't support the imgmake command)

AFAIK, 2 GB is the largest image size that actually works in official source -- a limit of the C runtime library file functions being used. So, not an issue with the ECE build in particular, and your claim of a 4 GB image working in 0.74 seems... questionable. There's a patch to allow images larger than 2 GB, which is likely in the Daum builds: Large HD images (DOSBOX)

4GB works fine with official Dosbox 0.74, I have installed Windows 98 normally and on top of that several programs which work fine. At times I have almost completely filled the whole 4GB too (with CD images etc). I can upload the image somewhere for someone to test it.

ETA: I'll check again the dosbox version I've been using.

I've never used dosbox ece: I have some questions

1. The situation with ECE's internal munt, is it on par with current munt sourceforge releases?
2. Can I still hook external wrapper nglide to this branch of dosbox, like I used to do with ykhwong's builds and dosbox-x ones?
3. Does it support ps1 audiocard like ykhwong or dosbox-x?

Myloch wrote:

I've never used dosbox ece: I have some questions […]
Show full quote

I've never used dosbox ece: I have some questions

1. The situation with ECE's internal munt, is it on par with current munt sourceforge releases?
2. Can I still hook external wrapper nglide to this branch of dosbox, like I used to do with ykhwong's builds and dosbox-x ones?
3. Does it support ps1 audiocard like ykhwong or dosbox-x?

1. It uses the libmt32emu form the current version 2.2.0, so yes.
2. No, kekkos patch is an completely internal wrapper that "translates" Glide calls into OpenGL calls, so no external wrapper is needed or supported
3. No.

Ok, ripsaw8080 was right. It was indeed a Daum build the one that was working with the 4GB image. It's just that I've used so many builds that I've lost count.

So I guess I'm out of luck if I want the Pixel Perfect patch with my 4GB image, unless of course I try to somehow merge the two builds myself...