Red!Viewer 1.5.0.14 released

[Red]

Usual place to download here.

- Fixed Sequence lists staying in italics once in it and loading other graphic
- Fixed the sequence list names not displaying the control values
- Added lenghtyer descriptions to the sequence text since there is more room
- Beautified code to make it respect my "coding standard"
d Added MSVBVM6/COMDLG32.OCX missing in bug FAQ
d Updated copyright section emails and typos
- Added version dispplay for ZARs and FRMs
- Support multi-direction FRMs properly
- Fixed "New" tile being corrupt when loaded within viewer

Well, sorry for updating so often

[Jimmyjay86]

Keep em coming Red. I haven't had too much of a chance to play with it, but I like what I see!

[Max-Violence]

*sigh* If only I knew how to use .ace files... now I gotta wait for DaC to post the msi...

Oh well, I think it'll be worth the wait

What JJ86 said: Keep 'em coming!

[Jimmyjay86]

Get Winrar, MV. It can handle all of the archives from ace to zip.

[Max-Violence]

Will do that.

Red: Any plans on making it possible to get all 4 layers from a character sprite into a .til? Hell, you could leave out layer #3 (hair, for those less in-the-know, like me...) if it'll make things easier. I don't care if my dead actors are all bald

Y'see, I tried making a tile version of a dead Ghoul, but since it can only grab 1 layer, the tile looks really stupid.

I guess I could make .til's from each of the 4 layers then make 'em overlap in the level editor... but... I don't like having to make tiles overlap. And I'm pretty sure having 4 tiles overlap with each other would cause some funky things to happen in-game (i.e. 3 of 'em not being drawn).

Being able to make tile versions of dead actors would dramatically improve the map... As it is, one needs to place extra entities in the map if one wants dead stuff, even if no item(s) is/are on the dead body, and that increases loading times and general confusion (not everyone knows you can Ctrl+click to "ignore" an entity when moving a character in-game).

Well, @ any rate, this is turning out to be a very handy program. Red - you get your own little place in my readme's special thanks from now on (right alongside JJ86).

[Red]

Any plans on making it possible to get all 4 layers from a character sprite into a .til? Hell, you could leave out layer #3 (hair, for those less in-the-know, like me...) if it'll make things easier.

No. This would mean that I write my own dithering algorithm, and this is something I would rather avoid for the time being - even though it is an interesting project, albeit one that's already been addressed several times and by plenty of applications. At best you could expect a "Save as PNG" function in the application.

Reason being that each layer has it's own 256 colour palette. Hence using 4 layers would make 1024 colours, and the tiles only have one layer, thus I'd have to revert it back to 256 colours. Additionally, you can do funky stuff with the layers (ie: change the colours for each within the game). Soemthing you won't be able to do with tiles. Quite frankly it's stupid that you can't set enteties as ones that "don't interact with the player". In fact I'm very suprised you can't... Cant' you just create a bogus entity with the character sprite? For resources, I'm affraid making tile version would actually consume more. See, when you use several entities which use the same sprite, it only loads the sprite once in memory... So resources shouldn't be that great as the entity overhead is minimal.

[Max-Violence]

Any plans on making it possible to get all 4 layers from a character sprite into a .til? Hell, you could leave out layer #3 (hair, for those less in-the-know, like me...) if it'll make things easier.

No.

Rats...

At best you could expect a "Save as PNG" function in the application.

Well, that would certainly be handy...

Cant' you just create a bogus entity with the character sprite?

What do you mean by "bogus entity?"

For resources, I'm affraid making tile version would actually consume more. See, when you use several entities which use the same sprite, it only loads the sprite once in memory... So resources shouldn't be that great as the entity overhead is minimal.

I'm not talking about RAM usage, I'm talking about the time it takes for the green bar (at the bottom of any "loading screen") to fill up (i.e. the map to load). Maps load far faster with no entites (both in the editor and in-game), so that's why I assumed tiles are "faster" than entities.

One last question (for now ): What's the difference between the Picture offset and the Frame offset? I noticed that if I messed with either too much, the tile would appear centered in the Bounding Box in the viewer, but waaaaaaaay out of the Box in the editor.

Also, if I have either offset selected and click somewhere in the viewing area (er whatever you call it - the area where the tile/sprite is displayed), sometimes, the graphic would move to about 1 1/2 inches to the right of wherever I clicked (1 1/2 inches on a 17" monitor... dunno the pixels offhand). I'm guessing this relates to one/both of the offsets.

[Red]

When not in "Edit offset" mode, you move the "center" of the tile. This is mostly useful if the tile is big and doesn't fit in the window, you can "recenter" it...

When in "Edit picture" or "Edit frame" modes, then you actually change the offset within the tile.

The "picture" is for the entire animation, while the "Frame" is just for this frame (only useful for multi-frame tiles).

When editing offsets, turn the bounding box display on, as otherwise it's near to impossible to center anything (Ctrl-U). The bounding box is how it tile will appear in the game (as you know), while the little black circle is the upper left of the picture. The little circle happens to be the place where the tile will move if you click on the screen (that is, when you click, the tile (and circle) will move wher eyou clicked...), so you need it as a reference. But for "close touch up" use the arrow keys instead as it moves 1 pixel at a time.

[Max-Violence]

The "picture" is for the entire animation, while the "Frame" is just for this frame (only useful for multi-frame tiles).

Ah, many thanks!