Oh great, I just booted into Windows to try it out, and apparently MSVC is a lot stricter than GCC, so I'm getting a bunch of errors.

I'm working on importing spritesets from images. Unlike the original editor, which immediately saved the generated spriteset, QtSphere IDE just imports the image, so you can make changes before saving it, or in case it didn't come out right. Also as you can see, I combined the frame width/height and the transparency i/o dialogs into one for user convenience.

That's a good idea, not saving the image right away to facilitate experimentation.  I've always been annoyed when an editor automatically saves something you just created that you might end up having to delete and start over; IDEs in particular are notorious for forcing you to save newly created projects (Sphere Studio also being an offender here).

As a suggestion for a future iteration it could be useful to see an actual preview of the generated spriteset before actually generating it; this would let the user fiddle with the values and see the results in realtime, before clicking OK.

That's a good idea, not saving the image right away to facilitate experimentation.  I've always been annoyed when an editor automatically saves something you just created that you might end up having to delete and start over; IDEs in particular are notorious for forcing you to save newly created projects (Sphere Studio also being an offender here).

Yeah, it just always felt really awkward. The menu even says "Import", which generally implies that something is being included or generated without being saved automatically.

As a suggestion for a future iteration it could be useful to see an actual preview of the generated spriteset before actually generating it; this would let the user fiddle with the values and see the results in realtime, before clicking OK.

That should be pretty easy with Qt's slots/signals.

Right now I'm having an extremely frustrating issue with the direction objects in the direction list being corrupted/reset after the function that they're created in returns. I'm not sure if it's caused by my pointer handling or Qt's implicit sharing system, but based on my experience with the same thing happening to individual QImage objects, I'm guessing it's the latter.

The way the system is described, it seems you're meant to pass around the shared object itself, rather than a pointer to it.  This ends up being efficient because the object is merely a wrapped pointer so there's no significant cost in making copies of it.

What I'm guessing is that you're creating the object on the stack and then returning a pointer to it.  This leaves you with a dangling pointer because the object itself goes out of scope.  A pointer doesn't count as a live reference, it's just a dumb memory address.

Code: (c++) [Select]

CSomeClass object(arg1, arg2);
return &object;  // dangling ptr, ticking time bomb

Uh...so it turns out  the directions being reset was caused by two really dumb mistakes. The direction.name was being reset because of what you described. Changing it from a char* to a QString fixed the issue.
As for the frames being "reset", I created each frame when looping through num_frames (an integer read from the .rss file), but forgot to actually add them to direction.frames!

Whatever, at least it works now, and importing is mostly finished, as you can see from the images. The spriteset in imported.png is ugly but it isn't meant to be pretty, since I was using it to make sure that the given color is being properly replaced with transparency (or another color if you don't need transparency).

Hehe, anti-aliasing and colorkeyed transparency indeed don't get along very well.

That was done deliberately in GIMP to see how the 1.x editor handles  similar shades of the given color. It's also why I added a gradient to the last frame.

Also importing works now, and the created file can be read by both QtSphere IDE and the original editor, though I don't know about Radnen's editor. sha256sum reports that the file generated by my editor has a different checksum from one generated by the original editor, but I suspect that's because of random junk in the reserved byte arrays.

Per spec (what little "spec" there is for the v1 formats...) I think the reserved bytes are always supposed to be zero'd.  Doing so helps with forward compatibility since the "default" for any new value can safely be assumed to be zero.

That said, it's unlikely those formats will be extended in any way going forward.

Alright, I zeroed out the reserved byte arrays and set the default frame delay to 8 (since I had it at 1), and now it creates a spriteset identical to one generated by the 1.x editor if you renamed the empty direction to "north", added "east", "south", and "west" directions, and gave each direction three frames.

This thread is in desperate need of an update since QtSphere IDE is still in development even though it isn't my main project. I'm currently working on the map editor, and even though it's still far from completion, it fully loads map files, and this is what the editor itself looks like so far:

It might end up being able to display the first frame of each entity as a preview, rather than a generic icon. I haven't decided yet.

And now the map editor is (slowly) starting to look like a map editor! Thanks @Fat Cerberus for helping with the weird tileset quirk.