Announcement

**Pedrunn** · September 1, 2003, 13:40

Woooooooooowww!

Martin, you are a genious!!!!!
The VTP2 sprites never looked so great. Checking out those game effects (GX) filled my head with ideas!

Cant wait to make my own sprites with this tool!

I have expeienced the same problem with GX05.spr, I checked the files and this sprite is suppose to be the Eco-ranger explosion. Wich, by the way is a enourmous explosion if you remember it. But this file was the only one with problems.
And i must point out that We cant see the victory animations. you may want to check this out.

Martin, congrats and thanks. This is a amzing utility and will open doors for sprite making

Now let me check some more sprites!

**The Big Mc** · September 1, 2003, 15:35

i am looking now

**The Big Mc** · September 1, 2003, 15:58

It totally crashed my computer but it is good

The error was that I thought there was a sprite that wasn’t there so instead of looking for it I just typed the name when loading

d’oh

You got an explanation of the break down of the spr file I have been trying to work it out for a year

Pc what did you program it in with any look we will be able to make the civ 3 to ctp convert about a million times quicker

**Martin the Dane** · September 1, 2003, 16:22

The error was that I thought there was a sprite that wasn’t there so instead of looking for it I just typed the name when loading

d’oh

Is that a feature request ?

I'll add a check to make sure it doesn't try loading files that are not there.

**Martin the Dane** · September 1, 2003, 16:33

Forgot to answer this one:

Pc what did you program it in with any look we will be able to make the civ 3 to ctp convert about a million times quicker

I'm using Delphi, but I have a complete write-up of the structure of the version 1.3 spritefile, (a bit messy) with a lot of comments about v 2.0 sprites.
I'll sell it to you for say...

nah, you can have it once I've gotten it written up a bit more structured.
Didn't take me all that long, once I had the right idea that is, to work out the format. Knowing the graphics format of the til-file helped a lot.

btw. is there a v 2.0 sprite-generator around, or is there only the v 1.3 that I have.

**Martin the Dane** · September 1, 2003, 17:53

And i must point out that We cant see the victory animations. you may want to check this out.

Just checked this out, it seems there are no victory animations, The game uses the idle animation in stead. I have checked the headers of all the sprite file I have, and none of them have more than 4 animations being Move, Idle, Attack, and Victory/Death. (The animations that have the Work animation were missing one or more of the other animations.)

Victory/Death is one animation and can be either Victory or Death, not both. It's called Victory/Death only because it's called UNIT_SPRITE_VICTORY in the V. 1.3 scripts and can have a UNIT_SPRITE_IS_DEATH option. After looking through the sprites however, I think I'll just rename it Death, as I have not yet found a victory animation. Then when I get to that part of the SpriteFile I'll call it Victory if it does not have the UNIT_SPRITE_IS_DEATH options set. (It's the last DWord of the Sprite File, and I'm not reading beond the last animation block yet.)

**Immortal Wombat** · September 2, 2003, 10:01

And lo! Suddenly, there was a sprite viewer!

btw. is there a v 2.0 sprite-generator around, or is there only the v 1.3 that I have.

No, we can only make sprites in C:CtP format, not CtP2 format. CtP2 renders both.

A question (or bug, or something): currently each heading (apart from North) has to be Played before a single frame can be selected for viewing. Could it be made so that even when the animation is stopped, a single frame from different headings can be viewed?

Other than that, it looks very chinky.

**Martin Gühmann** · September 2, 2003, 10:34

Well I tried GG023.spr, and I got an "List index out of bounce (-1)" message. Of course only if I just view the sprite, if I play the sprite, I get tons of these messages and also with index 0.

Maybe you should also check if the sprite just contains one frame then no animation playing is needed.

The flickering occurs because the background is paintend first and then the frame is painted over this. The solution would be not to update this part of the screen with the background first and than paint over it the frame, but just paint the frame. I know that overwriting the according method can be a pain. I think I know how to do it in C++ MFC but know idea how to do it in Delphi.

Oh and a feature request, whenever I start SpriteEdit it should open the last directory, and if I open the file dialog box it should display the content of the last directory and not just the last sprite.

-Martin

**Martin the Dane** · September 2, 2003, 19:33

Ok I've now updated the SpriteEdit to build 2

Here's a list of what I've changed/fixed[list=1][*]Removed flicker[*]Partially fixed load bug for sprite 'GG023.spr'. This turned out to be a version 2.1 good sprite. I's a slightly different format than the 1.3 good sprite. Still need to do the anim-sequence load.[*]Found and fixed a memory-leak.[*]Added Options, menu, and a number of different Directory options.[*]Added quick-loading of sprites in the sprite-list. So now the selected[*]sprite will be loaded without double-clicking. (Option)[*]fixed a number of minor bugs, ie. the headdings bug, so now you don't have to play the animation to see different headings.[/list=1]

Still haven't found out what's wrong with the GX05.spr, it has the right version number, and the first couple of frames loads fine. But then I't goes hay-wire, and claims to have strange number of lines in each frame.

Martin, believe it or not I actually did the oposite of what you suggested to get rid of the flickker, as I was drawing the image in the background and then painting the whole image to the screen in one go. For some reason however Delphi updates the background control (in this case a scrool-box) befor doing the actual paint operation.

This defies logic, but now it works. I'm drawing directly to the image on the screen, after first clearing it, and then I draw each line, one at a time.

Just grab the zip of my site, the links are in the first post.

**Martin Gühmann** · September 3, 2003, 13:05

OK I tested the latest version. Well it loads now the good sprite in question, as mentioned the animation has still to be done, there is another sprite that makes problems, in your last version it gave me an index out of bounce error, this time I get an "Access violation at address 004614B5 in module 'SPRITEEDIT.EXE'. Write of address 01208000." error message. It is GU194.spr it comes with MedPack or Cradle. So it should be a fanmade sprite and should be version 1.3. But obviously something is wrong. Unfortunatly afterwards I clicked on that particular sprite I can't load any other sprites until I close SpriteEdit and start it again. I get only these Access violation messages with different addresses, even if I close the program.

Another rather graphical problem is that if I let run the animation and I hit Colors->Background or View on the menue bar, the pixels of the frame are replaced by a dark grenn bright green square pattern. (These two greens are part of my system colors.) To restore the actual sprite frame I have to select another sprite first and then to select it again. No problem if the animation is turned of and only these two options are affected. Unfortunatly this problem also occurs afterwards I changed the shadow or background color.

Another problem occurs with the painting if I switch to another program and then back. The sprite pixels are replaced by a very kight brown. Well the problem only occurs if I switch to Mozilla and then back and only sometimes, but often enough. If I remember correctly I also saw this in TileEdit.

Another feature I would like to see is the possibility to show just the shadows or just the pixels or just the transparency values and of course each combination. That should be possible with three additional check boxes on the main window.

-Martin

**Martin the Dane** · September 3, 2003, 16:20

I've uploaded an update to SpriteEdit to my website, and added a link to my sig, so you can as allways get it from the link there.

Finally I've found and fixed the problem with the large sprite (a DWord was saved as a Word

) and fixed the anim-block of version 2.1 good-sprites.

Originally posted by Martin Gühmann
... this time I get an "Access violation at address 004614B5 in module 'SPRITEEDIT.EXE'. Write of address 01208000." error message. It is GU194.spr it comes with MedPack or Cradle. So it should be a fanmade sprite and should be version 1.3. But obviously something is wrong. Unfortunatly afterwards I clicked on that particular sprite I can't load any other sprites until I close SpriteEdit and start it again. I get only these Access violation messages with different addresses, even if I close the program.

Martin, I don't have the sprite you mention, so could you mail it to me, and I'll take a look at it.
As for the Access violation error, I've tried adding a few protections that might help, but I'll look into that in the comming days.

Originally posted by Martin Gühmann
Another rather graphical problem is that if I let run the animation and I hit Colors->Background or View on the menue bar, the pixels of the frame are replaced by a dark grenn bright green square pattern. (These two greens are part of my system colors.) To restore the actual sprite frame I have to select another sprite first and then to select it again. No problem if the animation is turned of and only these two options are affected. Unfortunatly this problem also occurs afterwards I changed the shadow or background color.

I have not been able to replicate your problem, but attempting to do that revealed another shadow-bug, that I've now fixed, so lets hope I've accidentally fixed your problem

. (Shadows were always black for animations and disregarded the shadow-color selected on the menu)

Originally posted by Martin Gühmann
Another problem occurs with the painting if I switch to another program and then back. The sprite pixels are replaced by a very kight brown. Well the problem only occurs if I switch to Mozilla and then back and only sometimes, but often enough. If I remember correctly I also saw this in TileEdit.

Havn't been able to recplicate this error, so if anyone else have a similar problem please let me know. It might be a windows problem, as I use Delphis own WinAPI-implementations to do the painting. I don't do any actual repainting on giving the program focus, that is taken care of by Window.

Originally posted by Martin Gühmann
Another feature I would like to see is the possibility to show just the shadows or just the pixels or just the transparency values and of course each combination. That should be possible with three additional check boxes on the main window.

I'm working on this, as it's part of the export functions, including this will be natuaral.

Martin the Dane

**The Big Mc** · September 4, 2003, 08:26

how about an exsport as gif function

so when we post new units we can atach a gif to show what they are like

**Martin the Dane** · September 4, 2003, 12:57

Originally posted by The Big Mc
how about an exsport as gif function

so when we post new units we can atach a gif to show what they are like

I'd love to, but I'm not sure about the licence isues with unisys. I've read that their patent expires September 2003, that would be just about now

, can anyone confirm this, with a source.

I've got the libraries (and code) to produce gifs so implementing it in SpriteEdit (and TileEdit for that matter) would not be very dificult, a few extra lines of code should do that.

**Martin Gühmann** · September 4, 2003, 13:54

Originally posted by Martin the Dane
Martin, I don't have the sprite you mention, so could you mail it to me, and I'll take a look at it.
As for the Access violation error, I've tried adding a few protections that might help, but I'll look into that in the comming days.

The sprite in question should be in the attachment.

Originally posted by Martin the Dane
I have not been able to replicate your problem, but attempting to do that revealed another shadow-bug, that I've now fixed, so lets hope I've accidentally fixed your problem

. (Shadows were always black for animations and disregarded the shadow-color selected on the menu)

Unfortunatly the problem is still in the programm. Unfortunatly also the other related shadow bug is still there and if I click on animation all I see is one frame with black shadows without actual animation even if the sprites does has more frames than one.

Originally posted by Martin the Dane
Havn't been able to recplicate this error, so if anyone else have a similar problem please let me know. It might be a windows problem, as I use Delphis own WinAPI-implementations to do the painting. I don't do any actual repainting on giving the program focus, that is taken care of by Window.

The bug still occurs also it was a little bit harder to reproduce now additional the sprite was replaced by white color, and that was easier to remove by clicking on another sprite and going back, but finally it occured again as I described above.

-Martin

Attached Files

gu194.zip (476.5 KB, 346 views)

Sprite Edit can now save the following:
Combined Image:	This saves all the graphical data of a given frame to a 32 bit tga image. The pixel data is saved as RGB-color values, the transparency mask is saved to the alpha channel. And the shadow is saved as the shadow color selected on the shadow menu.
Masked Image:	Same as Combined Image except the shadow is not saved.
Pixels:	This will save the pixel data to a 32 bit RGB tga image, with no shadow or Mask.
Mask:	Saves the Mask to both the alpha channel and as gray values to a 32 bit RGB tga image.
Shadow:	Save the shadow as a 2 color image, it is actually saved as a 32 bit RGB tga image.

Announcement

Sprite Editor

Sprite Editor

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment