Quote Originally Posted by Jigglysaint View Post
But anyway, I know there are limitations and stuff. I just can't seem to get zcript and Zasm down. For some reason I am unsure how to work out all the variables. I know 6502c and a little Z80, but zasm seems to be a low level language aimed at programmers, not rom hackers. If I had an opcode list and a list of ram loations, I could go to town. Oh well, I'll keep trying tonight.
Oh, sweet...

No. Although I've not looked too much at ZASM, I can only hope there are no pointers in it. Or direct memory addressing.

Honestly, stick to ZScript for most of your code, and if you have a small, but frequently called function, you could write it in ZASM.

And, I'm not sure what you mean by "I am unsure how to work out all the variables". Zscript is pseudo object oriented, revolving around the five major classes: Link, FFC, Screen, Game and NPC. So, all your magic variables are going to be members of those objects.

Link, Screen and Game are singletons (i.e. there is only one of each, and are accessed by their class name), while FFC and NPC are instances of the FFCs and enemies on the screen, respectively.

ZScript.txt outlines the members for each class, and gives you all the information you need.

And, you can create your own variables of types int, float (which is the same as int), bool, ffc and npc. The last two are pointers to FFC and NPC classes.

So, for example:

Code:
ffc Zelda = Screen->LoadFFC(1);
Zelda->X = 16;
Zelda->Y = 16;
This snippet grabs a pointer to the first FFC, and places it at (16,16) (measured in pixels). Since we use a variable to hold the results of Screen->LoadFFC, we can reference it by name.

The clusterfuck I refer to is actually the rest of the stuff, wrapping scripts in "ffc script" blocks, which have members themselves, but oh! they can't have variables, all globals are in the global namespace.

And, no, swearing is not my last course of action. It's simply the most accurate word to describe the state of scripting.