and their relevance these days

So here's the deal. We have three kinds of images for in-game sprites (ship, weapons, planets, etc.): PICT, rle8, and rleD.

PICT support is known to be inconsistent and shouldn't be trusted. Why support its use? I don't think anybody would complain if DA made a shan editor that didn't support them.

rle8 and rleD are very similar, but because of the rle8 color palette, it can be annoying to support them in any program that doesn't have easy access to QuickDraw. Of course, as many of you know, I've released the palette to the community, but it requires looking up each ID/color whenever you want to support rle8s - not good for performance. However, that's not the main thing. The main thing is that nobody needs them! I think it's great that Nova supports 8-bit systems, but come on, even 16-bit is becoming obsolete. The Windows version doesn't even bother with them, and I doubt if there are any computers that can run OS X but can't handle 16-bit color (which would have to be a limitation of the graphics hardware). It's often recommended that you don't bother, and I fully agree.

To the point: I propose that we, as a community, retire PICT- and rle8-based sprites for good. I've been working on a utility, and originally planned to support all three, but recently decided to scrap all but rleD support, and I can't imagine that anyone is going to care. What do you guys think? Should we bother with them at all? Should the RLE tools (the ones I'm working on - basically EnRLE and DeRLE, but updated) even support rle8s? They already default to rleD only.

Yes.
This should be a poll.

I think the option should still be available, just in case. for my project, I am not using Rle8's.

but good luck on the RLE program. I am going to need it.

@orcaloverbri9, on Jun 25 2008, 07:11 PM, said in rle8- and PICT-based sprites:

PICT support is known to be inconsistent and shouldn't be trusted. Why support its use? I don't think anybody would complain if DA made a shan editor that didn't support them.

On the other hand, I can't think of any reason to do so. If I had a shän editor that supported rlëDs, adding support for rlë8 and PICT would only need a few extra lines of code, which would be well worth it to fully support the format as specified.

@orcaloverbri9, on Jun 25 2008, 07:11 PM, said in rle8- and PICT-based sprites:

Of course, as many of you know, I've released the palette to
the community, but it requires looking up each ID/color whenever you want to support rle8s - not good for performance.

I haven't ever had any performance troubles when it came to rlë8s. In fact, when I had a computer slow enough for the time it takes MissionComputer to decode an RLE to be perceptible, I would use them for my tests rather than rlëD because of the time savings that came from having fewer bytes to process.

I've been saying this for ages :). Down with rle8s!

I really don't know enough about the situation to make a fully educated vote. I usually prefer rleDs. However, it is very convenient to be able to use PICT sprites in early development or when testing a ship graphic that might need to be modified - I saved myself a lot of time by being able to directly modify a PICT resource instead of converting between rleD to image format and back, and even if I had to re-render a rotation animation, I didn't have to convert the PICT to an rleD just to throw the sprite away later and replace it with the re-rendered version.

In short, although I don't really know a whole lot about the topic, PICT resources can be convenient in development, but I think that the only things necessary in final versions are rleDs.

This post has been edited by Crusader Alpha : 25 June 2008 - 11:12 PM

I just keep the original image file that I made the rleD from. There definately isn't any reason to keep the rle8 support, as I don't think you can even tell MC to draw from that. Pic, I don't know. I never use it, myself, because it's helpful to be able to watch the animation without starting EVN up to spot any problems. But some people might like it.

@david-arthur, on Jun 25 2008, 08:55 PM, said in rle8- and PICT-based sprites:

On the other hand, I can't think of any reason to do so. If I had a shän editor that supported rlëDs, adding support for rlë8 and PICT would only need a few extra lines of code, which would be well worth it to fully support the format as specified.

I have no doubt; I was merely using it as an illustration.

Quote

I haven't ever had any performance troubles when it came to rlë8s. In fact, when I had a computer slow enough for the time it takes MissionComputer to decode an RLE to be perceptible, I would use them for my tests rather than rlëD because of the time savings that came from having fewer bytes to process.

You may be right; I always figured memoryblock.colorvalue was faster than my 256-item select statement. In either case, it's not as relevant to MC as it is to my tools, which were designed for batch processing.

As for my other unnamed utility (Guy knows what it is though), it actually would have been very little work to support rle8, but I simply didn't see the point.

I figured a discussion would be more useful than a poll. I don't think there's such a thing as "officially" retiring PICT/rle8 sprites but if there is I second Guy on it; I definitely promote the idea of "unofficially" retiring them - recommending against their use, at least.

This post has been edited by orcaloverbri9 : 26 June 2008 - 01:01 PM

@orcaloverbri9, on Jun 26 2008, 02:00 PM, said in rle8- and PICT-based sprites:

I always figured memoryblock.colorvalue was faster than my 256-item select statement.

It might very well be. I decode rlë8s not with a select statement, but by creating an array of Color values, with each colour's index in the array matching the index used to indicate it in the rlë8 format.

I've always recommended against PICT sprites on EV Nova , but I'm not prepared to do the same to rlë8.

@david-arthur, on Jun 26 2008, 02:18 PM, said in rle8- and PICT-based sprites:

It might very well be. I decode rlë8s not with a select statement, but by creating an array of Color values, with each colour's index in the array matching the index used to indicate it in the rlë8 format.

I've always recommended against PICT sprites on EV Nova , but I'm not prepared to do the same to rlë8.

Honestly, I don't see the point; in theory it's nice, but I really don't think there's anybody who plays the game and is limited to 8-bit on a Mac. It simply seems like wasted resource space - and it gets pretty significant, considering that these are graphics we're discussing (even if they are more or less compressed).