Good question, especially now that Ykhwong has disappeared 🙁
And direct3d is the only output that seems to be able to do full-screen, aspect correct high/true-color VESA modes.
(But if anyone can advise how to set up all of them (not just one, fixed resolution) to correctly fill an approppriate part of my 16:10 display in its native resolution, please don't hold it back 😅

high/true-color VESA modes

Which games use those?

alvaro84 wrote:

Good question, especially now that Ykhwong has disappeared 🙁

Too sad. I loved to use Gulikoza's and Ykhwong's builds. Now I have to rely on those AEP vanilla builds. They just aren't as good. 😢

"Good" or "Bad" are not appropriate terms in this case - that should be something like "has many features" or "has not so many features". Ykhwong's builds, btw, had some serious stability problems and bugs in the last few versions he released - i wouldn't call that "good" (no offense meant - i used his build and liked it very much, but it's a fact that the last versions were quite buggy). I've switched to Gulizoka's build (AFAIK, he's the author of D3D output anyway, so i presume his builds should be the "real" ones), and i'm quite happy with it. Having certain patches included in the main DOSBox build would be quite convenient, of course. But i understand that DOSBox is a multi-platform programm, so including any Windows-specific features like the D3D output won't be high priority for the devs, i believe. We should either motivate the patch authors (especially Gulizoka, whose build is now de-facto the most advanced build for the Windows platform) to continue relasing builds in the future (maybe more frequently, ahem... (; ), or create an own environment for building from the sources.

I think AEP is using something like an automatic building process to create the builds. Maybe something similar could be done with Gulizoka's build? It would be great to have the features from Gulizoka's build, "on top" of the latest DOSBox source (bugfixes, etc.).

Not games are VESA HC/TC, but many demos I like to watch.

On Gulikoza's builds: I am one of those who experienced stability problems with Ykhwong's most recent builds switching to fullscreen and back. Pity that Gulikoza builds seem to be ~10% slower. I don't know the reason, but it shows on Blood framerates (~30 vs 33 fps at start position - blood @ 800*600 needs every drop of extra power I can get, and I already maxed out my Conroe at 3.33GHz for this highest reasonable/tasteful 1.4375V setting...) - and most probably on those demos, I just can't measure them to bring numeric data. Again, I don't know what's wrong with these builds, but both the Ykhwong and the AEP builds have better performance. Probably a different compiler or different settings?

Well...maintaining all the patches is a lot of work. Every release needs a careful examination of the code. Even if the patch applies and compiles cleanly with the new cvs, some other code might have changed breaking everything. Unfortunately I don't have as much time as I used to have and I like to test my builds for a while before releasing them...there's a lot of patches out there, I'd like to see those that fix some issues to be committed so I don't have to track them. Maintaining a few "big" patches like D3D and Glide shouldn't be a problem then...
Also, since I have access to the beta board, I sometimes get new dosbox code before it is committed to the cvs. Since usually it comes with the warning not to release it, I wait for it to become public. Why release a build I know lacks some features 😉 I also tend to wait for bugs I know are present in cvs to be fixed (hint: I don't think a fix for 'cycles max limit 15000' syntax has been committed yet? 😉 😉).
One the performance issues, a few years ago I spent some time checking all the flags...I think I got the best performance at the time, I haven't changed the settings since. I don't do profiling optimizations but I try to get the best possible speed with compiler flags...if anybody has any suggestions... Back then -O2 was faster than -O3, so I still use -O2...

hint: I don't think a fix for 'cycles max limit 15000' syntax has been committed yet? Wink Wink).

12008-04-29 10:24  qbix79
2
3	* src/dosbox.cpp: Convert both cycles and serial port to new
4	  multiremain class. TODO src/hardware/serialport.cpp to parse new
5	  classes.
6
72008-04-29 10:23  qbix79
8
9	* include/setup.h, src/misc/setup.cpp: Add multiremain class.

Must have missed it then, sorry 😜

it wasn't very descriptive I admit 😀

alvaro84 wrote:

Not games are VESA HC/TC, but many demos I like to watch.

Could you give an example? I'd like to check them out too.

An example I tried is Core by Chrysalis:

http://pouet.net/prod.php?which=2670

Now I can't experiment with it because this PC at my workplace is not very suitable, but I'll be glad if you try a few things with it 😀

The following settings gave me a pillarboxed (i.e. correct aspect ratio while filling as much as possible of the screen) demo in Dosbox:

fullresolution=1680x1050
output=ddraw
scaler=none
aspect=true

This is what it looks like with the same settings on this PC (at my workplace - an intel 915G or something similar...):

Well, not exactly the same settings, fullresolution was 1600x1200 here (so it should be fullscreen), and it made huge horizontal pillarboxes with an extremely distorted image 😒
With output=opengl and openglnb it simply died (well, 915G...), surface didn't work in fullscreen at all, and surface showed a tiny 320*200 picture in the middle of the screen - none of them were of the correct aspect 😒 I'll go home 2 days from now and I'll try all of them on my 8600GT - but I've already done that, no avail (resolution is 1920*1200 there) 😒 Opengl/nb, for example, did the '320*200 stamp' effect.

edit (14 hours(?) later): I've tried on my brother's AMD690G in 1024*768 - the result is the same.

The version I used is the latest AEP build.

This might be a stupid question but did you try it with the official, vanilla 0.72?

Tried Overlay??

Overlay -> 320*200 letterbox with nVidia 8600GT. Looks extremely dumb in the middle of a 1920*1200 screen 😁

No, I haven't tried the 'vanilla' 0.72, not yet. I was interested in the new builds much more. In the past CVS builds always were *much* ahead of the ?factory? version both in functionality and compatibility, so I early got used to using those builds (gulikoza's then ykhwong's builds). But I'll give it a try, development may slowed down enough nowadays not to lose too much.
One thing is sure: the most recent ykhwong builds have stability problem on my 8600GT and d3d output, they have a good chance when I switch to fullscreen or back to window. Gulikoza's builds seem not to have this problem anyway.

Don't want to go offtopic or anything, but since Ykhwong's name popped up, just wanted to say that I too noticed his absence and just hope that the chap is alive and well, caught up in real life obligations like studies or something and will return one day with his builds.

both Openglhq and Direct3d have wrong aspect ratio (in flashback for example)with aspect=true, openglhq also adds some "special effects" 😉
openglhq with aspect=false too
(all in fullscreen) (window mode is ok)

it looks openglhq works correctly with scaler=none (correct aspect ratio and straight picture), while it works as on the picture with scaler=normal2x

direct3d seems to have right or wrong aspect randomly?
although even when it has the right aspect, the picture is sometimes smaller than with other output= settings