Ad blocker detected: Our website is made possible by displaying online advertisements to our visitors. Please consider supporting us by disabling your ad blocker on our website.
PNG->ZAR conversion: I doubt it. I might be able to pull something off with paletted PNGs, if DirectX supports it. The main problem is that I don't feel like dealing with the color downsampling right now, though I actually do wish to tackle this eventually.
HW: I managed to find HW and have it installed. The lastest release version of Red!Viewer is 1.6.23 so make sure to get it to see if the bug is still there.
- Updated Visual Studio to Service Pack 6
- DX8 Added support for video cards which only support square textures and made
the program able to support non-power of two textures on cards which support
them
c Rearranged code: moved all possible constants, enums and types into their
respective classes; Changed the variable names so that they fit the context
of their use better; Changed "really short" variables where possible; made all
code follow the same coding standard (except for the 80 column limit which I'm
not very constant with in VB); simplified object identification mechanism to
use what is already supplied by VB; added compiler option to remove the
software rendering given I'm dearly thinking about removing it
- Mouse offset editing now supports proper zoom conditions
- TIL Added easy bounding box editing: click on the square to select the
direction to edit then click & drag on the canvas to modify
- When clicking and leaving the mouse pressed, the image is nowrendered all
the time instead of when you unpress the mouse (applies to TIL offsets too)
Not PNG -> ZAR, PNG -> SPR or PNG -> TIL cutting out the zars entirely. The game only uses zars for portraits, the mini-map and the interface and using the editor to convert them is adequate for that.
Having a universal clipboard you can add zars and pngs to, then import directly into a sprite or tile.
Would that be feasible?
If you can bear to hear the truth you've spoken
Twisted by knaves to make a trap for fools,
Yeah, version 23 does work with the problem tiles. Great. But sprite conversion would be a nice touch if possible for a future version. Do you think there might be an easy way to do a conversion from tile to sprite or vice versa?
The thing is that ALL images in the game actually use the ZAR format... Sprite are really just a bunch of ZARs tied together in a file by a bunch of "header" infromation... This is why the ZAR clipboard is there and this is why I need to program a PNG->ZAR conversion function to actually be able to add PNGs to sprites.
Given that the FOT editor handily does exactly that I figure it's not a priority for me to program it, specially since it can convert a bunch of them at a time...
Tile->Sprite will be easy once I actually program the sprite saving functiions...
Sprite->Tile is much more complicated since sprites can have up to 4 layers. For items this isn't a problem, but for all characters and vehicles it is as they use all 4 layers and I would need to merge them back into 1 (which is doable but I'd have to downsample the images which is something I'll keep probably until as late as possible...)
Not sure why you'd want a sprite to tile function, there's so few sprites worth turning into tiles that you might as well just export a tga of each layer and join them up or use spr-gif.
If you can bear to hear the truth you've spoken
Twisted by knaves to make a trap for fools,
A sprite>tile function may be useful in a limited number of cases but it still might be interesting.
I'm not sure if this is addressed in your next version Red, but even with the latest version I get the ocassional run-time error crash when making TGA's.
Yeah, it's with the tiles. On afew of the HW tiles I tried to make tga files to have a picture to post on my site and they crashed.
One thing I noticed when playing HW is that the ramped floor tiles allow for the car to drive up them. When converted to FOT they can't be. I assume the bounding box has been changed from a wedge shape to a box? In other words, FOT doesn't support wedge-shaped bounding boxes. Does this sound right? Is there any way to get FOT to support this feature or does the older version of the engine block this feature?
Indeed. FOT doesn't support wedges... Though I haven't tested this I beleive that the wedge in HW tiles are in some of the unknown attributes of the tile, idndicating in which direction is the wedge too and perhaps it's slant...
The way FOT works is that when the elevation difference is less then 1 you can climb it...perhaps it can even be higher, it's been way too long I've toyed with the FOT engine... The solution would thus be either to divide the tiles into smaller ones, or create fake placeholder ones (preferably invisible though with a placeholder images would be preferable) to simulate the ramp...
If a tile is 1 WU high it can be climbed without it needing to be flagged climbable or stairs. The sloped tiles aren't flagged anything different from floor (or even wall cap) tiles the main difference in building a slope or ramp is that with the steep slopes under the mountain tileset you have to break the slope up (something like every 7 levels) and have at least a 2 WU wide tile every now and again. The wider slopes in the ruined city road set can go up pretty much uninterrupted.
If the HW tiles are higher than 1 WU then it'll probably be best to cut the tiles up rather than have an invisible ramp underneath, less clipping and overlapping tiles to worry about.
If you can bear to hear the truth you've spoken
Twisted by knaves to make a trap for fools,
Hey Guys,
It's good to see some of you die-hard FOT
guys are still hanging in there!. Has anyone got the lastest word on whether red has his lastest version
of redviewer out yet?
I've got just alittle while longer and then I'm
getting busy with some modding work for FOT and
my other project Deathlands.
