SpriteGen 2 teaser/release thread

[Mercator]

I started working on the second version of SpriteGen, a utility that can generate a static sprite file from a units bitmap.

It's main use so far was hiding unit's health bars. This next version will have two new features:
- You can set different unit heights for each unit individually.
- You can let it use a mask image, so parts of each unit can be painted in the tribe colour.

I've only done interface so far, so it can't actually do anything yet. I should be able to re-use a lot of my earlier code, though.

Here's a screenie...

You see the unit on the left (you can browse through them with the scrollbar), the properties on the right can be set for each unit individually.

Any comments so far?

[Boco]

You had to ask!

Just a few opinionated suggestions.

• Scrolling through the list might become tedious. I'd be more than willing to do it to get the sprites, but why not use your very intuitive SpriteGen 1 interface? The option button determines the icon. If you eager to use the scroll bar, perhaps make it bigger and set LargeChange to 9.
  
• The mask checkbox toggles the enabled or visible state of the dropdown. The initial value for the dropdown is the ToT default.
  
• Use your icons not these buttons (this mockup was made in Excel).
  
• Is the magnifying glass to find a file or an icon from the @Units listing? The latter is nice, but unless you already have the code, its IMHO not worth the effort.

Hope this doesn't stir it up too much.

[Oops! First post was too blunt and stated opinion as fact: would be -> might become.]

[Mercator]

Re: You had to ask!

Originally posted by Boco
Scrolling through the list might become tedious.

That's what I feared...

I'd be more than willing to do it to get the sprites, but why not use your very intuitive SpriteGen 1 interface?

Being able to set height and use mask for each unit individually makes it rather difficult to maintain that interface. Unless you don't mind 81 checkboxes and drop-down lists. But that wouldn't look very appealing, and I want my utilities to look good too!

Oh wait... you're using radio buttons in your mockup...

The option button determines the icon.

If I maintain the original interface, the icon woldn't really be necessary. I'm only using the icon here, because that's the easiest way to identify the units with the interface I'm now using.

If you eager to use the scroll bar, perhaps make it bigger and set LargeChange to 9.

That's already the case, the LargeChange, that is.

The mask checkbox toggles the enabled or visible state of the dropdown. The initial value for the dropdown is the ToT default.

Judging from your mockup, you misunderstand what the mask is. The mask is what can let you add civilization colours to a unit, using a separate mask unit bitmap like what CivSprite does... What Catfish did here: http://users.tpg.com.au/jpwbeest/ (second image)

The height checkbox toggles the enabled state of the dropdown.

Is the magnifying glass to find a file or an icon from the @Units listing? The latter is nice, but unless you already have the code, its IMHO not worth the effort.

No, it's the standard "Preview" icon... You can preview the mask with it. Not quite like what you would see in ToT, but it'll overlay the civ colour mask over the unit image... In case you want to make sure the mask matches the unit.

About the mask, what I'm thinking of now is that you have to create a separate mask bitmap. That one should look just like the ToT units bitmap, except the spaces for the unit icons would be black and white masks, like what you get with CivSprite.

I think it's easiest if the mask is simply a variation on the units bitmap filename (e.g. Units.bmp vs. Units-mask.bmp), so SpriteGen can automatically locate the separate mask bitmap.

Hope this doesn't stir it up too much.

That depends, are my arguments convincing enough?

[Sava]

looks good Mercator

I'll be looking forward to the finished product. Keep up the good work.

TOT 4EVA!

[Boco]

The village idiot speaks again.

Judging from your mockup, you misunderstand what the mask is.

Must never post before morning coffee again! Yes, I was reading mask but thinking sprite. That's also why I didn't catch on to the preview icon.

Oh wait... you're using radio buttons in your mockup...

Yeah I was thinking, select the icon with the radio buttons, then update the single dropdown with the appropriate selected value. One dropdown, one icon (not really necessary, as you point out), but many radio buttons. Although it reduces the icon selection process to a single click as opposed to many scrollings, it still doesn't provide an instant icon height summary for all units. Maybe, on the option buttons' captions.... Nope, that doesn't help to summarize the mask settings.

Time to shut up. Truth is, I'd be very grateful to use just about any interface to manufacture sprites.

[Mercator]

I guess I better get started then... I haven't done anything today (designing the interface is the most fun part).

[curtsibling]

Good luck!

This facility may revamp ToT completely!

[Boco]

After finalizing my units (ha! ), I decided to give CivSprite a run. It's working very well , but it's slow going. My Static-nnn-img.bmp files have ranged in height from 48-64, then 640. About a third use masks. Many thanks, Merc.

Yeah, I think we may start seeing AFV's from all angles soon.

[Mercator]

Originally posted by curtsibling
Good luck!

This facility may revamp ToT completely!

Thanks... (I haven't done anything more yet)

I don't know about revamping. I already heard that with CivSprite and the first SpriteGen, and it's only starting to take off now.

Originally posted by Boco
After finalizing my units (ha! ), I decided to give CivSprite a run. It's working very well , but it's slow going. My Static-nnn-img.bmp files have ranged in height from 48-64, then 640. About a third use masks. Many thanks, Merc.

Great... CivSprite is far from perfect either, but updating that would take a hell of a lot longer than SpriteGen...
SpriteGen creates far more compact sprite files too (because it only uses one angle). So when its new version sees the light, you might want to recreate the sprite file.

Yeah, I think we may start seeing AFV's from all angles soon.

[Catfish]

Mercator, one thing I noticed about sprites generated using the current version of SpriteGen, is that they appear superimposed on fortresses.

The screenshot on the left shows four sprites generated using SpriteGen for Curt's Bitterfrost scenario. The one on the right (and you might want to fetch yourself a bucket before viewing this) shows sprites from the Sci-Fi (I think - I've got 'em all jumbled up) game.

Originally posted by Boco
Yeah, I think we may start seeing AFV's from all angles soon.

Five orientations. *cough* 3-D models. *choke*

[Mercator]

Yikes! That won't do (not unless I can turn that into an option anyway).

How does that work with the sprites you created with CivSprite, Catfish/Boco? Is there any difference between "normal" units, and those with their shield hidden?

[Catfish]

Sorry, I should've looked into it further. No, it appears to be just the ones with the hidden health bars. The others (for both SpriteGen and CivSprite) appear fine.

[Boco]

My CivSprite-derived sprites had the same problem with both Fortified status and Fortress. Virtually all of my sprites have altered heights, and the Fortified overlaying bug seems related to the difference between the icon height and 64. Placing the Fortress icon higher in its square within City.bmp can optimize the icon for sprites of a particular height. That helps a little, but its no panacea. Only way to really fix it is to have all sprites of uniform height, and then adjust the Fortress/Fortified icons accordingly.

In this shot, the cavalry sprite is 55 pixels high, the camelry is 61, and the Ford weighs in at 45. None of my 640 pixel sprites show anything when fortified. The Fortified icon (barbed wire) has been raised 3-4 pixels in city.bmp.

Since most of my sprites are around 50-55 pixels tall, the benefits outweigh this bug. It helps that I'm using stackable terrain in which the Fortress icon doesn't play an important role. I really like the masking feature your sprite editors give.

[Catfish]

Originally posted by Boco
Placing the Fortress icon higher in its square within City.bmp can optimize the icon for sprites of a particular height. That helps a little, but its no panacea. Only way to really fix it is to have all sprites of uniform height, and then adjust the Fortress/Fortified icons accordingly.

Are we talking about the same thing? I don't believe so. I'm talking about the sprite "layer" being superimposed on the fortress "layer" - a z-axis issue, is the best way I can put it. You are describing a y-axis issue.

I believe that the fortress and fortify issues are separate. The disappearing fortify icon is a new one to me – the only units for which I've ever altered the heights have been immobile terrain/item types which don't fortify. Investigating it briefly myself: the fortify icon is actually dragged around with the unit key. Fortunately it's not a big deal for me because of the category of units I generally use with SpriteGen. It will be a tad unsightly for units with slightly varying heights (as in El Aurens). I'm sure Mercator will have a crack at figuring something out.

The fortress issue (from my end, anyway) appears to affect only those with the health bar raised using SpriteGen (yes, they do have non-standard heights). That's the only conclusion I can draw at the moment. You'd have to investigate differences between the two formats - in addition to height.

[Mercator]

You're both definitely talking about the same thing, though different aspects of it. I'm afraid I can't fix it.

The screenshot below should say a lot. I adjusted the unit height to 128. I, ahem, improvised the fortress graphic a bit so I could see whether it overlapped the unit or not.

It seems the fortress is drawn twice. Once when the terrain is painted (the one that is actually on the right square), then a second time along with the unit (64 down from the top of the shield). That second one overlaps the unit, and that's also how it shows up on the status window.

The difference with the fortify graphic, is that fortifying is only a unit property, while the fortress is really a terrain property. That means the fortify graphic is only painted once, along with the unit, as per the second time for the fortress.

So it isn't really that the sprite is suddenly on top of the fortress, but rather that the top fortress has disappeared, revealing the bottom fortress which you normally wouldn't see (except on squares with no units on it, but in that case you won't know it's actually a different one).

I tried to see if I could use a different approach for hiding the shields by increasing the unit width rather than height. If the shield were centered at the top that should also make it disappear. But unfortunately the shield doesn't move.

So, bad luck! Unless one day someone hacks the executable and changes the fixed fortress/shield dependence to a variable one, based on the unit height. I guess they weren't expecting anyone would crack the sprite format.

Bad Microprose, Bad!

*smacks Mick Uhl and John Possidente on the head repeatedly with a sprite*