ViewRLE

now on OS9!

All right folks, while I was mostly away from the 'Net in August, I worked on back-porting ViewRLE on OS9. First I had to identify any OSX-specific stuff I was using (besides Quartz, which was obvious), then use OS9 stuff to replace them (say, QuickDraw instead of Quartz). Then I had to get a development environment which could target OS9: The Macintosh Programmer's Workshop (usually known as MPW). Then compile the code, fix the compilation problems, then run the stuff on OSX (since my app is Carbon and requires CarbonLib, the OS9 build also runs on X), fix some bugs, then run it on 9, fix MANY bugs adn change some stuff that didn't really run well on OS9 (say, the popup menu diamond marks were replaced by a checkmark each time they were picked, leading to problems, so I scrapped the popup menu altogether and replaced it by something that makes better sense), then package it in a nice almost-universal bundle, that contains an OSX-specific build and an OS9 build (that could run in OSX, but this isn't supported) that even contains a mini 68k app that tells the user of a 68k machine that it requires a PowerPC, courtesy of BurgerB..., ironically... Just let me add an Intel build (the code is ready for that, just wait I get Tiger...), and you get a really wholly universal binary (68k, PowerPC, OSX, x86).

It should run without problem, provided you meet the requirements, which are... mostly unknown. Indeed, I don't have an OS8 computer to test on, and though I'm pretty sure I'm using OS9-specific stuff, I'm not really sure and hence the prog does not check for appropriate system specs before going on; therefore it will likely crash. Same thing for CarbonLib: I think version 1.3 is enough, but I couldn't really try. Please tell me if it does work for you, with which system and CarbonLib version. However, one important problem (which I'll try to fix) is that, if the app runs out of memory, it doesn't even realise it and tries to use the memory it requested but that couldn't be allocated and... crashes, yes. this shouldn't happen unless you lower its memory partition or open a ridiculous number of RLEs.

Another thing: dmgs don't work with OS9, and .sit cannot keep important UNIX stuff such as the execute bit, meaning I have to distribute this in .sitx, therefore OS9 users will have to get the latest Stuffit expander they can download (7.0.3) in order to get ViewRLE. Due to stupid IPB limitations (extension of uploaded files), it has been uploaded to my webhosting, you can get it at -removed linky- . The source is attached to that post, it includes notes on the OS9 porting process, and a MPW makefile (with of course as usual the Project Builder project).

EDIT: I've removed this old version and its source. Please grab the official release at the Nova add-on files. Thanks!

This post has been edited by Zacha Pedro : 03 December 2005 - 05:14 PM

Nice, good work. I thought you were implementing overlaying though - is that still happening?

You could use a gzipped, but not compressed by Disk Copy, disk image for us OS 9 users. Just use the OS 9 Disk Copy. That even a Quadra user that can't use CarbonLib can crunch.

Guy, on Sep 18 2005, 04:52 AM, said:

Nice, good work. I thought you were implementing overlaying though - is that still happening?
View Post

It's still hapenning, I'm taking care of this now. I wanted the OS9 backporting to be a surprise, so I didn't talk about it.

The Apple Cřre, on Sep 18 2005, 05:49 AM, said:

You could use a gzipped, but not compressed by Disk Copy, disk image for us OS 9 users. Just use the OS 9 Disk Copy. That even a Quadra user that can't use CarbonLib can crunch.
View Post

Good remark, I'll investigate this (though a Quadra user can't run my prog, the Quadra being a 68k machine).

This post has been edited by Zacha Pedro : 18 September 2005 - 03:53 AM

I love it zacha.. the rotation speed is also much better then the novatools one.

I still have my Centris 650 somewhere if you need a tester

Zacha Pedro, on Sep 18 2005, 03:52 AM, said:

Good remark, I'll investigate this (though a Quadra user can't run my prog, the Quadra being a 68k machine).
View Post

Guy, on Sep 18 2005, 04:52 AM, said:

Nice, good work. I thought you were implementing overlaying though - is that still happening?
View Post

Just a note to let you know I've gotten overlaying to work very preliminarly: the principle works. Right now however only the first frame is shown, the different parts have to be the same size and same number of frames, it crashes from time to time, only rlë8 works and all other such wonderful stuff. Indeed, I need to change the structure of the app a bit so that a Sprite can know it commands more than one resource, not to mention doing byte-by-byte addition with saturation without any SIMD instruction (AltiVec or SSE) in an efficient way is hard, you wouldn't like to see the code.

Unfortunately, I am ill right now (vomiting and diarhea) and though this means I'll remain at home these days, this doesn't mean I'll be very much in shape to work on this.

Gahh... not that stuff. That took my dad out of comission for the better part of a week a while ago.

I'm pleased to report overlaying is working perfectly, with all possible esoteric combinations (yeah, I took some time, I was busy finishing Avernum 2). I was worried performance would be a problem, especially given the complexity of calculations at hand, but apparently (especially on my iBook, since Apple laptops recently have had abysmal frontside bus speeds) the main bottleneck is memory bandwidth and not CPU usage; still, I did well to optimise my code, though perhaps a little too much with the PowerPC in mind: given the way it is written, it should shine on a late G4 and G5 especially given their munerous integer units since there is much parallelism. There are just two problems however: you can't play with it yet, since I need to rewrite the overlaying decoding engine for QuickDraw for it to work on OS9 as well, before I distribute it, and while running lights, weapon glows and engine glows (and, I suppose, shield bubbles) are overlayed in-game by adding the colors components, this isn't the case for the alt frames (which it seems mask what's behind), but my app has no way in hell to know which part is an alt frame and which is engine glow so it simply adds the color component for all that's overlayed. The net result is that, for the Thunderforge for instance, you have a one-pixel wide white strip where the alt frame (the rotating middle section) and the rest of the ship touch... but you will notice NovaTools does that as well (and NovaTools does know which is which since it knows about the shän, so no excuse there)! So you will admit with me that this is a pretty minor issue...

When I will distibute this version, this will mark an important milestone: I will give it a version number, and will be 1.0.0b1. That's right, it's entering beta. It will be a public beta of course, and I will even post it to the Nova board for them to test (heck, you don't need to be a plug dever to use this!), it ought to resist to their assault. Then once it will have been tested enough I will upload it to the add-on files as an official release. This means the feature set is rather frozen, i will add anciliary features and probably make it easier to use but I won't embark on radical changes such as supporting opening more than one file at the same time, I want to get it tested and released first.

Yay!

Thanks for the continued os 9 support

Woo, go Zacha This should be pretty cool.
Now make a fully fledged shan editor for version 2.0

How exactly does that work, adding the color component? Is it something as simple as average the two colors? As in, (200,0,0) + (0,0,200) = (100,0,100)? Or is it more complicated?

Nope. It's more like (200, 0, 0) + (0, 0, 200) = (200, 0, 200)... except that, given the max is 255, this means (200, 0, 0) + (100, 100, 0) = (255, 100, 0). So contrary to before where I just had to get the data off the rlë, make a simple transform on it (lookup the palette for rlë8, extend to 8-8-8 from 5-5-5 for rlëD), and put that in the output buffer, I have to get the data off the buffer, extract the color components off it, extract the color components off the rlë, add the color components one by one, check if result is more than 255 for each color component and replace with 255 if yes, while avoiding "if (result>255) {}" constructs that are not efficient, stuff the color components back together and put this back where I found it in the buffer. For every single non-transparent pixel for each image to be overlayed.

Such stuff is why SIMD (Single Instruction, Multiple Data) extensions have been designed (AltiVec on PowerPC starting from G4, MMX then SSE on Intel): they take a bunch of data and apply the same operation to all of them at once (yes, among these instructions is adding bytewise with saturation); unfortunately there is none on the G3, which happens to be the processor I'm using.

Zacha Pedro, on Oct 14 2005, 01:05 PM, said:

Nope. It's more like (200, 0, 0) + (0, 0, 200) = (200, 0, 200)... except that, given the max is 255, this means (200, 0, 0) + (100, 100, 0) = (255, 100, 0).

So, it just adds them together and makes it 255 if greater than 255? Hmm.

By the way, isn't 16-bit color 5-6-5? It certainly couldn't be 5-5-5, and from memory, isn't green generally given the extra?