I'd like to add an extra button to the build menu. Is there a way to display an image on top of it? I tried to use SetImagePositionZ, but to no effect. Screenshot showing the problem is attached.
My map idea would also benefit greatly from the ability to make that work. Though I think I'd need to set the images over the existing ones to make enough room. Doing that would likely cause problems clicking two units at once, but it's an easy enough fix if you lock out the unit on the bottom.
Whether support for this is added or not, I would be immensely grateful if someone could toss me the green and red unit background pictures without any information on them. A base for any custom units made. I could color a block green, but there's a subtle shading in these images that I couldn't capture in a month of my own effort.
Hmmm.
That menu bar is rendered using a different 'camera'. So there is no way to get a game element on top of it. It's hard wired to draw on top of everything else (other than things draw using the same camera, like popup messages and such).
The only option is to add you buttons to the right, left, or top of the menu box. You could put another small button box on either side or in a row above where the spore notification appears.
Alright, a box to the side works, too. In a related question: what is the font type used for the build menu icons?
Tempesta and Aldrich at the two fonts I use in the game (other than Arial for the 'gray' gui elements like scores, dmd, Colonial Space). Radio Stars is used for the very largest fonts in a couple places.
I think tempesta is the smallest I use. Note that they the font is loaded up into a texture atlas and a black shadow is added. That atlas is then used to for drawing the fonts. If you are making an image by hand and just need it to look the same, you can use the attached atlases to pull the characters.
Using the Tempesta font I made two images of the same button. One with a green background is displayed by default. The other one with a gray background is shown when the mouse cursor is above the button. Except for the background, both .png files are identical.
The two .jpg images are screenshots of the added button when left alone (green background) and when the cursor is above it (gray background). If you look closely you can see that the 'd' is displayed differently. Any idea why that happens? Both images are in 64x64pp slots and scaled by a factor of 2.667.
Try moving the image coordinates by 0.5 in each direction (plus and minus for each at the same time in different combinations). See if that makes a difference. If it does, let me know and I'll have more to say... :)
Moving the images or the entire core to the left by 0.5 does the trick.
Edit: A full pixel to the left works, too. Nothing when going right, so far.
Ok.... yeah, I know what is going on.
It's a sad tale really: http://drilian.com/2008/11/25/understanding-half-pixel-and-half-texel-offsets/
Now, yes this means that you need to use the half pixel offset when running under directx9. "No problem" you say, "that's what the game is set to use". Problem is, that isn't true on OSX and linux (they use opengl). I have code like this stuck around in a few places:
if (needsHalfPixelOffset) {
v.x -= 0.5f;
v.y += 0.5f;
}
And needsHalfPixelOffset is based off of the platform the game is running on.
So, what to do....
Minimally I could provide a CRPL call to get the runtime platform. Then you'd have to check if it is windows and apply a half pixel offset yourself. Next step up would be an API that return a bool on whether to apply a half pixel offset. Up from that would be an API that applies the half-pixel offset (only if needed), and lastly would be some magic that makes this happen all by itself.
The problem with magically doing this is that it sounds like a bad idea to always try to do it. That would probably break things. It's only necessary when trying to achieve pixel perfect rendering of certain images. So there has to be a setting for whether to do it or not. But a core can have N images, so the setting shouldn't be per core it must be per image.
I'll work something up later today and try to get a new build out tonight. I have to do a whole new general release this week anyway to fix the problem that affects the Ruine mission...
Try setting the scale to 2.6667 (add a bit more precision) and leaving the offset at 0. Does that work?
Yes, that works way better than 2.667. The font now matches the one on the build menu buttons perfectly.
Yeah we can skip this nastiness with half pixel offsets. I already some of that internally I just didn't remember if it applied to these images or not. When I was playing with it I noticed that a wee bit more precision on the scale would fix the problem you were seeing.
That'll teach you to short-change your decimals instead of using div(64.0 24.0)! :)
Quote from: Grayzzur on February 10, 2014, 08:02:46 PM
That'll teach you to short-change your decimals instead of using div(64.0 24.0)! :)
Ahah! That's pretty funny, and cool. But you could just as easily use "8.0 3.0 div ->pixOffset" with no accuracy lost :P
Quote from: Grayzzur on February 10, 2014, 08:02:46 PM
That'll teach you to short-change your decimals instead of using div(64.0 24.0)! :)
But... but... that's two additional opcodes! I was just trying to be economical :)
Quote from: Flabort on February 11, 2014, 12:19:07 AM
Quote from: Grayzzur on February 10, 2014, 08:02:46 PM
That'll teach you to short-change your decimals instead of using div(64.0 24.0)! :)
Ahah! That's pretty funny, and cool. But you could just as easily use "8.0 3.0 div ->pixOffset" with no accuracy lost :P
True, but 64 and 24 have more meaning. At a scale of 1.0, images display at a size of 24 pixels on a fully zoomed map. In this instance, he's trying to make a 64x64 image display at 64x64. 8/3 and 64/24 are the same mathematically, but 64/24 tells me what I was doing when I'm looking at the code again a week from now.
As for economical, I'd create and store some useful constants like this in variables (like Flabort did there) up in the once/endonce block and use those.