ca65 Questions

Well, I've been using ca65 for a while now after "The Incident" and I like it for the most part, but there are a couple of things I'm not sure how to do that I was able to do in WLA. See, in the game I'm making, I have an "object spawner" that looks for an empty object slot to put the specified number in. I then go through and check all the slots in the object table and jump to the code that corresponds to the number I stored earlier, if that makes sense. It works perfectly, but if I want to create a bullet, it looks like this:


In the code, 4 represents a bullet, but when I start adding a ton of different objects, it is going to become difficult as to what number corresponds to what object. I know in WLA, you could say something like "bullet = 4" and whenever you mentioned "bullet" the assembler would now to substitute it with 4, so the code above would look like:


Is this possible to do in ca65?

Sure it is! Simply put in a line somewhere saying...

bullet = 4

That's how to define for at least the .asm file.

Should be lda #bullet, but other than that the syntax for equates is exactly as you said.

You can also use .enum:

Serious answers plea... Oh wait, never mind. I was confused because I didn't use a #, which thefox pointed out. You know, what is the game loading if you don't use a #? I tried it and it crashed because it must point to some place I don't want it to. I like that you can do something like that. It's so obvious that it's unobvious, unless there is some sort of "standard" for defining things.

The assembler loads a value from a memory location (which would be whatever is stored in $0004 plus the data bank register) instead of a constant without that # there.

Oh yeah, I have another question. Is it possible to say the address of a something like this (player1:) instead of something like this? (.proc player1) I had a jump table that wasn't working with the first method because it said player1 was undefined or something so I changed it and then it worked.

.proc is a combination label and enclosing .scope for any labels inside the proc. If you don't need a scope, you don't need to use .proc, but it's a useful feature if used consistently. The main thing is you can have generic label names like loop: within a proc without worrying about a conflict with the same name in another proc.

.proc player1 should create a global label player1 that you can use elsewhere like in a jump table. Did you maybe forget an .endproc somewhere?

Also, something I find convenient when the setup for common subroutine calls tedious is to roll them up in a macro: