Sprite Editor

[The Big Mc]

Martin why would some one make an animated tile gif

[Immortal Wombat]

Not animated, but gifs can have transparencies that might be useful for tiles.

[The Big Mc]

it will be really great when we can use this program rather then the dos compiler looking throw the sprites already is making my mouth dribble let alone the alleged handing over of source code

i did some concept art on units as well as some units generated just by changing the hue of the ctp unit

[Martin the Dane]

Martin, where on earth did you get that sprite???

It apears to be a v 2.1 unit sprite, so I'd like to talk to whoever created it, and ge hold of that sprite-generator.

From what I have been able to figure out this format is close to version 2.0 (wich makes sence) but with enough differences to be quite pain in the lower backside. My first priority will be to fik the crashes-on-errors, and get some usefull error-messages in stead. But I've had enough for now, so I'm of to bed.

Good night

[Immortal Wombat]

Ah, it's the EB Zulu warrior sprite. There'll be another one like that as well, the javelineer. We don't, (as far as I know) know anything about their creation process: whether EB artists (?) made them, or sponsered Activision to make them later on. But the art is very similar to the Activision units, so I guess they were working closely, or EB put some serious manpower into it. Either way, I don't think either we need to worry about it too much (We can guarantee only 2 sprites are affected) and secondly, I don't rate your chances of getting hold of their sprite generator, which may be a later Activision one given to them.

[Martin the Dane]

Ok I'll skip, it implement som sensible errorhandling (like checkking the version befor attempting to load anything), and then go on with the more important aspects of the project. Then if I feel like it at some point I'll take a look at it again.

Now I realy have to find that bed of mine, my phone might wake me in less than 5½ hour and if so I'll have to be rested.......

[The Big Mc]

Martin I have been testing the latest version for you but can't seam to get the run command working it worked on the first version but not this one

also love the quick load box with all the spr files in the directory do you think you could get it to load using the keyboard rather then clicking with the mouse

[Martin the Dane]

Ok here comes build 4.

Seems like I managed to break as much as I fixed between build 2 and 3, so let's hope I've managed to fix it again this time. (What was it MrOgre said about debugging and adding features )

So what has changed?

1. The animations now plays again
2. Fixed the craches on load, now you should get an inteligable error message.
3. Added invers-shadows, so the shadow color is the invers of the background.
4. Added display of seperate and combined Pixel, Mask, and Shadow.
5. Sprites can now be loaded from the list by key-board bot in single and double-click mode. ([space-bar] and [enter])
6. Saved BG and SH colors (ini-file) are now reflected on menues.

I've also added a few things on the options page, but they have no effect until I get the export working, wich is my next task.

I don't think I mentioned earlier, but on the Options page there is a checkbox that affects the way the file-list acts. It can auto load the selected file or let you scroll through the list and load when you either double-click or press [enter] or [space-bar]

[The Big Mc]

nice one

[Martin the Dane]

Ok I have a question for all you potential sprite-artists:
How do you prefer to work with the individual frames of the sprites?[list=1][*]Thre seperate images - one for each colored pixels, shadow and transparency mask.[*]Two files - one for colored pixels and tranpsarency mask in alpha chanel, and one for shadows.[*]One file, color pixels with mask in alpha chanel and shadow being a specific color in same image.[/list=1]
I'm not sure what would be the easiest option for me, I think the two-file system would be most natural for historical reasons. But I'll go for whatever is the prefered option for most artists. (I might even allow two or more options).
As for export I now have the exports available for all three options. Need to implement them into the interface, and do some error-checkking, but I have most of the coding for it done.

[Immortal Wombat]

Hmm, yeah, I was about to say two files out of habit, but one might be easier to keep track of. I usually make the image and shadow in one file anyway then separate them.

[Maquiladora]

When i did some sprite work i used the same method as IW, selecting the shadow then cut-pasting it out. That would make one file easier.

[The Big Mc]

As long as you can chose the colour and split the shadow one is good

I also have a question what you doing about sprite hot points like in the original compile you could set a point to be the hot spot it would be good if you could get this spot on before playing it in ctp

The second point is are you going to add example terrains to this I would be happy to sort the graphics out for you. so lets say for example you can test your new unit on all the bog standard ctp terrain to see if it is still visible

[Martin the Dane]

Seems the consensus is one file.

Originally posted by The Big Mc
I also have a question what you doing about sprite hot points like in the original compile you could set a point to be the hot spot it would be good if you could get this spot on before playing it in ctp

I'll get to that later, for now I'm concentrating on getting the Graphics part up and running, but I'll have to have hotpoints and fadeing implemented before making save-srpite available, or the sprites won't play in CTP.

Originally posted by The Big Mc
The second point is are you going to add example terrains to this I would be happy to sort the graphics out for you. so lets say for example you can test your new unit on all the bog standard ctp terrain to see if it is still visible

Yes I'm going to add the option of having background images, the paint-methodes I use for the sprites support it, I just haven't figured out the best way of implementing it yet.

I was thinking of loading the terrain from the .til-file. It would however be much easier (for me ) if someone would make a number of equal-sized terrain-images and save them as a long rectangular .bmp, with the terrains side by side.

Taking the terrain from the .til file would require a lot more coding, most of that would probably be cut-n-past, but anyway.
In either case the background graphics would be stored outside the .exe, and loaded at startup, or on demand.

[Immortal Wombat]

.