You might have to post a picture...could it be as simple as switching the tiles?

Sorry, I should have probably posted this here instead of it's own thread, but i actually didn't notice this sticky thread. Sorry for that. I was asking the following;

Hi,

I know how busy folks are, but I wanted to talk a little bit about one of my Favorite games on the SNES, Harvest Moon.

I was wondering, how difficult would it be, to do a relatively simple hack of Harvest Moon? What I want to do, is firstly, go back through the dialong and clean up the typos and bad grammar. Second, I wanted to go through the Girls, and change the looks of the sprites for the characters to the more modern versions of them that appear in the newer games.

At this time I think this is more of an educational exercise for me, but how difficult would this be to do? The characters dont have a lot of animations you would have to go through and change, (really they just have their directional walking sprites)

My final question is, the possibility of adding character portraits to the dialog when talking to the girls...

I dont know if this is possible or not as it would be a major modification to the game... Any thoughts on this?

I have plenty of experience with C and C+ programming, also, but Im not exactly sure how SNES games are written, so I dont know if my skill will transfer over very well...

http://gyazo.com/08cf1354df68eb9ccbd1b8b22d1ca376  <-- What the normal sprite looks like [after pressing right]
http://gyazo.com/518373409760ff3d7efe42390dcb7115  <-- What the flipped sprite looks like [after pressing left]
And no, you can't switch the tiles, I tried.

Yes. You just need to switch the tiles that you are displaying. Make the left sprite show the tile currently showing on the right one and vice versa.

Yeah, using the flip flag is tricky. It flips each individual tile in their current locations. It doesn't know that you're using four tiles to make up your sprite.

So you'll need to do:

When facing right (assuming your character starts at $0300):
$0301 - top left sprite ;not flipped.
$0305 - top right sprite
$0309 - bottom left sprite
$030D - bottom right sprite

When facing left:
$0301 - top right sprite (flipped)
$0305 - top left sprite (flipped)
$0309 - bottom right sprite (flipped)
$030D - bottom left sprite (flipped)

I have a question, is there documentation somewhere with all the functions you can do for the 6502? I think the tutorial mentions there are 52 functions right? 10 of which we will use all the time...

Some documentation and example code of each would be awesome IMO.

http://www.obelisk.demon.co.uk/65... is the site I use. It doesn't have a source code example, but it has the logical function and what addressing modes can be used with each opcode. It also has the instructions grouped by function: http://www.obelisk.demon.co.uk/65...

Quick question. I have a routine that updates 6 sprites based off the first one. When I move the sprites all together, the first sprite is a pixel or two ahead of the rest. My movement routine moves only the first sprite. The code is similar to MRN's in his engine building tuts.

Is there a way to compensate for this delay? Here are the subroutines:

MovePlayer:
LDA UpHeld ;Up
CMP #$01
BNE .NotUp
LDA PLAYER_SPRITE_RAM
SEC
SBC #$03
STA PLAYER_SPRITE_RAM
.NotUp
LDA DownHeld ;Down
CMP #$01
BNE .NotDown
LDA PLAYER_SPRITE_RAM
CLC
ADC #$03
STA PLAYER_SPRITE_RAM
.NotDown
LDA LeftHeld ;Left
CMP #$01
BNE .NotLeft
LDA PLAYER_SPRITE_RAM+3
SEC
SBC #$03
STA PLAYER_SPRITE_RAM+3
.NotLeft
LDA RightHeld ;Right
CMP #$01
BNE .End
LDA PLAYER_SPRITE_RAM+3
CLC
ADC #$03
STA PLAYER_SPRITE_RAM+3
.End
RTS

UpdatePlayerSprites:
LDA PLAYER_SPRITE_RAM ;Update vertical positions.
STA PLAYER_SPRITE_RAM+4
CLC
ADC #$08
STA PLAYER_SPRITE_RAM+8
STA PLAYER_SPRITE_RAM+12
CLC
ADC #$08
STA PLAYER_SPRITE_RAM+16
STA PLAYER_SPRITE_RAM+20
CLC
ADC #$08
STA PLAYER_SPRITE_RAM+24
STA PLAYER_SPRITE_RAM+28
LDA PLAYER_SPRITE_RAM+3 ;Update horizontal positions.
STA PLAYER_SPRITE_RAM+11
STA PLAYER_SPRITE_RAM+19
STA PLAYER_SPRITE_RAM+27
CLC
ADC #$08
STA PLAYER_SPRITE_RAM+7
STA PLAYER_SPRITE_RAM+15
STA PLAYER_SPRITE_RAM+23
STA PLAYER_SPRITE_RAM+31
RTS

I'm not looking at the code, but if you want to move others based off the first sprite, you obviously need to figure the first sprite position, then you need to move all other sprites based from that number instead of any other number you'll be using to initiate them, they should be initiated this way, too.

And if there's a pixel off, your math is a pixel off somewhere. Make sure to CLC before you ADC. Then also lastly, indent your code. You need white space before instructions to really tell the assembler it's not a label, and also you need it to make it more readable, as the execution flow is 10x easier to see with label indents.

Would have to see more code, but you probably have the order wrong. Likely you have:

MovePlayer (updates only first sprite)
sprite dma (now first and rest are out of sync)
UpdatePlayerSprites (now in sync, but too late to display)

Forgot to clarify that everything works like it should, just the top left sprite moves a split second before the rest.
Some pics:
http://goo.gl/HLJP3G... When not moving
http://goo.gl/hYZqoP... When moving left

When not moving, all the sprites are in the proper places.
Here is the code if interested: http://pastebin.com/gA8qBYdT...

Yup swap lines 367 and 368. You want to move the player, then update all the sprites.

Gotcha, works perfect now. Thanks! I was guessing since everything moves frame-by-frame, order would not have mattered.

Hello all.

I have a small? request for help on a mini project of mine. I don't want to post any specifics because it will be part of something larger later on. Whoever helps I will make sure is credited for their work.

Basically I have dumped 3 chips off a NES cart, the PRG, CHR and a 3rd chip which I believe to possibly be some sort of patch/modification to the original code. I have verified the dumps and I have been able to get the main code to run in an emulator. I have skimmed the 3rd chip but I am stuck as to what it actually changes/what it's purpose really is.

If you think you could help me, please send me a PM and we will go from there. If any of the programming gods want to have a go, I would really appreciate it.
BTW due to the nature of the content (which really could turn out to be nothing special) I would like to try and work with someone who has a good rep, nothing to do with skills, more on the whole keeping it between myself and the other person.

Wish I could be more clear, but if you want to help, please send me a PM. I know some of you don't do PM's (I'm looking at you Bunny) and you want to help, just post here and I can contact you via email or whatever your preferred communication method is.
I am from Australia so bear with me in terms of the time difference. I am in no hurry though.

Thanks!

This is a problem that I skipped over a while ago in order to focus on getting a single room to work, but now I would like to have more than one room actually functional (think Adventure for the 2600, or any overhead action-adventure). I have different backgrounds, attributes, and palettes loading, but the question is: how to get different sprites for different rooms, while keeping the location of the hero sprite dependent on player input. If a looped sprite table is used, as found in the NN tutorials, the hero’s position understandably jumps to whatever location it is assigned in the table. If a routine similar to the UpdateSprites routine in NN Week 9 is used in place of this, and in combination with a routine that sets the initial position of the hero (similar to the "update ball stats here" section near the beginning of NN Week 9), hero movement is fluid, but all addresses must be individually declared. Further, all sprite locations ($0200, $0201, etc.) must first have a variable assigned to them (herox, heroy, etc.), creating a ton of extra variables that may or may not be needed. This becomes more confusing when the whole SPRITE_ constant system is used, since herox, heroy, etc. can all be replaced with SPRITE_ and function just fine. What exactly needs to be done when loading a new room to ensure that the hero’s location is kept, and that new enemy sprites are loaded? Should some sort of routine that stores and loads the hero’s last location be used? The looped table is really appealing, but it also seems to be fairly rigid when it comes to moving beyond single screen games (although I am hopefully just using it wrong). Do there need to be long lists of Update____ for each room (i.e. UpdateEneniesRoom1, UpdateEnemiesRoom2, etc.)? Any help would be greatly appreciated, and if this does not make sense just ask. I am guessing that this is a fairly easy problem, but something is wrong in my logic (brain or computer). I am more than ready to start playing around with sprites, but have been hung up on this problem for a while.

　

Examples of the three systems discussed above:
 

Room1spr:                 ; Table, there would be one of these for each room, or one at the

;vert tile attr horiz       ; beginning of the playing state?

.db $C0, $00, $00, $70 ;Hero

.db $FE, $FE, $00, $FE

or

 

UpdateHeroSprite:

LDA HeroY ;;update all hero sprite info

STA $0200

LDA #$00

STA $0201

LDA #$00

STA $0202

LDA HeroX

STA $0203

RTS

In conjunction with:

 

SetInitialHeroLocation: ; Only used once at the beginning of the Playing State

LDA #$C0

STA HeroY

LDA #$20

STA HeroX

LDA #$01

STA InitialState

.Done

RTS

I basically have a table with the coordinates for the locations where my sprite (in this case, leisure suit larry) can be, depending on which room he's coming from:

When I'm leaving one room, I will assign a variable called ReturnFlag.  This variable will have a value of #00,#01,#02, etc.  Every two numbers is a set of coordinates.

ReturnCoords:
  .db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF ;title
  .db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF ;credits
  .db $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF ;gameover
  .db $97,$78,$88,$78,$82,$D8,$FF,$FF ;bar (0=starting, 1=leaving bar, 2=dumpster)
  .db $AA,$78,$79,$47,$95,$CD,$FF,$FF ;inside bar (0=from outside, 1=drunk, 2=bouncer)
  .db $90,$78,$76,$99,$FF,$FF,$FF,$FF ;drunk dude (0=inside bar, 1=bathroom)
  .db $78,$5A,$FF,$FF,$FF,$FF,$FF,$FF ;bathroom
  .db $8C,$23,$4E,$A4,$FF,$FF,$FF,$FF ;bouncer (0=from inside bar, 1=from prostitute)
  .db $7C,$58,$8C,$CB,$FF,$FF,$FF,$FF ;prostitute (0=from bouncer, 1=from window)
;;;;;;;;;;;;;;; etc etc

Then I take that value to see where I need to place Larry, depending on what room I'm in.  I run this subroutine after my LoadSprites is finished, just so that everything else is in its proper place for whatever room it is, but then Larry is moved to his correct position only after that.

PositionLarry:
  LDX BG_ptr    ;set BG_ptr to X
  TXA                  ;transfer to A
  ASL A              ;multiply by 2
  ASL A              ;x4
  ASL A              ;x8 (because I have 8 possible coordinates per room)
  TAX                  ;transfer back to X
.Loop:
  LDA ReturnFlag    ;then I load the variable ReturnFlag
  CMP #$00
  BEQ .Place            ;if it's #$00, just load the first two coordinates in a row
  INX
  INX                          ;increment by 2 to get the next two coordinates
  DEC ReturnFlag  ;decrement ReturnFlag once and repeat this until return flag is 0.
  JMP .Loop
.Place:
  LDA ReturnCoords,x             ;position sprite to correct location.
  STA SPRITE_BANKV
  STA SPRITE_BANKV+4
  CLC
  ADC #$08
  STA SPRITE_BANKV+8
  STA SPRITE_BANKV+12
  CLC
  ADC #$08
  STA SPRITE_BANKV+16
  STA SPRITE_BANKV+20
  CLC
  ADC #$08
  STA SPRITE_BANKV+24
  STA SPRITE_BANKV+28
  INX
  LDA ReturnCoords,x
  STA SPRITE_BANK
  STA SPRITE_BANK+8
  STA SPRITE_BANK+16
  STA SPRITE_BANK+24
  CLC
  ADC #$08
  STA SPRITE_BANK+4
  STA SPRITE_BANK+12
  STA SPRITE_BANK+20
  STA SPRITE_BANK+28
  RTS

You'll likely want to keep all the sprites in the Sprite_RAM+XXX thinking when you get to making collision detection engines. Just have two routines, one that updates the hero and others that update the bad guys. Just start the badguy update loops at Sprite_RAM+4 instead of Sprite_RAM+0.

Thanks Kevin. I thought about it a bit, and since the player will be able to enter from any border point I came up with the following based on your logic (I think anyways). After declaring a HeroPosition variable, and reserving enough space (16), I added the following routines:

StoreHeroLocation:
  LDA SPRITE_BANK
  STA HeroPosition
  LDA SPRITE_BANK+1
  STA HeroPosition+1
  LDA SPRITE_BANK+2
  STA HeroPosition+2
  LDA SPRITE_BANK+3
  STA HeroPosition+3
.Done
  RTS



RetrieveHeroLocation:
  LDA HeroPosition
  STA SPRITE_BANK
  LDA HeroPosition+1
  STA SPRITE_BANK+1
  LDA HeroPosition+2
  STA SPRITE_BANK+2
  LDA HeroPosition+3
  STA SPRITE_BANK+3
.Done
  RTS

Hopefully that is transcribed correctly, I am away from my other computer at the moment. Calling the store routine at the beginning of a room loading routine and again at the end seems to accomplish what I was after. Hopefully this help anyone else who has a similar problem, and if there are problems with what I have, please point them out sooner than later Thanks too MRN, just saw your post. I have a feeling that that will be my next issue (and may be related to the question below).



On another note, how does one get rid of sprites that loaded in a different state? I ran into this with Pong too, once the game finished and the background changed to the Game Over background, the sprites were still visible, though inactive. In my current situation the sprites all load fine in the rooms, but once the player moves from a room with three sprites to two, for example, the third sprite still appears in its old location. Any thoughts?

As you get into more advanced games, using the sprite page for storage turns into a bad idea. What you will want is:

Move player/enemies - none of the variables used will be in the sprite page. player position is separate from sprite coords
Render sprites - copy relevant data from the player/enemies into the sprite page. if an object is off screen or hidden it won't get copied.
Fill sprites - set the Y coord of all unused sprite slots to off screen

That way if you have a cut screen you skip move+render and just do fill. No sprites will be on screen but all your player data is still valid.

Well let's see how much or how little I understand. The HeroPosition variable is already in the zero page; is this what you meant? Or am I missing something? Should I not be not be touching the SPRITE_BANK addresses at all when doing player movement?

As far as rendering sprites, should I figure out the maximum number that will be on a screen at once and then load all of them in a table each time that I call the LoadSprites routine? Any that are not used would of course be given addresses off screen.

The "fill sprites" thing you mention, is that part of the sprite table, or will a separate routine be needed? I assume that it is part of the table, but just wanted to clarify.

Sad to say, but the last comment leaves me baffled in terms of the "if you have a cut screen (?) you skip move+render and just do fill." Sorry for asking you to dumb it down a shade (to quote a famous cartoon character), but I want to make sure that I get what is going on before proceeding and the having to go back and redo a bunch of things.

This never occured to me.  Very interesting.  I haven't run into something where this would be a problem as all the cut screens that I've done have been between independent screens.  Good tip!

Showoff.

Consider your sprite page as write only.  All your player/enemy variables should be somewhere else so you don't have to read from it.  The idea is to decouple the sprite page (used for drawing) from the object variables (used for moving/collisions).

You would go through each one of your players/enemies/objects and copy the x/y/tile to the sprite page if that object is on screen and active.  The number that will be on screen won't matter unless you have more than 64 sprites total.

All those 3 parts (move, render, fill) are completely separate functions.  The fill sprites only fills the unused sprites with Y = off screen.  If you want something slightly easier and less efficient, first fill ALL sprite with Y = off screen, then do render sprites.  That way any unused sprite slots will already be off screen.

Go to 3:10 in this video of Battle Kid: 

 Player is on screen, then the cut screen with dialog shows up.  Don't want the player visible or able to move around, so the move and render steps get skipped.  When the cut screen exits the player is still in the same place and rendered again.

Don't be sorry, thats what this thread is for  

Looking back at the Nerdy Nights, I have tried to apply what you mentioned to what was in the lessons. Conceptually, at least, here is what I have:

-Move/Collide Players/Enemies: variables are assigned in the zero page, such as ballx, bally, paddle1ytop, paddle2ybot, etc. When moving these objects, or determining collisions, these variables are called and NOT $02xx (or SPRITE_BANK/RAM+xxx, assuming that these are constants that begin at $0200 or somewhere like that).

-Render Sprites: Not entirely certain on this one, but this appears to be equivalent to the UpdateSprites routine in Week 9. Each room would have one(/several?) of these that loads into (write) the sprite page what is needed on the present screen. This will involve a rather lengthy routine for each room, or for each type of object to be updated; see below for what I think I mean.

-Fill: This is equivalent to the LoadSprites routine and the accompanying tables? One of these would be needed for each room. This did not appear to be included in Week 9, since there is not a LoadSprites routine and also if the table is commented out the program seems to run no different (though I could be wrong).



Summary: The fill routine gives the default values for the room (although this would mean that it is read from, but only prior to the room loading. Hmm...). The render routine is where the object variables are read from, and they are the values that are written back to the fill portion of code. Movement/collisions use object variables, NOT sprite page addresses.



If the above makes sense, I think that my main source of confusion was in equating $02xx/SPRITE_RAM+xx with object variables (ballx, bally, etc.) since they can at times functionally be the same. If I INC or DEC $0200 I can change the y position of the first sprite (though I now know that I should not). It was such a nice system since it eliminated the middle man (variable). I have wondered since last July why they were part of the code, now I know . Out curiosity, where should I reserve spaces for object variables? Should these still be in the zero page as they are in the NN? If each sprite has four elements (y, tile, attribute, x), will I need to reserve 256 spaces? It should then be a simple processing of finding/replacing the old SPRITE_BANK+xxx addresses with the new variable. These, of course, could be divided between the different elements of the game, such as Hero, Weapons, Enemies, etc. Different update routines, such as UpdateHero, UpdateWeapons, UpdateEnemies, etc., would be used for the rendering portions(?). Let me know if any of this is on track, hopefully some of it is. Connections to the NN would be helpful, if there are analogous elements. And thanks! I have been avoiding sprites for far too long, and this is really helpful. If nothing else, just trying to figure them out is a step in the right direction.


Edit/Update: I switched everything around and it all appears to be working using the logic above Also added in MRN's move one sprite, move the whole meta-sprite routine, which works wonderfully! Code is much more simplified now, though does it save on space/memory?

$00xx should be used for pointers...only.
$01xx is your stack.
$02xx is what you're using for sprites (though you can use whatever you want)
so use $03xx, $04xx, $05xx, $06xx, or $07xx for other variables.

Though MetalSlime uses $03xx for sound variables in his tutorials, IIRC.

So use one of the other pages for your "soft" sprite variables.