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).
Woe is me...
I'm working on my loading screen and opeing screens and the colr resource is giving me headaches! Here is the end of my debuglog...
beginning version check setting up main screen graphics doing main screen warning: button slide animation image has wrong dimensions
I am getting to the opening screen (new pilot, etc) and the game is freezing there, forcequit being my only option. All of my spin resources for them are correctly filled out and are working in ResEdit. Is this another instance of our etuff being limited by the way that the ATMOS game was done? I was using my button slide animations for something else so they are not the ATMOS size, as it indicates in the debuglog. Has anyone else gotten to this point in thier TCs? Any experience? This colr resource seems about assinine!
Correct the slide animation sizes. My guess is you've got the spďns wrong.
I heard something about needing the same number of frames that they used, or an odd number, or something strange like that. Im pretty sure the dimensions themselves don't matter, so long as they all match.
The spins are internally self-consistant- they themselves are fine. It is something having to do with the opening screen itself. I REALLY don't want to be limited to the ATMOSian setup, sizes or positions here! What's the point of being able to customize this stuff if we end up having to do it just like the ATMOS crew did?
Nothing personal against them, of course.
Umm, you can definitely change it. UT proved that. You are not limited to ATMOS's chosen sizes or positions. As for the number of frames...I don't know.
I did not have a high-speed internet connection when the SFA public alpha was available so I can't check that. Perhaps I'll check Polycon....
Well, I cheated -- I made each animation a pixel by a pixel, nothing happening (but the same number of frames), and then lined them up in the upper left hand corner right next to each other. They're still there, and they still "animate," but they have no effect on the image.
It definately doesn't have any strong need to have the original button slide-in graphics (on a Mac, at least). One of my project doesn't even have the spins or PICTs for them, and earlier it used re-sized and -positioned ones.
I'd recommend temporarily replacing them with the original graphics, seeing if the problem goes away, and then re-building the buttons from your original image files (if they're the problem).
Edwards
This post has been edited by Edwards : 07 October 2005 - 12:20 AM
Thanks, everyone, for the suggestions. I'll work on that today and see if I can't take some notes and put them online somewhere after I get it working.
Here's the damnest thing: My 'logo' spin was one frame- this was somehow the problem! Making it seven identical frames in a manner similar to the ATMOSisn logo fixed everything right up (and made me realize that I have lots of design work to do!).
Thanks, everyone
You mean the flaming ATMOS logo? I've replaced that with a single black dot without crashing (in the EVO port).
That is exactly what I refered to. I took Edwards' advice and replaced everything with stock and added in elements one at a time. I had everything changed out except the flaming Nova logo and, when I swapped in my one frame logo, it crashed the game. As in it would stop playing the music and just sit there unresponsive in need of a force-quit, just before it would draw the buttons. What is odd is that it would draw the logo! When I swapped in a logo consisting of seven identical frames (and a spin to match; I maintain that my spins have been internally consistant) it would work. So I am somewhat mystified as to why this worked, but I am not complaining.
Nova seems to pick a random image from the set of seven when it rotates it. So it was picking, say frame #4 out of 1 frame, and confused itsself.
Try leaving the spin the same but making the actual sprite just a single black pixel.
rmx256, on Oct 7 2005, 05:05 AM, said:
Here's the damnest thing: My 'logo' spin was one frame- this was somehow the problem
Ah, yes. That blasted thing. I solved that crash with a two-pixel PICT and a two-frame spin. One frame doesn't work, and I don't know about multiple frames with one pixel (although from what Guy says, it may work).
And remember: If it doesn't work, get something that does work and break it.
UncleTwitchy, on Oct 6 2005, 08:48 PM, said:
Yes, but you still proved that they can be changed.
Anyways, I've experienced this exact behavior under similar conditions in the past (meaning it did the same thing to me when I had a one-frame logo). It's nice to finally know why the hell it happened.