0x0 ?
Or wasn't that implemented ?

Seems to work, so it must be implemented, but not documented.

Wasn't that renamed to =original, or what's the difference?

If I use fullscreenresolution=original DOSBox crashes and burns and asks me if I want to send a bug report to Microsoft.

fullresolution=original along with fullscreen=true ?

wd wrote:

fullresolution=original along with fullscreen=true ?

Yes. Or if I do fullscreen=false and then switch to FS with ALT-ENTER, then DOSBox aborts.

That's odd, meaning that the default dosbox.conf would not work on
that pc. Maybe try the windib stuff, try some self-built sources where
you can add logging where it crashes (or squeeze it through some debugger).

Actually, it depends on the output method. surface and ddraw simply collapses DOSBox into the Windows task bar. overlay crashes it. Haven't tried the opengl methods.

Maybe the (SDL?) call that queries the desktop resolution returns bad values for some reason.

wd wrote:

That's odd, meaning that the default dosbox.conf would not work on that pc.

Correct. I created this little config-file:

1[sdl]
2fullscreen=true
3fullresolution=original
4output=overlay

and ran

dosbox.exe -conf my.conf

I see the DOSBox intro screen, then the screen blanks out, and next I am presented with the "DOSBox DOS Emulator has encountered a problem" dialog.

the only difference i see between 0x0 and original is the
sdl.desktop.full.fixed being set to true. so they aren't identical.
I seem to recall that original would be the game it's own resolution.

Ahhh - found something!

I tried it with SDL_VIDEODRIVER=windib and noticed that my Citrix MetaFrame Window popped up for a short moment and resized itself. After closing Citrix down, DOSBox no longer crashes when it goes fullscreen with my little 4-line config.

It is still a little unstable though. ALT-ENTER works fine, but ALT-TAB often^H^H^H^H^H sometimes causes DOSBox to crash.

That's known, it is due to speed reasons. We can't quit the rendering
fast enough in some rare cases (which is a reproducable case for you
it seems due to some background app if i understand correctly).

Sorry, probably hardly a meaningful question, but I'm curious :

I realize default is fullresolution=original, allright.
And, I guess, that's likely the only setting of it I ever had in my .conf files.

I'm afraid I didn't understand what this fullresolution=0x0 is for though.

I mean, is it locked to the desktop resolution afterwards, or can it still shift to dynamically match the application's ?
Has it practical pros as an option ?

--------------

P.S.
Isn't it cool to complete one's
unaccomplished elucidations by means of a nifty
P.S.
Isn't it cool to complete one's
unaccomplished elucidations by means of a nifty
P.S.
Isn't it cool to complete one's

gidierre wrote:

Sorry, probably hardly a meaningful question, but I'm curious :

I realize default is fullresolution=original, allright.

My understanding of this is that original refers to the resolution that the application (the game) was originally written for, e.g. 320×200.

If you then try to run the application in full-screen mode, DOSBox will tell your graphics card to "Please switch to a 320×200 full-screen" and will assume that any resizing/scaling will be taken care of by the card.

But what if the graphics driver, the graphics card, or perhaps the monitor can not do 320×200? Perhaps you get a big black screen with a tiny 320×200 area in the middle? Perhaps you get something close to 320×200 - like 400x240 ? Nobody knows.

gidierre wrote:

And, I guess, that's likely the only setting of it I ever had in my .conf files.

Maybe you were just lucky that your graphics card/monitor could do the original resolutions.

gidierre wrote:

I'm afraid I didn't understand what this fullresolution=0x0 is for though.

I think the 0x0 tells DOSBox to ask the graphics card/driver "Hey! What is the current resolution of this desktop?". And the driver will respond with something like "1680x1050". When the game then asks for 320×200 in full-screen, DOSBox will tell the graphics card "Please, keep the 1680x1050 resolution, but scale this image up by a factor 5½ using that nice output method called overlay" (or ddraw, or whatever).

gidierre wrote:

I mean, is it locked to the desktop resolution afterwards, or can it still shift to dynamically match the application's ?

I do not see why it should be locked. If DOSBox detects that the game tries to switch to 640×350, it will just have to tell the graphics card to scale the image with a factor 2.625 and add a black bar at the top and the bottom.

Somewhat relevant to the problem of running dosbox from usb drive on machines that don't support the currently set resolution: the d-fend reloaded frontend allows you to change the resolution settings of all (or some) profiles in about three mouse clicks.

Not sure if any other frontends can also do this though.

MiniMax wrote:

My understanding of this is that original refers to the resolution that the application was originally written for, e.g. 320×200.

If you then try to run the application in full-screen mode, DOSBox will tell your graphics card to "Please switch to a 320×200 full-screen" and will assume that any resizing/scaling will be taken care of by the card.

I think the 0x0 tells DOSBox to ask the graphics card/driver "Hey! What is the current resolution of this desktop?"... When the game then asks for 320×200 in full-screen, DOSBox will tell the graphics card "Please, keep the 1680x1050 resolution, but scale this image up"

now, to make a blurry sketch of it,

fullresolution=original
will let, if possible, the video adaptor take care of business, including size, scale et paraphernalia similia.
No assumption necessary about actual desktop state

while

fullresolution=0x0
and as far as I can tell, necessarily its relation too, namely fullresolution=1440x900 (obviosuly such being the case),
forcing desktop recognition will handle the thing feeding the card any details its customized way.

Does this come near the real liturgy ?

---------------------

Posthumum Scriptum

Is it just a figment of my bold imagination or,
such being the choice, should it end up being a hardware vs. software race,
then fullres=original *might* 😊 be performing faster than =0x0 ???

(that is if one's machine parts harmonize
and you don't sport a graphics processor which processes @1Hz and the CPU @8GHz...)

It's all in the code...

fullresolution=original switches to whatever the game runs at. This is probably best on CRT monitors, you get the very same resolution as running native (but as MiniMax points out, IF the graphics card supports it). No scaling is done by dosbox.

fullresolution=0x0 switches to desktop resolution on WIN32 (GetSystemMetrics() call) and 1024x768 on other platforms (one might call DisplayWidth(), DisplayHeight() on Linux, it is possible 😉). The scaling is then handled by dosbox the same as if fullresolution='whatever is your dekstop resolution on windows or 1024x768 otherwise' was set.

gidierre wrote:

Is it just a figment of my bold imagination or,
such being the choice, should it end up being a hardware vs. software race, then fullres=original *might* 😊 be performing faster than =0x0 ???

I hope not. The scaling would be done in the hardware on both occasions. Think for moment how it works if you have a TV-tuner in your machine (like I have). You can get a small TV-window, a larger, or a fullscreen TV-window. And you resize it as fast as you can shake you mouse. The scaling of the video is done entirely in hardware - all DOSBox have to do is to tell the card how much to scale. BUT ONLY (as it says in the configuration notes):

1# windowresolution -- Scale the window to this size IF the output device supports hardware scaling.

Overlay is (I believe) one such output method.

Note: I am not a DOSBox or SDL programmer. I haven't studied the code nor the documentation. The above is just my "mental image" of how it might work based on my experience with DOSBox.