user222 wrote:

Why does DOSBox take extra CPU time to draw the screen? I don't think DOSEmu takes extra CPU time simply for just drawing the screen.

Drawing the screen, especially a graphics screen, takes quite some time, since the internal buffers have to be converted to output suitable for your display configuration. I'm quite sure DOSemu does this as well.

JAL

uhm dosemu has lot's videodrivers installed I think
it writes directly to your screen. (i think).

Does dosemu smell like lemons as well? 🙄

Seriously, dosbox is better off not writing to the screen since it will work with more types of computers. Drivers are needed for correct video card usage and if you start requiring drivers you will loose multi-platform support as well as hardware compatibilty.

If dosbox will every have a "write to screen" option then I hope it will be optional otherwise I see many problems with it.

avatar_58 wrote:

If dosbox will every have a "write to screen" option then I hope it will be optional otherwise I see many problems with it.

I don't think Windows allows writing directly to screen, ever. DirectX is as close as you get... Also, Hercules or Tandy emulation wouldn't be possible with direct writing to screen. It has many disadvantages, emulation wise. If you have an incompatible graphics card, DOSbox cannot run, and that defeats the purpose of having an emulator in the first place!

JAL

Well, full-screen NTVDM can write directly to screen but obviously that wouldn't be an option for DosBox for the above mentioned reasons.

Qbix wrote:

uhm dosemu has lot's videodrivers installed I think
it writes directly to your screen. (i think).

It runs in a window, though. Also, there is no such thing as "frameskip" in DOSemu. Notice the CPU usage of DOSemu is lower, especially in the "console", because it takes less CPU time to draw the screen.

DOSEmu doesn't have any CPU emulation. That's the main reason it's faster. So to use DOSEmu a x86 compatible CPU is required.

AFAIK, dosemu with it's "direct access" even goes as far as using your video card's BIOS for setting modes and everything (configurable). Including messed up screen on exit and no way to kill that program that just runs etc. If, on the other hand, you are running dosemu with it's X window output, it's actually feels slower than dosbox.

How does DOSBOX do it?

Really, there are 2 majors OS's that DOSBOX will be run on. Linux/Unix and Windows. How much does DOSBOX use DirectX/OpenGL. I know they are output options, but does DOSBOX really take advantage of them? One would think if they can run a game like Doom3/Half Life2 that DOSBOX should be able to draw fast as well. There can always be fallback paths for people that don't have OpenGL capable cards. But I'd think that most people out there who are looking at DOSBOX have a card with decent OpenGL drivers. Hell, most cards from 2000 onward have extremely mature OpenGL ICDs. And OpenGL is cross platform.....

Is there any in-depth documentation on how Dosbox does what it does? Like developer comments? Other than browsing thru tons of source code? It would probably be a beneficial thing to have stickied on the forum for visitors to read. Might reduce the daily questions about functionality.

DOOM 3/HALF LIFE 2 use 3D graphic. DOSBOX does not use 3D at all. I think that OpenGL is used just for copying textures/scaling/filtering (basically just 2D features).
Comparing graphic output of DOOM 3 and DOSBOX has no sense (DOSBOX has no 3D graphic).

Mirek

The APIs must have some sort of 2D screen management. Is DirectDraw useless? Actually I've read that DDraw is sort of redundant now, with DX9 using D3D for most of DDraw functions......could be totally wrong on that though.

DDraw is sorta the VESA VBE/AF for Windows isn't it?

@swaaye - I don't think the answer to your question lies inside DOSBox, since DOSBox is built on top of SDL (Simple DirectMedia Layer) - an open source, cross-platform library. I think DOSBox just informs SDL about the chosen output method (normal, surface, opengl, ...) and SDL does the magic.

(Please don't think in a Linux-vs.-Windows way. There is Mac OS X, which has some (deserved) fame, and there even are handheld devices that run Dosbox. Oh, I've heard the X-Box also does it. The world is more than just the IBM PC.)

One thing I could imagine making dosbox video slow is the rather exact emulation of the chips. At least compared to other emulators, it tries to simulate a real VGA (or early SVGA) card. This does make a difference, not in most programs, but some program the chip in an interesting way and such stuff. All this has to happen before OpenGL/DDraw etc. have their turn, and they can't accelerate it.

Modern 3D Games work fast because they were coded specifically for (say) OpenGL. If they wanted to do something not provided by OpenGL, they'd be real slow, too. Game designers use what is given to them. Emulator coders have to do what the emulated machine does, they can't go and say "hmm... this is slow in OpenGL, let's do something different".

That being said, OpenGL/DDraw/... solve the question of how to get the fully prepared screen image on your display, which is mostly a question of moving bytes around real quickly. Unless you are using experimental things like OpenGL-HQ scaling, all the modern graphics APIs can only serve as fast byte-movers, that's the sad truth, and a fact which cannot be changed.

When I referred to Unix/Linux, I was including OS X in there too. It is a derivative of Unix just like Linux, and it supports OpenGL.

I guess I understand what you are saying. The graphics APIs are being used in the last step of the graphics basically. DOSBOX prepares its emulated 'framebuffer' and throws the whole thing at the screen thru one of the APIs.

From what I understand the graphics portion of DOSBOX is the most demanding. I can see how it would be extremely difficult, if not impossible, to accelerate DOS games because they all do things differently. Those were different days when programmers did whatever they could think up to make game graphics different and better, with very limited hardware.

Exactly. The output setting is only used in the last step when writing emulated framebuffer to the screen. But not all outputs are efficient on all systems. OpenGL is slow on ATi (since DOSBox uses some nVidia specific extension). In any case...DOSBox shouldn't use much cpu when simply left idle in prompt. With my Direct3D patch (which works around sdl and goes directly to DirectX in Windows 😎) Dosbox uses about 3-5% cpu in prompt.

gulikoza wrote:

OpenGL is slow on ATi (since DOSBox uses some nVidia specific extension).

Not entirely true. That nvidia extension is optional. It's a problem with the design of OpenGL in general, which nvidia tried to work around by providing an extension that dosbox uses if available. There are others, but the ATI driver seems to support none of them (at least on linux).

Yeah, but OGL output is rather useless without it in DOSBox. I have 80+% cpu used just in prompt. I don't know what the exact reason for this is, I suspect it has to do something with fast writes. Since the pixels for the texture are generated by the cpu this is actually what fast writes were designed to do (fw are mostly feared because they sometime cause instability and only a small performance increase - but this is beacuse games load textures from disk, they do not pass through cpu). Without the extension the texture memory is allocated with normal malloc and this apparently puts more stress on fsb/memory bandwidth then writing directly to AGP memory. It's also interesting that Vertex Buffer Objects are now part of ARB, yet texture memory still cannot be allocated in AGP memory without nVidia pixeldatarange extension 😀
That's why I'm also eager to test your changes to OGL output in DOSBox, to see if OpenGL becomes useable on my card. If not...Direct3D might be the only option to get any dosbox shader scaler with decent speed.

Using DMA, the CPU won't have to touch the incoming bytes from a disk, but AGP is also just a DMA mechanism. Main memory, regardless of being malloced or not, is always involved in-between. The buffers where programs read textures into are just malloced. There's nothing wrong with that.
Important is that AGP DMA access is actually used to transfer textures.

I'm not entirely sure, but from what I've read, ATI tries a different approach on linux (no idea about windows): Since the memory subsystem is well-known and documented, they are able to violate OpenGL rules without breaking things. DMA transfers are used, so the CPU doesn't do any copying, and some kind of locking ensures that the CPU doesn't access the not-yet transferred memory. The NVidia extension isn't all that different, but it provides a mechanism to allocate memory that's sufficiently aligned, which is the most important thing. It does not allocate memory directly on the video card, because CPU access to PCI memory is comparatively slow.

Currently, DosBox's OpenGL code reuses one framebuffer, which is malloced blindly. My patch tries to help out by using two framebuffers used alternately (so the new frame can already be written while the old frame is still in transfer) and by manually aligning texture memory on a 4k-boundary. So yes, there may indeed be an improvement, even for non-HQ-scaling.

Oh, and by the way, there's also a ARB_pixel_buffer_object extension, but ATI doesn't support that either.

jal wrote:

user222 wrote:

Why does DOSBox take extra CPU time to draw the screen? I don't think DOSEmu takes extra CPU time simply for just drawing the screen.

Drawing the screen, especially a graphics screen, takes quite some time, since the internal buffers have to be converted to output suitable for your display configuration. I'm quite sure DOSemu does this as well.

JAL

Is it because DOSBox updates the screen continously, while other emulators, including DOSEmu, only update the screen when necessary. Continously updating the screen would definitely take a lot of CPU time, notice what happens when you keep scrolling the scrollbar up and down.