here's my console utility to copy graphics. it can load paletted png or pcx file, and writes .new.png files. use it like this:

zgfxcopy.exe Item.png destx desty Item.pcx srcx srcy

here, "Item.png" is destination file, "Item.pcx" is source file, "dest" and "src" are destination and source coordinates in pixels, respectively. it will create "Item.new.png" file with 16x16 tile copied, and will try to do color translation for you.

dunno if it will work right with comm. pngs, tho: for some unknown reason comm. fork has palette written backwards, and color translation code may be confused by that.

your image editor prolly converted png to true-color behind your back (your png is 24-bit one). it is not possible to "fix" it, only do it all again, closely watching for conversions. remember, you cannot have non-256-color pngs for I.V.A.N., and png palette should be left intact too!

p.s.: that is, convert 24-bit png back to paletted one won't work as expected.

and another bugfix. new post, 'cause somebody may already downloaded old buggy version.

i decided to start providing windows builds of my fork again! go to the correspoinding topic, and read the first post there. it should contain the date of release, and the latest win32 build.

also, i used this as an excuse to make a post here.

for those who still don't know what K8IVAN is, a brief:
this is a fork based on CVS (not on comm. version), with CLIVAN and other forks content added. it also contains some content from comm. version too. also, it has alot of improvements in interface, smart 'g'o command, d'U'mp command for liquids, mod system, and some bugfixes not yet backported to comm. version. what it lacks, tho, is proper balance. and fire system from comm. version, 'cause i'm still not sure if i want it.

can we have .7z attachements allowed? for some reason the forum allows .tar files, but not .7z, so i had to wrap my k8ivan windoze build in .7z.tar, which is… fun. %-)

added windoze build for those who want to try it out. it at leasts starts with wine, but i don't know if it really works.


p.s.: slightly updated.

i want to try some other LOS algorithms too. currently, the game is using a straightforward raycasting algo. i want to try at least some shadowcasting implementations (restrictive precise angle shadowcasting looks interesting, for example).

fixed (i hope) a really ancient and really nasty bug with spilling liquids (use-after-free).

the game can `delete` liquid object in one of `SpillFluid()` methods, but will continue using deleted object for some time. this is really hard to catch bug, 'cause most of the time that use-after-free is not fatal, and works ok. but sometimes it randomly fails.

comm. fork has this bug too, btw. it is less disasterous, tho, 'cause comm. fork doesn't have some mosters k8ivan has, and the bug best manifests itself with `ADD_MESSAGE`, which tries to get a liquid name.

as for light tracing: this commit in my fork may serve as a base. it basically tries to trace line from both points before giving up. the side effect is that corners are "rounder" now, that is, player is able to see some squares he cannot see with the current algo:

.*?
..#
..@

the square marked with "*" is not visible now, but will be visible with the new algo. it is acceptable for me, but i don't know about others.

it is quite easy to move all the "special effect mechanics" to scripts. see k8ivan commits from this upto this. then people will be able to balance chilling axe and terror scythe without recompiling the code (and create other "magic effect weapons" too as a consequence).