DosFreak wrote:

The 11/29 build finally makes opengl and openglnb useable on my ATI X800. CPU utilization at the CLI is around 20% as opposed to 99% on 11/28 and all other DosBox builds. Nice. Now I can finally use HDR! 😀

Which gets you exactly nothing. HDR cannot possibly have any effect that your gamma/brightness/contrast sliders already have. HDR requires input with a high dynamic range, so this excludes any DOS games by definition.

BTW, having a compressed executable isn't as bad as it may seem at first, if you only run one copy of the program at a time. It may seem bigger in memory, but unneeded parts will be swapped out, so it doesn't make things worse - unless you run two copies at the same time.

I wouldn't say it gets you nothing. Seems to work better than simply increasing the gamma. The HDR pixel shader that I'm using seems to focus mostly on increasing brightness on objects that are already bright...basically it's just bloom not HDR (the shader is named HDRish.ps which is why I referred to it as HDR),while of course increasing the brightness of the surrounding environment...but this is why you tweak the shader.

This 11/29 seems to be much faster. Duke3D tops out at 55000 cycles in the 11/29 now it's 120,000 cycles. framerate is still the same @ 640x480 @ 15fps tho....it's perfectly playable although I haven't tried any heavy actions scenes yet.

Ithought UPX compression just compressed the EXEs in the disk, once they are loaded to memory, the whole program should take up the same space as the uncompressed version.

GreatBarrier86 wrote:

woah...that's the biggest dosbox exe i've ever seen.

That's becaouse it includes the SDL, SDL_net, zlib, and the libpng libraries (you don't need the separated DLLs)

But what if you want to override those libraries with a different version?

I assume you would just recompile it...Or is that too easy

HunterZ wrote:

But what if you want to override those libraries with a different version?

The only library you would probably want to override is the SDL.dll, but the others are best to keep statically linked, I think.

I have a slight problem to report with Version 7. The changes now declare the struct Rect, which is conflicting with an OS X struct in one of the header files SDL calls. Changing the name of the struct fixes it entirely.

neowolf wrote:

I have a slight problem to report with Version 7. The changes now declare the struct Rect, which is conflicting with an OS X struct in one of the header files SDL calls. Changing the name of the struct fixes it entirely.

Yeah, we'll have to find a coross platform Rect structure or something... let's wait what Qbix says

Yeah, not complaining. That's something I fixed easily enough just be editing the diff file. But I'd certianly love to see your patch become part of the full fledged CVS. 😁

Hey, Kronuz. Latest Latest UPack 0.38ß packs your dosbox.exe to just 470,3KB and it seems it is working well.

It will need ALOT of testing before it's integrated. I've been having some graphical problems with Surface from the 11/29 build and alot with video modes other than VGA. Haven't gotten around to documenting them yet tho.

DosFreak wrote:

It will need ALOT of testing before it's integrated. I've been having some graphical problems with Surface from the 11/29 build and alot with video modes other than VGA. Haven't gotten around to documenting them yet tho.

There are many experimental things in the 11/29 patch 😉 but soon all these things will be tested and issues worked out 😀

Please tell me more about any problems you find in a way that I can reproduce them, or at leas figure out what the issues might be 😀

Okay this is an improved version of the patch, it should run even a bit faster... also, I have included, in the attachment, two versions of the same patch. One updating the entire screen (dosbox_mode2.exe) and one updating just parts of it (dosbox_mode1.exe). Please I need your help testing these binaries if you have problems with mode1 please let me know what the problems are and what output mode you're using; also if the problem goes away using the mode2 of the patch.

I've also updated the patch for anyone to download in the first post of this thread.

Qbix: Attachment removed

eL_PuSHeR wrote:

Hey, Kronuz. Latest Latest UPack 0.38ß packs your dosbox.exe to just 470,3KB and it seems it is working well.

I couldn't find the 0.38ß version of UPack... all the official pages seem to be down, all I could find is version 0.30ß and it had the same problem as with UPX 🙁

gulikoza: It just hit me, I know why SDL_UpdateRect wasn't working on your computer. Try deactivating the "aspect correction" 😉
I'll work on that later, now that I know what the problem is 😀

If anyone is having problems with my mode1 binary, check if the problem is concerning the aspect correction being turned on plz. 😀

I've noticed that with your patch that since your optimizations are so good that frameskip does not reduce processor usage anymore. It still performs it's function tho (reducing framerate). Is frameskip obsolete with this patch?

DosFreak wrote:

I've noticed that with your patch that since your optimizations are so good that frameskip does not reduce processor usage anymore. It still performs it's function tho (reducing framerate). Is frameskip obsolete with this patch?

Well, in a way yes. Since version 7 (where gulikoza suggested some improvements) the frameskip could be said to be almost obsolete 😉

Frameskip may still be useful for some ports, like PocketPC. So the feature should stay there.

I just forsee alot of users in the future (if the patch makes it in), the kind of users who have no understanding and simply follow instructions, hitting frameskip and wondering why their game is slowing down and their performance is not improving. Whereas before if you used frameskip you'd get a drastic decrease in processor usage and could up the cycles more.

Just a possible issue we may need to look out for in the future. Remember we don't exactly have the brightest user base out there. 😉

I'll try, in my next post to give some insight in how I optimized the DOSBox graphics and scalers with my patch, but mainly I'll discuss something that has been causing a small debate about the way the scalers should write to the memory that's going to be displayed in the screen.

I tried to keep it as simple as possible so that anybody could understand it, and thought that's a tough thing to do (especially making it understandable even for non-programmers) I hope you can understand what I wrote. Please ask me if something is not clear enough or if you have more doubts.