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).
Huge ship with 72 frames getting messed up
Okay. The ship has 72 frames, and I've never made one with more than 36 before, so it's possible I'm missing something very basic. The sprite has been laid out as a 9x8 grid, unless I'm mistaken. It rotates perfectly fine in mission computer, however ingame it rotates clockwise by 180 degrees, then snaps back to the first position as if the other 36 frames aren't there. It also appears to fly sideways. I'd appreciate any assistance to resolve this problem.
edit
I hit export sprite and it looks like missioncomputer is treating the ship as a 6x12 sprite. I wonder if this could be why I'm seeing the behavior that I am, maybe it's looking at the top six rows as a single 6x6 rotation. Not sure how to fix that.
This post has been edited by Shlimazel : 27 February 2010 - 04:56 PM
PICT or RLED? What's the shän look like?
It's a straight up, no frills RLED rotation. No special rotating frames or anything, just a 72 frame rotation. Looking at the stock nova files I have noted that none of them use a 72 frame rotation, they seem to use a 64 frame rotation which is divided into an 8x8 grid for the larger ships. Maybe I should go with that? I'd hate to redo a half hour render unnecessarily...
I do not replicate your findings. What is the size of your RLE resource in bytes? Could you please post a plug-in containing only the shän resource?
In the meantime, here is a plug-in I made quickly on my Mac to demonstrate that a 9×8 sprite turned into an RLED works fine for a ship in EV Nova. I've converted the plug-in to .rez for easier distribution, but it was made with MissionComputer. Shuttle_Test.rez.zip (993bytes) Number of downloads: 1 The sprite starts red then changes in an obvious manner to blue then back to red, with every frame clearly identifiable. If it only showed 36 in-game then there would be a sudden jump from all-red to all-blue. There isn't. Each frame is displayed in the proper order.
I used MATLAB to automatically generate the 24×24 frames which I saved as PNG files with the imwrite command. Then I used p2s to make one big grid of these, with nine across and eight down. EnRLE easily turned that into an RLED, and I made a shän for it in MissionComputer. When I click Export Sprite, I see a 6×12 grid. When I start EV Nova and fly a shuttle, all the frames work properly.
CTC-C uses sprites with 108 frames (36*3) and does not exhibit this behavior on Windows or OS X.
This post has been edited by JacaByte : 28 February 2010 - 04:43 PM
Shlimazel, did you have MC make the shän resource for you or did you make it manually? Also, you're sure the shän resources checks out? It's set to 1 base set count, the right base size, the right frames per spin? Other than those, the only reason I can think of for you to have a problem would be for there to be a bug in your copy of MC or a bug in the file with the RLE or the shän.
I've had this problem before, though I can't remember what caused it. Though, it may well have something to do with the FramesPer not being set to 72, or however many frames the ship is, in the shän. Perhaps, it's set at 64 or 36? In the section between Light Image and Blinking in MC.
QUOTE (Shlimazel @ Feb 27 2010, 04:49 PM) <{POST_SNAPBACK}>
The sprite has been laid out as a 9x8 grid, unless I'm mistaken. ... I hit export sprite and it looks like missioncomputer is treating the ship as a 6x12 sprite.
RLE resources actually contain a string of individual frames; the grid is just a way of getting those frames in and out of the RLE, and a holdover from the old PICT method. There's no grid inherent in an RLE resource, so when MissionComputer exports just picks arbitrary numbers that multiply out to the right number of frames. It doesn't mean that there's anything wrong with the resource.
If the RLE spins properly in MissionComputer but the sprite is wrong in the game, that suggests that the problem is more likely with the shän resource than the RLE graphics. If you post its contents we can probably tell you more.
I was looking at not being done with a ship I'd been working on all day last night, so I said screw it and rerendered it at 64 frames instead of 72 frames. This time it worked perfectly, with no problems in MC or ingame. I haven't figured out what the original problem was, but I'll simply render any large graphics with 64 frames to dodge the issue from now on.
QUOTE
I had MC make the shan for me, and yes all those things checked out on the original sprite. Like I said, it displayed perfectly in MC rendered in as a 9x8 grid at 72 frames, but ingame it appeared to be skipping half of the frames, and also I think it may have been flying sideways.
I checked that, sadly it was set to 72 frames as it was suppose to be, so that wasn't the culprit.
Okay, I see. I didn't realize that. My mistake.
I'm afraid I didn't see the request for a post of the Shan yesterday and overwrote the shan when I rerendered it at 64 frames. I might be able to dig up a copy of the 72 frame sprites though and set it up again, I'll take a look.
I found the old sprites and remade the Shan. There's not a lot to see, and I can't really give you the RLE, unfortunately. I don't know if this will be of any use or not, but you're welcome to take a look.
This post has been edited by Shlimazel : 28 February 2010 - 10:54 AM
The file you posted contains no resources Nova uses. You either need to use Plugin Archiver to make a .bin.zip, or use MissionComputer to save as Windows format and upload it as .rez.zip.
In addition to seeing the shän, I'd also like to know how big, in Bytes, are the 72-frame rlëD, and the 64-frame rlëD. I am 99% percent confident that with those three things, the problem and its solution will immediately be apparent.
...I did use plugin archiver. WTF..... I'll have to re-upload it apparently. How do I find the byte size of the rleD?
In MissionComputer, select the resource and Get Info on it. That's tell you in KB. Or open in Rezilla and you'll see the exact size of each resource in bytes. Either way should be good enough for now.
Okay, thanks. I checked this file to make sure, and it expands properly for me. If it doesn't work for you, let me know.
According to MC, all the shans in my file are 192 kb in size.
I want to know the size in KB of the rlëD resources.
The shän you sent works perfectly. I made my own 688×688 rlëD with 72 frames. The only change I made to your shän was setting its ID to 128 so it replaces the Shuttle graphic. Sprite_Test.rez.zip (2.93K) Number of downloads: 1
Ugh, sorry. I'm trying to prepare for a party as well as post, so I'm afraid I got a bit mixed up. The size of the (functioning) 64 frame graphic is 6.1 MB, which I believe that makes it 6100KB, correct? The original (non-functioning) 72 frame is 6.7 MB, or 6700KB.
Okay, the possibilities I see are:
Perhaps the original shän was incorrectly set to 36 frames instead of 72. Perhaps the plug-in file is over 16MB. Perhaps there is an issue with individual resource sizes above some threshold between 6.1 and 6.7MB.
For reference, here are the known limitations of the resource fork, including resource file size: http://www.ambrosiasw.com/forums/index.php?showtopic=20693
This post has been edited by Qaanol : 28 February 2010 - 03:05 PM
Actually, a megabyte is 1024 kb, same with a gigabyte being 1024 mb. So 6.1 mb is actually a bit more than 6100 kb. According to my calculator, it's actually 6246.4 kb. I don't know if that really makes a difference to you, though.
What I'm curious about is if Windows .rez files are subject to the same data limits. I haven't attempted it, but it would seem that the .rez files, based on the data fork (since resource forks don't exist on Windows,) shouldn't be subject to those limits, yes? In a related question, are the new .ndat formats still based around the resource fork? I'm just thinking that if Nova could be updated around the data fork, as in WinNova, perhaps we could do away with some of the unwieldyness of the resource fork. It would also benefit from a single file format between platforms. I'm something of an amateur programmer at best, so I'm guessing there is probably a good reason why this is not a viable idea.
Perhaps the original shän was incorrectly set to 36 frames instead of 72.
I can confirm this was not it. MC automatically set it to 72 frames and I didn't tamper with those settings.
Perhaps the plug-in file is over 16MB.
I had already split the file to avoid that problem and can confirm that it was under that limit.
Perhaps there is an issue with individual resource sizes above some threshold between 6.1 and 6.7MB.
That is entirely possible, and could be the problem. This warrants further testing.
Understood, that's interesting. Thanks for the clarification. That might be useful if I sit down to do exhaustive testing to see where the limits are. Maybe when I go to try to fix AbsoluteMinimum I could poke into that as well.
Maybe Mission Computer just hates you.
QUOTE (krugeruwsp @ Mar 1 2010, 08:58 PM) <{POST_SNAPBACK}>
What I'm curious about is if Windows .rez files are subject to the same data limits.
.rez is an entirely different format from the resource fork stream, and isn't affected by the old format's limits. It does have some limits of its own, but you are unlikely to encounter most of them; since it's more than twenty years newer than the resource fork, it was designed contemplating much larger files, and so the various parameters giving offsets support much higher values.
For this reason — as well as for increased compatibility and to escape dependence on the ageing Resource Manager — I have lobbied for the Macintosh version of EV Nova to support .rez files, but without success. In the mean time, it's still necessary for plug-ins to comply with the limitations of the resource fork, since they'll inevitably need to be converted to it at some point.
(And yes, I can confirm that MissionComputer calculates sizes using real, base-1024 kilobytes and megabytes, rather than the base-1000 nonsense that the hard drive industry have been pushing so that their disks sound bigger.)