Hm, thanks for the tip, but now I'm stuck with these errors:

../../../include\dosbox.h:25:1: error: unknown type name 'GCC_ATTRIBUTE' GCC_ATTRIBUTE(noreturn) void E_Exit(const char * message,...) GCC_ATTRIBUTE( __format__(__printf__, 1, 2));

/include\dosbox.h:32:9: error: unknown type name 'Bitu' typedef Bitu (LoopHandler)(void);

For what it's worth, I'm using msys2 x86_64 with the clang compiler.

weird, it's applying fine on my ppa and it was built 3 days ago.

Applying patch /home/buildd/build-RECIPEBRANCHBUILD-2530369/chroot-autobuild/home/buildd/work/tree/recipe/debian/patches/voodoo_gl.diff
patching file include/GL/gl.h
patching file include/logging.h
patching file include/Makefile.am
patching file include/pci_bus.h
patching file include/video.h
patching file include/voodoo.h
patching file src/cpu/paging.cpp
patching file src/debug/debug_gui.cpp
patching file src/dosbox.cpp
patching file src/gui/sdlmain.cpp
Hunk #1 succeeded at 2693 (offset 11 lines).
patching file src/hardware/Makefile.am
patching file src/hardware/memory.cpp
patching file src/hardware/pci_bus.cpp
patching file src/hardware/pci_devices.h
patching file src/hardware/voodoo.cpp
patching file src/hardware/voodoo_data.h
patching file src/hardware/voodoo_def.h
patching file src/hardware/voodoo_emu.cpp
patching file src/hardware/voodoo_emu.h
patching file src/hardware/voodoo_interface.cpp
patching file src/hardware/voodoo_interface.h
patching file src/hardware/voodoo_opengl.cpp
patching file src/hardware/voodoo_opengl.h
patching file src/hardware/voodoo_types.h
patching file src/hardware/voodoo_vogl.cpp
patching file src/hardware/voodoo_vogl.h

Seems to work now, looks like I didn't have the latest version of the patch! My bad, sorry for the confusion 😀

There is a mistake found by the dosbox-core fork for retroarch on this patch :
https://github.com/realnc/dosbox-core/commit/ … 49b3d646d031541

There is also this but i suspect it's irrelevant for non libretro environments:
https://github.com/realnc/dosbox-core/commit/ … e623e6be20a8636

edit: or maybe not now that i think about it, if it was in the original, it can't be about the libretro api; confirmed it's a original bug.

I just applied those two fixes to kekkos part of kjliews combined patch. I'll update ECE with it when a new SVN comes out.

Yesterplay80 wrote on 2020-05-15, 10:42:

I just applied those two fixes to kekkos part of kjliews combined patch. I'll update ECE with it when a new SVN comes out.

Thanks for keeping this up to date for the rest of us, it's very much appreciated.

I'm attaching a tiny patch that also looks for glide2x.ovl in the user config directory (e.g. ~/.dosbox). This was more convenient for me than moving files to the system. Perhaps it's useful to you, too.

Hi everyone,
I found some time to set up again my compiler environment.
This is an updated patch against current svn.
- fixes minor compiling issues
- fixes a major video memory leak in Quake2 and Descent2
Quake2 uses sort of dynamic textures for realtime lighting, changing existing textures thus invalidating textures cache and forcing to reload them.
Descent 2 writes to existing textures for animations and fonts.
The fix adds a glDeleteTextures in function voodoo_ogl_texture_clear, which is called when a texture is invalidated due to a write.
There is still a performance issue because of texture caching during explosions or gun firing.
If anyone has an idea of how efficiently handle textures in the above scenarios please let me know here.

@kekko, i just updated the patch to the latest version on the ppa, and it failed building. I think it's because of a path separator thing in a header include, and i'm going to edit the patch to see if it is, but i thought you should know:

https://launchpadlibrarian.net/486219180/buil … BUILDING.txt.gz

(search for 'compilation terminated')

I don't know if the forward slash also works in windows, but i have the idea that it's possible and it would be something where the compilers would prefer to allow.

Another:

https://launchpadlibrarian.net/486353544/buil … BUILDING.txt.gz

the 'expected' typedef or define seems to be (from grep):
src/debug/debug_disasm.cpp:typedef Bit32s INT32;

since this appears to only be defined in the debug path i'm not sure how it even compiles in other places, if it even does. I'm reverting to the old version until these linux miscompiles are fixed.

Has anyone been able to get the latest version of the patch (voodoo_20200616) working in Linux or MacOS?

I am using MacOS Mojave and I was able to apply the patch to SVN 4441 without any errors.

When I first tried to compile, it came up with this error:

1pci_bus.cpp:29:10: fatal error: '..\ints\int10.h' file not found
2#include "..\ints\int10.h"

I then changed the "\" to "/" and tried again.

Second time around it comes up with this:

1voodoo_opengl.cpp:1796:57: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
2      (aka 'unsigned int')
3                                        if (info->so_vertex_shader >= 0) glDetachObjectARB(info->so_shader_program, info->so_vertex_shader);
4                                                                                           ^~~~~~~~~~~~~~~~~~~~~~~
5voodoo_opengl.cpp:1797:59: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
6      (aka 'unsigned int')
7                                        if (info->so_fragment_shader >= 0) glDetachObjectARB(info->so_shader_program, info->so_fragment_shader);
8                                                                                             ^~~~~~~~~~~~~~~~~~~~~~~
9voodoo_opengl.cpp:1798:57: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
10      (aka 'unsigned int')
11                                        if (info->so_vertex_shader >= 0) glDeleteObjectARB(info->so_vertex_shader);
12                                                                                           ^~~~~~~~~~~~~~~~~~~~~~
13voodoo_opengl.cpp:1799:59: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
14      (aka 'unsigned int')
15                                        if (info->so_fragment_shader >= 0) glDeleteObjectARB(info->so_fragment_shader);
16                                                                                             ^~~~~~~~~~~~~~~~~~~~~~~~
17voodoo_opengl.cpp:1800:24: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
18      (aka 'unsigned int')
19                                        glDeleteObjectARB(info->so_shader_program);

Those look like general 64-bit compatibility errors rather than being MacOS specific.

I think you had issues with header files inclusion, particularly SDL_opengl.h. Someone had provided the solution for Linux compile here at VOGONS. You could probably do a search. Both my 64-bit version on Windows 10 and Linux compiled fine with the latest patch.

Thanks , I found your Linux instructions from a 2014 thread and I will try adapting that to Mac. It looks straight-forward..

Yesterplay80 wrote on 2017-07-14, 13:01:

The patch you're trying to use is for Windows and differs from the one for Linux and possibly OSX. Please try this one:
1_voodoo_gl.diff

There's a thread about compilig DOSBox with 3Dfx under Linux: Tutorial: dosbox with Glide under Linux

I have had success in applying the above Linux-specific version of the patch to the latest SVN 4441 in macOS.

It patches cleanly (with -p1), except for two lines in the /include/video.h file which I manually inserted.

I also had to edit /src/hardware/voodoo_opengl.cpp as follows:

The references to UINT32 need to be altered:

1/* use this shader */
2		glUseProgramObjectARB(m_hProgramObject);
3		extra->info->so_shader_program=(UINT32)m_hProgramObject;
4		extra->info->so_vertex_shader=(UINT32)m_hVertexShader;
5		extra->info->so_fragment_shader=(UINT32)m_hFragmentShader;

As follows:

1/* use this shader */
2		glUseProgramObjectARB(m_hProgramObject);
3		extra->info->so_shader_program=(uintptr_t)m_hProgramObject;
4		extra->info->so_vertex_shader=(uintptr_t)m_hVertexShader;
5		extra->info->so_fragment_shader=(uintptr_t)m_hFragmentShader;

All tested and working fine.

I still have to figure out why the very latest patch is failing in macOS.

The errors I get for "UINT32" from the new patch (as reported in my earlier post) reference multiple lines in voodoo_opengl.cpp that do not actually contain "UINT32". So, it is not obvious where to make the replacement/s with "unintptr_t".

So yes, it is probably header related.. if I am successful in resolving that one I will report back, but I am happy enough with the earlier patch working.

I had a look at dosbox-pure recently (it's a dosbox port to RetroArch/Libretro).
Apparently the author has performed a code refactoring of the voodoo emulator for dosbox.
Main features I found interesting are:
- code refactored and fully contained into a single file voodoo.cpp
- software-only renderer (opengl code almost totally removed), but in change a quite fast multi-threaded triangle renderer has been added (or probably re-added from original mame code)
- apparently the code might have been updated with recent mame code changes

Even if not as fast as with opengl renderer, it seems to be a simpler, more reliable and portable solution.

I just thought of sharing this 😀

The only odd omission in the 3dfx emulation judging from pure's implementation of mame's 3dfx (from the curiosity of trying the very interestingly usable Win9X support) is the lack of CLUT emulation so none of that fun gamma stuff works.

Is there any chance of this being converted to an SVN-compatible patch in the future, or are there too many Libretro-specific dependencies?

I did create a diff and check out the code changes, but could not make much sense of it.

Better put it in DOSBox Staging.

kekko wrote on 2022-08-23, 20:53:

Main features I found interesting are: - code refactored and fully contained into a single file voodoo.cpp - software-only rende […]
Show full quote

Main features I found interesting are:
- code refactored and fully contained into a single file voodoo.cpp
- software-only renderer (opengl code almost totally removed), but in change a quite fast multi-threaded triangle renderer has been added (or probably re-added from original mame code)
- apparently the code might have been updated with recent mame code changes

Even if not as fast as with opengl renderer, it seems to be a simpler, more reliable and portable solution.

Hey there, I created the dosbox-pure fork and thanks for checking out the refactoring I did. The code you linked is fully based on your patch (as mentioned in the github release notes), thanks again for the great work! But sadly nothing of the advancements made over the years in mame have made it in. The multi-threading I wrote myself but I did notice the leftover of some `thread_stats` variable so the stats handling is probably very similar. My fork also runs the emulation parts in its own thread and I rewrote the auto cycles management and stripped out a bunch of scaler code and render line caching to eke out some more performance overall.

I did leave some commented-out OpenGL code in because I'm still interested in supporting it again some day, especially because the libretro core is used on many low end devices (phones, PS Vita, Raspberry Pi and all kinds of handheld emulator consoles). But as a libretro core the 3D accelerator context handling is a bit different and it would need some general reworking. I'm still trying to get the dynrec core working on WiiU, but once that works, I certainly want to try some 3dfx games on its PowerPC CPU 😀

Someone did mention to me that the 3dfx implementation of PCem was both accurate and apparently very fast while still in software, but I have not looked at it. Maybe it makes more sense to steer towards that than whats in mame? No idea.

Psyraven wrote on 2022-09-02, 17:05:

Hey there, I created the dosbox-pure fork and thanks for checking out the refactoring I did. The code you linked is fully based on your patch (as mentioned in the github release notes), thanks again for the great work! But sadly nothing of the advancements made over the years in mame have made it in. The multi-threading I wrote myself but I did notice the leftover of some `thread_stats` variable so the stats handling is probably very similar. My fork also runs the emulation parts in its own thread and I rewrote the auto cycles management and stripped out a bunch of scaler code and render line caching to eke out some more performance overall.

I did leave some commented-out OpenGL code in because I'm still interested in supporting it again some day, especially because the libretro core is used on many low end devices (phones, PS Vita, Raspberry Pi and all kinds of handheld emulator consoles). But as a libretro core the 3D accelerator context handling is a bit different and it would need some general reworking. I'm still trying to get the dynrec core working on WiiU, but once that works, I certainly want to try some 3dfx games on its PowerPC CPU 😀

Someone did mention to me that the 3dfx implementation of PCem was both accurate and apparently very fast while still in software, but I have not looked at it. Maybe it makes more sense to steer towards that than whats in mame? No idea.

Nice work, congrats!
at the time I did the porting, I didn't care of a multithreaded software renderer, I was going to use opengl anyways afterall. Later I regretted it.
The opengl renderer provided higher performance and nice video quality, but later I realized my opengl code is quite messy and hard to make portable.
Your implementation seem stable and quite fast, and a pure software renderer is much easier to port; probably it would have had a better chance to make it to the official svn (12 years ago 😀 ).

If you add features or fix things, please let me know 😀 I don't actively work on dosbox anymore, but I like to have a look at any new features still being worked on.
Btw if you have this code in a version that patches against svn (i.e. for internal testing) I would be very interested to give it a look!

Thanks and keep it up!