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]

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]

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.

[Mercator]

I found out a little more about all the peculiarities...

The static.spr didn't work at first with Multiverse. But after some testing it appeared that the static.spr WAS being used for the units that also had a unit animation sprite file (unitNN.spr).

But then I saved the scenario again in a new folder, and lo and behold, it used the static.spr. That folder did not have a units.bmp in it, and unit animations must be turned off.

Another thing. If a unit sprite icon is higher than 512 pixels it will disappear from the maximum zoom. The higher you make it, the more zoom levels it will disappear from. When a sprite is higher than 1024 pixels, it will also disappear from the standard zoom (it will still be visible if you zoom out more).

The only problem there is, at 512 pixels high (using the standard screen layout and a screen resolution of 1024x768), the unit key is still visible. That is, for a unit at the very bottom of the screen, the unit key will appear at about 2 squares from the top.
So there isn't really a way to make the unit key invisible at standard zoom and still have a visible unit icon at maximum zoom...

[Boco]

Thanks for doing all that testing. When I have a chance, I'll save the scen in a new folder without a Units.bmp (and no UnitXX.spr's either). ToT has an eccentric memory!

(Thanks to the Scouse Gits for the smilie)

[Alinestra Covelia]

This sounds really good! I'll have to try this out and also give a BIG THANKS to Mercator!

[Mercator]

Here's a new version... You now have several options as to what unit height you want.

I updated the previous attachment, here's a link to it.

[Boco]

Many thanks. I'll try to give it a whirl soon, but RL may intervene a little.

[fairline]

Fantastic work Mercator. When Civ Sprite originally came out I toyed with idea of making some sprites up, but it was far too much like hard work. Now the 5 angles without animation in the staticsprite file look much more manageable. mmm.... *reaches for PSP*

BTW do you know of any way of changing the code that reverses the 2nd, 3rd and 4th frames and allows you to use 8 individual frames for static sprite? I'm thinking the reversed unit flag effect, here.

[Mercator]

Nope, there's no way to change that...

I'm not sure what happens if you remove both the units.bmp and static.spr from your scenario directory though.

It would then likely use the standard Original graphics, but just maybe it uses the Idle animation graphic. The animations do have 8 different angles.

[Boco]

But then I saved the scenario again in a new folder, and lo and behold, it used the static.spr. That folder did not have a units.bmp in it, and unit animations must be turned off.

I tried to do this and it didn't work for me. It's getting me more than a little p1ssed off. Trying it when I'm tired and impatient doesn't help, but it shouldn't be so hard to make ToT recognize the new file.

Can someone who has gotten this to work write an idiot's guide, an explicit list of things to do? What is in your scenario folder? What is missing? Is there a particular sequence to follow when you start with an existing scenario containing no static.spr file? What settings do you use for the following?

(1) Game|Graphic Options|Animated Units
(2) Cheat|Scenario Parameters|Edit Special Rules|Unit Animation Lockout
(3) Cheat|Scenario Parameters|Edit Special Rules|.SPR Override

Can I assume that the ToT and Original folders have no spr files?

[Mercator]

Just a few quick "hints" first. I'll re-try the whole thing again later, I played around with the options so much last time, so I'm not sure what exactly did it...

Animated units must be turned OFF (this turns off the use of the unitXX.spr files).

The lockout options in the cheat menu do only one thing. They disable the related menu item in the game menu (and consequently, it fixes that setting for the scenario to whatever it was when you locked it out).

So ideally, you turn off unit animation in the game menu and then set the unit animation lockout to 1. That way unit animation will always be off for the scenario, even for people who usually have the animation on.

The sprite override must be OFF (zero), since this option disables the use of all sprite files.

In my ToT, there are no spr files in the main ToT folder. I didn't move around any sprite files, so those in the Original folder are still there.

[Boco]

D**n. Did all these things and ToT still used the Units.bmp of the \Original directory. That ToT art is hideous against a backdrop of current SL art.

Would it help if I sent you the scenario?

[Mercator]

Still didn't look any further...

Yes you could send it. I don't know if my return will be very speedy... But in principle you'd only need the graphics when you release the scenario... right?

[Boco]

Hmm...Time to show more ignorance. I'm assuming that the SpriteGenerated Static.spr (SGSS) is fine. I'll test later by putting the scifi static.spr in my scenario test directory.

If the SGSS is okay, then something with ToT is interfering. In my simple mind, this bulldogged insistence to use the \original\units.bmp could arise from (1) something embedded in the SCN file, (2) a ToT config file somewhere, or (3) particular spr/bmp files present/missing in specific directories. I'll send you the link, and perhaps you could give me an idiots guide to making El Aurens use Static.spr.

If the SGSS is not okay, then I'll experiment a little later with CivSprite. I'd like to experiment with icons that are 10% higher than the standard ones anyway, as well as placing masks in locations just above the unit key (e.g. in the blue region of this icon).

[Mercator]

Originally posted by Boco
Hmm...Time to show more ignorance. I'm assuming that the SpriteGenerated Static.spr (SGSS) is fine. I'll test later by putting the scifi static.spr in my scenario test directory.

Isn't it better to test it by putting your SGSS into the Original directory and see if the original game uses it properly?

If the SGSS is okay, then something with ToT is interfering. In my simple mind, this bulldogged insistence to use the \original\units.bmp could arise from (1) something embedded in the SCN file, (2) a ToT config file somewhere, or (3) particular spr/bmp files present/missing in specific directories. I'll send you the link, and perhaps you could give me an idiots guide to making El Aurens use Static.spr.

I think (1) must be the case, and possibly (3). I don't think ToT really has any config files... And yes, please send a link (I don't think my Hotmail account can handle any more large attachments... I have to rearrange/download some).

If the SGSS is not okay, then I'll experiment a little later with CivSprite. I'd like to experiment with icons that are 10% higher than the standard ones anyway, as well as placing masks in locations just above the unit key (e.g. in the blue region of this icon).

You have to be careful with the unit key graphic, though... I just remembered another use. It gets a blue/green border when a unit can transport/build a transporter... Do you know how that is affected when the entire key is made invisible? That's only an issue in games with multiple maps, though.

[Mercator]

Have you come any further?

Or had you mailed me? If you did, I didn't receive it.

[Boco]

Mea culpa! I haven't checked it yet. PM on the way.