Re: Darker polygons when running Tomb Raider with Glide
Posted on 2018-09-23, 06:09
See here: Re: Glide patch
Re: Large HD images (DOSBOX)
Posted on 2018-08-05, 04:47
Sorry, no idea, never studied the differences between fat32 and fat16.
Re: GLIDE.DLL LFB implementation issue + WIN64 DLL?
Posted on 2018-08-05, 03:54
Gulikoza's patch actually resizes the window for dgVoodoo1 based on Glide resolution. It is detecting dgvoodoo1 by the exported symbol "DispatchDosNT". Obviously, this had failed for dgVoodoo2. If you add back the symbol as dummy, then DOSBox will resize the window for you, too. It's new …
Re: DOSBox wont start without mouse
Posted on 2018-08-05, 03:30
This is SDL (the library handling graphics, input and audio) requirement, not DOSBox directly. Maybe you can try switching to WINDIB backend.
Re: Large HD images (DOSBOX)
Posted on 2018-08-05, 02:50
That 'if' is just a quick hack to allow unrecognized (fat32) or unformatted images to be mounted. DOSBox will obviously not read those drives, but they can be used inside booted OS (if supported). An unsupported "fattype = FAT32" is assigned to these drives (even if the image is unformatted), this …
Re: MSYS2/mingw-w64 for Win64 DOSBox
Posted on 2018-05-10, 07:23
Did you change the define in gen_load_param_* functions for mingw? wd wrote the dynrec core, but I did the debugging as @wd did not have the environment at the time. So I could probably debug this, but I'm afraid I don't have anything of mingw-w64 set up at the moment... edit: dynrec core is quite …
Re: MSYS2/mingw-w64 for Win64 DOSBox
Posted on 2018-05-05, 18:26
This is interesting, I do remember some ABI differences were coded in (check the define for _MSC_VER in gen_load_param_imm). But yeah, most likely you would need to change the defines for FC_OP1 and FC_OP2. R8 and R9 are already handled in gen_load_param_* functions, you just need to add define for …
Re: Patch for pixel-perfect scaling
Posted on 2017-08-15, 16:13
If anybody knows how to use pixel shaders with opengl in SDL 1.2, will they please help me with a pixel-perfect scaler for the opengl output mode? 3Dfx code uses pixel (fragment) shaders...even generates them dynamically based on (emulated) hw state. Check the code (search for …
Re: DOSBox-X branch
Posted on 2017-05-14, 06:21
Direct3D is set as default: #ifdef __WIN32__ Pstring = sdl_sec->Add_string("output",Property::Changeable::Always,"direct3d"); #else yet, the init function is set to trigger the error when d3d is initialized: #ifdef __WIN32__ static void d3d_init(void) { #if 1 E_Exit("D3D not supported"); #else I …
Re: DOSBox-X branch
Posted on 2017-05-06, 07:27
Perhaps you shouldn't select direct3d in the config then if it's not supported?
Re: Old DX SDKs
Posted on 2017-04-15, 12:02
This is from my archives: magnet:?xt=urn:btih:D12B1F0FD330624341ECDCB11C2E1DDDC36C57C4&dn=idx5sdk.exe f00938648587bd0f23739f00b89f1ba4 *idx5sdk.exe Timestamp of the file is 17.9.1997 23:10 😁
Re: Your old CD-ROMs are probably rotting
Posted on 2017-03-12, 11:32
My own experience is that most CD-Rs burned in the early 2000s have problems but DVD-Rs from that period are OK. It may have been my fault for burning too fast though, I just don't remember. DVD-Rs have data stored between 2 plastic discs. CD-R only has 1 plastic disc, the data is stored on top ( …
Re: Patch for OpenGL fullscreen bug
Posted on 2016-11-08, 10:13
Depends on the drivers really, but I imagine current drivers are much more optimized than they used to be, even without PBO. In any case, using PBO shouldn't cause any corruptions and shouldn't be slower even if it's not faster. I assume there's some buffer that isn't cleared and that's the reason …
Re: Patch for OpenGL fullscreen bug
Posted on 2016-11-08, 08:20
It's an optimization. Dosbox basically draws the image pixel-by-pixel to a texture. Without pixel_buffer_object, the texture is created in system memory and then uploaded to graphics card. This means that each frame was basically processed twice (not really, but for easier understanding...) - dosbox …
Re: Dosbox Win95 - disk size 2GB limit hack?
Posted on 2016-10-04, 06:54
That's certainly a problem in itself. But official goal of DOSBox is to emulate DOS games and DOS has little use for 2GB+ images...
Re: Dosbox Win95 - disk size 2GB limit hack?
Posted on 2016-10-04, 06:42
A patch for mounting hard drive image larger than 2GB - how self-explanatory 😁
Re: Dosbox Win95 - disk size 2GB limit hack?
Posted on 2016-10-04, 06:36
SVN dosbox does not support images larger than 2GB, but there are patches to make that work. But once image is mounted (you can use -fs none switch) and windows booted, windows is accessing it directly so it can do whatever it wants...
Re: Dosbox Win95 - disk size 2GB limit hack?
Posted on 2016-10-04, 05:59
This has nothing to do with dosbox! If Windows is booted inside dosbox, fat32 works just fine...
Re: Dosbox Win95 - disk size 2GB limit hack?
Posted on 2016-10-04, 05:55
Why does dosbox need support for fat32? And you don't need overlayfs, the writes are always going to the overlay image, not the base (the base can be read-only or immutable, if you want to make sure :)). Also, linux already has an overlay system that is more granular than just 'copy the whole file …
Re: Dosbox Win95 - disk size 2GB limit hack?
Posted on 2016-10-04, 05:33
Most of these issues can be solved with images. I've mentioned qcow2 support - you can have a read-only base image with writable overlay which only contains changed sectors. VHD has differencing disks as well. All these functions are already established and have supporting tools (merging disks and …
Page 1 of 74