It is currently Fri Nov 17, 2017 5:39 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 29 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Aug 07, 2017 7:56 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
For both my previous games, the "x" register always meant: "This entity" during my entity update loop. If I wanted to parameterize a child entity, I had to save the x register on the stack, set up the child entity, then restore the x register. For my new game, I now have my "entity_spawn" routine work entirely with the y register. Now it just feels a heck of a lot cleaner to spawn child entities, no stack required...I can just transfer straight from the parent entity, indexed by x being "this" entity, to the child entity, indexed by y being "that" entity.

This feels very idiomatic to me, like the "right way" to use 6502 in this particular instance. I.e. all previous ways I've designed this type of code were definitely clumsier in some fashion.


Last edited by GradualGames on Mon Aug 07, 2017 8:13 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 8:02 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7265
Location: Chexbres, VD, Switzerland
My native langauge do not have direct equivalents of words such as "this" or "that", so it makes no sense to me, but if it works for you then fine.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 8:03 am 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
Bregalad wrote:
My native langauge do not have direct equivalents of words such as "this" or "that", so it makes no sense to me, but if it works for you then fine.


I would define "that" as "another this distinct from the original this."


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 8:11 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19221
Location: NE Indiana, USA (NTSC)
I too have used X and Y as "this" and "that". I also tend to use X as "this" and Y as an index into a table of properties of, say, each frame of animation of "this".

In The Curse of Possum Hollow, spawning a child entity in my engine is fairly heavyweight if has to be spawned immediately, as opposed to possibly several frames from now. (It may take a few frames for one of six slots in the active object table or one of two enemy CHR windows to become available.) So there's one routine that spawns an entity "whenever" by adding it to a queue that's checked every frame, quickly and using few registers. And there's another routine that spawns the enemy right effing nyeaaouw or returns an error code if there was a conflict keeping it from being spawned, so that the move routine can try again next frame. And there's a dedicated global variable for the index of the entity whose move routine is running, allowing move routines to restore X from that variable.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 9:07 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
I use X and Y as this and that sometimes too.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 9:27 am 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 206
Location: NYC
Bregalad wrote:
My native langauge do not have direct equivalents of words such as "this" or "that", so it makes no sense to me, but if it works for you then fine.

«Ceci» et «cela», n'est pas?


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 10:53 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19221
Location: NE Indiana, USA (NTSC)
Unless it's German, where diese(r) means both "this" and "that", and jene(r) means only "that" but is rarely used in speech.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 1:55 pm 
Offline

Joined: Tue May 28, 2013 5:49 am
Posts: 858
Location: Sweden
Swedish is pretty much like English in this case.

Adding Japanese into the mix might mess things up though. Japanese has: "kore" (this), "sore" (that) and "are" (that over there). The last one is used for things that isn't particularly close to neither the speaker nor the listener. I think I'd use A for kore, X for sore and Y for are maybe, messing things up.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 1:56 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5821
Location: Canada
I don't think either register should really get an exclusive semantic purpose like this. They aren't symmetrical so it doesn't make sense to me that one convention would fit every case.

e.g. X can be used with INC, but Y cannot, etc. Whether this asymmetry matters depends very specifically on what you're doing with either of the two things you're indexing. I'd generally suggest starting with X by "default" for indexing fixed arrays, because it's got more powerful operations for that. (Y on the other hand is more powerful for pointers.)

Once you have a pair of things to index, though, if it's as simple as a copy from one to another it doesn't really matter, and if it's not that simple there are situational advantages to both arrangements.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 2:01 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
rainwarrior wrote:
I don't think either register should really get an exclusive semantic purpose like this. They aren't symmetrical so it doesn't make sense to me that one convention would fit every case.

e.g. X can be used with INC, but Y cannot, etc. Whether this asymmetry matters depends very specifically on what you're doing with either of the two things you're indexing. I'd generally suggest starting with X by "default" for indexing fixed arrays, because it's got more powerful operations for that. (Y on the other hand is more powerful for pointers.)

Once you have a pair of things to index, though, if it's as simple as a copy from one to another it doesn't really matter, and if it's not that simple there are situational advantages to both arrangements.

I don't think I took quite as hard line as that. I just said "in this particular instance," implying it was idiomatic in the case I'm applying it to. All I mean by that is I can't think of a neater or cleaner way to accomplish what I'm doing.

It feels natural partly because y follows x in the alphabet, and it further feels natural because most of the time, you'll be starting at some top level lookup table or array by addressing it directly, and then you might start picking addresses out of it and addressing those indirectly with y. Not saying that applies in all cases, but I'm wondering if that natural progression from "top level lookup table -> more detailed tables addressed indirectly" was in the mind of the creator of the 6502, or not. It seems to imply a natural hierarchical traversal of data starting at a table you know about, proceeding to other tables you don't yet know about til you read about them.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 2:21 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5821
Location: Canada
GradualGames wrote:
It seems to imply a natural hierarchical traversal of data starting at a table you know about, proceeding to other tables you don't yet know about til you read about them.

Well, I'd argue quite the opposite. Think of the very common case of unpacking from compressed data into your working structures. Compressed data comes in a stream, and pointers are usually the appropriate mechanism for reading serial data, so it has to be copying from a Y indexed pointer.

There is no logic to their alphabetical order. That's entirely irrelevant to what you actually need to do with these registers.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 2:38 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
Pokun wrote:
Japanese has: "kore" (this), "sore" (that) and "are" (that over there)

Portuguese has these 3 as well: isto, isso, aquilo.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 3:43 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5821
Location: Canada
To put my point a different way, I think X and Y do have some strong and useful connections to various methods of data storage.

"Source" and "destination" are not types of data, though. Neither is "this", "that" or "the other". Even most copy operations are not copying between symmetrical equivalents, usually there is a transformation being done at the same time.

What I'm talking about are factors like:
  • serial vs random acesss
  • fixed or pointer
  • under or over 256 entries
  • read only or read and write
  • compressed or uncompressed
  • list or tree etc.
  • preserved after read or not

There's no general case for this. The source part of a "copy" has independent properties from the destination (though they can sometimes be the same). There's a lot of stuff that either X or Y can do, and several important things that only X or Y can do.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 4:06 pm 
Offline

Joined: Thu Jul 23, 2015 7:54 pm
Posts: 147
Location: USA
tokumaru wrote:
Portuguese has these 3 as well: isto, isso, aquilo.
I remember learning something similar back when I took Spanish, that there were 3.

So far I've only learned 2 in French, ce/ceci and ça/cela; so I don't understand what Bregalad's talking about when he said it wouldn't translate well. But I guess I can't really argue as he is a native speaker.


Top
 Profile  
 
PostPosted: Mon Aug 07, 2017 4:17 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 987
Location: Pennsylvania, USA
rainwarrior wrote:
To put my point a different way, I think X and Y do have some strong and useful connections to various methods of data storage.

"Source" and "destination" are not types of data, though. Neither is "this", "that" or "the other". Even most copy operations are not copying between symmetrical equivalents, usually there is a transformation being done at the same time.

What I'm talking about are factors like:
  • serial vs random acesss
  • fixed or pointer
  • under or over 256 entries
  • read only or read and write
  • compressed or uncompressed
  • list or tree etc.
  • preserved after read or not

There's no general case for this. The source part of a "copy" has independent properties from the destination (though they can sometimes be the same). There's a lot of stuff that either X or Y can do, and several important things that only X or Y can do.


Yeah I agree with all that. I guess what I'm really getting at is simply wondering what informed the design of the 6502. I suppose it perhaps mostly had to do with how expensive it was to design processors back then, but I wonder if they designed the instruction set with any particular use cases in mind. I.e. Were they informed by experience in any type of business related data processing for which their particular choices were particularly well suited? Or was it totally arbitrary and based only on : "What is actually possible to support given how few logic units we can use to design this thing?"

Regardless of that though, a more solid point I could really make is that when one is a beginner with assembly language, one does things in a clumsy fashion, over-using the stack or what not, but when one gains experience, it becomes more clear how to use registers in clearer or more consistent/persistent way. That's probably what I should have said to begin with. I definitely hadn't intended to say that this applied everywhere.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 13 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