Cloud and I are using Verge 2.01 Delta (it's the "last stable official release" on the verge-rpg download page). It's predictable, and while it has a few bugs (namely, certain translucency effects don't work) it's never crashed on us, despite Cloud's tendency to do audacious things in the code.

I had a hell of a time getting any of the versions by TSB up and running; I would bring our code across and modify it to the new specs and still the system refused to load. Now that I think about it, I may need to load and resave our maps in the 2.5 format...

Of course, if you use 2.01, you don't get the hicolor routines. Since we're aiming at the lowest common denominator, and have the software to do massive palette manipulations, 8 bit works fine for us, but you may have other ideas in mind.

WinV2 is nice, but I'd wait until it hits a code freeze / stable version. Vecna's a genious, but if he says he's still working on stuff it's probably not worth it until he's satisfied and takes a break. ^^;

You know, my question is this: what books are you reading, Vecna? I got the part about you being a student studying computer something-or-other, but most schools don't teach the practical side of CS (ie, no tilebased graphics), so where did you learn all this stuff? I particularly like the memory handler you use -- Cloud loves it too, as it allows him to track down memory leaks with a minimum amount of fuss. And I was glad to see that we're not the only ones with a PARANOID set of #ifdef's in our code. ^^;

- the Lady Vesper

---

heh, there is no v2.5 map format. The map and VSP file formats haven't changed throughout v2.x

And sorry about that, I have a rare disorder that makes it impossible for me to properly set up a distribution zip. -_-;

As for the "which version?" question, use winv2. The original v2 codebase has been proven time and again to be bitchy, unstable, and just hard to predict. If I ever find myself working on it again, (not likely, but not impossible, given my tendency to tinker with whatever sounds interesting to me at the time) I'll be refactoring and basically rewriting it one piece at a time, so as to make it less bitchy, unstable, etc...

On an almost-related note, take a loot at http://www.flipcode.com/tutorials/tut_memleak.shtml. It's an article on overloading new and delete so that you can track your memory allocations/deallocations and make it all completely transparent. (ie no custom valloc/vfree functions or anything of the like, which saves you time converting existing code to use said memory handling stuff)

---

"Ignorance is its own reward" -- Proverb