Reply 120 of 145, by WilliamC
But I was talking about the DosBox version.
But I was talking about the DosBox version.
Sorry, I didn't do a very good job of splitting the topics (never done it before).
You can always re-post your last question in this thread.
Will the DB-version be updated sometime or is the 20050427(?) considered final?
Thanks for splitting. Actually, unless you convince me of something else, I consider the dosbox-openglhq dead, as it is horrible code. The SDL version works as well (or even better: less bugs), and the output is identical.
I had to alter dosbox heavily to get openglhq done, so the source patch would probably break every few months. The SDL variant is much cleaner (and easier to get, just overwrite SDL.DLL 😉 ).
So, I won't work on it anymore, unless someone has a compelling reason why I should. It's up to you in the end 😉
BTW, gulikoza, feel free to mirror/link the SDL-openglhq relase as of 06-23 on your download page. It's pretty stable and more or less bugfree to be used.
It sounds to me like Moe has decided that it makes more sense to implement this at the SDL level and doesn't plan to continue developing it at the DOSBox level any more. If he included the source changes, you could probably keep it ported to the latest DOSBox CVS on your own...
EDIT: Oops, Moe beat me to the punch 😀
No really, convince me and I will keep dosbox-openglhq. I think the SDL variant is superior in all regards, but no one is infallible. I guess I'm hard to convince once I have decided, but if there's something I didn't think about, just go ahead.
Well...I'm still having a hard time relating to sdl-openglhq. Using env variables is somewhat inconvenient (yeah...I could make bat files but I'm too lazy 😜), but I dunno, that's just how I feel. I'm somewhat overdue for an update of my cvs build (also with some D3D changes I made in the last month)...among other things I don't know to include sdl or dosbox ohq version 😁. I agree, SDL implementation is much nicer (plus DB version breaks my D3D patch as well 😜), but DB implementation makes all video related options in the same place - dosbox.conf...
What I'd really like is to have a D3D version of HQ filter...but shader programming is still somewhat out of my league and you're using linux so there's little chance of having it soon. D3D still beats OpenGL on my system by almost 50% (no scalers), although with hw D3D scale2x vs. OpenGL HQ, the difference is just about 15%.
Can't you keep the setting in the config file?
But instead of a bat file inicializing the sdl code, do it so the dosbox executable does?
On second thought probably much uglier dosbox code, anyway. Forget it.
Gulikkoza, I will prepare a small patch for dosbox that adds "output=openglhq" and sets the neccessary environment vars for you 😉
You can also add the envornment variables to your Windows system properties->advanced->environment variables menu. Still inconvenient if you need to turn it on and off though.
That would probably be best solution 😁
Hello! 😀
First of all, I want to thank Moe for the very useful patches both for dosbox and for SDL as well as people who build dosbox binaries with them (or without 😀 ) and creators of wonderful program "dosbox".
And now, the problem. That is strange, but for me any dosbox build past 9 april 2005 with OpenGL-HQ2x patch works 3-5 times slower. If I have 30000 cycles with 9/04/2005 build, any of the laters give 5000-10000 😵 (with timesynched=true), which is insanely slow in some games. The quality is exactly the same. This is true for Gulikoza's builds as well as ykhwong's Korean (where it is even slower) or Moe's, and does not depend on SDL.
What hardware do you have, and how is performance of the SDL version?
Also...OpenGLHQ was released 16.4. by Moe...there are no 9.4. builds with openglhq 😕
To Moe:
Oh, sorry, I forgot to mention my config.
My hardware:
CPU: Athlon FX-55 (2.6 GHz)
MB: MSI K8N Diamond (nForce4 SLI, bios 1.2)
RAM: 2 Gb DDR400 Kingston
Video: Gigabyte GV-NX68U256D-B (GF6800 ultra 256 mb pci-e)
HDD: RAID0 massive of 2x Samsung SP0812C
Sound: Creative SB Audigy 4 pro
OS: Windows XP SP2
As for the SDL version performance, it is good, 40000-45000 cycles on 4x scaling. Gulikoza's DosBox builds for 09/04/2005 and earlier give the same result.
wrote:Also...OpenGLHQ was released 16.4. by Moe...there are no 9.4. builds with openglhq 😕
eeehhh... I'm sorry, I didn't realize that your hq2x patch and moe's opengl-hq2x were different things. Anyway, the problem is that hq2x scaler since your 29/04/2005 build has become extremely slow. The 9/04/2005 build works fine with hq2x turned on, as well as Moe's patched SDL.
By the way, I have noticed some strange artifacts with Moe's SDL. The picture twitches a little in some places during movies, or around the cursor.
Oh, you're talking about software hq2x. Yeah, I had to undo a few optimizations, as they made the code horribly convoluted. I'm still trying to get hq2x into dosbox CVS, so the code must stay clean-ish. Moreover, there have been changes in the rendering code of dosbox which made hq2x slower.
If OpenGL-HQ works nicely, just use that 😀 About the mouse problem, could you send screenshots? I already have an idea what that could be, but would like to confirm.
Unfortunately, I can't send screenshots, because this effect is noticeable only in the moving picture (i.e. in-game movie, where black "sparkles" appear, or while moving cursor). It happens only with scaling greater than 2x. I have noticed black "sparkles" in the intro movie of Realms of Arkania 2 - Star Trail in dosbox. The "cursor" effect is interesting - it is if the picture "runs" or "flows" around the moving cursor. The best match I can think of, is when you put a finger onto LCD panel and move it. This is very noticeable in Exult (especially with a book or a scroll opened). My settings for SDL are:
SDL_VIDEODRIVER=openglhq
SDL_OPENGLHQ_WINRES=2
SDL_OPENGLHQ_FULLRES=4
In the windowed mode flowing effect seems to disappear, but occasional black "sparkles" are still there.
Maybe it is related to my LCD monitor and its synchronization and refresh rates, I don't know... I have tried different settings.
Ah, so it's exult... yes, that's possible. Could it be that these are two distinct effects? I know what the exult thing could be, but I don't know what might effect dosbox.
Oh, sorry for the false alarm. The black and white artifacts in dosbox were due to ForceWare 77.72, which does have a number of new glitches. With 71.89 all works flawlessly. But 800x600 exult bug is still there, but it is not very annoying.