Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
Round 2
Meet EnRLE II. EnRLE II will from now on perform EnRLE's old job. He promises to improve things by not using the "fill color" RLE token which upsets Mr. Nova. However, his RLEs will only be as efficient as those created by Dr. MissionComputer's Make RLE department. On the other hand, EnRLE II will do batch processing.
Hire him here.
He promises to do his best to dither your sprites, but still advises dithering them beforehand because it will end up better. Also, we have not yet hired a secretary to report on his progress, and he may have accidentally written "My Application" under "name" on his business card. We apologize for the latter two and will rectify them shortly.
(By the way, if anybody who has experience in this (DA, that means you) has any suggestions as to how to report the progress, please let me know. That's the only reason I haven't implemented the progress bar yet.)
The name EnRLE is tentative and is Š Ralph & Rodger Sutherland of w00tware. Official permission for name use pending confirmation. The name will be changed in the event of a denial or lack of response.
EDIT: Fixed incorrect assessment (and thus citation) of the efficiency of RLEs created by MC.
This post has been edited by orcaloverbri9 : 11 February 2007 - 02:25 PM
w00t, thankyou
Will drag-n-drop be supported in future? (edit) Type/Creator codes of output are bung. I think they look like UTF-8.
This post has been edited by Guy : 04 February 2007 - 08:18 PM
@guy, on Feb 4 2007, 08:13 PM, said in EnRLE:
Oops, they are. I have MacRoman constants for rle8, rleD, and spin, but didn't think of it for Nova and Npif. I was wondering why they weren't working...
And yeah, I'll add drag and drop in the future. I just wanted to get a working version out quickly.
Well it looks good so far :). I re-encoded all the EVO sprites and they only ended up a total of a couple of KB larger than the old EnRLE I versions. I have some other things which would benefit from re-encoding but can't do that easily yet without a working DeRLE (or a ReRLE function, hint hint ;)).
This post has been edited by Guy : 04 February 2007 - 09:22 PM
@guy, on Feb 4 2007, 08:59 PM, said in EnRLE:
Well it looks good so far :). I re-encoded all the EVO sprites and they only ended up a total of a couple of KB larger than the old EnRLE I versions (edit: actually the difference in size ends up larger after compression, though still no biggie). I have some other things which would benefit from re-encoding but can't do that easily yet without a working DeRLE (or a ReRLE function, hint hint ;)).
But there is a working DeRLE...DeRLE doesn't have the problems EnRLE does. I do plan to make one though, and a ReRLE that partly DeRLEs and then EnRLEs.
Oops, I got mixed up with the compression sizes, the new ones actually end up smaller somehow :).
DeRLE has the same problems Nova does - the output masks end up black wherever there were colour runs.
They do? Sweet! I wonder how that is. Can you send me the RLEs so I can examine them?
As for DeRLE...ah. Well, you could always export as movie in MC and use m2s (or Spritemaker ;)).
Compressed, as in zipped. The actual RLEs are a tad larger but if I zip both the old and the new then I find the new is now curiously smaller.
Nah, MC doesn't do batch processing - it would be rather painstaking.
Could we have an option to name the RLEs with the name of the spin?
This post has been edited by Guy : 04 February 2007 - 10:20 PM
@guy, on Feb 4 2007, 10:16 PM, said in EnRLE:
Ahh, okay.
Quote
I suppose. I also want to add support for folders at some point.
I guess. I started to implement one and then decided it wasn't important.
Heh. Well for anyone who doesn't know what this is all about, here we have a Voinian Dreadnought encoded first with EnRLE and then with EnRLE II. Painted blue
Heh. I got around that problem by making sure my masks were saved as 1 bit PICT files.
I got around the problem by manually changing the color of every other pixel of the color runs an (almost) imperceptible amount, for Quantum Beams. You do not want to know how many betas we went through trying to get them looking right first for my sprites, then for my second batch of sprites, then finally for Guy's much nicer-looking replacement sprites which I went through by hand to get the masks working because when I DeRLE'd his sprites to dither the colors the masks that resulted had to be corrected too.
@pipeline, on Feb 5 2007, 11:02 PM, said in EnRLE:
Are you sure that's the same problem? Because I don't see how that could make a difference - it's the sprite that's causing the problem, not the mask. In any case, what did you use to save as 1-bit? Graphic Converter seems to only save as 4-bit and Blitzen doesn't have a 1-bit option.
@guy, on Feb 5 2007, 03:48 PM, said in EnRLE:
Are you sure that's the same problem? Because I don't see how that could make a difference
Simply put, the way RLEs work, it couldn't. My guess is pipester is thinking of a different problem.
DeRLEing is trivial anyway, even when having to take fill color tokens into account. It doesn't even need to be as complicated as ViewRLE's decoder (as it expands the colors into 32-bit RGBA and does overlaying and checks for correctness)
@orcaloverbri9, on Feb 4 2007, 06:40 PM, said in EnRLE:
By the way, if anybody who has experience in this (DA, that means you) has any suggestions as to how to report the progress, please let me know. That's the only reason I haven't implemented the progress bar yet.)
I dont know how your encoder works, but if its on a line-by-line basis, you could simply have a progress bar where Maximum is set to the height of the image and Value to the line youre currently encoding.
What exactly is the trouble that youve had with MissionComputers Make RLE?
Well as already mentioned, MC doesn't do batch processing.
Is batch processing that important, Guy? I have to use EVNEW because I'm on a windows box and there's no possible way I'm going to get MC to work on OS 7.5.5 running on Basilisk II, and it doesn't do batch processing of images into rlëDs. The only thing I can see any sort of batch processing being useful for is if I could import the sprite and its mask at the same time, personally. THen again, I'm not doing anything huge, either. Just working on Clavius rEVisited.
Well the batch processing of EnRLE works by taking a plug with sprites already in PICT format complete with spins and then it can read the spins to know how to make the RLEs. Ie, you could just drop the Clavius plug straight onto it and it would do it all for you in one go. All you have to do now is copy the RLEs from the output file back into the plug and delete the PICTs.
@david-arthur, on Feb 9 2007, 12:19 PM, said in EnRLE:
What exactly is the trouble that you’ve had with MissionComputer’s Make RLE?
Well, the sprites it makes are very inefficient, as it encodes (from what I remember) on a pixel-by-pixel basis, completely forsaking the tokens which compress the RLE. Basically, MC's RLEs are in RLE format, but aren't really RLEs at all. Essentially, the only significant benefit of using MC's Make RLE is that Nova will like your sprites (there may be a reduction in size, but not nearly as much as an RLE encoded with either EnRLE, especially the first one).
As for the progress bar, the problem is that it is meant to represent total progress for all the RLEs. I guess I'll just have to go through the spďns initially and get all their heights - actually, perhaps areas would make for a smoother progress bar.
By the way, do you know of any way I could contact Ralph or Rodger? I sent an email via the board to the former, but no reply, so I'm thinking it's out of date.
This post has been edited by orcaloverbri9 : 11 February 2007 - 10:11 AM