It is currently Wed Oct 18, 2017 6:17 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Mon Aug 07, 2017 8:17 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 919
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".

_________________
.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 10:46 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10051
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 11:09 pm 
Online
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7227
Location: Chexbres, VD, Switzerland
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".

My thoughts exactly.


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 12:32 am 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 351
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.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 12:47 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5713
Location: Canada
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. ;)


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 1:52 am 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 211
Location: Fort Wayne, Indiana
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.


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 2:01 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10051
Location: Rio de Janeiro - Brazil
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.

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.

Quote:
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.

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.


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 2:55 am 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 211
Location: Fort Wayne, Indiana
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).

tokumaru wrote:
Yeah, Y then becomes the first choice for accessing data

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.


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 3:55 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5713
Location: Canada
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.


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 5:19 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19094
Location: NE Indiana, USA (NTSC)
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.

What sets up the health, initial animation frame, and other attributes of a newly spawned object, and ensures its cels are in CHR RAM?


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 5:49 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 983
Location: Pennsylvania, USA
rainwarrior 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. ;)

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 just

Code:
ldy the_other_entity
move16 original_entity_variable, the_other_entity_variable, x, y


everywhere. (in other words, my macros only supported the x register at first, hence all that mess with zp transfer I mentioned above. once I added support for specifying registers it simplified a whole lot.)


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 7:20 am 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 191
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.


Top
 Profile  
 
PostPosted: Tue Aug 08, 2017 10:52 am 
Offline
User avatar

Joined: Fri Feb 27, 2009 2:35 pm
Posts: 211
Location: Fort Wayne, Indiana
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.

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.

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?

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.


Top
 Profile  
 
PostPosted: Tue Aug 22, 2017 6:37 pm 
Offline
User avatar

Joined: Mon Jul 14, 2014 6:05 am
Posts: 88
Location: Lausanne, Switzerland
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 29 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bregalad and 9 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group