if 10 Ghz machines are the standard maybe 😉

It's easy to support them. The trouble is they are very slow and the amount of screendata is doubled.

What DOS games even make use of those modes? 65k colors in DOS would almost seem disturbing.

It's actually a 16-Bit Slideshow (by NeoBook) with Sound, not a game - don't matter how long graphics take to load for me - there are no animation or anything, just presenting 16-Bit PCX graphics in 640x480. Should be possible with 2 GHz machines (the show works in 256 colors without problems, but looks terrible) - so why not implementing it? 😁 😁 🤑 😎

Good luck on implementing it basti007

😁 😁 if i just could. 😀

I'm just wondering if there are plans to do so or if it's unlikely that i will ever be able show that stuff again in full colors and sound. 😉

oneirotekt wrote:

What DOS games even make use of those modes? 65k colors in DOS would almost seem disturbing.

Battlespire, a DOS game from 1997 uses 16-bit resolutions. A card that can handle 15/16bit is required for that game, which is pretty much the only reason I want to see it in DOSBox 😜

And while we are at it, Voodoo emulation would be nice too. There are some DOS games that have Voodoo support, such as Redguard.

Two of my favorites games support 16-bit graphics in DOS! :

The Last Express (yes, it supports DOS!)
Star Trek : A Final Unity

It would be great to see them running in DOSBox! (although dogslow!)

WE NEED 16-bit color! (and an Itanium!!!)

Abe's Oddysee uses 16-bit colour (although it runs in dos only in vga) (svga in windows). The readme says that the game won't run if graphic card donsn't support 16-bit though it runs in dosbox... in black and white 😉

Talking about speed, have anyone tried DOSBox with a AMD64 CPU? In 64bit Linux compiling a 64bit DOSBox? That should give some nice speed 😎

I don't think that would help much, because 64 bit doesn't affect the processor's speed. 64 bit just means the processor's registers are 64 bit wide, i.e. you can store values from 0 to 2^64 -1 in one register.
operations using these registers should be as fast as on a 32 bit cpu, unless the data values exceed 2^32.
as there is not much of computation of values exceeding the range of 2^32, the speed of dosbox should only depend on the cpu's amount of instructions/time.
(of course there could be compilers using 64 bit to compute two 32bit-instructions at one time, thus gaining a little speed, i don't think there is such a compiler yet. plz correct me if i'm wrong)

Instructions yes, compilers, no. MMX is exactly what you just described. MMX provides for 8 64-bit registers and several additional instructions that can do operations on the parts of those 8 registers. For instance, you can multiply two 32 bit integers, four 16 bit integers, or eight 8 bit integers simulatenously. This isn't a feature of 64-bit CPU's, this is a feature of nearly every x86 processor since the pentium II and the K5.

I know this is late but:

Battlespire, although using 16bit graphics, can run under DOSBOX by using 1.5 patch. A little slow, but playable on my PC.

I think it is important to support the higher resolution and color depth modes, even if we can't use them today at full speed, in the future we will overcome those obstacles. Otherwise a good number of games will be lost in limbo. If MESS handles the IBM PC games and booters, DOSBox for any DOS game requiring no more than 8-bit SVGA/VESA, that still leave quite a few games that are essentially unplayable unless you have an older computer, even if you keep a Windows 9x dual boot as I hope to.

When multi-core processors become more popular, you can have one core draw the screen and the other handle everything else.

Isn't it ridiculous that we require massive power to play 10 year old games slowly that we could play at full speed on the average flea market computer?

Also, consider the joys of an SLI setup. Two cards can each render half a frame or render frames alternately. If you can split the graphics work between two such cards, you could support 16-bit VESA modes with only a reasonable overhead rather than double it.

That's assuming that the current bottleneck for emulating high-color VESA modes is hardware rendering, which I find extremely hard to believe due to the fact that current video cards can easily handle full-motion video, 2D and 3D graphics at resolutions upwards of 1600x1200 and refresh rates well over 60Hz.

Does 0.70 add support for 16-bit color? I can seem to get A Final Unity to do it if I run the UniVBE option in the setup, but the actual game won't load past the first cinematic. The game has options for 32,768 colors and 65,536 colors. 320x200 - 640x480.

edit:
Well, it seems I just can't use any of the 640x480 modes at all. I can run 320x200 at any of the color depths......

Yeah, the bottleneck is the *emulated* writing to the framebuffer (AKA screen memory). It goes emulated software -> emulated framebuffer -> real framebuffer. The first bit is the slow bit. Copying from the emulated framebuffer to the real one is relatively fast unless filters are applied along the way.

Well I wasn't asking about speed. 😀 I can't get it to do 640x480 at all for the vids in A Final Unity. I think it's doing 640x480 for the actual gameplay tho...

Another potential speed problem is color conversion. Though it could be offloaded to GPU using fragment (shader) programs, as long as emulated framebuffer is (copied/DMA'd ) in(to) video RAM (think also about those demos with copper bars!).

486-class hardware didn't even have speed to do fullscreen high or true color blits, so games/programs mostly used static background and modified small parts of screen, so as long as algorithm tracks dirty areas and doesn't do unnecessary copying, it shouldn't be a big hit.