In-tool Guides and References for Coders

MistSonata

Moderator
So, as I dig in to the code and experiment with ideas, it's been a little difficult trying to find where things translate from the way they are in the tool to the way they're implemented in code. For instance, if you want to create an object at a certain location on screen you either have to do it by trial and error or you have to take a screenshot of your screen, bring it into an image editor, find the desired coordinates and convert to hex.

Now, I'm sure there are already plans for things like this, but in case there isn't I'd like to propose some things that would really help out.

- Screen coordinate checker
- Object addresses (for creating an object)
- Object instance naming (give it the object a name like the tool does for player1_object, I've discovered how to do this on my own, but it'd be nice to have the option in-tool)
- An easy way to declare variables and set their values in tool

Things like that.
 

RadJunk

Administrator
Staff member
Yeah, some of this is planned...some of it I want to work out but finding the right ways/places to hook into the code is tough.

I'll chime in at least a little:
Screen coordinate checker...hm...you could also use FCEUX's Nametable viewer to find actual position in hex (you can see the hex value of where your mouse is). I can see how this would be helpful, though, and I'm sure we could potentially add it to the screen data at the top of the room which displays mouse position. I worry it might get confusing, though, as some things are handled by TILE, while others by PIXEL.

Object addresses effectively could be handled now at the point of creating an object, but would require code. For instance, as soon as something is created, whatever is loaded into X could be pushed to a variable using:
Code:
TXA
STA yourChosenVariable

So a macro seems...unnecessary? Also, I can't conceive of a way to handle this from a front end. But these are the things that keep me up at night. Also, like...being able to play a sound effect from the front end...how do I add that hook to literally ANYWHERE? In the code, it's pretty simple, but front end, there are simply too many variable places, and unlike in a modern engine, no real way to handle without adding too much to the ROM file. But yeah, I continue to think of options on these sorts of things.

Variables are planned :)
 

MistSonata

Moderator
TheNew8bitHeroes said:
Object addresses effectively could be handled now at the point of creating an object, but would require code. For instance, as soon as something is created, whatever is loaded into X could be pushed to a variable using:
Code:
TXA
STA yourChosenVariable

I'm guessing you mean that whenever you use the createobject macro, the address that particular instance of the created object is loaded into X? If so, that's awesome, because I was wasting an AI action slot just to push the value into a custom variable.

EDIT: Now that I think about it, that'd be a great thing to put in the description of macros. Not just what it does in terms of its function, but what registers it effects and what (if anything) is loaded into them. That way you'll know if you need to reload data into a register for use in your code.
 

RadJunk

Administrator
Staff member
Yes...essentially, when an object is created, it looks for the first available "slot" (indexed by X in the routines, where X represents a number #$00 - #$0f...0-15). What you could do is in the AI action slot itself, just do the above...push that X to the variable (TXA pushes whatever is in X to the accumulator, STA stores the accumulator, in this case into that variable) :)

And yeah - we want to make a breakdown of the macros and how they work. It's on the list :)
 

RadJunk

Administrator
Staff member
Should be fine - I'm not sure if ASM6 supports STX. If it does, I don't think it saves you any cycles (just shorthand for doing the same thing, I'd imagine!), but if that looks neater, and compiles...should be good to go. :)
 

Kasumi

New member
STX is fine in asm6, and it saves you 2 cycles and a byte over txa sta. (As well as not changing A.) The only time you'd want to do txa first is when the addressing mode isn't supported by STX. (for instance, stx nonzeropage,y is not valid, but sta nonzeropage,y is)

One other note is that you don't need to convert screen coordinates to hex. Omitting the '$' allows you to use decimal numbers.
lda #255
is identical to
lda #$FF

lda #10
is identical to
lda #$0A

lda #16
is identical to
lda #$10
etc.
 

RadJunk

Administrator
Staff member
One other note is that you don't need to convert screen coordinates to hex. Omitting the '$' allows you to use decimal numbers.
lda #255
is identical to
lda #$FF

What's this now?! How was I not aware of that?! haha

STX I feel once gave me an issue so I never really ended up utilizing it...I think you just articulated the reason!

Kasumi...still teaching me new tricks after all this time...you're the man!
 

dale_coop

Moderator
Staff member
Yep.
Respect, kasumi. Can't stop learning from you.
It's a real pleasure to read you all, guys!
 
Top Bottom