Different resolution ratios and behaviour of gfx lumps

[Tormentor667]

Okay, as I have some serious problems with the same issue currently again while working on a mod, I thought it might be fair to bring the issue up again that has been locked two years ago.

The problem
ZDoom has certain rules for displaying graphics of different ratios in different resolutions. At the moment, it behaves like this: (this goes for the INTERPIC gfx btw)

• A gfx with a ratio of 4:3 gets displayed normal when the resolution is 4:3
• A gfx with a ratio of 16:9 gets displayed squeezed when the resolution is 4:3
• A gfx with a ratio of 16:9 gets displayed squeezed when the resolution is 16:9
• A gfx with a ratio of 4:3 gets displayed normal when the resolution is 16:9 (with black borders)

The problem is, that you actually can't control anything of that, you only can adjust graphics for one game ratio, it will always look ugly in another one.

The solution
Actually, Enjay has posted already a solution 2 years ago which sounds quite simple and clean to me:

Something that could be added to the gameinfo section of MAPINFO then? Like, I don't know, a way of explicitly stating the ratio of a graphic and at what screen ratios to use it?

...so actually adding something to the MAPINFO lump, that states the ratio and states the behaviour might work pretty well.

Code: Select all

graphics
{
titlepic = "TITLEPIC", 16, 9, crop
interpic = "INTERPIC", 4,3, scale
}

This would result in the TITLEPIC gfx being cropped if the used resolution is different from 16:9 and the INTERPIC gfx being scaled to fill the whole screen if the resolution is different from 4:3. Would something like that be hard to code? Or easily doable?

Thanks already in return, this is like a urethritis to me I'd be happy to get that solved somehow.

[GooberMan]

I don't see it as an easy one to solve though. And the problem lies within the original resolution.

Doom's original resolution was 320x200. This is not a 4:3 resolution - in fact, the rendering buffer's aspect ratio is 16:10. However, it does what is effectively an anamorphic projection - the pixels are in fact meant to be vertically rectangular. The 320x200 image is meant to be displayed on a 4:3 monitor. Moving over to a modern Windows world makes that a whole lot more complicated. 320x200 windows can be created, but even displayed on a 4:3 monitor means that they will be displayed in a 16:10 resolution.

This gets trickier if, say, someone ports ZDoom to the iPhone with its 3:2 aspect ratio; or any of the ridiculous number of standard and non-standard Android resolutions out there. At its heart, the problem is that you need to know the physical dimensions of the space you're rendering to rather than just the pixel dimensions. That is the most important part for correct rendering.

How does it tie in to altering MAPINFO (or, far more prefarably, creating a new lump like GFXINFO)? Quite simply, you can't just say "this is a 4:3 graphic" or "this is a 16:9 graphic" because it won't automagically be correct. It's going to need a bit of modification on ZDoom's part to separate pixel ratio from display ratio.

I think trying to define virtual aspect ratios for new GFXINFO elements is the wrong way to go about it though. Handling multi-resolution and multi-aspect-ratio HUDs is a tricky problem because there's generally not an all-in-one solution. The most sane way to handle it with ZDoom would be to have an orthographic projection (or equivalent for software mode) that centers the 4:3 area in the middle of each display, and to peek at the hardware display ratio and base the ortho correction off that.

And because modding is fun, in the absence of the corresponding lump that defines HUD behaviour Doom engine games would use a set of defaults that defines a 320x200 HUD that needs to scale to a 4:3 physical display ratio. Modders can then override that lump to define HUD sizes and how it's meant to scale. GFXINFO would be irrelevant in this scenario.

[Enjay]

I suppose the nearest situation to that currently exists in ZDoom is displaying graphics with HUD messages. If you set the HUD size to 640x480 and then use a HUD message to show a graphic, you can make the graphic much wider than 640 (and taller for that matter) and have it centred on screen so that the edges are hidden in 4:3(ish) ratios but visible in widescreen modes.

I think that's really what this is about: being able to show a graphic that covers the entire screen area in widescreen modes (which most users have now) and not have it forced to the centre of the screen with black bands either side. So what would be good is some way of saying "when full screen graphics are being shown, treat the screen as [insert values here] but don't force graphics to that size so that, instead, narrow ratios clip the graphic but wide ratios show more of it".

A modder can already work around the issue with a titlepic (by using a titlemap that uses a HUD message to show a graphic) and it is possible to use ACS to script an intermission too but that is far more fiddly.

[edit]I think that it also works "out of the box" with status bars. Provide a wide one and the edges get clipped in narrow resolutions but shown in widescreen ones, allowing the use of status bars that hide the GRNROCK border at wide resolutions.[/edit]

[GooberMan]

I suppose the nearest situation to that currently exists in ZDoom is displaying graphics with HUD messages.[/edit]

Aye, I was going to bring that up, but I don't think it goes quite far enough to solve all problems that will crop up ever.

The new lump and aspect-checking code would ideally move all the current out-of-the-box behaviour over to the lump.

What would be fab is if there was an ACS command to find out what the current physical aspect ratio is. You could then write your ACS to take that in to account (ie rather than have everything with an absolute position you'd have then as offsets from screen boundaries calculated by the function).

[Tormentor667]

Enjay exactly hit the nail, this is what we would need.

The behaviour that HUDMessage and SBAR currently have already do the job. Larger graphics get cropped so they work fine in 4:3, 3:2 and 16:9. The problem atm is that graphics for the INTERMISSION (and other places as well) do not get cropped but scaled to a different ratio which looks terrible.

[GooberMan]

The behaviour that HUDMessage and SBAR currently have already do the job.

Not properly. SBAR's a custom system, and HudMessage (even with SetHudSize) makes the concession of specific pixel aspect ratios locked to the pixel backbuffer aspect ratio. I'm not disputing that you can get by if you reuse that functionality, but it's still working around the core problem and is why there's so much pain when it comes to different resolutions and aspect ratios. I'm basically suggesting a final solution to the problem.

[Tormentor667]

The latest version of TUTNT actually suffers this problem and also the project that I have currently in development needs a solution for that. I have to admit I am still quite surprised that no-one else encountered this issue yet.

[Tormentor667]

Sorry for the bump but as there has been some time now since I've posted the question I just wanted to know how the status on this is, and if there are still chances to get this in - or something similar.

[Graf Zahl]

There has obviously been no status change.

[Tormentor667]

Any plans? It would be more pleasing to know if this feature has a chance to get in or if it's just too complicated - or whatever

[Graf Zahl]

No plans, no ideas, no nothing right now. Most importantly no idea how to do it.

[Xaser]

Any plans? It would be more pleasing to know if this feature has a chance to get in or if it's just too complicated - or whatever

Not to play the annoyed guy (though I totally am), but if there were, they'd have been posted about. A lack of post is "no noteworthy progress" by default, and I'm not sure why folks tend to expect otherwise so often.

[Tormentor667]

The list of suggestions is long and I was just curious. People sometimes miss things, it's not that I want to be annoying

[DOOMGABR [RU]]

Is this issue fixable now? My Full HD Titlepic looks disproportionately

[Rachael]

Please don't bump 5 year old threads to ask questions like this. It's better to start a new thread.