VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 260 of 1008, by telanus

User metadata
Rank Newbie
Rank
Newbie

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:

In file included from voodoo_opengl.h:33:0,
from voodoo_opengl.cpp:28:
voodoo_vogl.h:28:34: error: ‘void (* glActiveTextureARB)(GLenum)’ redeclared as different kind of symbol
extern PFNGLACTIVETEXTUREARBPROC glActiveTextureARB;
^
In file included from /usr/include/SDL/SDL_opengl.h:46:0,
from voodoo_vogl.h:24,
from voodoo_opengl.h:33,
from voodoo_opengl.cpp:28:
/usr/include/GL/gl.h:1971:23: note: previous declaration ‘void glActiveTextureARB(GLenum)’
GLAPI void GLAPIENTRY glActiveTextureARB(GLenum texture);
^
In file included from voodoo_opengl.h:33:0,
from voodoo_opengl.cpp:28:
voodoo_vogl.h:29:36: error: ‘void (* glMultiTexCoord4fARB)(GLenum, GLfloat, GLfloat, GLfloat, GLfloat)’ redeclared as different kind of symbol
extern PFNGLMULTITEXCOORD4FARBPROC glMultiTexCoord4fARB;
^
In file included from /usr/include/SDL/SDL_opengl.h:46:0,
from voodoo_vogl.h:24,
from voodoo_opengl.h:33,
from voodoo_opengl.cpp:28:
/usr/include/GL/gl.h:1999:23: note: previous declaration ‘void glMultiTexCoord4fARB(GLenum, GLfloat, GLfloat, GLfloat, GLfloat)’
GLAPI void GLAPIENTRY glMultiTexCoord4fARB(GLenum target, GLfloat s, GLfloat t, GLfloat r, GLfloat q);
^
In file included from voodoo_opengl.h:33:0,
from voodoo_opengl.cpp:28:
voodoo_vogl.h:30:37: error: ‘void (* glMultiTexCoord4fvARB)(GLenum, const GLfloat*)’ redeclared as different kind of symbol
extern PFNGLMULTITEXCOORD4FVARBPROC glMultiTexCoord4fvARB;
^
In file included from /usr/include/SDL/SDL_opengl.h:46:0,
from voodoo_vogl.h:24,
from voodoo_opengl.h:33,
from voodoo_opengl.cpp:28:
/usr/include/GL/gl.h:2000:23: note: previous declaration ‘void glMultiTexCoord4fvARB(GLenum, const GLfloat*)’
GLAPI void GLAPIENTRY glMultiTexCoord4fvARB(GLenum target, const GLfloat *v);
^
In file included from voodoo_opengl.h:33:0,
from voodoo_emu.cpp:81:
voodoo_vogl.h:28:34: error: ‘void (* glActiveTextureARB)(GLenum)’ redeclared as different kind of symbol
extern PFNGLACTIVETEXTUREARBPROC glActiveTextureARB;
^
In file included from /usr/include/SDL/SDL_opengl.h:46:0,
from voodoo_vogl.h:24,
from voodoo_opengl.h:33,
from voodoo_emu.cpp:81:
/usr/include/GL/gl.h:1971:23: note: previous declaration ‘void glActiveTextureARB(GLenum)’
GLAPI void GLAPIENTRY glActiveTextureARB(GLenum texture);
^
In file included from voodoo_opengl.h:33:0,
from voodoo_emu.cpp:81:
voodoo_vogl.h:29:36: error: ‘void (* glMultiTexCoord4fARB)(GLenum, GLfloat, GLfloat, GLfloat, GLfloat)’ redeclared as different kind of symbol
extern PFNGLMULTITEXCOORD4FARBPROC glMultiTexCoord4fARB;
^
In file included from /usr/include/SDL/SDL_opengl.h:46:0,
from voodoo_vogl.h:24,
from voodoo_opengl.h:33,
from voodoo_emu.cpp:81:
/usr/include/GL/gl.h:1999:23: note: previous declaration ‘void glMultiTexCoord4fARB(GLenum, GLfloat, GLfloat, GLfloat, GLfloat)’
GLAPI void GLAPIENTRY glMultiTexCoord4fARB(GLenum target, GLfloat s, GLfloat t,
^
Show last 39 lines
In file included from voodoo_opengl.h:33:0,
from voodoo_emu.cpp:81:
voodoo_vogl.h:30:37: error: ‘void (* glMultiTexCoord4fvARB)(GLenum, const GLfloat*)’ redeclared as different kind of symbol
extern PFNGLMULTITEXCOORD4FVARBPROC glMultiTexCoord4fvARB;
^
In file included from /usr/include/SDL/SDL_opengl.h:46:0,
from voodoo_vogl.h:24,
from voodoo_opengl.h:33,
from voodoo_emu.cpp:81:
/usr/include/GL/gl.h:2000:23: note: previous declaration ‘void glMultiTexCoord4fvARB(GLenum, const GLfloat*)’
GLAPI void GLAPIENTRY glMultiTexCoord4fvARB(GLenum target, const GLfloat *v);
^
voodoo_emu.cpp: In function ‘void init_fbi(voodoo_state*, fbi_state*, int)’:
voodoo_emu.cpp:566:14: error: ‘FALSE’ was not declared in this scope
f->vblank = FALSE;
^
voodoo_emu.cpp: In function ‘UINT32 register_r(UINT32)’:
voodoo_emu.cpp:2784:25: error: ‘TRUE’ was not declared in this scope
update_statistics(v, TRUE);
^
Makefile:438: recipe for target 'voodoo_opengl.o' failed
make[4]: *** [voodoo_opengl.o] Error 1
make[4]: *** Waiting for unfinished jobs....
Makefile:438: recipe for target 'voodoo_emu.o' failed
make[4]: *** [voodoo_emu.o] Error 1
mv -f .deps/dbopl.Tpo .deps/dbopl.Po
make[4]: Leaving directory '/home/user001/src/dosboxece/src/hardware'
Makefile:458: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/home/user001/src/dosboxece/src/hardware'
Makefile:436: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/home/user001/src/dosboxece/src'
Makefile:377: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/user001/src/dosboxece'
Makefile:318: recipe for target 'all' failed
make: *** [all] Error 2

My Retro PC:
Spec: PII400 with 400MB, Riva128zx and C-Media soundcard
OS: Win 98SE
Main:
Spec: Dual-Core 2.60, GeForce GT 240 3Gb Ram & Creative Audigy
OS: Win XP Pro (SP3)

Reply 261 of 1008, by Yesterplay80

User metadata
Rank Member
Rank
Member

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)

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 262 of 1008, by telanus

User metadata
Rank Newbie
Rank
Newbie
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

My Retro PC:
Spec: PII400 with 400MB, Riva128zx and C-Media soundcard
OS: Win 98SE
Main:
Spec: Dual-Core 2.60, GeForce GT 240 3Gb Ram & Creative Audigy
OS: Win XP Pro (SP3)

Reply 263 of 1008, by Yesterplay80

User metadata
Rank Member
Rank
Member

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.

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 264 of 1008, by Ant_222

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

Reply 265 of 1008, by telanus

User metadata
Rank Newbie
Rank
Newbie
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 😢 😕

My Retro PC:
Spec: PII400 with 400MB, Riva128zx and C-Media soundcard
OS: Win 98SE
Main:
Spec: Dual-Core 2.60, GeForce GT 240 3Gb Ram & Creative Audigy
OS: Win XP Pro (SP3)

Reply 266 of 1008, by Marty2dos

User metadata
Rank Newbie
Rank
Newbie

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

Reply 267 of 1008, by Yesterplay80

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 268 of 1008, by Ant_222

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

Last edited by Ant_222 on 2017-11-01, 08:47. Edited 1 time in total.

Reply 269 of 1008, by lukeman3000

User metadata
Rank Member
Rank
Member

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

Reply 270 of 1008, by Yesterplay80

User metadata
Rank Member
Rank
Member
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:

Filename
libfluidsynth.zip
File size
141.64 KiB
Downloads
54 downloads
File license
Fair use/fair dealing exception

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 271 of 1008, by Yesterplay80

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 272 of 1008, by micmic

User metadata
Rank Newbie
Rank
Newbie

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 ?

Reply 273 of 1008, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Probably don't mix it. Install anew with ECE

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 274 of 1008, by micmic

User metadata
Rank Newbie
Rank
Newbie
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)

Reply 275 of 1008, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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)

Reply 276 of 1008, by micmic

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 277 of 1008, by Myloch

User metadata
Rank Member
Rank
Member

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?

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Reply 278 of 1008, by Yesterplay80

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 279 of 1008, by micmic

User metadata
Rank Newbie
Rank
Newbie

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