 |
| |
|
| |
|
|
Mercator
|
 |
Sorekara no Nanimo
Jan 1970
time: 06:24
|
|
 Strange about the ocx thing...
The main reasons I didn't add them to the package are the size of the files (which many may already have) and because the files need to be registered.
That either means I have wrap the program into an installer, like MapEdit, or I have to trust the users' intelligence and explain how to do it in the readme. And hope it works the same way for all Windows versions. But you didn't seem to have any problems with my instructions, so the difference between windows version isn't too dramatic after all then... Well, I'll just have to see what I do about them...
quote:
But that's quite the format, isn't it? [...] |
Indeed. Not quite the handiest for you perhaps, but it was easiest for me, which in turn is good for you since I was able to release something useful much earlier.
Exporting animation files would be a lot easier for you, probably, but a lot harder for me to do.
First of all, the bitmap file format is trivial, GIF format is not free (not to mention it's limited to 256 colors) and I don't know anything about the MNG format.
Secondly, while it should be fairly easy to export (disregarding the complexity of the file format), it would be difficult to import efficiently.
Sprite animations are not just a plain and simple chronological sequence of frames, nor can you specify frame display time. I'd have to take all those discrepancies into acount.
Still, you can import the bitmaps into an animation, edit it and export the frames back to bitmaps, if you want "animation editing powers".
Once I know more about the animation information in the sprite files, I might start thinking about more handy exporting methods. If not in animated format, I could at least export each animation to a separate subfolder.
I have been thinking about an "advanced" version, but I'll just have to see how that will come along.
Have you tried it yet? 
And, thanks! 
Oh, yet another thing... If, say, you're only interested in changing one animation, you can delete all the other images you've exported. Importing will only change images it finds replacements for.
|
|
| |
|
| |
|
| |
|
|
|
Mercator
|
|
Sorekara no Nanimo
Jan 1970
time: 06:24
|
|
By the way, I bumped into that bug when trying out the following:
The bitmap images need not be the prescribed size. That is, if you fancy, you can make your unit images have any size you want (well, there might be some limit, but 128x128 seems to work at least). Different frames of one animation don't even have to match.
There are only two slight problems: As with earlier Civ2 versions, anything below the unit's diamond won't be displayed. Secondly, only the standard 64x64 "box" will be updated properly in the Civ2 display.
The unit "box" is always aligned to the bottom and left of the current tile.
On the other hand, there's at least one advantage: The health-bar will be displayed at the top rows of the sprite image. So, if you have a sleek, low unit, you could make the unit, say, only 32 pixels high (rather than 64). In that case the healthbar will be displayed with its top aligned to the top of the sprite image. I think this will be handy especially for units you don't want to have a healthbar, although it's still a bit limited.
Another thing that might be the case (but I'm not sure)... For moving units having images larger than 64x64 will not be optimal because of the bad graphic rendering beyond the 64x64 box. But for 0-move units it might not be a problem. If it isn't you could for instance recreate the mountains Favoured Flight did in his LOTR scenarios, but with several extra large units, rather than a bunch of normal-sized ones...
|
|
| |
All times are GMT. The time now is 05:24.
Apolyton Time is 00:24. |
top of page
|
|
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is ON
vB code is ON
Smilies are ON
[IMG] code is ON
|
|
|
|
|
|
14-12-2002 21:40
)
Merc
. Any ideas how to get round this?
|