I have read somewhere that it is possible to make dosbox correctly recognize large drive images that use more than 512 MB of disk space. This is my experience with disk images so far: DOSBox is incorrectly reporting the size of the disk, that may be due to either a DOSBox bug or a problem with MS- …

If i set the cpu core to anything but "normal" DOSBox crashes with a segmentation fault when trying to launch Tomb Raider - at normal setting it works but is unplayably slow. also the 16Bit color bug gives me a headache again. http://img683.imageshack.us/img683/3636/colorsq.png the bug and the crash …

looking good so far in Windows 95: I'll install DirectX real quick to give Croc a try. awesome work kekko & gulikoza 😉

sorry for asking unnecessary questions, I usually tend to double check things when I'm not 100% sure what I'm going. Anyway the source seems to have compiled correctly now - thats for the help. I got some of these messages in the console during the compile - are they of any importance? Making all in …

so just to make sure I get that right - you want me to change INLINE void VOODOO_ShowMsg(char const* format,...) to void VOODOO_ShowMsg(char const* format,...) ?

I'm using gcc 4.0.1 on an OSX 10.5.8 system. Where can I find this function for forced inlining?

UPDATE: I have searched voodoo_data.h for further numbers that could be too long and the problem seems to have vanished now - however it still won't compile this is what I get now. voodoo_func.h: In function ‘void recompute_video_memory(voodoo_state*)’: voodoo_func.h:44: sorry, unimplemented: …

ok I changed the values in voodoo_data.h and those errors are gone now but I don't know what to change in voodoo_func.h Copy code to clipboard 1 RASTERIZER(generic_0tmu, 0, v->reg[fbzColorPath].u, v->reg[fbzMode].u, v->reg[alphaMode].u,

I get this error message when attempting to compile the Voodoo DOSBox source on my Mac OS X machine: voodoo_main.cpp In file included from voodoo_main.cpp:18: voodoo_data.h:1905: error: integer constant is too large for ‘long’ type voodoo_data.h:2006: error: integer constant is too large for ‘long’ …

To my knowledge, gulikoza & Moe were working on an SDL-based OpenGLide/MacGLide hybrid with better compatibility. With the proper tweaks it should theoretically be possible to compile his custom MacGLide sourcecode for Mac OS X as well. http://www.vogons.org/viewtopic.php?t=16565 I have sent …

nope, switching between surface and opengl output doesn't make a difference - the bug exists in all modes.

I didn't create a patch file but getting rid of the problem was pretty straight forward anyway. GL_EXT_packed_pixels does not exist in the OSX opengl drivers, instead there is an extension called GL_APPLE_packed_pixels -> all I did was rename all occurences of this extension name in the sourcecode …

For proper custmization I have created a few hi-res OSX icon files of DOS Glide games for the Wrappers. Successfully tested were: Carmageddon GTA + GTA London Blood (has texture errors on nVidia Macs) Shadow Warrior (has texture errors on nVidia Macs) Screamer 2 Screamer Rally Tomb Raider Burnout …

This package includes a custom patched DOSBox build with Glide support as well as a native version of the OpenGLide 3Dfx API Wrapper for Intel Mac OS X 10.5 & 10.6. I was able to implement them both into a DOSBox game wrapper which allows everyone to port hardware accelerated DOS games to OSX with …

Dominus, did you check out this topic? Guide to the DOSBox debugger sorry but this is as helpful as I can be concerning that matter 😜

well there are ways of getting OSX86 builds to work through VMWare on Windows machines, but that's a bit experimental.... ...but on the other hand - so is dosbox 😁

I got the glide version working as well with similar results - the color bug affects only the main menu - as soon as the 3dfx part takes over it's all good again. Is there any hope for a fix of this particular Mac problem in future DOSBox versions?