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).
Status Update:
I can finally use RLE sprites. What a bloody nightmare that was. Does anyone want to hear me recite the entire hex code for the Shuttle rlë8? Due to my newfound insight into the ugliest file format I have ever seen, my first editor will most definately be an RLE editor. It will do the following things:
The main reason I'm doing this is because quite a few of the other editors will rely on it, and it gave me such a nightmare (because Spriteworld, oh so useful for Carbon users, is next to useless in ProjectBuilder without extensive modifications) that I want it out of the way. Now : )
I'm sure it's already been done, but I'm doing it anyway.
Cheers!
------------------ Kane O'Donnell
Quote
Originally posted by AriosSw: **An extremely good idea, but yes, unless Ambrosia does it, probably infeasible.
**
I was hoping they'd release a developer's version before the final version came out, but it didn't happen. :frown: Is there any way to access RLE graphics without using Cocoa? Say, REALBasic, or something?
------------------ Eat blazing electric death! (url="http://"http://www.geocities.com/infernomsh")Inferno Studios)(/url) (being remade better than ever!)
Originally posted by SpacePirate: **Is there any way to access RLE graphics without using Cocoa? Say, REALBasic, or something?
Sure, it is simply a resource format. You would just have to write your own compressors and decompressors (which isn't exactly easy). EVONE can read and write RLE resources and it is written in C.
------------------ (url="http://"http://www.ariossoftware.com/upcoming")EVONE 1.0.0 - the plugin editor for EV/EVO/EVN(/url)
Yes, it would be simple task in RB, the REALBasic MemoryBlock class has all the properties necessary.
As JS said, C is the way to go. It's okay, all the pain is over now anyway...
Originally posted by shado83: ** Yes, it would be simple task in RB, the REALBasic MemoryBlock class has all the properties necessary.
Possibly, but remember the RLE format is, by definition, run-length-encoded. The (relative) hard part is actually writing the decoder, reading the memory in is easy.
Originally posted by AriosSw: **Possibly, but remember the RLE format is, by definition, run-length-encoded. The (relative) hard part is actually writing the decoder, reading the memory in is easy. **
That's correct - what I was referring to is that the MemoryBlock class in RB has accessor methods ( readDouble, readShort, etc) that makes it easier to write the decoder since you don't have to worry about token alignment. The decoder that I wrote is based on the BlitPixieRLE decoder but it required some minor (but not intuitive) modification to get it to work under PB, because the token alignment macro (ALIGN_PTR) wasn't working.
I guess DA may have found a way for MC 2.0, but I was wondering, where did you all find your information about the RLE format? Or did you figure it out through trial and error?
Originally posted by SpacePirate: I guess DA may have found a way for MC 2.0, but I was wondering, where did you all find your information about the RLE format? Or did you figure it out through trial and error?
No RLEs in MissionComputer 2.0 yet, so I'm just as interested in knowing as you are.
------------------ David Arthur @ (url="http://"http://davidarthur.evula.net/")davidarthur.evula.net(/url) (url="http://"http://davidarthur.evula.net/showpic.php?image=beta/mc2progress.gif&width;=480&height;=282&title;=MissionComputer+2.0+Progress+Update")MissionComputer 2.0 Progress Update(/url), 2 December 2002
Is (url="http://"http://djvu.sourceforge.net/doc/man/csepdjvu.html")this(/url) it? Or maybe (url="http://"http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcmn98/html/vbprobackcoloractivexcontrols.asp")this?(/url) I think the latter may be easy to play with in RB through Quicktime, but who knows? Jeffrey or Shado, where did you find it?
Originally posted by David Arthur: **No RLEs in MissionComputer 2.0 yet, so I'm just as interested in knowing as you are.
Mine was a combination of luck and good help. I was searching the web for the info and I came across a webboard post at some other site by AriosSw saying that he used SpriteWorld to display the RLE sprites in EVONE. Having downloaded and examined SpriteWorld (and BlitPixie) I then contacted him about it and he helpfully sent me the RLE C struct, which is pretty much the same as the BlitPixie version. Fortunately for AriosSw his compiler will actually compile SpriteWorld (a 2D graphics engine). Mine won't. I had to write a sort of replacement engine based on SpriteWorld.
It wasn't until a few days ago that I found out EV's engine (EV, EVO, EVN) is actually based on SpriteWorld - makes sense why the rlë8/D format is exactly the same as the RLE# format used in SpriteWorld!
The decompression/compression idea behind the SpriteWorld RLE and the "classic" RLE format is a little different, I can explain it in a private email if you like (it's a little too technical to be posted here). AriosSw probably knows more about it than I do, but if you are using ProjectBuilder, you're in my boat, unfortunately...
Cheers,
Kane O'Donnell
Originally posted by SpacePirate: **Is this it? Or maybe this? I think the latter may be easy to play with in RB through Quicktime, but who knows? Jeffrey or Shado, where did you find it?
It's definately not either for EVN. The RLE format is not a FORMAT, it's just a lossless compression technique that is used in file formats such as TIFF. The format for an EVN rlë8/D is pretty simple in theory - the first 16 bytes are the width, height, depth, colour palette, number of frames, and three reserved spots, all 2 byte integers (shorts in C, words in ResEdit). All the rest of the data is pixel data compressed in the SpriteWorld/BlitPixie RLE format using certain tokens (fill, draw, skip, new line, end of shape) and raw pixel data. The decoding algorithm is fairly simple - once you read it over a few times and examine one of the rlë8/D hex data you'll understand how it works. Implementing it in your favourite language is your next step. For Carbon with Codewarrior, use BlitPixie/SpriteWorld where you can - it's fast and highly reliable, having been around and tested for a long time.
For RB, don't even think of using Quicktime. You need to make pixel-level manipulations. Take a ResourceFork class, a MemoryBlock class and make an RLE class. Read the appropriate data into a MemoryBlock and decode into another MemoryBlock (your pixel map) and the RLE class, then do pixel-level manipulations on a Canvas class using the pixel map.
For ProjectBuilder (Carbon or Cocoa), contact me and I'll just send you the decoder/encoder when I'm finished optimizing (read: debugging... : ) ).
Originally posted by shado83: I had to write a sort of replacement engine based on SpriteWorld.
That's what I'm probably going to have to do if I implement RLE, since I'm doing this in REALbasic, which is great for rapid application development, but not so good for using other people's libraries.
Originally posted by shado83: The decompression/compression idea behind the SpriteWorld RLE and the "classic" RLE format is a little different, I can explain it in a private email if you like (it's a little too technical to be posted here).
I downloaded SpriteWorld, and the documentation seems to cover the RLE tokens, but not how fit together into a whole resource with multi-frame animation - any light you could shed on this would be a big help.
Originally posted by shado83: Take a ResourceFork class, a MemoryBlock class and make an RLE class. Read the appropriate data into a MemoryBlock and decode into another MemoryBlock (your pixel map) and the RLE class, then do pixel-level manipulations on a Canvas class using the pixel map.
Actually, it would probably be faster to do the pixel-level manipulations on an RGBSurface and then paint that to the canvas once you were done.
------------------ David Arthur @ (url="http://"http://davidarthur.evula.net/")davidarthur.evula.net(/url) (url="http://"http://www.ev-nova.net/faq/")EV Nova Gameplay FAQ(/url) - Now Hosted by (url="http://"http://www.ev-nova.net/")EV-Nova.net(/url)!
Originally posted by shado83: **It wasn't until a few days ago that I found out EV's engine (EV, EVO, EVN) is actually based on SpriteWorld - makes sense why the rlë8/D format is exactly the same as the RLE# format used in SpriteWorld!
Note that EV and EVO's engine was based on Sprite Animation Toolkit, the original sprite library that was then surpassed by SpriteWorld. SAT development ceased and was never Carbonized, so the EV engine was re-written using SpriteWorld for EVN (which allowed the use of RLE sprites). The latter is what I have been trying to stress: Since the EVN engine is based on SW, the ONLY difference between SpriteWorld's RLE# resource and EVN's rlë8/D is the name. SW will load all of EVN's graphics flawlessly and without complaining.
I'm still here and Novaburst is gonna see some actual work now. I'm loking into building a RB RLE kit based on sprite world. I'll release it if I can get it to work.
I hope to get it out. BUt the old version is still up. (url="http://"http://snow.prohosting.com/thorprim/index.html")Site here(/url)
------------------ (url="http://"http://snow.prohosting.com/thorprim/")NovaBurst Home(/url)
I've been out of the REALBasic game too long - I've never heard of an RGBSurface...or maybe I've just forgotten...
In any case, since a few people are interested, I'll explain the whole thing here.
The idea behind tokens/multiframe animation is pretty simple. Each token is 4 bytes, a C long. The high word's high byte (the A in ABCD if you stick the four bytes together into a long) is the token type. The valid tokens are 00 (end of shape = end of frame), 01 (new line), 02 (draw pixels), 03 (skip pixels), 04 (single colour draw).
The above are all hex, by the way (one hex character = four bits)
The other six hex characters (the remaining 24 bits) tell you how different things depending on the token:
00: The other numbers shouldn't be there : )
01: The remaining 24 bits describe how many bytes (BYTES, not longs) until the next new line token, not inclusive.
02: The remaining 24 bits tell you that the next N bytes are pixel data, so the token 02000004 (in hex) would be followed by 4 bytes (8 hex characters) of pixel data. Of course, whether 1 byte = 1 pixel or 2 bytes = 1 pixel depends on whether you're using 8 or 16 bit rle's, but the same algorithm can be used for both with no modifications (lucky, hey!).
03: The remaining 24 bits tell you how many pixels to skip.
04: The remaining 24 bits is the number of pixels you should fill with colour described by the NEXT FOUR BYTES. So, on an 8 bit system, 04000010 000000FF would mean fill the next 16 pixels with the colour at index 255 in the colour palette used by the RLE. For the default palette this is black.
It's just as simple as that. I hope every developer can approach the EVN rle's without fear now. As AriosSW said, SpriteWorld uses exactly the same RLE format except that the resource name is different, so if you're using C, save yourself the time and effort.
By the way, each frame is delineated by an end of shape token, so using this and the numFrames field you can easily find where each shape begins and ends. The trick (and this is important!) is keeping your memory pointer aligned so that when it reads a LONG (4 bytes) it always reads, say 01000000 instead of 00000100. This is because whilst the tokens are 4 bytes, the pixels are either 1 or 2 bytes, and so the pointer can get misaligned during the draw and single colour draw operations.
Enjoy your programming!
By the way, unless it's already been taken, I'm changing the name of my project to NovaLord. When I released EVOGod a lot of Americans complained it was insulting to their religion, and whilst back then I was a headstrong young lad who didn't care, now I would prefer if people could just use my program without worrying whether their deity will strike them down for using it : )
I'm also going to have a sister application NovaFace, which will be used to edit the inferface (the ďntf and cölr resources) of EVN. It will be separate because if I included them I'd have 14 editors, which doesn't have the graphical symmetry of 12 editors. You'll understand when you see the main plugin window for NovaLord.
Are you taking on testers? Me
------------------ Upcoming website, for the(url="http://"http://www.evula.org/godsunderstudy") New Era (/url) TC. Look out for the New Era!
Originally posted by shado83: ** <snip> **
Nice to know you are changing the name. I didn't like the 'God' part on EVOGod, so I kinda just let it be.
------------------ "Moronic User Error. Details:If I had hands I would slap you silly." "It must be a common fault. I see that error message all the time."-(url="http://"http://freefall.purrsia.com/")Freefall(/url) "I told you never to speak of that again!" "...and I chose to ignore you."-(url="http://"http://www.peterandcompany.com")P&C;(/url)
Originally posted by no_use_for_a_name: **Are you taking on testers? Me
At the moment I only have the main window, preferences management open/save management, resource access and list management things working, I'm not really at the stage where plugins could be used to test NovaLord. I have a few quick hacks like my RLE editor and so forth just to see what I could do with Cocoa, but the application shell has no editing features at the moment, although it is progressing very quickly and should be fully operational in a week or so.
A quick reminder - NovaLord/NovaFace are OS X only. Testing will be commenced on the main application when all the preferences/lists/interface features that are independent of any specific editors are completed, and I will outsource testing where possible.
Originally posted by shado83: **I have a few quick hacks like my RLE editor and so forth just to see what I could do with Cocoa, but the application shell has no editing features at the moment, although it is progressing very quickly and should be fully operational in a week or so.
Hehe, EVONE was started on January 28 of this year, and is just now becoming fully operational. That is the difference between Carbon and Cocoa.