Kronuz wrote:

This is NOT a bug in the patch, it's the way it should be, however I understand that's not fine and that it's an issue that needs to be fixed. All it's needed to fix this issue is either to force a complete or a partial redraw of the sections of the window that just became visible after being covered by other window or coming from outside the desktop, but that's not as easy as it sounds if you want to keep portability, so we'll have to wait and see what can be done about this without breaking portability.

SDL gives you an easy cross-platform way of handling this. It's called "exposure" and SDL delivers exposure events to you. This "only" requires fiddling with DOSBoxens event handling loop. See the SDL API docs for details.

DosFreak wrote:

I remember Quake 1 being very very system heavy....very very brown....and very very boring.

As someone I know put it: Yeah, cool, a game with 16.7 million colors - and all of them are brown. 😀

`Moe` wrote:

SDL gives you an easy cross-platform way of handling this. It's called "exposure" and SDL delivers exposure events to you. This "only" requires fiddling with DOSBoxens event handling loop. See the SDL API docs for details.

Great Moe, thanks! That's exactly what I needed to know, I'll work on it right now 😀

Dosboxens? Whats that?

🙄

I wasn't trying to be a jerk. I really meant it

neowolf wrote:

I hate to bothersome but are there any plans to switch to a different name other than Rect? It seems like it'd be a good idea to go ahead and adjust it slightly before it starts to get merged down the line. It's easy to switch around while it's a patch but I'd hate to have to dig in for it. 😀

The thing is that if I change it nobody will remind us that it needs to be checked and it probably do needs to be moved to where all the data types are declared. I suppose it should be typedef as a RECT in Windows and probably to other datatype in other platforms. We'll have to dig on that later.

Kronuz wrote:

I really hadn't checked, but also compare the CPU usage of DOSBox with and without my patch when you're playing a game 😉

Not that I say it, but it's AMAZING!! I now can smoothly play Warcraft 2, like in my old days. I'm running it at 20,000 cycles and with 0% CPU usage!! whereas before I couldn't even begin to play without the sound being choppy and the game being really slow... all that along the huge noise of my CPU fan at full power and the CPU usage at maximum.

What I noticed is that my CPU usage varied a lot more (but of course never got higher than without your patch), indicating that you've addressed a big bottleneck in DOSBox.

Okay it's done now I've added the exposure event and now DOSBox is working like it should 😀
I'm attaching the compiler super-optimized binary for the new version here.

Qbix: Attachment removed

Kronuz wrote:

I'll keep on trying to further optimize this patch as much as I possibly can with my limited knowledge of the DOSBox code.

I dare not imagine what you would be able to achieve if you knew the program inside out 😉

Your latest build works a treat in surface and ddraw.

Btw, the problem I mentioned earlier about some late Legend games (Death Gate, Shannara, Mission Control) crashing the emu with your patch... I actually found the culprit, but this is a weird one. The games crash with a quick "Tandy dac" error; it happens when I force Tandy=true instead of auto. Very weird since those games don't use Tandy sound whatsoever...

Must be a recent behaviour of the CVS, and not specifically related to your patch.

Kronuz, let me start by saying you have indeed done some mighty impressive work; quite a lot of games run significantly better in your build.
Congratulations, I really hope your hard work will eventually lead to your patch ending up in CVS. That might make for a real 'must-have' feature for release 0.64 heh 😉

Unfortunately, the latest build seems to have problems in fullscreen for surface and ddraw modes: nothing is shown and the screen remains black. All other modes, or surface/ddraw in a window run without any problems (yet). Previous builds did not have this problem, that is to say, for me (ATI9700 Mobility). Hope you can find and fix fix the culprit.

Regards,

Ronald

rcblanke wrote:

Kronuz, let me start by saying you have indeed done some mighty impressive work; quite a lot of games run significantly better in your build.
Congratulations, I really hope your hard work will eventually lead to your patch ending up in CVS. That might make for a real 'must-have' feature for release 0.64 heh 😉

Unfortunately, the latest build seems to have problems in fullscreen for surface and ddraw modes: nothing is shown and the screen remains black. All other modes, or surface/ddraw in a window run without any problems (yet). Previous builds did not have this problem, that is to say, for me (ATI9700 Mobility). Hope you can find and fix fix the culprit.

Thanks Ronald, I tried hard to make DOSBox run a bit faster; as for the problem you're getting please, once in fullscreen could you please do some writting on the prompt, some [ENTER]'s, movements, execute some commands (dir, etc.) to see if any part of the screen becomes visible? at that point (or wait a couple minutes to see if the screen is painted) I just want to know if the problem is due the first time screen not being painted or if it something else with the way I'm updating the screen.

rcblanke wrote:

Unfortunately, the latest build seems to have problems in fullscreen for surface and ddraw modes: nothing is shown and the screen remains black.

I've seen this too. Make sure you didn't set fulldouble=true.

Exactly. Fulldouble=true does the same for me.

> "Tandy dac" error; it happens when I force Tandy=true instead of auto

Tandy DAC is incompatible with the sb16 (2nd dma), so i hope you know
what you're doing when forcing tandy sound (that is switched the games
to non-sb16 mode).

Kronuz: After reading the last 8 pages I JUST HAD to test out the latest cvs build to test out your changes to dosbox, and all I can is WOW. I`d become so used to games running ok but not fast. But now they run practicly perfect. Those that worked in dosbox anyways.

I tested out my main 4 games that I use dosbox to play. Results were as follows:

System Shock:
I`ve not tested this one in dosbox in quite some time, but it had worked in the previous cvs builds that I had tested, but extremelly slowly. Sadly I received a error message about increasing the "files=" stuff. I doubt this was due to your changes.

Might and Magic 5 - Darkside of Xeen:
This game ran 100% perfect. Better than I have ever seen it run before in dosbox. Intro ran perfect as did the game itself. No cpu cycle increases were needed at all. I was very impressed with this one.

Command and Conquer:
This game had worked in the cvs versions for the last year, but apon trying to run it with this version I received a page fault error and dosbox closed itself shortly after. Hmm.

Syndicate:
This game had been working for quite some time in the cvs builds, and I was glad to see that it worked in this version as well. This game however did require a few cpu increases to run well. The interesting part (for me atleast) was that when I increased the cycles there was no impact on sound quality at all. Sound stayed perfect, and the game ran perfectly for the most part (cutscenes ran a bit slow). In all of my previous experiences with dosbox, even a few increases of cpu cycles would always lead to a loss of sound quality and increase in sound stuttering. This was not the case with Syndicate. The ingame levels ran PERFECT which was what mattered to me though. A spot on match to how I`d always remembered them running as.

I too have noticed alot of DPMI games recently that are having problems. Not sure if this is with ykhwong's/kronuz builds or not....really haven't gotten around to trying them out in ordinary CVS yet.

Although I doubt it's either of their faults because kronuz just uses CVS and his render patch unless it's a compiler difference...

Icemann, can you test the games you noted that you have problems with, with straight CVS and then post a thread for these games (assuming I haven't done so already by then)? If you don't have a copy or can't compile just use the latest build from AEP.

For C&C I've always had to use DOS32A. Dos4gw which is included with the game has never worked for me with dosbox. (I think it works in normal mode tho)

Okay, after analyzing the problem of the fullscreen doublebuffer, I've found that it would require many changes for the optimized scalers to support double buffer, and also than those changes, I believe, would make the optimized scalers slower losing the benefits of double buffering; hence, my latest patch disables the optimized scalers if double buffer is turned on.
I hope you find okay, this little issue of the double buffer not being supported. I particularly dislike the idea, but I think having faster scalers not supporting double buffer is better than having double-buffer supported by slower scalers.
I'm attaching here my Windows binary with a couple other small bug fixes.

I`ll do a quick test of the 2 non working games now with the AEP version.

[edit]
Same exact errors in the AEP build. Must be something else causing the problems.

Kronuz wrote:

I suppose it should be typedef as a RECT in Windows and probably to other datatype in other platforms.

Don't do that. Your code should not contain any #ifdef's or platform-specific code in any way. SDL is meant to be your cross-platform toolkit, so only use SDL data types, otherwise you won't get a portable DOSBox. Portability is more than "runs on windows and linux".

@iceman: Both C&C and System shock run fine for me under normal core?! Did you use dynamic core while testing?

@kronuz: I can live with your temporary(?) solution most certainly! Unfortunately, your latest build displays the dreaded "This application has failed to start because the application configuration is incorrect" message again...

Regards,
Ronald