VOGONS


First post, by truth_deleted

User metadata

Attached are two ZIP files, one has the binaries of DOSBox-G and the other the source code. This is a heavily modified Daum build and has the core components of Daum's along with Kekko's enhanced Voodoo1 device. This device requires a lot of supporting code. However, removed are almost all third-party dependencies along with their respective features. The only necessary DLL files in DOSBox-G are SDL.dll and SDL_net.dll, the first for constructing the DOSBox window and the latter for communicating over a network. Because this was compiled by Visual C++ 2010 Express, there are runtime dependencies which are typically installed on recent Windows based systems. The binaries and source code are now fairly compact in file size, too; and with familiarity of Visual C++ 2010, the compiling effort should not be overly difficult. I assume this will also compile in the 2012 edition.

Further, capturing images and video can be done via external utilities, so the relevant code was commented out from the source. This can be re-enabled, if necessary. In the case of this function and some others, not all the code was wrapped in a definition for the preprocessor, so instead I universally commented out this code. Similarly, some of the (presumably) lesser used audio emulators were removed. I removed as much as reasonable without having to rewrite sections of code.

(Edit: added CPU cycles to the title bar and updated attachments).

There may be bugs in the code, so please reply if any supported features in this compilation are not working, yet functioning properly in Daum's build. I was also careful not to interfere with core functions of the emulator.

I tried to modify the 3d hardware acceleration, but these attempts caused graphical anomalies. It is amazing work by Kekko, and it is not limited just to the inner-workings of the device, but also to the opengl rendering routines. I also appreciate ykhwong's extensive work on DOSBox. The handling of page faults appears very different from the one in DOSBox. This must be one of the major reasons why Daum's build is stable while running Windows 98SE.

I thought this compilation would be helpful to someone and, at the least, it will allow you to compile it yourself and optimize the build for your system. The -G stands for gaming.

[ Technical notes: In other posts I've described alternate DOSBox configuration files. For new users, it's simple to set 3d hardware acceleration as: fullscreen=true, fullresolution=original, voodoo=opengl, glide=emu. For 2d games and for those cases where the image is not filling the screen, then output=openglhq is an easy-to-configure setup; if this mode is ever too slow, there are combinations of other output modes with scalers which can achieve a very good result, such as hardware2x or 3x.

Before compiling DOSBox-G, first patch and compile SDL. The attachment, OpenGLHQ_patch.zip, contains this patch to add files and code to SDL 1.2.15. To do this, a patch tool is run while the patch file is located in the SDL directory. A Windows version of the tool is available here: http://gnuwin32.sourceforge.net/packages/patch.htm

The patch was downloaded from ykhwong's web site and converted to a Windows format so the patch tool can process it.

I had to use Visual C++ 2008 to compile the patched-SDL for Windows. It would be possible to use the ready-made SDL libraries instead, but the OpenGLHQ functions would have to be ignored while compiling the attached source code. ]

[ Compiling on Linux: DOSBox-G source code was updated on 6/21/13 so that it may compile on Linux. I tested this on Linux (circa 2006) via remote shell in the case where OpenGL and SDL_net were not installed, so I had to remove many dependencies so that the source would compile. I did eventually make a binary for Linux; even so, I could only test standard output from the binary because of the limitations of a login shell. If it was compiled on a system with the headers and libraries for SDL, SDL_net, OpenGL, ALSA, and an OpenGL driver installed for a modern video card, then the code should require few well-placed edits, I suppose mostly to Makefiles, to make a dosbox binary. This would only be an exercise for those who routinely work with editing Makefiles. ]

Reply 1 of 9, by leileilol

User metadata
Rank l33t++
Rank
l33t++

If it's a modified daum, then where's the menu? 🙁

apsosig.png
long live PCem

Reply 2 of 9, by truth_deleted

User metadata
leileilol wrote:

If it's a modified daum, then where's the menu? 🙁

The goal is to make the source code as portable as possible, but without removing the major advances made in Daum's build with respect to gaming. Removing many dependencies will help this effort, for example.

We can think of the main DOSBox code base as the trunk of a tree of which Daum's build is a major branch. However, this branch contains many code changes and it would be very difficult to revert back to the trunk; perhaps so extensive that it is misleading to call Daum's just a build of DOSBox. By reverting to a part of this branch which is closer to the trunk, then it should be simpler to edit and compile code by others. I did this for EF2000, for instance.

I almost completed compiling the above source in Linux, but I was still missing a compatible GL header file (freeglut3 doesn't appear compatible in this case, at least without editing important parts of source code). I also didn't install a required video driver which the compiling effort may be dependent on. The only other difficulty was related to the MT32 emulation which did not compile cleanly. I may try to remove this emulation to increase portability, and MT32 has quite an extensive code base.

I used the Synaptic Manager in Ubuntu 12 to install many of the required headers and libraries - those mentioned in the parent post. However, for SDL I patched and installed it via a Makefile. Overall, the dosbox-G source code should compile cleanly without much difficulty.

These particular problems did not occur in the Windows procedure.

Reply 3 of 9, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

Not to underestimate or appreciate your work, but I believe you should rethink your strategy. ykhwong's build is just trunk + (quite extensive) collection of patches done by various authors. By taking his build as a base and moving back towards the trunk + adding changes, you are actually moving away since it would be very difficult to ascertain what these changes are. Ideally you would start with the trunk and add each patch you like/want. From the quick glance of your sources, you have mostly removed functionality (including some that is supported by the official release), so that might actually not be such a big task.

Ideally, your build would be trunk + patches + your modifications which would also enable patch authors to check your changes and perhaps merge some of those. It would also give the users more insight into what advantages your build has and maybe avoid the questions like 'if it's a modified daum, then where's the menu?' 😁

http://www.si-gamer.net/gulikoza

Reply 4 of 9, by truth_deleted

User metadata
gulikoza wrote:

Not to underestimate or appreciate your work, but I believe you should rethink your strategy. ykhwong's build is just trunk + (quite extensive) collection of patches done by various authors. By taking his build as a base and moving back towards the trunk + adding changes, you are actually moving away since it would be very difficult to ascertain what these changes are. Ideally you would start with the trunk and add each patch you like/want. From the quick glance of your sources, you have mostly removed functionality (including some that is supported by the official release), so that might actually not be such a big task.

Ideally, your build would be trunk + patches + your modifications which would also enable patch authors to check your changes and perhaps merge some of those. It would also give the users more insight into what advantages your build has and maybe avoid the questions like 'if it's a modified daum, then where's the menu?' 😁

I greatly value your experience and insight. I had the same thoughts until I tried to modify the DOSBox SVN code and add the important features, such as Kekko's Voodoo1 device. I couldn't find the latest code for this device and the only location was Daum's build. I did note that Kekko released a patch here at Vogons, however, but I imagine there were further updates since then. Even aside from this work, there is also the page fault handling in Daum's which must be crucial to Windows 9x support inside the emulator. As I removed code from Daum's, I perceived increased stability running Windows inside dosbox, so I continued along this path. An additional benefit is enhanced ability to adapt code to other platforms, at least from my impression.

Reply 5 of 9, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
An additional benefit is enhanced ability to adapt code to other platforms, at least from my impression.

That I don't understand at all. How is Ykhwongs build more adaptable to other platforms?

And Guli is right. The way you are doing it is getting further and further away from Dosbox SVN and therefore never going to be backported again. And Ykhwong as so many patches integrated that it would probably more stable to use plain svn and go from there.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 6 of 9, by truth_deleted

User metadata
Dominus wrote:
That I don't understand at all. How is Ykhwongs build more adaptable to other platforms? […]
Show full quote
An additional benefit is enhanced ability to adapt code to other platforms, at least from my impression.

That I don't understand at all. How is Ykhwongs build more adaptable to other platforms?

And Guli is right. The way you are doing it is getting further and further away from Dosbox SVN and therefore never going to be backported again. And Ykhwong as so many patches integrated that it would probably more stable to use plain svn and go from there.

My goal has been to provide others with solutions to run their games. I hope this is welcome.

Reply 7 of 9, by truth_deleted

User metadata

[Edit: I plan to patch against the code from the DOSBox trunk in the future. I now fully appreciate this procedure because it allows for easy exchange of code among programmers. Furthermore, DOSBox is under active development and we will all be beneficiaries of the final product.

However, I will leave the instructions below so you may compile a Linux version from DOSBox SVN or possibly Daum's. Also, if you post about any general display problems in games, this may be one area I can help patch code (or at least try).]

[Edit: This pertains to Daum's build only. The optimal settings for 2d are the OpenGLHQ output mode, and for 3d Voodoo1-compatible titles one could try: fullscreen true, fullresolution original, output openglnb, voodoo opengl, glide emu. If video hardware acceleration is not present, then one could fallback on a default output mode (and possibly avoid a screen scaler).]

BUILD INSTRUCTIONS FOR UBUNTU LINUX
Ubuntu ver. 12.04 Live CD (or an installed version but the instructions below would vary somewhat, such as the location of the home directory)
Also, verify a driver is installed for a 3d accelerated video card, if available; for example, in the case of an AMD/ATI card, follow these instructions: https://help.ubuntu.com/community/BinaryDriverHowto/ATI

PREPARE SYSTEM FOR COMPILING DOSBOX
Add dosbox source to a newly created directory: /home/ubuntu/dosbox
Install Synaptic Package Manager via the Ubuntu Software Center
Install the following developmental tools, headers, and libraries (SDL_net, ALSA) via the Synaptic Package Manager:
libsdl-net1.2-dev; autogen; autoconf2.13; g++
(OpenGL headers and libraries were already included with OS: libglu1-mesa-dev; libgl1-mesa-dev)

[Edit: This is only relevant to Daum's build.
Edit /usr/include/GL/gl.h (vi is a text editor):
sudo vi /usr/include/GL/gl.h
comment out a block of code as shown below:
/*
GLAPI void GLAPIENTRY glActiveTextureARB(GLenum texture);
...
GLAPI void GLAPIENTRY glMultiTexCoord4svARB(GLenum target, const GLshort *v);
*/

(After compiling this dosbox, remove the above change to the gl.h file so that future compiling of OpenGL software will function correctly)]

INSTALL SDL
Download SDL source code named SDL-1.2.15.tar.gz:
www.libsdl.org/download-1.2.php
Uncompress SDL package (using tar tool with parameters xzf) in any directory

In the SDL-1.2.15/ directory, ensure that configure can be run by entering this command line:
chmod +x configure
Then, make and install SDL:
./configure
make
sudo make install

Add the SDL library directory to LD_LIBRARY_PATH via a text editor:
vi /home/ubuntu/.profile
Add this line to the end of .profile:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib

Add SDL_net.h to a SDL directory of header files by this command line:
sudo cp /usr/include/SDL/SDL_net.h /usr/local/include/SDL/

COMPILE DOSBOX
Enter dosbox/ directory with dosbox source code
Ensure that autogen.sh can be run by entering this line:
chmod +x autogen.sh
Procedure to compile DOSBox:
./autogen.sh
./configure
make

PREPARE CONFIGURATION FILE
The first run of DOSBox will create a new dosbox.conf in the user directory:
/home/ubuntu/.dosbox/dosbox-CVS.conf (I believe this is correct)
Rename this file to dosbox.conf and move it to the directory with the dosbox binary

Change the following lines of dosbox.conf to enable midi device:
mididevice=alsa
midiconfig=128:0

Add lines to mount a directory or an image; for example:
# mount a directory for DOSBox
mount c /home/ubuntu/dosbox/HDD
c:

[Edit: These instructions were modified, so please post if there is any difficulty in making a binary.]

Reply 8 of 9, by Sammy

User metadata
Rank Oldbie
Rank
Oldbie

Is a new Version planned ?

Dosbox-G ist the most compatible Version if you use openGL with 3dfx emulation.
Nearly no Graphic-bugs. And very fast.

Hope the are new releases in the future.

Very good Job.

Reply 9 of 9, by truth_deleted

User metadata

Thanks. Please visit the web page in my signature for single feature custom builds, and these may meet some of your expectations, but I've left the feature rich builds to Ykhwong and Codeholio. Mr. Codeholio has extended dosbox so far with hundreds of important code additions, that the attached build is obsolete apart from running dos games with or without 3dfx emulation. I also posted a couple of recent patches which enhance this emulation, but are not part of the above build either. Dosbox-x should be the future for running the various add-ons to dosbox, and Codeholio's current work on the cpu and pci emulation will increase compatibility with many games. I also have a post on installing 95b and there are similar instructions at the web site below. This may help you meet your goals. Over time the emulation will improve, in the meanwhile try to install what you can make work.