DOSBox ECE (for Windows)

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Re: DOSBox ECE (for Windows)

Postby telanus » 2017-10-25 @ 05:49

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:

Code: Select all
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,
                       ^
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)
User avatar
telanus
Newbie
 
Posts: 77
Joined: 2007-10-03 @ 14:20

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2017-10-25 @ 07:07

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: viewtopic.php?f=41&t=41853&start=40#p597692
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 255
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby telanus » 2017-10-25 @ 14:15

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: viewtopic.php?f=41&t=41853&start=40#p597692

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)
User avatar
telanus
Newbie
 
Posts: 77
Joined: 2007-10-03 @ 14:20

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2017-10-25 @ 18:02

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)
User avatar
Yesterplay80
Member
 
Posts: 255
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby Ant_222 » 2017-10-26 @ 10:53

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?
Ant_222
Member
 
Posts: 335
Joined: 2010-7-24 @ 21:29

Re: DOSBox ECE (for Windows)

Postby telanus » 2017-10-27 @ 03:33

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: viewtopic.php?f=41&t=41853&start=40#p597692

It seems that the patch is no longer capable of being merged with the current branch :depressed: :confused:
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)
User avatar
telanus
Newbie
 
Posts: 77
Joined: 2007-10-03 @ 14:20

Re: DOSBox ECE (for Windows)

Postby Marty2dos » 2017-10-29 @ 03:01

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
Newbie
 
Posts: 16
Joined: 2013-6-04 @ 01:43

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2017-10-29 @ 19:19

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)
User avatar
Yesterplay80
Member
 
Posts: 255
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby Ant_222 » 2017-10-29 @ 19:51

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.
Ant_222
Member
 
Posts: 335
Joined: 2010-7-24 @ 21:29

Re: DOSBox ECE (for Windows)

Postby lukeman3000 » 2017-11-01 @ 05:08

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
Member
 
Posts: 189
Joined: 2009-3-17 @ 00:59

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2017-11-01 @ 09:41

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:

libfluidsynth.zip
(141.64 KiB) Downloaded 24 times
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 255
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2017-11-02 @ 07:18

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)
User avatar
Yesterplay80
Member
 
Posts: 255
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby micmic » 2017-11-13 @ 18:35

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 ?
micmic
Newbie
 
Posts: 18
Joined: 2007-3-07 @ 10:33

Re: DOSBox ECE (for Windows)

Postby Dominus » 2017-11-13 @ 18:53

Probably don't mix it. Install anew with ECE
User avatar
Dominus
DOSBox Moderator
 
Posts: 7285
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: DOSBox ECE (for Windows)

Postby micmic » 2017-11-14 @ 16:25

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: viewtopic.php?t=33667)

The same with any new hdd image I create (with other dosbox versions since ECE doesn't support the imgmake command)
micmic
Newbie
 
Posts: 18
Joined: 2007-3-07 @ 10:33

Re: DOSBox ECE (for Windows)

Postby ripsaw8080 » 2017-11-14 @ 17:50

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: viewtopic.php?f=41&t=34642
User avatar
ripsaw8080
DOSBox Author
 
Posts: 4100
Joined: 2006-4-25 @ 23:24

Re: DOSBox ECE (for Windows)

Postby micmic » 2017-11-14 @ 17:53

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.
micmic
Newbie
 
Posts: 18
Joined: 2007-3-07 @ 10:33

Re: DOSBox ECE (for Windows)

Postby Myloch » 2017-11-14 @ 21:56

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"
User avatar
Myloch
Member
 
Posts: 386
Joined: 2007-4-18 @ 22:13

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2017-11-15 @ 11:44

Myloch wrote: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)
User avatar
Yesterplay80
Member
 
Posts: 255
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby micmic » 2017-11-19 @ 11:19

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...
micmic
Newbie
 
Posts: 18
Joined: 2007-3-07 @ 10:33

PreviousNext

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 3 guests