[http://sourceforge.net/p/ufoai/patches/384 Item 384] imported from sourceforge.net tracker on 2013-01-28 20:34:58

this minor patch prevents some glitches with the tiled textures of the spinners when in resolutions < ....x768 (it does rounding by hand in DrawNormPic instead of relaying on gl_nearest in order to assure all spinners in the same screen are of the same height, and draw the upper button of the spinner bottom-up); could also affect positively other widgets, but i only tested that doesnt break things
===== Comments Ported from Sourceforge =====

====== bayo-fr (2008-11-24 15:46:41) ======

Hello. It maybe a good idea.

I dont know about gl_nearest, better or not (to implement, to reduce computation). But this patch can do a good job. And at least in 1024x768 it will affect nothing.

Just a little thing:
* hard to me to know, is center and low align are right? "y1 = rint(y1) - rint(nh)" (align the bottom pixel first with a normalised size) will be better? too hard to me to think about center align
* is "roundf" and "rint" do the same job? why using both?
* we may also do the same for width, for coherency.
* if accepted, think about updating the panel renderer (m_drawutil.h) to compute it like the patch do with the spinner. Any problems with draw buttons?
====== ernieball (2008-11-24 16:20:16) ======

hi bayo; roundf is almost the same as rint, but x.5 goes to x+1 instead of x (chose that by try&build for an issue at 960x720, it wasn&#039;t a teorical choice);
As for the alignment, up and low are ok, center should, as far than we guarantee the (normalized) height remain the same by rounding it before being added to y1 (to get y3), and rounding y1 itself after that. in other words, center alignment will be short (using rint) or long (using roundf) of 1 pixel, but no problem if that happens for each widget, not depending on its top position.
Sure we can do the same for width and maintain aspect, in general glitches dont happen because most lists are vertical, however it&#039;s a matter of tastes :)
As for gl_nearest, it is already used default for applying textures (instead of gl_linear) and it works right (well it wasnt designed to draw pixel-correct uis, so its rounding calculation, which is indeed correct, doesnt give the desired result).


====== ernieball (2008-11-26 01:49:24) ======

fix graphics at lower resolutions
====== ernieball (2008-11-26 01:50:15) ======

fixed textures for small buttons
====== ernieball (2008-11-26 01:50:34) ======

fixed textures for big buttons
====== ernieball (2008-11-26 01:59:57) ======

i added a new version of the patch (targeted at trunk) and two fixed pics for the buttons following bayo suggestion about MN_DrawPanel:
* the new pics are the same, but alpha channel is 0,0,0,0 instead of 255,255,255,0 (made glitches with blending and gl_linear when scaling down -> light pixels around edges)
* changed DrawNormPic (rounding by hand to avoid gaps between adjacent tiles, apply it to both x and y axis to keep aspect); DrawPanel, m_node_windowpanel and m_node_spinner (changed rendering order) in order to render (almost) correctly at lower resolutions;
* fixed load game menu button heights to be the same of save game menu
====== bayo-fr (2008-12-12 13:48:50) ======

Thanks a lot.

For the moment i just apply the textures to the trunk. I agree with your code patch, but maybe the panel computation is a little too much complex (its now more than an util; it use round and viddef). I have no idea for the moment (maybe it need at least a merge and a move to the render code, waiting improvment if possible, but out of the menu).

If you agree, i can apply that for the spinner and draw; and thinking a little more for the panel.
====== ernieball (2008-12-12 15:31:06) ======

hello bayo, please do whatever you want with it; consider that the pics with the modified alpha channel fix the most noticeable glitches; the changes to spinner and window panel are maybe very minor issues (the latter in particular)