Sprite Editor

[Martin the Dane]

I found the error, and corrected it, but alas! My troubles were just beginning. It seems I have been maintaining several different versions of the tga-import routeen and calling different versions from different parts of SpritEedit. Nedless to say this resulted in some quite wierd behavior, to say the least, and made debugging near impossible. So now I have started som major "housecleaning" of the code. (btw. where is that floor-sweeping smilie?)
This progresses quite well, witch makes me a little nervouse (One of Murphy's laws of programing says: If a program compiles on the first try, there is somthing fundamentally wrong with the code)

[Martin the Dane]

Well, my current build does not work as intended. There are quite a few serious problems. You can't add or remove frames from the sprites. You can only change the graphics, and as you can se from my previous post, this is quite buggy. I have errors ranging from unexpected crashes to errors in the imported graphics. I'll se what I can do this week and week-end, but I don't expect to get much coding done from next week to mid Januarry.

[Martin the Dane]

An update and a question.

First I have fianly finished the "housecleaning" of my code, and have completed the tga-import functions, so it is now possible to change, add, and remove frames, for now this only works correctly for uni-directional animations (Idle, Wictory/Death, and Effects).

This brings me to the question. As I se it there are two ways of handling penta-directional animations (Move, Attack, and Work). Theses require the same number of frames for each headding, so building each headding individually will requre too much error-handling in TileEdit.

The first possible way of handling this is that when a frame is added to one of the headdings, blank frames for each of the other. These blank frames can then be eddited later. (here I would limit the ability to add frames to the first headding).

The second option is that the "OK"-button on the add/insert screen will not be available untill all five frames have been filled with graphics of the correct size.

Personally I'd prefer the first option, first becaus I find this to be the most logical approach, secondly becaus it seems to be the easiest to program. But since I'm probably not going to make many sprites, I'll program whatever you guys find the most logical.

I'll post a new build later today.

[Ekmek]

Thanks Martin! I'd say go with what is easier for you as this will speed a release I guess just adding the details to your approach to the readme will be enough too. I think the first is best anyways...

[The Big Mc]

Martin just put the image you just imported into the other sections. This allows the maker to import it into ctp and test the directional animation. If it was left as a blank tga and the person starts importing on the south facing this could meaning the spr vanishes in ctp.

[Martin the Dane]

You have a point there Mc. I'll do that. And thanks fo the feedback, to both of you.

[Martin the Dane]

Ok, made it.

I have now implemented Add, Remove, Insert, and Edit Sprite Frame. This is verry much beta, so please report any odd behaviour. Note that it is not possible create sprites from scratch, (thats next on my list) for now you'll have to open a sprite of the desired type, with the desired animations, and start from there.

Just grab Build 10 from my sig.

[Ekmek]

Originally posted by Martin the Dane
Ok, made it.

I have now implemented Add, Remove, Insert, and Edit Sprite Frame. This is verry much beta, so please report any odd behaviour. Note that it is not possible create sprites from scratch, (thats next on my list) for now you'll have to open a sprite of the desired type, with the desired animations, and start from there.

Just grab Build 10 from my sig.

I'm assuming you mean the different types ofanimations (move, attack, etc).

I'll give it a whirl thanks!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Ekmek]

Martin,

I think I found a problem...

Ok I saved the GU02.spr (settler) as Settler.spr into a separate folder. I then exported the move animations of the Civ3 settler and converted them to Uncompressed 24bit TGAs. I then INSERTED the north graphics and saw that it changed all directions to be North facing (like you said it would, and big MC requested). I then went to edit the northeast frames andother directions and from time to time I found it editing the North direction only and not the other directions. maybe its me trying to get a hang on the new features but maybe bigmc ran into it too?

[The Big Mc]

big mc has not downloaded it yet

[Martin the Dane]

I can't believe I forgot to check that!!! Standing under the shower this morning I started thinking of the latest build of SpriteEdit, and realized I couldn't remember whether or not I checked if editing a frame edited the correct heading. Apparently I did not.

Fortunately the fix was very simple, so now it should be fixed. Just grab Build 11 via my sig.

[Ekmek]

Thanks Martin!

I tried it again. So far so good. I havent finished my first sprite yet but I think its working fine.

Are you going to add other features like short cut keys? they helped in tileedit. Atleast make a short cut key for editing frames that's probably used the most.

great work, it makes sprite editing much easier...this deserves a news item.

[Ekmek]

Sorry Martin but I think I found a problem. I made my first sprite.

I edited the GU02 sprite of the cradle settler and used the civ3 settler. I exported the files from flicster (pcx format) then batch converted them using PSP 7 into 24bit uncompressed TGAs. Then frame by frane I added each one into the sprite. I did delete one "row" or set of directions (9 instad of ten) for the moves. and added a bunch in the death.

I started a new game. game started fine and the idlle worked (I didnt add or delete frames there) but when I tried to move the game crashed. Also when I went to "kill" the unit, it just disappeared with no animation. this is a uni-directional death and I added frames.

So I think it has to do with deleting frames.

Here's the sprite (I renamed the file to replace the ctp2 standard settler so I could see it on start up so mine is GU002)

[The Big Mc]

I think I know why e sprite failed to work.

Examining his sprite I found that there was pure black on the first image. When pure black is in a sprit ctp does a fit and crashes however I don’t know if pure black was put in on the original image or when it was imported into sprit edit.

[Martin the Dane]

Thank's for the feedback.

I'll look into the black pixels issue some time next year. The rest of this year (all 11 hours of it) will be occupied by RL issues.