Well, I've not found it easy to concentrate on RezEditor, though at least part of that was due to "circumstances" of my personal life that I don't really plan on talking about. I have, however been poring over the EVNEW source in an effort to make it fit for human consumption. Seriously, there was some awful code in there. break after unconditional return, checking new/delete for NULL, all sorts of stuff that the compiler does for you, better.
Having a clear and reachable goal seems to be doing wonders, I never thought it would.

Anyway, my point is I discovered a bug in the Nebu handler. To reproduce, try to load a file with OnExplore and ActiveOn fields filled in. Saving works properly, fortunately.

There's also an error in the .rez file opening code that could potentially lead to resources being shuffled randomly, but there probably aren't any .rez files out there that meaningfully used that field.

I've fixed the first, will probably fix the second, have added color support for RLE8, and once I finish my tour through the code I'll release a version (including Makefile for MinGW, it's possible VS will break, but VS doesn't have a real C++ compiler anyway) to see if anything broke. (I had to stop myself from "fixing" the handling of Contribute/Require in the text format because I'd probably break the Endianness-handler).

After that, there's a possibility of going through and replacing the load/save sequence, which is really wasteful, because all the interpretation of stuff - and creation of empty dialog elements - happens when the file is opened. It'd be much faster and more memory-efficient if that only happened when. and replacing the mostly-meaningless vector indices with a map...

Any other bugs I should look out for?

-NC

Edit: fixed a bug when opening an Outf with ModType 2 = 43 (Paint)

Edit: fixed a bug where in Spob where landing fee was loaded incorrectly

This post has been edited by Nonconventionally Creative : 10 September 2010 - 03:37 AM

Funny, in the past years I've been using EVNEW, I have never had any problems and I never noticed any of these glitches. The paint thing really doesn't 'break' the program, it just looks bad, and resetting mod type 2 back to paint fixes it. The nebu thing is pretty serious, but I haven't figured out a good use of that field except for use as a cheat like with the gamma cannon in Polycon. Again I've never had problems like loss of data or the resources 'magically' being shuffled around. Is that glitch tied to the nebu thing, or is it completely different?

QUOTE (Nonconventionally Creative @ Sep 7 2010, 04:37 AM) <{POST_SNAPBACK}>

Seriously, there was some awful code in there. break after unconditional return, checking new/delete for NULL, all sorts of stuff that the compiler does for you, better.

People just don't know how to code these days. Proper use of the STL makes memory leaks almost impossible, yet at work I keep encountering code strewn with manual memory management for no good reason....

QUOTE

(including Makefile for MinGW, it's possible VS will break, but VS doesn't have a real C++ compiler anyway)

What do you mean? Visual Studio has been very standards-compliant since version 8 (VS2005), and while Visual Studio 2010 hasn't implemented quite as much of the C++0x standard as I'd like just yet, it's more or less on a par with gcc's status in that regard. (Hurry up with the template aliases and variadic templates, both of you.....!)

Current status: everything seems to be working (cicn, PICT, rle*, snd not checked), except there might still be problems in loading a .txt file.
Feature: destination filename is optional with -totxt and -torez
Feature: allow / as a path separator (supposedly, this works in the standard library. Might not work everywhere)
Annoying bug I finally fixed: it really does matter what you return from a GUI callback, because the system has its own handlers that you might want to run.

Other news: basic structure of RezEditor dynamic (run-time) GUI is working. Of course, that requires that I force myself to write in Java again...
Also: ImageMagick has a complete, open-source parser for .pict files. Of course, that requires understanding how ImageMagick stores images internally, or else calling the program externally.

I guess I'm going more by VS's reputation than by reality. Some, from personal experience - you need to specify a flag to allow exceptions - and when I was writing C, it was restricted to C89, with no plans to change that (despite the fact that many C99 features are in C++, in which mode they are supported).

It chafes to restrict myself to C++98, but the gcc I have is only 4.2.

C++0x (seems a misnomer, now) features I'm looking forward to:
move constructors (faster standard library just by recompiling to the new standard), + allowing unique_ptr, finally STL-safe.
"rvalue references for *this" - confusing name, but control whether member functions can be called on && or & instances. (Make +=, etc. act as on primitive types) (not yet in GCC)
constexpr - goodbye, nasty recursive template syntax (not yet usable in GCC) - might save compile time, as well, since The instantiations don't need to be cached
auto and decltype()
ranged for - often using auto, this is the one that most programs would prefer to use, including this one.
((attributes)) - (don't like the syntax) to prevent bugs in virtual functions (not yet in GCC)

Annoyance (also in Java): variable scope around case labels.

linecount for current EVNEW is down by 25%, even with new headers that aren't fully used in place of oft-repeated code. Of course, many of those were blank lines or braces.

Currently, There are a lot of raw pointers passed around that could be lost in the event of an exception. Of course, any exception will just cause the program to exit.
More significantly: using destructors has simplified logic. TODO get rid of most of the member variables in classes that do not derive from CNovaResource - some of them exist in more than one copy. Particularly, the AskFor*ExportFormat for nontext resource saved as text.

TODO keep resources uninterpreted until needed - maybe use my mmap-based library.
TODO: also, get rid of all the magic numbers in favor of symbolic names.

This post has been edited by Nonconventionally Creative : 18 September 2010 - 12:17 AM