Need help with keeping tile change after coming back to old screen

So, I finished re-watching the advanced tutorials on the new8bitheros site. and came up with an idea for keeping the tiles positions for when brought back from the
battle scene/room. the idea came from the scrolling platformer tutorial which was to take the code from the checkpoint script to keep the changes in tiles despite
transitioning scenes/rooms... still doesn't work. I dunno man here is the segment of the code where I wish it would save changed location changes of all tiles:

changeTileOneBackToEmpty:
LDA currentNametable ;; shouldn't this be what needs to be loaded?
STA continueScreen ;; and saved here?
ChangeTileAtCollision #$00, #$0E
DestroyObject
RTS
and yes before you ask I put LDA currentNametable and STA contunueScreen before and after ChangeTileAtCollision.

if you can help me thanks! if not I'll figure it out eventually.

EDIT: IGNORE THIS SCRIPT TRY HELPING WITH THE NEXT PLEASE!
 
Last edited:
tried this in post screen load via the power of the MetroVania tutorial and it still didn't work but it seems like the more correct path based off the video
now that I thought of it:
checkForLockTiles:
UNIT_01_VALUE = #$01
UNIT_02_VALUE = #$02
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; Before we turn the screen on, check for lock blocks.
;;; If a tile is a lock block, and the trigger is tripped,
;;; turn it into a null block.
LDY #$00
doCheckForLockTiles
;; first, do we check colTab1 or colTab2?
; LDA camScreen
; AND #%00000001
; BNE +isOddScreen
;; is even screen
; LDA collisionTable,y
CMP #UNIT_01_VALUE ;; change this to whatever value you are looking for.
;; here, we're looking to see if the collision type is
;; a Unit block, which we currently have in our 1st tile
;; spot.
BEQ +isALockTile
CMP #UNIT_02_VALUE
BEQ +isALockTile
JMP +checkNextTile
+isALockTile
LDA #$00
STA collisionTable,y
LDA #$20
STA temp1
JMP +doUpdateGraphicsForThisTile
+isOddScreen
LDA collisionTable2,y
CMP #UNIT_01_VALUE ;; change this to whatever value you are looking for.
;; here, we're looking to see if the collision type is
;; a lock block, which we currently have in our 6th tile
;; spot.
BEQ +isALockTile
CMP #MONSTER_BLOCK_TILE
BEQ +isALockTile
JMP +checkNextTile
+isALockTile
LDA #$00
STA collisionTable2,y
LDA #$24
STA temp1
doUpdateGraphicsForThisTile:

TYA
STA temp
LSR
LSR
LSR
LSR
LSR
LSR
clc
ADC temp1
STA temp2 ;;;temp16+1
TYA
AND #%11110000
ASL
ASL
STA tempz
TYA
AND #%00001111
ASL
ORA tempz
STA temp3 ;temp16

LDA temp2
STA $2006
LDA temp3
STA $2006
LDA #$00
STA $2007

LDA temp2
STA $2006
LDA temp3
CLC
ADC #$01
STA $2006
LDA #$01
STA $2007


LDA temp3
CLC
ADC #$20
STA temp3
LDA temp2
ADC #$00
STA temp2

LDA temp2
STA $2006
LDA temp3
STA $2006
LDA #$10
STA $2007

LDA temp2
STA $2006
LDA temp3
CLC
ADC #$01
STA $2006
LDA #$11
STA $2007

+checkNextTile:
INY
CPY #$F0 ;; 240 - last collision byte.
BEQ +doneWithLockTiles
JMP doCheckForLockTiles
+doneWithLockTiles
this doesn't even change the #$01 tile or #$02 tile even on bootup load... :|
 

Jonny

Well-known member
The scrolling platformer tutorial you mention. Is is covered in the intermediate one or advanced??? I feel like I need to re-watch that before attempting to help.

To be clear, are you wanting to change a tile with the ChangeTileAtCollision macro within a tile type script, then walk away from it (on a section of scrolling screens) walk back and have it still changed, not back to its original tile?

I'll watch the video first but initial thoughs are that the nametable data will have not changed so when it loads there is no record of that change to the tile. Personally, I'd be thinking about putting some sort of check in the tile script to make it change to the activated tile streight away by using a variable to indicate if you've already activated it before. In other words, make it so the tile is always changed whether you colide with it or not but only when that certain condition is met. Hope that makes SOME sense. It's hard to explain lol
 
The scrolling platformer tutorial you mention. Is is covered in the intermediate one or advanced??? I feel like I need to re-watch that before attempting to help.

To be clear, are you wanting to change a tile with the ChangeTileAtCollision macro within a tile type script, then walk away from it (on a section of scrolling screens) walk back and have it still changed, not back to its original tile?

I'll watch the video first but initial thoughs are that the nametable data will have not changed so when it loads there is no record of that change to the tile. Personally, I'd be thinking about putting some sort of check in the tile script to make it change to the activated tile streight away by using a variable to indicate if you've already activated it before. In other words, make it so the tile is always changed whether you colide with it or not but only when that certain condition is met. Hope that makes SOME sense. It's hard to explain lol
Answer for Question One, they do not cover checkpoints in the platformer tutorial just popped into my head

Answer for Question Two, not a platformer check this video out for what game I'm making:
View: https://www.youtube.com/watch?v=_xGyOq6pnME


Answer for Question(?) Three, I already use ChangeTileAtCollision with the "player" it doesn't save between one screen and another. it's not a scroller but it might be later
if I have enough space (which is probably)

thank you so much for the check in! hope you can help me!
 
sorry for the impatience but I am ALMOST done with the demo.
I promised a group of people that I would show them the pre-alpha demo around July 3rd (yes that funnily close to holiday haha)
and yeah, worse comes to worse I'll just show them current progress... but it would be great to let them test it!
and to do that I STILL need to figure out how to save tile changes between screens
I've tried implementing tile changes from the Scrolling Platformer and Metrovania official tutorials and still no dice BTW :|
 

JamesNES

Well-known member
If you're letting players change arbitrary tiles to arbitrary tiles, like moving characters around the screen as tiles as in Fire Emblem, there's no simple way to preserve them across screen changes.

When you load the original screen back in it'll load in all the default collisions for that screen, so you'd have to have saved all the changes, ie tile X/Y and what type it changed to, into RAM somewhere, then reload them all before the screen turns on. There's no standard NES Maker thing to do that, you'd have to write it yourself.
 
If you're letting players change arbitrary tiles to arbitrary tiles, like moving characters around the screen as tiles as in Fire Emblem, there's no simple way to preserve them across screen changes.

When you load the original screen back in it'll load in all the default collisions for that screen, so you'd have to have saved all the changes, ie tile X/Y and what type it changed to, into RAM somewhere, then reload them all before the screen turns on. There's no standard NES Maker thing to do that, you'd have to write it yourself.
Just had an idea reading that! (it makes things maybe slightly not optimal but it should still WORK in theory). My player cursor moves tile by tile already by just updating x & y via input scripts... maybe I should start the cursor that (if multiplayer no CPUs will currently made in demo but will later) will change who controls it via their turn.
BUT The main thing about the cursor is that depending on how many times it moves left, right, up, or down I'll set a X vartiable and Y variable in RAM that ADC's or SBC's
in the input scripts EX: MoveCursorDown ADC's the Y variable. THEN when moving a unit tile it'll have to save the currentCursorXY Vars to a specificUnit XY Vars and bata-boom
again in theory change these tiles with the power of POSTSCREENLOAD and your saved vars then your done! you might be concerned with two things though

1. that limits How many units you can move because of how many of the variables you can fit and if you want to duplicate the same unit you can't with this idea!

Answer: 4 Units per Side no duplicates and same applies to even in-story levels (trust me it sounds lame but there are gameplay reasons for that to tech ones just a gameplay idea that changes this from FE the most)

2. Then how are you going to handle scrolling?

Answer: No Clue yet LMAO worse comes to worse I won't have enough space 512 whateverbyte-wise to fit eventual solution to that and the scrolling itself
but for now there is no scrolling and because of that in the muliplayer alpha demo there can only be a 1v1 match instead of say potential future 2v2 or free for all.
GRANTED YES I KNOW NESMAKER DOESN'T IMMEADITLY LET YOU USE THE FOUR SCORE PLAYER METHOD BUT THIS MIGHT BE LATER TOO IDK! and the main reason you need
scrolling for a free for all or 2v2 is due to more space to move units and have some distance to move around.

but yeah this idea SHOULD work for the alpha demo but I won't have time to code that today due to me having appointments multiple places today.
so tomorrow is when I'll try this. again if i missed anything from anyone's perspective let me know alright? K talk to all yall later. PEACE!
 
also (again) it does fully work now forgot to say I worked on it for 15 mins after an hour yesterday,
CLC command man... HOW DID I FORGET THAT YESTERDAY!?!
if you want to know how/why I did it btw wait for episode 2 of my DEVLOGS, almost there but I need to finish one or two more things before
I make that devlog. alright peace! (for now ; )
 
UPDATE TO THIS "SOLVED" ISSUE:
the demo I show is going to be more limited than I thought...
which is fine as long as I can show the very baseline
TLDR, the postscreenload is only allowing one tile unit per load. despite me spawning in a few checkers for changetileatlocation stuff
"why?" you may ask. I THINK because the tile script that changes it when collided into is causing the issue. because there are MULTIPLE quick spawned in checks based on the previous location... it wont change more then the first CreateObject location because it would have to happen at LEAST more than once at the same time.
but yeah that's the best I can explain my best guess... if someone can help me with that before at LEAST the end of august that would be great.
I will show this problem and a bit of positivity other places in DEVLOG 02 so look foreward to that at least! okay deuces!
 
Top Bottom