Maes
I like big butts!
Posts: 8664
Registered: 07-06 |
entryway said:
doubling?
No, it has actual resolution scaling with a program-wide VideoScale setting that affects initialization and size of e.g. visplanes, line buffers and other resolution-dependent LUTs or buffering structures that normally depend on the hardcoded SCREENWIDTH and SCREENHEIGHT. Been like that since uhm... 1.4?
The SCREENWIDTH and SCREENHEIGHT "constants" themselves are not actually constants, but can be set independently for each module that can potentially be affected by a resolution scaling (these implement the IVideoScaleAware interface).
The only limitations is that it's still tied to the original 320:200 aspect ratios and can only accomodate integer multiples of that resolution, but I'm working towards allowing arbitrary ratios as well. I just ain't sure what approach should I use for non-integer scaling of static graphics: ratio-preserving letterboxing/cropping or ZDoom-like arbitrary scaling with distortion (e.g. think of the status bar or title screen)?
Actually, I was amazed when I discovered that it's VERY easy to implement high resolutions just by giving SCREENWIDTH and SCREENHEIGHT different constant values. Anything drawn by the RenderPlayerView function as well as the automap would work smoothly practically with no further changes. That ain't the hard part at all.
The really hard part is handling static graphics like menus, status bar, HUD, fonts, etc. require a totally different system as they are actually tied to hardcoded positions on a 320x200 screen, and are not drawn by the renderer's colfuncs but by the fixed-scale ones in v_. Thus, you need to change each and every place in the code where they are drawn to work with an arbitrary scale system. Currently, I'm using a DrawScaledPatch function ripped derived from Eternity Engine by _D_.
I suppose that's the reason why e.g. fraggle chose not to implement true scaling in Chocolate Doom: yeah, he could pre-multiply SCREENWIDTH and SCREENHEIGHT and get the renderer and automap going in literally under a minute, but then he'd have to rewrite every place where static patches are drawn...and it's a bit hard to guarantee that this would not introduce side effects. There are forks (?) of Choco that do just that, though.
Here's a full resolution version of the above image.
http://img406.imageshack.us/img406/1854/mochableeding.th.png
The visplane rendering on top looks a bit like ass because it's using the 6.10 precision vanilla span function which goes over the roof after drawing about halfway through the screen, but it's possible to use anything you like ;-) When using multi-threaded visplane rendering with strict startx/endx bounding though (each visplane renders only a set horizontal range), this problem goes away because the function "starts clean" with every visplane, and breaks even long spans across different threads.
Last edited by Maes on 11-07-11 at 17:43
|
11-07-11 11:22 
