Opened 18 years ago

Closed 17 years ago

Last modified 5 years ago

#7486 closed feature request

ALL: Widescreen display support

Reported by: SF/aurora_noir Owned by: sev-
Priority: normal Component: Graphics
Version: Keywords:
Cc: Game:


Hi Team,

I had a brief chat with sev recently concerning implementing a feature to handle widescreen displays. We determined that currently, ScummVM outputs display exactly to what the games original resolution was, except where graphics filters (eg: 2x, hq2x etc...) increase the resolution output to accomodate pixel smoothing etc...

Currently, dosbox have a nice way of handling this, whereby you force dosbox to display at the native resolution, and the filters will compensate for the correct display (including aspect ratio) in display overlay processing, thereby introducing black bars on either side of the output.

Here is a snip from my dosbox config ----------------------------------------- [sdl] fullscreen=true fulldouble=false #fullresolution=original fullresolution=1680x1050 windowresolution=original output=overlay autolock=true


frameskip=0 aspect=true scaler=normal3x -----------------------------------------

I understand that ScummVM also uses SDL, so if these features could be accessible, I believe that ScummVM could support every widescreen device using this method. Also, I think it may address another feature request regarding FM-Towns' aspect ratio enable.

Many thanks

Ticket imported from: #1471116. Ticket imported from: feature-requests/302.

Change History (12)

comment:1 by sev-, 18 years ago

The idea is to query original resolution and use special parameter to force that resolution in full screen mode. I.e. use, say, 1680x1050 even for 320x200 fullscreen. Shouldn't be too hard to implement, and backends can have screen size hardcoded.

comment:2 by fingolfin, 18 years ago

Summary: Widescreen display supportALL: Widescreen display support

comment:3 by sev-, 18 years ago

Owner: set to sev-

comment:4 by fingolfin, 17 years ago

It's certainly not hard to implement this, though it seems like a rather hackish thing for power users... I'd really prefer if things worked "out of the box" for 99% of our users, w/o requiring them to learn arcane procedures (well, for us, this isn't arcane of course, but for most people who just want to play an adventure, it certainly is).

In other words, once again I believe it's better to find a cure for the problem instead of working around the problem :-). Of course, maybe we don't find a way to do that ... :-/

comment:5 by sev-, 17 years ago

Status: newpending

comment:6 by sev-, 17 years ago

Just looked at the dosbox code. Well, they just create Surface with those specified parameters. We in our SDL code assume that Surface starts at (0,0), and that means that adding this functionality will complicate the code a lot with benefit to a really small amount of users....

I am not sure what to do.

comment:7 by SF/sf-robot, 17 years ago

This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker).

comment:8 by SF/sf-robot, 17 years ago

Status: pendingclosed

comment:9 by SF/mbandsmer, 17 years ago

This feature is apparently already implemented in SDL 1.3 (still in beta). See

and the thread here:

If I understand the gist properly of the thread properly, with SDL 1.3, users can set environment variables to ovveride physical width and physical height selected by SetVideoMode(). Display windows would thus automatically be centered in whatever physical window size the user wants. There's probably also custom SetVideo*() functions that would do the same in SDL 1.3, but I haven't looked at the 1.3 API interface in detail. It seems to me that this bug is worth reopening if all it would take is waiting for & upgrading to SDL 1.3.

comment:10 by fingolfin, 17 years ago

Component: Engine: SCUMM

comment:11 by fingolfin, 17 years ago

SDL 1.3 has been in the works for what, 4 years? Granted, it picked up lots of steam in the past year, but don't hold your breath on it being released. And once it's been released, it won't be available for all platforms initially. Hence we won't be using it initially (it's not fully backwards compatible either).

And it's not necessary either, we *could* implement this feature atop SDL 1.2.x any time. The question is more, do we *want* to do that? I still think "no", but that's just my two cents.

comment:12 by digitall, 5 years ago

Component: Graphics
Note: See TracTickets for help on using tickets.