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).
Guy, on May 26 2005, 08:52 PM, said:
Ah, that works. Unzips and mounts by itself. Wow, I never knew this was out! Ah, I see it was on the EV boards. Nuts, looks like stuffit 9.0.1 doesn't work with it.View Post
Yup, 9.0.1 doesn't work. Find an earlier version of Stuffit (I can send you one if need be), and drag only the first file into the expand window. Everything should work, and you should get a ~64MB folder.
@Zacha Pedro: I like. It's very nice to be able to see the ends of some of those big ships, and it's also fun to have more than one spinning at a time (next up: try to get all the big ships from nova spinning onscreen at once. Will they all fit in one file? Find out next week!).
Edwards
Edwards, on May 27 2005, 03:05 AM, said:
Edwards View Post
Actually, I only wrote that because I read the topic where you mentioned that. After downloading it I found it expanded perfectly fine with 9.0.1. Seems it wasn't designed for big screens though - I can see a flashing "Port Authority" below the main menu.
And as for the app, what'd really be neat is if it could overlay multiple sprite sets so you can see engine glows and lights and stuff on the ships.
Guy, on May 27 2005, 10:27 AM, said:
And as for the app, what'd really be neat is if it could overlay multiple sprite sets so you can see engine glows and lights and stuff on the ships. View Post
That's pretty easy to do, My host program actually did that. It is very trivial, just remember that the lights and glows and stuff are centered. If you don't, your ship and the engine glow will not match up because the ship rectangle is smaller than the glow's rectangle.
Hmm... Not that itÂ’d be hard to do (though it would require me to rethink the UI, suggestions are welcome), but itÂ’s low on my list of priorities.
I’ve done some progress on it (making the initial open file dialog movable and resizable, reorganising the code, stuff like that...), but I won’t realease a build right now since I’ve modified the main window to include more controls and what they do isn’t implemented yet for some of them... especially, I’m currently working on allowing you to close a file, so that you don't have to quit and relaunch to open another (no more than one file at a time though). The next thing I will do is, instead of precalculating all shape as Byrce’s code does, is keep the resource around and redecode each frame as it is needed - this will allow the app to consume MUCH LESS memory, especially when you open many big rlë’s. However, this will require me to make important optimisations to the decoding logic, so that it work acceptably even on lower-end machines (coding in PowerPC assembly is not excluded...).
Then after that, think about the possibility to open more than one file at a time. However, what would the user interface to do that be? Have as many of the windows, currently named “Control Window”, as open files, or just one? But if the latter, how to specify which file to close? I await your suggestions.
Double-post (I had mistakenly hit return when making the post below, and managed to stop the browser from going on allowing me to continue typing the post, but apparently it didn't prevent it from being sent).
This post has been edited by Zacha Pedro : 06 June 2005 - 09:16 AM
All right, here's a new build. Contrary to the previous ones, I made modifications to Bryce's code, so I feel obliged to make these public. I'm removing the old builds from this topic - they have no reason to keep taking up my attachment space.
As always, you'll need the main.nib (and other such stuff) found in the app to rebuild it.
EDIT: oops, loks like there's too much text for the poor IPB. Let me improvise.
(attachment=726:attachment)
This post has been edited by Zacha Pedro : 06 June 2005 - 06:20 AM
Yup, there's rEV's Confed Cruiser spinning smoothly in a window on my screen, with its engine glow spinning in a second window and the Escort Carrier in a third. Very nice, ZP and Bryce! Thank you!
"Copyright 2005 the EVDC" -- Clever, but perhaps too vague to have any legal effect? Probably not important.
This will hopefully save me from having to fire up Classic so I can view sprites in NovaTools from time to time, but I'd like to second the suggestion that you make it deal with overlaying sprites atop one another -- that would make it even more useful for "flightchecking" sprites to see if they line up. Another quick addition would be to list resource ID next to resource names in the pull-down menu, so both are easily accessible when building a spin or shan in MissionComputer.
EDIT: And if you don't want to claim "copyright" for yourselves, at least put "by Zacha Pedro, based on work by Bryce" in the "About" box so we all remember who to thank.
This post has been edited by Dr. Trowel : 06 June 2005 - 09:23 AM
Dr. Trowel, on Jun 6 2005, 02:25 PM, said:
Yup, there's rEV's Confed Cruiser spinning smoothly in a window on my screen, with its engine glow spinning in a second window and the Escort Carrier in a third. Very nice, ZP and Bryce! Thank you! View Post
Hey, what do you think I'm testing this app with? rEV's bigass sprites have been the basis to test my memory and CPU usage in the worst conditions possible (I don't think anyone is reasonably going to do much more than that ). In fact, with the previous versions, when I loaded all the sprites from ~Cruisers Large it was taking up more than the physical memory of my computer, which meant it was constantly in need to reload each precalculated shape from disk where it had been paged out of physical memory, as it was the least recently used... Thus, it was going at the speed of the hard drive (i.e. SLOW). Having a 800MHz iBook G3 with Jaguar sure helps supporting lower-end configs...
Didn't get time to tell what was new with this version: - Sprites are now decoded in real-time instead of being predecoded at loading (which took some time during which no interaction was possible, and which took abusive amounts of memory). This means that CPU usage is likely more than before, but the more frugal memory usage should more than compensate for that! - Ability to close the file currently open, open another, etc... with still only one file open at the same time. To support that, various enhancements of the controls of the main window have been done (disabling rlë-related controls when no file is opened, disabling the rlë8 popup menu when there are only rlëDs (and conversely), etc...) - Now the app prevents you from opening a rlë that's already open, by selecting the window displaying it if you ask to load it.
I ask for your attention on the last feature: if, by any way whatsoever, you sucessfully invoke two windows containing the same rlë, then it's a bug, and I want to hear about it (note: invoking a rlëD and the corresponding rlë8 doesn't count, it's normal operation), whith instructions on how to trigger that and preferably a screenshot. This is because, when the first window would be dismissed, it would release the underlying resource in memory and the second window would cause the app to crash as it counts on the same underlying resource as the source of the data to decode when attempting to compute the next frame. Especially, the app knows a resource has already a window displaying it only by the mean of the diamond mark of the corresponding menu item! Should it be corrupted (by, say, the popup menu control which might try and add a checkmark to the currently selected menu item and remove the diamond one), then this check would no longer exist and the app wouldn't be reliable.
By the way, here are the sources, all in a zip archive - this is really to much text for IPB to cope with in a post, even in a codebox. Notice I put the actual decoding logic in a separate "decode.c" file, that has quite optimised, error-checking-less, rle parsing code. In fact, I'm now studying the assembly code that gcc generates from it to know if I can enhance it even more. The old parsing code is kept (but commented out) to be later used as a mean to debug an rle before displaying it: it will parse the rlë data, without generating an image from it, to check it when loading the resource to know if it is valid - if not, it will generate a detailed warning, which could be useful when writing rlë's by hand or an rlë encoder.
(attachment=727:attachment)
Since so many people are asking for overlaying, this is what I'll do next (instead of opening more than one file at the same time since I still don't know which UI design would be best for that). I have some things to ask first: - Are you 100% sure that all rlë's have an even height and width? Since I need to align them with their center, this is pretty necessary, as for an odd size the center is exactly on a center pixel while for an even size the center is in the corner between 4 pixels. - What would the best UI design for doing that be? Drag and drop (warning: not sure I can do that...), new button "overlay on existing window" (which would after clicking it let you click on the window on which to overlay the rlë currently selected in the popup menu), other? And should I allow removing one overlayed rlë from a window, instead of having to dismiss the window and start over? - More accurately, how do the various components (light, alt frames, weapon glow, shield, engine glow) add to the base image? It seems to me light, for instance, has its color components added to the base image (otherwise, we would have some ghosting black surrounding the lights), while others may be simply applied on top, replacing the contents below.
EDIT: oh, yeah, forgot about the about box. I will put a serious one.
This post has been edited by Zacha Pedro : 06 June 2005 - 10:17 AM
All RLEs do not have even heights and widths -- on my Mac, they work in-game regardless of this. My guess is that any wobble created by the center of rotation being slightly off is too small to notice.
I'll attach a rle8 with uneven dimensions for you to experiment with. It's a highly unusual image, but it's what I've got! This seems to work in your program just fine. (The image looks better in the rleD, but of course the file is much larger.)
Volcanobubble
This post has been edited by Dr. Trowel : 06 June 2005 - 10:54 AM
I have a 333 mhz G3 upgraded Power Mac 8500- in OS9: that's lowend if I've ever heard it- and it runs 2 640*480 72 frame with banking and engine flares ships at about 6 fps with other ships in the system, if that's any help... A bit lower-end, and shows that it is possible to use big, oddly shaped sprites in a somewhat usable form...
Zacha Pedro, on Jun 6 2005, 09:15 AM, said:
Hey, what do you think I'm testing this app with? rEV's bigass sprites have been the basis to test my memory and CPU usage in the worst conditions possible (I don't think anyone is reasonably going to do much more than that ).
Having a 800MHz iBook G3 with Jaguar sure helps supporting lower-end configs...
- Are you 100% sure that all rlë's have an even height and width? Since I need to align them with their center, this is pretty necessary, as for an odd size the center is exactly on a center pixel while for an even size the center is in the corner between 4 pixels. View Post
Zacha Pedro, on Jun 6 2005, 03:15 PM, said:
- What would the best UI design for doing that be? Drag and drop (warning: not sure I can do that...), new button "overlay on existing window" (which would after clicking it let you click on the window on which to overlay the rlë currently selected in the popup menu), other? And should I allow removing one overlayed rlë from a window, instead of having to dismiss the window and start over? View Post
Maybe you could have another pop-up box saying "Open in:" with the options "New Window" plus all the existing windows.
New features will be delayed by the time required for me to make sure I correct all my big-endian assumptions, due to WWDC news.
I'm back. I evaluated all the endian-swapping issues, and I think I nailed them down. Of course, this is something I can't really know, since I don't have a x86 system to test, but at least it's done. Better do it as soon as possible.
As I was at doing this (mainly in the now-optimised rlë parser), I thought that it would crash real fast when confronted to a faulty rlë. This is something I intended, but then I thought of people who might wish to test rlës they wrote by hand or who are testing an rlë encoder they wrote. So I added a new parser, that reads the whole resource (and not just one frame) at once when it's first loaded (before the window shown up), but without generating an image, just checking the rlë is valid. I made it so that as much information about the error is returned (which error, with which token, at which offset in the resource, etc...) in the prospect the rlë hacker can fire up ResEdit (or just any other hex resource editor) and check what's wrong really quick. Writing the parser didn't take much time (just that I had to devise a way to return the error), but presenting the information in an acceptable way took much more. Even now a problem remains: in the alert window that warns of an erroneous rlë, the detailed information should be able to be copy-and-pasted (for future use), but I've only been able to acheive that with an editable text field, which means you can erase it - and locking text edition prevents from selecting. So I'm not uploading a build since this may not really be acceptable, though it's a bit minor since not many people will see that anyway. So, yes, I spent my weekend working on a feature 99% on users will never see anyway. Go me.
Sorry for the hiatus folks, but I've been kept real busy and completely forgot about that. I did not really find a solution: the text of the detailed information still can be modified and erased (I tried another solution which would be blocking text input events but that in turn brought other unacceptable problems and didn't completely solve the issue). Therefore, here's the app with the debug parser. Please be mean with it. Send it your worst, most buggy rlës you wrote yourself, pure garbage, existing rlës to which you made the wildest modifications, everything. The app shouldn't crash. If it does, it's a bug (well, okay, it's always a bug, but now I explicitely support crashless operation on buggy data).
Since now the source code is too big to fit in a post and thus I have to put it in a .zip, as I'm at it I'm including the Project Builder project file (that XCode can import) and main.nib so that you can build it without the build, in the zip archive.
And here is the source:(attachment=828:attachment)