I have some concerns regarding macros, memory usage and speed. I have
written a macro that will update a sprite. The sprite table occupies
$0200 - $02FF in my game. Right now, my meta sprites are 16 bytes in
length.
The following will set the tiles for my 2x2 meta sprites:

The neat part about this is that I can use the same code for any 2x2
tile. Not just my main character. When I call drwFrame param 1
is the frame table to use, param 2 is the start address of the sprite
to alter.
So far, my game only uses this code 4 times. One for each frame of my
main character. The downside, is that every time I call this macro, it
re-writes the macro to memory right?
I've thought about using a zero-page pointer to use indirect Y to access
the frame table. This would not be as fast, but it would take up less
PRG-Memory. I could also just write several unique sub routines, but
that would be harder to maintain and take up the same space as the macro.
I'm just not sure how else to go about this. I can't seem to grasp whether or
not speed, space, or flexibility is more important.
Is the above solution sound? Do you recommend another approach?
Thanks

_________________
http://www.thestarrlab.com

You have to decide for yourself whether speed, space or flexibility are more important

Not sure I follow you. In particular I'm not sure what sta spr, x+1 means

Off the top of my head possible alternatives are use a table for the multiply
and get rid of the explicit comparison.

It sounds like you knew the answer already. Yes, the macro code gets assembled every time you invoke the macro. If it's written the same as you would write without out it anyway, there's no speed penalty at all-- it's just more clear what you're doing. You have complete control over what the macro assembles; but once those details are ironed out, there's no need to keep looking at them and cluttering your code. What would take less memory is a subroutine, but you can't do that if the internal details are different each time. My article on macros might be beneficial. There's also the topic a viewtopic.php?f=2&t=1586.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

This is the sort of trade-off that doesn't have a one-size-fits-all answer. Which is more important varies with what exactly you're trying to achieve. Experience helps to judge when size or speed or flexibility is more important. But some general tips:

Worry about size when you're starting to run out of room.

Worry about speed when your program starts to run too slow.

Worry about flexibility when you find yourself writing the same code over and over again with just tiny little changes each time.

In other words, don't worry yourself to death until you have an actual problem you need solve. When you do, it'll become very clear which area you need to focus on.

I'd say there's a lot of overlap. For example, if you're careful to avoid unnecessary instructions and to merge steps, you'll mostly come out with shorter code that also runs faster. Using the macros to make it easier to see what you're doing and to maintain the code might also expose places that you could shorten it up and get rid of things that might have otherwise hidden in the mess.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

The other thing is that since the macro is a mechanism of abstraction, later if you decide you want to change it to a subroutine, then your main source code need not change at all. Rather, you adjust the macro to set up the calling sequence (move the parameters to the right spot, push them on the stack, whatever) and then call the subroutine.

Then in your code, you simply add the subroutine itself in the right place, or, put the subroutine in another macro and place that in the right place in the program. Then, later, if you decide to switch back, the macro is all of the code and the subroutine macro is effectively an empty do nothing macro. But in the end, the overall source code doesn't change.