Getting rid of the health bar!

[Mercator]

Mr. Oobir and Boco gave me a little stroke of genius, and I figured out a way to hide the health bar!

I have to be a bit careful, because I haven't tested it yet...

PRELIMINARY 1: In the sprite files, the unit images don't need to be 64x64 pixels. In fact they can be just about any size you want.
PRELIMINARY 2: The sprite image is always aligned to the left and bottom sides of a square (in the attachment:against the pink lines for the Engineer). So if you make the sprite image any larger it'll expand to the right and up.
PRELIMINARY 3: The health bar is always positioned centred at the top of the unit icon.

In the attachment I changed the height of the Engineer (in the Static.spr) to 64x128 (twice the height). And as you can see, the health bar is located twice as high (compared to the normal height of the Warrior).

I had hoped this would be high enough, so it wouldn't be painted, but alas! But then I started thinking... If you can make it twice as high, why not make it 1000 times higher? That way the health bar will fall off the top edge of the entire map!

Moreover, the .spr files are encoded in such a way that leading empty lines don't make any difference at all in filesize. The only thing that changes are a few numbers that say how many leading empty lines there are!

There is some (minor) bad news though:
(1) This method won't work in the units.bmp. But then it DOES work for the static.spr, and you can edit that fairly easily with CivSprite.

(2) Since you can so far only use CivSprite, each unit needs to have 5 images (for 5 different angles). You can simply use the same image 5 times, but the static.spr file is slightly bigger than the units.bmp (and much bigger when both are zipped)... But if you use the same image for all 5 angles there won't be much difference even when you zip them up (the zipped up sprite file might even be smaller).

(3) For sprite files the height might not matter, but for bitmaps it certainly does! Since you need to use CivSprite you have to make the images as bitmaps first.
The image should probably be some 10,000 pixels high, which means a filesize of almost 2MB per bitmap!
Then again, people have gigabytes of harddrive space anyway, and you can get rid of the bitmaps once you created the sprite file...

In other words, there's nothing to worry about. Get busy!

[Boco]

aw shhhhiiiiitttttt! Mercator yer the man! I'm gonna hump your leg for this one!

[techumseh]

Mercator, you may have revolutionized ToT. I salute you!

Getting rid of the health bar has been a hope of mine ever since I decided (belatedly) that ToT was the ultimate vehicle for scenario making.

I've broken down the static sprite using CivSprite. There are 405 bitmaps of the units (5 views each X 81 units), plus an equal number of masks. If you leave the Static Spr. in the main (or scenario) directory, you will play the game with 5 views of each unit, as opposed to the 2 views from using the Units bmp. file.

This is much more manageable than trying to modify all the unit sprite files, each with dozens of images and masks, and a wide variation in the number of images for each unit.

So if one wanted to make a scenario with units with 5 views of each unit and have the units incorporate national colors, and permit some (or all) units to appear without those obnoxious ToT health bars, now it is possible!

Viva Mercator!

[techumseh]

Here is a conversion of the 5 views and 5 masks of the helicopter unit from ToT. It's converted to the standard FW/MGE palette in Gif format in order to meet the file size limitations of 'Poly, so it may be a little grainy.

The white parts of the masks are those portions which appear in the national colors of the Civ which owns the unit.

Test of Time automatically provides mirror images of the 2nd, 3rd, and 4th images (and masks), when the unit is moving towards the left of the screen. Therefore, there are 8 total views per unit using the static sprite as opposed to the 2 views (L and R) of the units bmp.

I believe this is a major step forward in graphic potential for Civ2. Congrats, Merc, Boco, and Mr. Oobir!

[Boco]

Using Static.spr has the added advantage that you can make sure flags/shields are in the correct orientation when images are mirrored.

Shoulda looked at CivSprite long ago! What a gem! I see a few options with the unit key now.[list=1][*]Make it disappear by Mercator's towering-sprite method. Perfect for impassable terrain, bridges, mines, and other such units. Maybe not so good for standard combat units.[*]Lower it to the top of currently existing icons (i.e. MGE scale icons). It looks as though with most units posted on the forums, that the unit key could be lowered about 6 pixels. That's actually not so good - it lowers the key to the middle of the square above. If you have an unusually short image, however, you can place the unit key in the same square.[*]Raise it to a less invasive portion of the square above. It's more removed from the unit it describes , but at least it doesn't obliterate its neighbor above. I'll experiment with this one. [*]Use the unit's mask for Civ-coloring, not the unit key. This gets rid of a chunk of the unit key and avoids the grayed colors that ToT insists on using in the key. Do I understand this right?[/list=1]

Did I miss anything?

What happens if the mask and image are different heights? If that's allowed, it might open things up even more.

[Mercator]

Ahem... I've now actually tested it, and it doesn't quite work how I hoped it would...

While I thought increasing the height into the thousands would make the health bar disappear, it also makes the unit icon disappear.
With lesser heights (of some 700 pixels extra) the health bar can be seen in more zoomed-out levels, a few dozen squares up. And when zooming in more, again, the unit icon disappears. In standard zoom though (and one or two zoom levels either way) the unit is visible and the shield is hidden from view, off the screen (invisible enough for me ). You won't see the shield when you scroll up either, because then the unit would disappear off-screen and it (along with its shield) won't be drawn in the first place.

I've made a little new application, which can automatically generate a static.spr from an existing units.bmp. So far, this can NOT use the masking, NOR the multiple facing directions, and I've used a fixed shield "distance" (you can select which units should have a hidden health bar). And more importantly, this file CANNOT be edited by CivSprite. The file is considerably smaller than a regular units.bmp though.

Is that good enough for you? Or would you rather have an editable shield distance, and all facing directions etc?

In any case, you can already use CivSprite to do everything. But my new utility would save you the trouble of adding extra pixels to the top by hand, and copying images for multiple facing directions. In fact, it actually uses 1 image per unit rather than 5 times the same image, which is why CivSprite can't load the created file (and also why the file is much smaller than a units bitmap)...

Using Static.spr has the added advantage that you can make sure flags/shields are in the correct orientation when images are mirrored.

Not really, since the static sprites also use mirroring, so all the left-facing units would also have mirrored flags.

Use the unit's mask for Civ-coloring, not the unit key. This gets rid of a chunk of the unit key and avoids the grayed colors that ToT insists on using in the key. Do I understand this right?

Except that the "action letter" also needs a place. Do I understand you right?

What happens if the mask and image are different heights? If that's allowed, it might open things up even more.

Not possible. In sprite files they're actually just the same image. Basically, every pixel has four properties (R, G, B and civ-colour), rather than the usual three (R, G, B).
I had to use two different images because I don't know how else to do it (except perhaps using image layers, but that's only possible in more complicated and less widely supported file formats).

[Boco]

Forget it, I'm going to look for another leg!

Jumped to a few wrong conclusions. I didn't look at Tech's image closely enough to see that mirroring still occurs with Static.spr.

Except that the "action letter" also needs a place. Do I understand you right?

Think so. I'm aiming to edit my unit key so that it only contains the action letter background and the health bar surrounded by a 'Mercator meter'. Remember ToT represents anything that's 255,0,255 in the unit key area as a modified civ color. It looks like the civ color is blended with a 64,64,64 mask. Ugh!

So, it looks like I can use masks in Static.spr to introduce a civ color emblem somewhere in the unit image (a kinda Civ2 FW retro feature). Is this right? If a mask pixel of a unit sprite is white and the corresponding image pixel is 255,0,255, then ToT will show the pixel as the unmodified civ color.

I've made a little new application, which can automatically generate a static.spr from an existing units.bmp. So far, this can NOT use the masking, NOR the multiple facing directions, and I've used a fixed shield "distance" (you can select which units should have a hidden health bar). And more importantly, this file CANNOT be edited by CivSprite. The file is considerably smaller than a regular units.bmp though

Uh-Oh! That dumb feeling is coming back. How do you hide the health bar?

The utility sounds great, except for the lack of masking. I think I can live with a fixed shield distance, especially if I can hide the health bar on only 3 units. I seriously doubt I'll be using multiple angles for any of my units.

[Mercator]

Originally posted by Boco
Forget it, I'm going to look for another leg!

'Mercator meter'

Uh-Oh! That dumb feeling is coming back. How do you hide the health bar?

Um... that's what this thread is about (health bar = unit key = shield), changing the height of a unit to something high (640 seems to do nicely) will keep it out of view.
My utility would simply allow you to tick checkboxes for which units you want to have an obscured unit key.

The utility sounds great, except for the lack of masking.

I guess I could add the possibility to use a second "mask bitmap". One that would look exactly like the units.bmp, except that the unit graphics would be black and white (just like the mask images for CivSprite).

I think I can live with a fixed shield distance, especially if I can hide the health bar on only 3 units.

Yes, I thought so... In principle it's a nice idea to be able to place it at any height. But you can pretty much only move it up (and to the right), and that really isn't good for anything (except move it up so far it disappears).

I seriously doubt I'll be using multiple angles for any of my units.

I thought so too... It would be lovely, but most of us aren't even good enough to create a decent graphic for one view. And if someone does need more angles, CivSprite does the job just fine...

The main advantage of this new utility would be (1) automating the height adjustment, (2) allowing you to work with one bitmap, rather than 1 for each unit, and (3) reducing the size of the static.spr.
3 is irrelevant if you need more angles anyway, and 2 is mostly just a matter of principle... The biggest objection to 1 was the file size of the bitmap (point 3 in my inital post), but that is much less the case now, since the height isn't in the thousands (some 2MB), but in the hundreds (max 150kB).

[Boco]

Mr. Beta is ready when you are!

As I see it now, I think I'll be using the same mask for all units.

I tend to split my time between standard and max zoom with occasional forays into medium zoom.

[Mercator]

How about this...

Select a units bitmap... Only 24-bit bitmaps work, so the original 16-bit bitmaps won't work. Opening and resaving those with your favourite image editor will probably convert them to 24-bit.

Anyway...
(1) select a units bitmap (type in the path or use the browse button),
(2) Check the checkboxes (the 9 by 9 "matrix" corresponds with the unit bitmap order),
(3) click OK and a file called static.spr will be created in the same directory as the unit bitmap you entered (if one already existed a backup will be created). It'll take a while, but a pop-up message will appear when it's done.
(4) exit by clicking "Cancel".

By the way, with this utility you can't use masks, you have only one image per unit and the resulting sprite file can't be edited by CivSprite.
To hide the unit key, the number of empty lines at the top will be increased to 640.

EDIT: new SpriteGen version.

EDIT2: newer version again... But this time I only changed the readme. I added information about transparency.

BTW, SpriteGen is also available at my utility site:

http://www.civgaming.net/mercator/mapedit

[Boco]

It worked but...

SpriteGen created a static.spr on my PC without mishap. I created the Static.Spr in my scenario directory and copied it into my ToT/Original directory. When I loaded a file from my scenario directory ToT didn't use the Static.spr, or at least the unit keys were all in the same location.

Btw,

(2) Check the checkboxes (the 9 by 9 "matrix" corresponds with the unit bitmap order),

nice & elegant.


Ill post the zipped Static.Spr next.

[Boco]

The zipped Static.SPR

[Mercator]

Re: It worked but...

Originally posted by Boco
When I loaded a file from my scenario directory ToT didn't use the Static.spr, or at least the unit keys were all in the same location.

Yes... This actually also happened with my testing, although I kind of ignored it. When trying it with Kestrel's Multiverse scenario it didn't work, for the Original game it did work though.

Is there a units bitmap in the same directory? Try removing/renaming it, or perhaps make some changes to its graphicsso you can see if the scenario uses the bitmap or the sprite.
And also check the sprite usage settings, in the graphics options and the scenario special rules, to make sure animations etc. are turned on.

I'll have to look into this a little bit more myself too...

[Boco]

It's using the BMP. When I removed my Units.BMP from the scenario directory, ToT used Units.BMP from ToT/Original. Animated units are checked. Created a new scenario with .SPR overide set to 0 instead of 1. ToT still used the Original Game Units.BMP.

[Mercator]

Damnit! That's no good...
Oh... does it work if you use the standard static.spr? (probably better use one from, say, the sci-fi game, so you can see the difference with the original graphics it falls back on)

If that doesn't work either it's not my fault ( )... Then it would come down to the civ2 sprite settings.