VOGONS

Common searches


VIDEO - 3dfx voodoo emulation (SDL1)

Topic actions

Reply 100 of 113, by Genju

User metadata
Rank Newbie
Rank
Newbie

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.

Reply 101 of 113, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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

Reply 103 of 113, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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.

Reply 104 of 113, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

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.

Attachments

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 105 of 113, by rpint

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

Attachments

Reply 106 of 113, by kekko

User metadata
Rank Member
Rank
Member

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.

Attachments

Reply 107 of 113, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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

Reply 108 of 113, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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.

Reply 109 of 113, by almeath

User metadata
Rank Member
Rank
Member

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:

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

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

Second time around it comes up with this:

voodoo_opengl.cpp:1796:57: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
if (info->so_vertex_shader >= 0) glDetachObjectARB(info->so_shader_program, info->so_vertex_shader);
^~~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1797:59: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
if (info->so_fragment_shader >= 0) glDetachObjectARB(info->so_shader_program, info->so_fragment_shader);
^~~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1798:57: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
if (info->so_vertex_shader >= 0) glDeleteObjectARB(info->so_vertex_shader);
^~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1799:59: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
if (info->so_fragment_shader >= 0) glDeleteObjectARB(info->so_fragment_shader);
^~~~~~~~~~~~~~~~~~~~~~~~
voodoo_opengl.cpp:1800:24: error: cannot initialize a parameter of type 'GLhandleARB' (aka 'void *') with an lvalue of type 'UINT32'
(aka 'unsigned int')
glDeleteObjectARB(info->so_shader_program);

Reply 111 of 113, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 113 of 113, by almeath

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

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

As follows:

/* use this shader */
glUseProgramObjectARB(m_hProgramObject);
extra->info->so_shader_program=(uintptr_t)m_hProgramObject;
extra->info->so_vertex_shader=(uintptr_t)m_hVertexShader;
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.