Opened 13 years ago

Closed 13 years ago

Last modified 9 months ago

#7486 closed enhancement

ALL: Widescreen display support

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

Description

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

[render]

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 Changed 13 years ago by sev-

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 Changed 13 years ago by fingolfin

Summary: Widescreen display supportALL: Widescreen display support

comment:3 Changed 13 years ago by sev-

Owner: set to sev-

comment:4 Changed 13 years ago by fingolfin

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 Changed 13 years ago by sev-

Status: newpending

comment:6 Changed 13 years ago by sev-

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 Changed 13 years ago by SF/sf-robot

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 Changed 13 years ago by SF/sf-robot

Status: pendingclosed

comment:9 Changed 13 years ago by SF/mbandsmer

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

http://bugzilla.libsdl.org/show_bug.cgi?id=302

and the thread here:

http://www.libsdl.org/pipermail/sdl/2006-September/076488.html

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 Changed 13 years ago by fingolfin

Component: Engine: SCUMM

comment:11 Changed 13 years ago by fingolfin

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 Changed 9 months ago by digitall

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