#7486 closed feature request
ALL: Widescreen display support
| Reported by: | SF/aurora_noir | Owned by: | sev- |
|---|---|---|---|
| Priority: | normal | Component: | Graphics |
| Version: | 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 by , 18 years ago
comment:2 by , 18 years ago
| Summary: | Widescreen display support → ALL: Widescreen display support |
|---|
comment:3 by , 18 years ago
| Owner: | set to |
|---|
comment:4 by , 18 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 , 17 years ago
| Status: | new → pending |
|---|
comment:6 by , 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 , 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 , 17 years ago
| Status: | pending → closed |
|---|
comment:9 by , 17 years ago
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 by , 17 years ago
| Component: | Engine: SCUMM |
|---|
comment:11 by , 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 , 5 years ago
| Component: | → Graphics |
|---|
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.