Exactly how do high-res ports handle static graphics?

From my understanding of the source code, the column, sprite and flat renderers can self-scale themselves to virtually any (?) resolution by leaving the code "as is", as they tap directly into the SCREENWIDTH and SCREENHEIGHT defines to precalculate multipliers etc.

However other stuff like the status bar, messages, endlevel screen, the title screen etc. are all defined by absolute coordinates which are not corrected at runtime to account for differing resolutions (they're all hardcoded to custom-fit a 320*200 canvas), and use functions such as V_DrawPatch which do not explicitly support any sort of scaling, not even static pixel doubling etc.

Exactly how do various source ports get around that (when using software renderers)?

• Pre-scaling specific patches and images?
  
• Pre-multiplying fixed offsets with appropriate factors, plus the above?
  
• Alter drawing routines at the "pixel level" to draw stretched pixels and automultiply offsets by a constant factor?
  

I'm asking because sooner or later I'll have to deal with it...I could peek at some SCs but I'd like to hear a comparative overview, preferably by people who got their hands "dirty" with the code.

Maes said:

• Pre-scaling specific patches and images?
  
• Pre-multiplying fixed offsets with appropriate factors, plus the above?
  
• Alter drawing routines at the "pixel level" to draw stretched pixels and automultiply offsets by a constant factor?
  

The third, sort of.

I can only speak for ZDoom, of course. It has an option to set a virtual screen size on which the graphic is placed. To render it onto a higher resolution screen it calculates scaled offset coordinates and scaling factors so that in the end they are drawn just as the sprites.

Of course that's only the simple cases. There's a lot more options, e.g. to avoid scaling by a fractional value in the menu. Menus and other text containing screens are only scaled by integer values to reduce the visible scaling artifacts.

And you have to watch out for the mini HOMs created by round-off issues.

Eventually I'll get to those issues too. Now my priority is making a reference "vanilla-like" Java port that works internally just like Doom and even the API looks just like Doom's (and so far, it seems like I can pull it off). After that I'll gradually move it towards a "Java Boom" direction (this includes support for higher resolutions).

Gez said:

And you have to watch out for the mini HOMs created by round-off issues.

Not to mention the opposite and much more insideous problem of drawing off the boundary of the framebuffer because something scales up too large, or stepping one off the end of the columnofs[] array in a patch because of the same sort of problem.

It has literally taken years to get Eternity to the point where it can never suffer from the aforementioned problems.

Something I've often wondered with software renderers is if any has gone the route of using STL-like bi-directional containers for their frame buffers (see STL-Style Generic Programming with Images: http://hci.iwr.uni-heidelberg.de/vigra/)?