TriForceX / MiyooCFW

Custom firmware source code and resources for BittBoy, PocketGo, PowKiddy V90-Q90-Q20 and third party handheld consoles
GNU General Public License v2.0
1.1k stars 112 forks source link

DOSBox and surface_dingux #259

Closed Rezzy-dev closed 2 years ago

Rezzy-dev commented 2 years ago

There's an odd thing going on with DOSBox where despite the screen resolution being set to the screen's native resolution (320 x 240), there are black bars for every game on the top and bottom, about 10-20 pixels.

It seems like the way DOSBox displays through surface_dingux, it doesn't get the full surface area of the screen for some reason.

What's even more peculiar is that I can't see any pixel distortion in the games despite them having been squashed, essentially.

I've tried changing the display output to overlay_dingux, turning on scaling, and setting aspect to true in the DOSBox settings, but this doesn't seem to have any effect on the output:

[sdl] fullscreen=true fulldouble=false fullresolution=320 x 240 windowresolution=320 x 240 output=overlay_dingux autolock=true sensitivity=100 waitonerror=true priority=higher,normal mapperfile=mapper.txt usescancodes=false

[render] aspect=true scaler=normal2x

Does anyone know what's going on here? I've heard that some DOS games render in 320 x 200 pixels by default, which would then be stretched to 4:3, but not all games, and this still doesn't explain why DOSBox won't scale them to aspect on my Miyoo device (PowKiddy Q90) even when I specifically tell it to. Does DOSBox and its overlay_dingux not support scaling at all on this platform?

Rezzy-dev commented 2 years ago

Ah, I think I've figured out what's going on. Both CGA and VGA (and I assume EGA as well) render at 320 x 200 pixels by default, so what's being drawn to the screen is accurate:

https://en.wikipedia.org/wiki/Color_Graphics_Adapter#Output_capabilities https://en.wikipedia.org/wiki/Video_Graphics_Array#Standard_graphics_modes

(Practically all DOS games will display with 200 pixels height in these display modes on this size a screen.)

The only problem is that normally this would be scaled up to a 4:3 aspect ratio on a monitor, but for some reason such video scaling doesn't seem to work on the Miyoo CFW, even when DOSBox is put into overlay mode and instructed to scale the image to aspect.

Rezzy-dev commented 2 years ago

Also, why are we calling the display output/mode "surface_dingux" and not the default "surface"? Is there anything different about "surface_dingux" that we need to name it differently? (The same goes for "overlay_dingux".)

Rezzy-dev commented 2 years ago

As an amusing sidenote, by chance, 320 x 200 happens to be a perfect 16:10 aspect ratio! :D In software and video game development, we were using 16:10 even in the 80s (without meaning to)! (4:3 was intended, but the technical limitations graphics cards of the time pushed it down to 16:10 in practice.)

TriForceX commented 2 years ago

Also, why are we calling the display output/mode "surface_dingux" and not the default "surface"? Is there anything different about "surface_dingux" that we need to name it differently? (The same goes for "overlay_dingux".)

"surface_dingux" may have some specific changes to make it working on this version, im not sure, but im uploading all the source codes for the apps, so we can see it there.

Rezzy-dev commented 2 years ago

"surface_dingux" may have some specific changes to make it working on this version, im not sure, but im uploading all the source codes for the apps, so we can see it there.

Oh, thank you so much! :D

I've encountered one game that is partially using the full screen -- so I can confirm my educated guess above: the DOSBox video output is working correctly, minus the aspect scaling feature.

I have to say, whoever worked on the Dingoo/Miyoo port of DOSBox did a fantastic job! Apart from the missing numpad section, the virtual keyboard implementation is reliable and excellent. On my PowKiddy Q90 and the PocketGo, DOSBox can successfully emulate an i486 PC at a speed somewhere between an i486 and an i386 -- which is no small accomplishment on a 700 MHz ARM architecture with limited memory!

Where it struggles is when there are multiple processes running at the same time, such as a multitude of moving, animated sprites or heavy music and graphics. In instances like that it slows down, but for DOS games released in the 80s era (CGA) -- everything up to 1992 -- it's doing wonderfully well in general!

Since it supports command-line parameters/instructions, I've managed to create a version of DOSBox for Miyoo that launches games the same way as the other emulators do, through the native file browser -- the selection of ROMs in the GMenuNX interface. See here: https://github.com/TriForceX/MiyooCFW/discussions/268

Rezzy-dev commented 2 years ago

I'm going to close this issue, as pretty much all the points have been answered.

DOSBox doesn't seem to support software-side aspect scaling, which is why "overlay_dingux" with the correct scaler and aspect settings seems to have no effect.

Since none of these Miyoo devices actually have a GPU to speak of, this is likely the cause for the lack of support in terms of scaling for DOSBox on the Miyoo CFW. It is likely doing this scaling hardware-side -- which is not supported on these devices.

Even if it did scale it on the software-side, it would likely do so with a performance impact, which for 40 vertical pixels really isn't worth it. It's not an enormous visual change from 16:10 to a 4:3 aspect ratio -- it's quite negligible.

image

The performance impact would likely be much greater than the benefits gained in terms of the visual change. And there is the fixed, limited pixel density of the small LCD screen to consider, too. Once scaled, we would either get some blurring or some pixel distortion. Which, again, for such a small aspect ratio change really isn't worth it. Better to have the native resolution to the display at the 16:10 ratio the games actually render at.

These may be the reasons this hasn't been pursued. And they seem valid and justifiable reasons to me, so I consider this issue closed/resolved.

TriForceX commented 2 years ago

I find your observations very interesting, I was unaware of many things about it. If you agree, I could give you permissions for the Wiki and thus be able to add a page dedicated to DosBox.

Rezzy-dev commented 2 years ago

Ooh! That's not a bad idea, actually! I could put what I have learned into simple to follow documentation that could prove useful to everyone, and that we can build upon. I grew up in MS-DOS, so this feels like going back home to me.