Will this have the same effect? Will it expand out into an array of the low bytes and high bytes?

This is just combining 2 separate functionalities of ca65: the .define command creates an identifier that will expand into the list of things every time you use it, while .lobytes and .hibytes will extract only the low or high bytes of the list of values you give them. So yeah, this will create two tables, one with only the low bytes and the other with only the high bytes.

Quote:

I've noticed some people using some "dot" type notation in their code, is this just by convention or is there some syntactic sugar for that type of thing in ca65?

Sounds like you're talking about scopes. Scopes encapsulate symbols so they're not visible to parent scopes, unless you use named scopes and access their children using "::". For example: jsr Video::UpdatePalette will call the subroutine "UpdatePalette" that was defined inside the "Video" scope. Scopes are useful for organization purposes, but also allow you to reuse labels (e.g. if each subroutine has its own scope, all of the can have a label called "Return").

Will this have the same effect? Will it expand out into an array of the low bytes and high bytes?

This is just combining 2 separate functionalities of ca65: the .define command creates an identifier that will expand into the list of things every time you use it, while .lobytes and .hibytes will extract only the low or high bytes of the list of values you give them. So yeah, this will create two tables, one with only the low bytes and the other with only the high bytes.

Quote:

I've noticed some people using some "dot" type notation in their code, is this just by convention or is there some syntactic sugar for that type of thing in ca65?

Sounds like you're talking about scopes. Scopes encapsulate symbols so they're not visible to parent scopes, unless you use named scopes and access their children using "::". For example: jsr Video::UpdatePalette will call the subroutine "UpdatePalette" that was defined inside the "Video" scope. Scopes are useful for organization purposes, but also allow you to reuse labels (e.g. if each subroutine has its own scope, all of the can have a label called "Return").

Ok that makes sense. As far as the scopes are concerned, that isn't quite what I was referring to. I was referring to seeing things like:

One other suggestion: You can maybe add the frame count as a parameter to your macro which would make it more fully generic, I think.

I had forgotten that I moved my frame count data outside of my sprite pointer array. You're right I need to pass it in. I've made a couple of updates now so that I can pass in a pointer to an animation and a pointer to a number of frames. This way I can transition between frames based on the state of the player.

Now I'm trying to figure out how to register button releases so I can transition in and out of walking and idle states. Right now I'm just storing a single frame of controller state. I assume I probably will want to store 2 frames and compare. If the previous frame's state shows that left has been pressed but the current frame's state shows that it's not pressed, then I can transition from the walking state back to the idle state. Hopefully that will work.

You then stack N animations in the main tables. Then your Walk animation either becomes a list of frames, or if you know you only want a range then you have Start,EndSo you keep a frame index in RAM, load it with Start, inc it each time until it hits End, then reset it to start.

Putting the data stripped in this way is a pain, but if you upgrade to Tass64 (which works on Mac Intel and PPC ) over CA65 you can start to do things like

It's also possible to duplicate the .lobytes/.hibytes functionality by using macros. This is sometimes useful if you need to do more complicated transforms, or extract some auxiliary data such as the bank byte.

Note though, that since this operates on tokens you can't have more complex expressions within the .define list itself. This won't work: .define maps map_foo+123 map_bar*2. However, it would be possible to modify the transform macro to support that as well (delimit the parameters by ,), I just wanted to keep it simple.

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum