This content has been marked as final. Show 6 replies
Seems like you have too much code inside a loop or a if condition. The player can only jump 32KB of bytecode, so there's too much going on inside a single statement. It could also be that some class is too big. Try to rebuild the code in smaller parts, or use additional classes that handle parts of the action.
ugh...Ok, so the error doesn't give any indication -where- this code is, and "32k of bytecode" isn't exactly an intuitive measure. I broke up a couple of functions, but what, am I supposed to redesign every large class, function and block in my entire program? That's an enormous and absurd task. My classes are too big? Please. This isn't an error on my part, it's a glaring flaw in Flash. Is adobe doing anything about this?
I've also confirmed that Flash is not reflecting some changes in my code. I have to close it and reopen it to get the changes to show up. Deleting ASO files doesn't do it.
I'm pretty frustrated. I'm trying to finish this project off, and Flash complete craps out on me...
I'm sorry but this is your fault. Flash wasn't initially desgined to be used to write larger programs like games in, the fact that it can shows how flexable the program can be.
You code should have been written, from the start, into smallest blocks that is logically acceptable as this is arguably the whole point of being a good writer. Remeber OOP is your friend.
If i was you, now you have written so much, i would work backwards. Find the largest loops/conditional statements and start to break them up then work down into the smaller ones until your game compiles again.
As to flash not reflecting changes made, this may not be your fault, i would try reinstalling if nothing else works.
> I'm sorry but this is your fault.
No .. its a bug in the compiler that it incorrect compiles code. It could
be changed so that it works correctly (by jumping to jumps). There is no
way one can blame a compiler generating bad code from correct script on the
person writing the script!
> Flash wasn't initially desgined to be used to...
That's just a reason being used as an excuse. Yes . .there are reasons why
it is that way.. but that does not mean there is not a bug and not a
> You code should have been written, from the start, into smallest blocks
> is logically acceptable as this is arguably the whole point of being a
> writer. Remeber OOP is your friend.
No .. the compiler should work regardless.
Yes .. there are benefits to better structured code .. but its not the fault
of the scipter if the compiler has bugs.
Of course ,once one is aware of the bugs, one can change the coding to work
aroudn them. But that situation is not good. Once should not be force to
changed ones progrmaming style in order to workaround bugs
I discovered the problem to be one 1500 line class that is used to represent the state of the level and provide operations on it. It wasn't a design flaw on my part - the code was so long because there are many complicated queries one might want to make of the level, including several complex collision detection routines optimized for different kinds of objects.
You haven't really seen my code, so it's a little obnoxious that you tried to qualify whether it was designed on firm principles or not just by its length. The statement that there's never a good reason for 32k of code to be in one place is absurd, though - sometimes there is a large amount of data that needs to be grouped into a single object, and there's nothing OOP can do to stop that.
I ended up fixing it by creating a second dummy class, moving all the variables and about half the code into there, and then subclassing the original from it. However, let me stress that this is -not- good OOP, as it makes the code substantially less intuitive to have code that is really for one class to be split into two files. I still believe this to be a flaw in Flash, a bug that they decided to slap a warning label instead of fixing. I don't care what it was originally intended for. They know full well what people use it for now, and that 32k is a reasonable amount of code. This restriction is complete BS, and it is ridiculous to argue that it's developers' fault if their code is too long for a compiler to handle.
The reason for the restriction is that the compiled script uses a 16-bit
signed offset for jumps .. ie +=32K. SO it is not possible for a single
jump to jump over more than 32K of code.
However, the compiler could be made to take this into account by doing large
jumps in multiple steps .. ie if you need to jump of 48K of code, jump 32K
to another jump statement, and that jump statement jumps another 16K etc.
So it is fixable (even though a little tricky)
I doubt very much if you will see a fix for this, because
Adobe/Macromedia/Flash is moving to Flash Player 9 + AS3 .. and that uses a
completely different compiled code which should no longer have the problem.
For now, you may need to ugly-fy your code to avoid large jumps.