Posts by janklorde - SMW Central

damn, I knew it would be simple $#smw{^_^;}$ . Thats printed some garbage to the status bar, but I can work with that.

Thanks Darolac!

Bottom Text
--------------------

Am I doing this right?

Bottom Text
--------------------

(restricted)

So I'm using this sprite, to which I have added a simple

Code

 INC $18B4	;inc counter

to the end of the sprite_interaction_explode routine to increase a free RAM address when the sprite explodes, like so:

Code

.explode
       LDA #$09
       STA $1DFC|!Base2
       LDA #$0D
       STA !9E,x
       LDA #$08
       STA !14C8,x
       JSL $07F7D2|!BankB
       LDA #$4F
       STA !1540,x
       INC !1534,x
       LDA.b #read1($07F3FE+$0D)|$30
       STA !166E,x
       LDA.b #read1($07F4C7+$0D)|$03
       STA !167A,x
	   INC $18B4					;inc counter
.return
       RTS

The issue is that the sprite is linked to other sprites for creating chained explosions.
When the code detects a proximity explosion it is running the counter increase twice, making the count invalid.
I've tried decreasing the counter inside sprite_interaction_others_interaction like so:

Code

.others_interaction
       TYX
       JSL $03B6E5|!BankB
       LDX $15E9|!Base2
       JSL $03B69F|!BankB
       JSL $03B72B|!BankB
       BCC .return
       LDA !14C8,y
       CMP #$0A
       BNE .not_kicked
       LDA #$0C
       JSR check_sprite_above_sprite
       BMI ..not_above
       LDA #$00
       STA.w !AA,y
       STA !14EC,y
       LDA !D8,x
       SEC
       SBC #$0F
       STA.w !D8,y
       LDA !14D4,x
       SBC #$00
       STA !14D4,y
	   DEC $18B4					;do not double count in a chain reaction
       RTS

Strangely this method works only when detecting chained explosions to the left of the sprite, but still double-counts for explosions to the right.
This I cannot figure out, as there is nothing I can see in the code that handles what side of the sprite a detection occurs, or why it would do this.

For example, if you put 3 of these in a row and jump on the left-most one you get a count of 5, if you jump on the middle one you get a count of 4, and a count of 3 for the right-most one.

Any help on how what I would need to do to accurately count how many of these sprites have been detonated would be hugely appriciated

Thanks

Bottom Text
--------------------

Thanks for the reply.

I should have mentioned what the intent is for sure. The idea is to use these in a similar way to Crash Bandicoot, with a level clear condition of destroying all of these crates.
I'm using it with this uberASM I've wrote for keeping track of the count:

Code

Code: Show/Hide
Tiles:
	db $0C,$1B,$0A,$1D,$0E,$1C,$FC					; Tile data, "CRATES "
	db $FC,$FC,$3D,$03,$00						; Tile data, "  -30"


!TextPosition    = $0F00						; Position in status bar for text
!CounterPosition = $0F08						; Position in status bar for counter
!Counter         = $18B4						; Free RAM address for counter
init:		

main:

	PHB								;\ Swap data bank to wherever this code is running
	PHK								;|
	PLB								;/
	JSR DrawTilemaps        					; Draw the text on the status bar routine
	PLX								; Pull X
	LDA !Counter							; Load counter into A
	PHX								; Push X
	JSR Hex2Dec							; Now registers are loaded, jump to hex2dec
	STX.w !CounterPosition						; Write new X value to status bar tilemap position
	STA.w !CounterPosition+1					; Write new A value to status bar tilemap position
	PLX								; Pull X
	RTL								; Return 
	
DrawTilemaps:
	LDX.b #$0B							; Number of tiles to draw (tile count - 1)
-	LDA Tiles,x							; Load tile data indexed by the size
	STA.w !TextPosition+1,x       	 				; .. and store to appropriate tile
	DEX								; Decrease index
	BPL -								; Loop point
	RTS								; Return once loop complete

Hex2Dec:
	LDX #$00							; Zero X
-	CMP #$0A							; Compare accumulator to A (hex), 10 (dec)
	BCC +								; if carry bit not set, we haven't reached 10(hex)
	SBC #$0A							; Subtract A from X
	INX								; Increase X
	BRA -								; Branch back to compare
+	RTS								; Return

This prints some text and the counter to the status bar. Its cobbled together from some borrowed code, so its probably far from perfect, but it seems to do the job so far.

Now I thought it would be as simple as including an instruction to increase the freeRAM address in the sprite code to keep track of the count of how many had been destroyed,
but it's proving not to be the case. There's several exceptions where this system doesn't work as intended. For example if you throw a block during explosions the counter goes nuts,
as well as the unintended behaviour mentioned in the OP.

Thanks for the reply, it would make some sense if its to do with spawning order, but doesn't completely make sense since the INC $freeram instruction I'm using only runs twice under such bizarre circumstances.

Bottom Text
--------------------

I was starting to think that they keep running code even after they explode, I couldn't find anything that actually sets their sprite status to killed.
This is another problem actually, because we quickly hit the sprite limit and things stop spawning altogether at a certain point.

I've added this:

Code

.explode
       LDA #$09
       STA $1DFC|!Base2
       LDA #$0D
       STA !9E,x
       LDA #$08
       STA !14C8,x
       JSL $07F7D2|!BankB
       LDA #$4F
       STA !1540,x
       INC !1534,x
       LDA.b #read1($07F3FE+$0D)|$30
       STA !166E,x
       LDA.b #read1($07F4C7+$0D)|$03
       STA !167A,x
	   INC $18B4					; inc counter
	   LDA #$04					;\ set sprite status to killed
	   STA $14C8					;/

To kill the sprite after it explodes, I have no idea how this wasn't included originally anywhere $#smw{-_-2}$ very odd indeed.
This seems to work anyways to stop clogging up all the sprite slots.

So you're saying I need a different approach to how to count the sprites in general. I was starting to think along those lines due to the amount situations where my simple method fails.
For example it gives the wrong count for explosions due to the spawning order we've discovered, when triggered by a bob-omb or by a shell, and there is the issue of throwing a block resetting the counter for some reason.
The counter getting reset by throwing a block during a chain of explosions makes no sense at all since its using a free RAM address.

So you think I need to use a sprite table, detect changes and then increase the counter. Sounds logical, although I have no clue where to start implementing something like that. My ASM skills are... not great.

I'll have a look to see what I can find, although if anyone else could point me in the right direction that would be super helpful

Bottom Text
--------------------

Ah that seems to have solved it, seems to be working perfectly now! Thanks!

I've ended up keeping in setting the sprite status to killed as I had it, to free up sprite slots as we run into the sprite limit real quickly without it it seems.
Not sure why there's nothing in the original code to kill it. Maybe they weren't expecting you to use so many in quick succession.
Actually setting it to use sprite tables with indexing as you suggested makes the sprite vanish in a puff of smoke without exploding, but still increases the counter.
Its strange how often ASM does the opposite of what I think its going to do...

I've solved the bizarre counter behaviour just by changing what free RAM address we write the counter to.
No idea why it was doing what it was, but I'm not going to worry about it since it seems to be working fine now with the change.

I was monitoring that address with a RAM watch in BizHawk and it was underflowing(?) to 255 when you throw the block at a certain point in the level during a chain of explosions.
Perhaps there is a push or pull missing somewhere down the line resulting in resetting one of the registers maybe? That's all I can think of that could cause that behaviour, but I don't know.
Really really strange, because when I swapped addresses over to $18C5 instead, it works perfectly, and the old address doesn't change (which it shouldn't as a free address...)

So that is all I think! It appears to be functioning as intended now. Hopefully I don't run into any more bizarre exceptions.

I'm going to use this system in a couple of other sprites I want to include to continue the level theme.
I was thinking of doing a CB style checkpoint crate, NITRO crates etc. There's a nitro crate on here but it seems janky as hell. Plus it would be good to have it chain like these TNTs.

I've been working on some artwork for said new crates:

These are 32x32 but I think I wanna do them as 16x16, anyways I'm rambling.
Don't know if I'll use all of them, but I should be using a couple at least.
I think I can re-use enough of this modified sprite code to do all of these things.

Huge thanks for helping me with this, I will make sure credit is given to you.

Thanks again!

Bottom Text
--------------------

Originally posted by NoMoreStars

Has anyone else had any issues with the ice block graphics? I tried to figure out where it's pulling the graphics from, but I can't seem to figure it out, leading me to believe that it pulls the graphics from somewhere else installed in memory added by the hijack. Here's what happens below, something similar happens on all levels i've tested with.

(with the garbled graphics on the right being the ice block)
I could be wrong (I'm probably wrong) but that's the only conclusion I could come to and I have no idea what I'd have to edit to fix it. Unless it has to do with the fact that I have yet to update to 3.4.2 from 3.4.1. In that case, what does the updating process look like (considering it's required to install on a fresh unedited rom)?

You should be able to patch over 3.4.1 to 3.4.2 without starting from a clean ROM IIRC. You may not need to do that to fix this though. You might want to for the extra fixes etc, but that's up to you.

Did you replace GFX00.bin that comes with the pack? It looks like you didn't, as the patch replaces the star graphic and moves it elsewhere. It looks like the ice block is using the graphics from the vanilla GFX00.bin. A lot of the GFX here are replaced by DMA routines I believe, hence all the X's.

it should look something like this:

those are the graphics the ice block uses.

Hope this helps!

Bottom Text
--------------------

Hi again all,

So I've been making a Crash Bandicoot themed level using these sprites.
I've modified this to function as a NITRO crate, as the nitro crate on here is a little jank and doesn't chain explosions together like I want.

Anyways I've got the behaviour working as intended, but I want to add a small hopping animation to this sprite like in the crash series.
I've setting the Y-speed in numerous ways, but the sprite remains stationary.
I'm probably putting it in the wrong place, but the best I've got is where the sprites location gets offset in game from where it is placed in LM, which is definitely not right $#smw{x_x}$

I want to add this:

Code

	LDA $14					; \ Every 128 frames...
	AND #$7F				; |
	BNE +					; /
	LDA #$14				; \ Set the sprite's y speed to 20.
	STA !AA,x				; /
+

Which I think should make it hop every 2-ish seconds.

I'm probably putting it in the wrong place? Sorry if I'm being dumb, I suck at ASM.

Any help would be hugely appreciated

Thanks

Bottom Text
--------------------

Thanks for the reply WYE!

I've tried to insert the edited version as so:

Code

tnt_main:
       JSR draw_sprite
       LDA !14C8,x
       EOR #$08
       ORA $9D
       BNE return
       LDA $1887|!Base2
       BNE .jump_explode
       LDA !7FAB10,x
       AND #$04
       BEQ .no_gravity
       LDA !1588,x
       AND #$04
       PHA
	   
	LDA $14					; \ Every 128 frames...
	AND #$7F				; |
	BNE +					; /
	LDA #$EC				; \ Set the sprite's y speed to 20.
	STA !AA,x				; /
+
       JSL $01802A|!BankB
       LDA !7FAB40,x
       BEQ +
       LDA !1588,x
       AND #$04
       BEQ +
       CMP $01,s
       BNE +
       PLA

But there's still no movement. These crates really do not want to hop it seems...

There must be something else at bay here that is stopping it, or I'm doing something wrong (which is more likely).

Bottom Text
--------------------

Got it to work, this is correct but after combing through what was happening it became apparent I needed to change the extra bits and bytes for it to run the JSL $01802A routine.

Thanks WYE, it was jumping into the floor too which definitely wasn't helping me debug.

Bottom Text
--------------------

Hi all,

So I was wondering if its impossible to use custom midway sprites with the retry patch? I've been trying to make my own but setting $13CE to #$01 doesn't work.
I've also downloaded a few off here to see if I was doing something wrong, but they all work in the same way. However they don't work in game.

I was going through the retry.asm code once I thought it might be something to do with that and found a comment saying
"; we won't rely on $13CE anymore (to support the intro level)"
leading me to believe that this is indeed what is causing the issue.

So I was wondering if there is a way to set the midway using custom sprites?

Thanks

Bottom Text
--------------------

Yo thanks KevinM! Saved my ass yet again.

I'll bare that in mind for sublevels, I'm not sure how long this level is going to be just yet or if I'm going to include a sublevel but I might need to look more into that if I do.

As for what you've provided, works perfectly as always. Huge thanks Kevin!

Bottom Text
--------------------

Hi all,

So I'm having an issue when using parallaxing HDMA created with Effect Tool on layer 2 with a custom layer 3 BG, where the layer 3 is snapping back every few pixels and its not working on layer 2. It's the same problem as in This thread, but this was unsolved back then and I wasn't about to bump it! I haven't been able to find anything else on the issue either.

I was wondering if anyone knows of a way to solve this? The problem only exists when layer 3 has some kind of scrolling enabled, which is important because thats kinda the aim here.

Any help would be hugely appreciated!

Thanks

Bottom Text
--------------------

Hi all,

So I'm working on an uberASM patch that "animates" the clock icon in the status bar. I have a working uberASM capable of printing text to the status bar, however I need to add something that delays how often it prints the new tile.

I have this:

Code

Tiles:
	db $55,$56,$57,$58,$65,$66,$67,$68		; Tiles


;Address Defines

!Position    = $0F11					; Position in status bar to print to


main:

	PHB						;\ Swap data bank to wherever this code is running
	PHK						;|
	PLB						;/
	LDA $14						;\ Every 32 frames...
	AND #$1E					;|
	BNE +						;/	
	JSR DrawTilemaps				; Draw the tile on the status bar.
+	
	PLX						; Pull X
	RTL


	
DrawTilemaps:

	LDX.b #$07					; Number of tiles to draw - 1
-	LDA Tiles,x					; Load tile data indexed by the size
	STA !Position 	       	 			; .. and store to position
	DEX						; Decrease index
	BPL -						; Loop
	RTS						; Return once loop complete

This only seems to update once though. I thought adding the wait (every 32 frames, JSR DrawTilemaps) would have it update slower but this is not whats happening.
It is either not drawing a new tile, or its drawing all of them at once making it appear to not change (I suspect its the latter).
I've tried moving the waiting routine into DrawTilemaps, but this results in crashes for how I set it up.

I think whats happening is its completing the loop every time it jumps to DrawTilemaps, making it look like it never changes?

This is probably (and hopefully) simple to fix, but I am not great at ASM just yet. I'm sure I'm missing something easy.

Any help would be hugely appreciated.

Thanks

Bottom Text
--------------------

(restricted)

The goal here is to use this as gamemode 14 once functional so it is present across all levels, not sure if the wrapper is required in that instance?
Anyways, having tried removing it, it crashes as soon as the level loads so it will be staying in.

I did assume that because uberASM runs every frame, that this would update with that?

How would I go about implementing the loop so it draws a new tile from the table every X frames? My original thought of ANDing with the effective frame counter isn't really working out as I imagined.

Thanks for the reply

Bottom Text
--------------------

Yo thanks Thomas!

I'd started looking into using LSR followed by BCS/BCC to determine if we were on an odd or even frame, then have it draw a new tile with each update there, but this was a way too fast for the animation update rate.
The way you've done it here is definitely better than what I was going for.
I didn't think of using LSR here to gain some control over the update rate, but seeing it wrote down now it makes complete sense.
I could have done the same thing here using LSR multiple times and used the new carry flag to get a much slower update rate.

Strangely the solution I was working towards was a combination of both of yours, but wouldn't have worked as well as either one. I have much to learn.

I was wondering now, if its possible to sync up with the in-game timer? It looks a little odd otherwise. I now have this:

Code


Tiles:
	db $68,$67,$66,$65,$58,$57,$56,$55
	;db $55,$56,$57,$58,$65,$66,$67,$68			; Tiles


;Address Defines

!Position    = $0F11		; Position in status bar to print text



main:
	JSR DrawTile
	RTL


DrawTile:
	LDA $F30				; timer frame counter address
	LSR #2					; the number of LSRs here controls the update rate (each additional LSR halves the rate, from 60fps with no LSRs)
	AND #$07				; the number of frames. should be a power of 2, minus 1
	TAX
	LDA Tiles,x				; get the tile number for this frame, and set it
	STA !Position
	RTS

This is really close, but there's a point where it repeats the final frame either at the start or end I can't tell. I've tried using $F30 as well as $F33, neither quite do what I was hoping.

Basically, I have drawn 8 frames for the clock icon, starting at 12 o'clock, and moving round. I want to cycle through all of them before looping.

This is synced with the timer, but has a slight hiccup where it either starts (or ends) on a repeated frame and I can't tell why, If I change the AND value we draw random frames of the animation depending on its what value we AND with. As it is, it does draw them all, but duplicates one somewhere...

Thanks

Bottom Text
--------------------

Very cool level. Reminds me of Mostly Harmless purely for the reason of that's the only kaizo cloud level I've seen recently. Definitely underused tech thats you've done something pretty cool with, I hope the P-balloon section turns out great too!

Bottom Text
--------------------

Hi all,

So I've been working a particular port that's causing me some issues. It plays fine in the SPC player, however in game there is the occasional click/pop that is not present. As I'm relatively new to porting and its nuances, I was wondering if there's something obvious I can do to rectify this or if I'm missing something?

I've done a handful of ports now and they have otherwise been fine, just this instance. It is heavily sampled, something I've ported over from modarchive. Its not the first thing I've grabbed from modarchive, but it is the first one that's causing these issues.

Any help would be hugely appreciated, as the track is otherwise what the kids would call "a banger".

I'll happily provide more information if needed.

Thanks

Bottom Text
--------------------