x and y registers used as a "this" vs. "that" idiom.
Moderator: Moderators
Re: x and y registers used as a "this" vs. "that" idiom.
To me, X and Y registers (and also A register) is just whatever fits best with the instruction set for the most efficiency, and does not mean "this" and "that", it just means "X register" and "Y register".
(Free Hero Mesh - FOSS puzzle game engine)
Re: x and y registers used as a "this" vs. "that" idiom.
Of course, but in the specific case of dealing with game entities/actors/objects, most people have arrays of them, so you need some sort of indexing or pointers to access and manipulate them. When one entity/actor/object needs to talk to another, it makes sense to use X to index one of them, and Y to index the other. Using X for "this" entity makes sense to me because on the 6502 more operations are available with X indexing (e.g. ASL, LSR, ROL and ROR can only do indexed addressing using the X register), leaving Y to be used for "that" entity. If you use pointers though, Y becomes the more versatile register (but still not as versatile as X in absolute indexed mode).
Of course that even when we use X and Y to manipulate entities/actors/objects like this, the 6502 is so short on registers that you'll likely need to temporarily backup those indices so you can free the registers to do other tasks while manipulating the objects.
Of course that even when we use X and Y to manipulate entities/actors/objects like this, the 6502 is so short on registers that you'll likely need to temporarily backup those indices so you can free the registers to do other tasks while manipulating the objects.
Re: x and y registers used as a "this" vs. "that" idiom.
My thoughts exactly.zzo38 wrote:To me, X and Y registers (and also A register) is just whatever fits best with the instruction set for the most efficiency, and does not mean "this" and "that", it just means "X register" and "Y register".
Re: x and y registers used as a "this" vs. "that" idiom.
In spanish, "this" is here, and "that" is there. "This tree" is close, within reach. "That tree" is far. I can get "this pencil" from the table, but I might have to leave my sit to reach "that one".
On the other hand, I've coded very little in assembly, but in my mindset, X=this and Y=that makes sense. I think I treated them that way.
On the other hand, I've coded very little in assembly, but in my mindset, X=this and Y=that makes sense. I think I treated them that way.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: x and y registers used as a "this" vs. "that" idiom.
For a more anecdotal example, in my game I used Y for "this entity" updates as a convention, and it was a mistake, largely because of how often it would be convenient to use it with INC. The "entities" are fixed arrays with fewer than 256 entries, so there's really no advantage to Y for them.
However, it doesn't really follow that I'd use X for "that entity". All cases of dealing with two at once are probably special. Sometimes I'll use X, sometimes I'll temporarily replace Y, sometimes I'll have switched "this" into the X position too. So... sometimes I would use X and Y to index two related things like that, but just as often I would do it some other way. Very situational. (For example: by temporarily replacing Y, I can reuse code that was written for the "this" case too, even when it's "that".)
And yeah, X should have been my primary convention for it, but hindsight is 20/20. In the end it's not really a big deal. After the entry to the entity's update code, I can transfer Y into X and use that instead if it's more convenient, etc. there's some inefficiency as a result, but not enough to make me want to refactor the whole thing. Even this wrong choice is good enough much of the time.
However, it doesn't really follow that I'd use X for "that entity". All cases of dealing with two at once are probably special. Sometimes I'll use X, sometimes I'll temporarily replace Y, sometimes I'll have switched "this" into the X position too. So... sometimes I would use X and Y to index two related things like that, but just as often I would do it some other way. Very situational. (For example: by temporarily replacing Y, I can reuse code that was written for the "this" case too, even when it's "that".)
And yeah, X should have been my primary convention for it, but hindsight is 20/20. In the end it's not really a big deal. After the entry to the entity's update code, I can transfer Y into X and use that instead if it's more convenient, etc. there's some inefficiency as a result, but not enough to make me want to refactor the whole thing. Even this wrong choice is good enough much of the time.
- NovaSquirrel
- Posts: 483
- Joined: Fri Feb 27, 2009 2:35 pm
- Location: Fort Wayne, Indiana
- Contact:
Re: x and y registers used as a "this" vs. "that" idiom.
All of my entity code uses the X register to refer to the current entity, and the entity routine is responsible for preserving X. Most of my entities need to read level data, and this is where indirect-indexed requiring Y comes in handy because it means I can directly use entity variables and level data together without needing to save and restore anything.
For entity spawning, I just have both a FindFreeObjectX and FindFreeObjectY because the routines are so small (21 bytes) and important that there's little reason not to just have both.
For entity spawning, I just have both a FindFreeObjectX and FindFreeObjectY because the routines are so small (21 bytes) and important that there's little reason not to just have both.
Re: x and y registers used as a "this" vs. "that" idiom.
When an entity is called in my engines, X contains the index of the slot where the entity is, but this index is also stored in RAM. This allows the entity routines to quickly use X for other purposes and restore it easily afterwards.NovaSquirrel wrote:All of my entity code uses the X register to refer to the current entity, and the entity routine is responsible for preserving X.
Yeah, Y then becomes the first choice for accessing data, but I can't always do everything using only Y, sometimes I need X too.Most of my entities need to read level data, and this is where indirect-indexed requiring Y comes in handy because it means I can directly use enemy variables and level data together without needing to save and restore anything.
- NovaSquirrel
- Posts: 483
- Joined: Fri Feb 27, 2009 2:35 pm
- Location: Fort Wayne, Indiana
- Contact:
Re: x and y registers used as a "this" vs. "that" idiom.
Of course I save and restore X if I need it for something else, it just means my STX is in the entity code itself rather than in the entity code caller (though it'd be a good idea to move it).
I think it's the other way around. If you have large arrays involved (like my game's 4 KB level buffer) it stops being an arbitrary choice, because you're almost definitely going to need Y for that. X then becomes the first choice for anything else because Y is already taken.tokumaru wrote:Yeah, Y then becomes the first choice for accessing data
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: x and y registers used as a "this" vs. "that" idiom.
Yeah, having the index redundantly in ZP somewhere is super convenient. (...sometimes not even X or Y is the right choice! We must not exclude other options.)
The other alternative to using Y, useful in some rare circumstances, is with self modifying code in RAM. You can roll your own pointer if you modify the address of the instruction directly.
The other alternative to using Y, useful in some rare circumstances, is with self modifying code in RAM. You can roll your own pointer if you modify the address of the instruction directly.
Re: x and y registers used as a "this" vs. "that" idiom.
What sets up the health, initial animation frame, and other attributes of a newly spawned object, and ensures its cels are in CHR RAM?NovaSquirrel wrote:For entity spawning, I just have both a FindFreeObjectX and FindFreeObjectY because the routines are so small (21 bytes) and important that there's little reason not to just have both.
- GradualGames
- Posts: 1106
- Joined: Sun Nov 09, 2008 9:18 pm
- Location: Pennsylvania, USA
- Contact:
Re: x and y registers used as a "this" vs. "that" idiom.
It sounds like the choices you made concerning y vs. x are not as bad as the ones I had made previously to what I currently have. When I wanted one entity to talk to another with my current system, say transfer a bunch of 16 bit variables, AND use my 16 bit convenience macros, I'd have to transfer a bunch of data out of the current entity to ZP, then save the current index on the stack, then transfer those ZP variables into the other entity also indexed by x, then finally restore the old index from the stack. It was really ugly and hard to follow. Now it's literally justrainwarrior wrote: And yeah, X should have been my primary convention for it, but hindsight is 20/20. In the end it's not really a big deal. After the entry to the entity's update code, I can transfer Y into X and use that instead if it's more convenient, etc. there's some inefficiency as a result, but not enough to make me want to refactor the whole thing. Even this wrong choice is good enough much of the time.
Code: Select all
ldy the_other_entity
move16 original_entity_variable, the_other_entity_variable, x, y
-
- Posts: 271
- Joined: Sun Mar 27, 2011 10:49 am
- Location: Victoria, BC
Re: x and y registers used as a "this" vs. "that" idiom.
Something sort of related is that on 8080 based processors and their descendants (GBZ80, Z80, and x86), the different registers do carry some amount of semantic meaning in idiomatic code.
On the (GB)Z80, B/C/BC are typically used for counters, and DE is typically the first choice for a DEstination pointer for copies and writes and such - and that's despite the fact that the instruction set is almost entirely orthogonal w.r.t. these registers. And because HL is sort of a "16-bit accumulator", its constituent 8-bit registers are rarely wasted on storing independent 8-bit values unless necessary. These idioms do start to break down when you're writing "speed code" or facing lots of register pressure, though.
On the (GB)Z80, B/C/BC are typically used for counters, and DE is typically the first choice for a DEstination pointer for copies and writes and such - and that's despite the fact that the instruction set is almost entirely orthogonal w.r.t. these registers. And because HL is sort of a "16-bit accumulator", its constituent 8-bit registers are rarely wasted on storing independent 8-bit values unless necessary. These idioms do start to break down when you're writing "speed code" or facing lots of register pressure, though.
- NovaSquirrel
- Posts: 483
- Joined: Fri Feb 27, 2009 2:35 pm
- Location: Fort Wayne, Indiana
- Contact:
Re: x and y registers used as a "this" vs. "that" idiom.
And then on the real z80 you've got instructions like "ldir" that do enforce DE as a destination, HL as a source, and BC as a counter, at least for the copy. "djnz" means that if you want to take advantage of it, the B register is already your loop counter.adam_smasher wrote:On the (GB)Z80, B/C/BC are typically used for counters, and DE is typically the first choice for a DEstination pointer for copies and writes and such - and that's despite the fact that the instruction set is almost entirely orthogonal w.r.t. these registers.
I've got a separate ObjectClearX and ObjectClearY that marks the entity as not coming from the level layout and also zeros out the entity's variables. I call that before overwriting whichever variables I want, but usually starting at zero is desired. I don't have variables specifically for things like health (almost all enemies die in one hit) or animation frame (based on timers) and in general my engine sounds simpler than yours are.tepples wrote:What sets up the health, initial animation frame, and other attributes of a newly spawned object, and ensures its cels are in CHR RAM?
- Vectrex2809
- Posts: 102
- Joined: Mon Jul 14, 2014 6:05 am
- Location: Tokyo, Japan
Re: x and y registers used as a "this" vs. "that" idiom.
I always use X for "this" entity and Y for other stuff like child entities, lookup tables (for entities that move in a sinusoidal way, like moving platforms in REKT).
As somebody else already mentioned, the use of X is great since it lets you use INCs and DECs with your entities, which is amazing for simple movements and animation.
As somebody else already mentioned, the use of X is great since it lets you use INCs and DECs with your entities, which is amazing for simple movements and animation.