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).
@orcaloverbri9, on Feb 11 2007, 10:09 AM, said in EnRLE:
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).
?
MissionComputer encodes on a line-by-line basis, not pixel-by-pixel, and uses all of the available tokens except the fill-colour one. As a test, I just encoded the Confederation Cruiser using all three encoders; MissionComputers RLEs were exactly the same size (in bytes) as the ones from your encoder, and only 1 K larger (between both the rlëD and rlë8) than those produced by DrRalphs EnRLE.
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.
How about this: Set the maximum of the progress bar to 100 times the number of sprites. Each time you start a new sprite, work out how much of it counts as one percent of that sprite, and then increment the progress bars value by 1 every time you encode that amount.
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.
I havent been in contact with DrRalph since we arranged the transfer of the w00tWare site to EV-Nova.net, and Im pretty sure his address has changed since then.
@david-arthur, on Feb 11 2007, 11:47 AM, said in EnRLE:
MissionComputer encodes on a line-by-line basis, not pixel-by-pixel, and uses all of the available tokens except the fill-colour one. As a test, I just encoded the Confederation Cruiser using all three encoders; MissionComputer’s RLEs were exactly the same size (in bytes) as the ones from your encoder, and only 1 K larger (between both the rlëD and rlë8) than those produced by DrRalph’s EnRLE.
Really? I could have sworn it worked on a pixel-by-pixel basis. I guess it was the lack of fill color token usage (and my own relative lack of experience with RLEs at the time) that threw me off. My apologies; I'll fix my first post.
As for the progress bar suggestion, that should work...thanks! I've always disliked using percentages in progress bars unless the bar was 100 pixels, but I guess this is a reasonable situation for it.
This post has been edited by orcaloverbri9 : 11 February 2007 - 12:57 PM
Well it is different somehow. I did a test of all three with the UE Cruiser earlier and found while EnRLE II makes an rleD 4 bytes larger than MC and the total of the rle8 and rleD is nearly 70k larger than EnRLE, when I zip each file EnRLE II's ended up 7k smaller than MC's and 4k smaller than even EnRLE's.
@orcaloverbri9, on Feb 11 2007, 12:56 PM, said in EnRLE:
I've always disliked using percentages in progress bars unless the bar was 100 pixels, but I guess this is a reasonable situation for it.
Its not particularly elegant, but Ive frequently been in situations where it was the only practical way to report progress. You always have to be careful; trying to report progress too precisely (or, in extreme cases, reporting it at all) can sometimes significantly slow down the actual operation.
Incidentally, my vote is for calling your utility something other than EnRLE. Its not as if its based on a common code platform, and giving it the same name as DrRalphs programme seems too confusion-prone to me. EnRLE is a bit buggy use EnRLE instead!
@guy, on Feb 11 2007, 03:50 PM, said in EnRLE:
Okay, this is weird. I re-ran my test of the Pale version of the Confederation Cruiser, and once again MissionComputers output was the exact same size at that of orcaloverbri9s utility. However , there must be some difference between what the two programmes are producing, because when I zipped the two files, the one from MissionComputer was significantly smaller.
I wouldnt have thought there was this much room for variation in how you could encode an RLE! :rolleyes:
Say, what happens to all the black outside of the sprite area? Does that all get compressed somehow? There would be no harm in using the Fill Colour in that area.
@guy, on Feb 11 2007, 07:01 PM, said in EnRLE:
It's masked, so it becomes transparent.
That is weird, DA - I'll take a look at the differences between the sprites. Incidentally, it's actually EnRLE II, and other than laziness and being terrible with names, I chose the name because the intention is for this to be the successor rather than simply a competing program.
That was a good explanation of why it's useful Guy, but remember, for the most part, the original ship graphics of Clavius and Beyond are pretty much useless to me, as I'm trying to make this on par with rEVisited. Furthermore, I'm working on a Windows box, so I can't use any of these nice apps for doing this even if I could use the original graphics. EVNEW is all I have.
'Guy' said in EnRLE:
Say, what happens to all the black outside of the sprite area? Does that all get compressed somehow?
Its left out entirely, and replaced with a SkipPixelsToken saying where the actual data begins. Thats where the main space saving in EV Nova s RLEs comes from; instead of having to include both the useless area of every sprite and a mask to get rid of it, they contain only the information thats actually needed.
@orcaloverbri9, on Feb 11 2007, 07:09 PM, said:
That is weird, DA - I'll take a look at the differences between the sprites.
It gets more complicated: Back when I was debugging MissionComputers encoder, I wrote a programme that outputs all the meaningful information contained in an RLE in human-readable form, so that I could compare what the encoder was trying to produce with what actually came out. I ran my test files through this programme, and the human-readable versions of MissionComputers output and the RLEs from your utility were identical.
I think what that must mean is that the only difference between the two is what were putting into the occasional few unused bytes fill up space between tokens that are of non-even length. MissionComputer just drops in whatever happens to be in its memory buffer at the time, and I dont know where yours gets its meaningless bytes; it must be that your pattern is sometimes more compressible, and sometimes less.
@orcaloverbri9, on Feb 11 2007, 07:09 PM, said in EnRLE:
Incidentally, it's actually EnRLE II, and other than laziness and being terrible with names, I chose the name because the intention is for this to be the successor rather than simply a competing program.
I'm with DA here -- you should choose a different name (RLEer?). Your app is by a different author and has a diffeent code lineage. It also isn't clearly an improvement in all situations (yet!). Mostly, though, I just don't relish the confusion this is going to cause. I already have enough trouble remembering the distinction between "Plugin Archiver" and "Plug-in Archiver." :rolleyes:
@dr--trowel, on Feb 12 2007, 10:11 AM, said in EnRLE:
I already have enough trouble remembering the distinction between "Plugin Archiver" and "Plug-in Archiver." :rolleyes:
:laugh:
I'll rename it "RLE Maker" or something if this is the popular opinion. As for Plug-in Archiver, I'm probably going to rename it with the next release, which will be Cocoa.
DA: They just get filled with 0. I can't do a meaningful comparison since the colors are different (not significantly, but they are).
@david-arthur, on Feb 13 2007, 03:45 AM, said in EnRLE:
Its left out entirely, and replaced with a SkipPixelsToken saying where the actual data begins.
Ah, so any image data in the masked area is destroyed. Well there's my secret plan to hide, er, secrets in the masked area out the window :rolleyes:
I think what that must mean is that the only difference between the two is what were putting into the occasional few unused bytes fill up space between tokens that are of non-even length.
But the data isn't always the same size - the UE Cruiser rleD was 4 bytes larger in EnRLE II.
As for the name, my vote will be for 'ReRLE' when that feature is implemented
@orcaloverbri9, on Feb 12 2007, 05:02 PM, said in EnRLE:
As for Plug-in Archiver, I'm probably going to rename it with the next release, which will be Cocoa.
:blink:
Please don't name it Cocoa. That really wouldn't help matters much. :laugh:
@orcaloverbri9, on Feb 11 2007, 04:09 PM, said in EnRLE:
I've been in contact with Dr. Ralph by email for some time now, PM me for the email (I'd rather not put it in public, even obscured for spam bots...) And yes, I definitely support a whole different name.
On that matter, before anyone asks where I am for porting NovaTools for Rezilla, since Rezilla 1.1 (the version that supports plug-ins) does not support all the features that make my templates for Rezilla usable, I still recommand the use of 1.0.8 custom 3 and there would be little point in releasing anything now since 1.0.8 custom 3 wouldn't be able to run this anything, so it's a bit on the back burner and I've been using the time to work on SketchMapMerge instead.
@david-arthur, on Feb 12 2007, 03:45 PM, said in EnRLE:
I was about to suggest the use of ViewRLE's RLE parser, but it's designed to only detect actual errors, so if they are that similar, it's not going to be of any help. Indeed, if one renounces on fill pixel tokens, there does not remain much room for variation (short of splitting a pixels run token or a skip pixels token in two, which both degrades decoding speed and space so there is no point in doing it) beyond the values in these unused filler bytes that are due to realigning (though you wouldn't believe the number of times I've seen the values in these pixels when debugging the SSE2 and AltiVec decoders/overlayers I wrote, ironically not when debugging the Intel-native code that has to do byte-swapping, as that worked right the first time... it has been quite helpful to me that in the Nova rles they are quite different from the regular pixels)
@zacha-pedro, on Feb 18 2007, 06:33 AM, said in EnRLE:
Indeed...there does not remain much room for variation...beyond the values in these unused filler bytes that are due to realigning (though you wouldn't believe the number of times I've seen the values in these pixels when debugging the SSE2 and AltiVec decoders/overlayers I wrote, ironically not when debugging the Intel-native code that has to do byte-swapping, as that worked right the first time... it has been quite helpful to me that in the Nova rles they are quite different from the regular pixels)
Im pretty sure thats the difference. In light of this discussion, Ive modified Make RLE in Crusoe (MissionComputer 4) to fill the unused pixels with zeroes. When I encoded my test sprite with the new settings, the end result was (of course) the exact same size, but when zipped it was 15% smaller.
So it's filling the unused bytes with 0 rather than useless junk that makes it smaller when compressed? I guess that makes sense. Also, a quick test yielded identical-sized RLEs (8- and 16-bit) from both apps, so the difference doesn't always occur. I can't imagine what's doing it.
This post has been edited by orcaloverbri9 : 19 February 2007 - 04:51 PM
@orcaloverbri9, on Feb 19 2007, 04:51 PM, said in EnRLE:
So it's filling the unused bytes with 0 rather than useless junk that makes it smaller when compressed?
Yes. Of course, filling them with any random number would have the same effect; all that matters is that theyre all the same, so the compressor can reduce them to one copy plus a number telling how many are needed to make the final version.
Also, a quick test yielded identical-sized RLEs (8- and 16-bit) from both apps, so the difference doesn't always occur. I can't imagine what's doing it.
The fact that Guys test was exactly four bytes larger makes me wonder whether your utility might be mistakenly adding a full four bytes if the entrys length happens to already be a multiple of four, rather than not adding any as MissionComputers Make RLE does.
Are you saying when you changed your code so that it would supposedly be the same as orca's then your results still zipped up 15% smaller than orca's? Strange. While we're talking about your MakeRLE utility though, I just noticed it crashes if you cancel when choosing an output file name.
@david-arthur, on Feb 19 2007, 06:27 PM, said in EnRLE:
The fact that Guy’s test was exactly four bytes larger makes me wonder whether your utility might be mistakenly adding a full four bytes if the entry’s length happens to already be a multiple of four, rather than not adding any as MissionComputer’s Make RLE does.
I actually did consider this, but I think I found it not to be the case. I'll check again.
...nope, definitely not the problem. Hmm.
Guy: I'm pretty sure he meant that zipped files made with Make RLE were 15% smaller after changing it to 0-fill than they were previously.
This post has been edited by orcaloverbri9 : 20 February 2007 - 01:21 AM
@guy, on Feb 19 2007, 09:50 PM, said in EnRLE:
Are you saying when you changed your code so that it would supposedly be the same as orca's then your results still zipped up 15% smaller than orca's? Strange.
No, I mean that an archive containing an RLE from MissionComputer 4 is 15% smaller than an archive containing the same RLE from MissionComputer 3.3.3. I havent compared that against orcaloverbri9s utility.
While we're talking about your MakeRLE utility though, I just noticed it crashes if you cancel when choosing an output file name.
Fixed, thanks.
Bug report for orca's RLE maker too: Sprite doesn't get dithered when creating rle8 so output looks terrible.