Language…
18 users online:  AmperSam, ASMagician Maks, autisticsceptile1993, Bernardo, bettyfelony27, Chadtronic,  Donut,  Fernap, Hayashi Neru, hh0962430, megfan2008, Moronsky, Reese, Selicre, ShoopDaWhoop, Thabeast721, TheKazooBloccGosh,  Valentine - Guests: 82 - Bots: 180
Users: 66,425 (2,327 active)
Latest user: Chadtronic

Posts by zuccha

zuccha's Profile → Posts

Right, this happens because the RPG hack hijacks mushroom, feather, fire flower, 1-up mushroom, and star sprites to tweak HPs and MPs in addition to add the power ups. When you are using custom shop blocks, you are not directly accessing those sprites, instead the blocks try to replicate their code.

To have the exact same behaviour of the power up items, you have two possibilities:

  1. Have shop blocks than spawn the power up sprite: This would work like a normal question block, but it activates only if you have enough coins. Instead of getting the power up or the HP/MP restore directly when hitting the block, the blocks would spawn a sprite that you collect (and in your case should have the exact same behaviour as defined by the RPG patch).
  2. Implement the same exact logic present in the RPG patch in the shop blocks: This would make it so that when Mario hits the block, he gets the power up or HP/MP restore directly, without the risk of the item running away. The problem with this approach, is that you would have to keep the blocks and sprites aligned (e.g., amount of HP restored); if you change one, you need to change the other.

Another reasonable solution would be having shop blocks that restore your HP and MP only, in addition to the shop blocks that give you special power ups (cape and fire). This way you don't need to replicate the entire logic of the hijacked items: Feather and Fire Flower items gives Mario cape and fire respectively if he doesn't already have them, otherwise they restores half of the MP restore value; IMO this is quite a weird behaviour for a shop block. Instead you could rely on simpler shop block, for example, you could have one that restores HPs to the max by doing this

Code
REP #$20	; Set A to 16-bit
LDA !MaxHealth	; Then set it to max health
STA !Health	; Replace health with new health
SEP #$20	; Set A back to 8-bit

and a block for restoring MPs to the max

Code
REP #$20	; Set A to 16-bit
LDA !MaxMP	; Then set it to max health
STA !MP		; Replace health with new health
SEP #$20	; Set A back to 8-bit

or combine the two to get both effects

Code
REP #$20	; Set A to 16-bit
LDA !MaxHealth	; Then set it to max health
STA !Health	; Replace health with new health
LDA !MaxMP	; Then set it to max health
STA !MP		; Replace health with new health
SEP #$20	; Set A back to 8-bit

Note that the defines !Health, !MaxHealth, !MP, and !MaxMP should be the same as those in "HP_Counter_Patch.asm". If you want to restore only a fixed amount of HPs/MPs the code becomes more complex because you would have to check that the added value doesn't exceed the max value or 999/99.

This is a design choice, but if you ask me, the ideal solution would be the alternative one, having shop blocks that have distinct and easily predictable outcomes (i.e., one block always give cape, one block always give fire, one block always restores HPs, etc.). Spawning item sprites (1) might also be reasonable. I don't like having shop blocks behaving like items (2), because their behaviour is context-dependent and might mislead the player (e.g., the player wants to restore HPs, but doesn't buy the mushroom because he think it's pointless since they are already big).
ROM Hack Manager - SMW Resources - SMW Toolbox
I can try working on this, but I promise nothing since I have little experience with sprites coding.

If I see that I'm unable to fulfil the request in the next few days, I will say so.

Just a few clarifications about the orbinaut's behaviour:

  1. If the player is not moving horizontally, the orbinaut doesn't move either
  2. When the player is moving horizontally, the orbinaut moves towards the player
  3. If the player is close enough to the orbinaut (regardless of them moving or not), the orbinaut starts shooting the spike balls at regular intervals

I'm asking just because I was a little confused by the "ignores player otherwise" part.
ROM Hack Manager - SMW Resources - SMW Toolbox
Hey people!

I'm implementing this request, a sprite where there is a central orbinaut, and four spiked balls rotating around it. The balls can be thrown towards the player.

I managed to implement the sprite by having one main sprite (the orbinaut) that spawns four spiked ball sprites on init. However, both the orbinaut and the spiked ball sprites are regular sprites, and the sprite ends up using 5 sprite slots, which is not ideal.

I tried implementing the spiked balls as cluster sprites instead, but I encountered the following problems:
  1. There is no equivalent of GetDrawInfo for cluster sprites.
  2. There are no utility routines for handling the interaction of cluster sprites with other sprites.

1. No equivalent of GetDrawInfo for cluster sprites

Peeking at other sprites on SMWCentral, I ended up implementing the following



Everything works fine until the spiked ball sprite goes slightly off screen horizontally, wrapping around on the other side of the screen. I guess it's because the screen starts at position 0, and if the value becomes negative it wraps around. What I can't understand is how normal sprites (using GetDrawInfo) can wrap around horizontally. I tried at looking at the code of the macro, but my brain is not cooperating in understanding it.

2. No utility routines for handling the interaction of cluster sprites with other sprites

When checking for collisions with other sprites, normal sprites rely on $018032, but this routine references normal sprite tables and values set through the CFG file. I tried copying and adapting it to cluster sprites, but the routine is rather long and has several branches handling all sort of stuff. Even if it can be simplified to handle only the behaviour of the spiked ball sprite, it does seem overkill and not flexible re-implemeting it.

Is there an equivalent routine for cluster sprites I'm not aware of, or simply put cluster sprites are not supposed to interact with other sprites, mostly for performance reasons?

TL;DR

Is trying to implement the spiked balls, which are supposed to interact with other sprites (e.g., can be eaten by Yoshi or killed by shells), with cluster sprites the right approach? Or are cluster sprites only supposed to have very simple logic (e.g., projectiles that kill Mario on touch and nothing else)?

If cluster sprites are not the answer, is there a way to implement such sprite without occupying more than one sprite slot? I thought about putting all the code (orbinaut + spiked balls) in one single sprite file, but that does seem too different than the cluster sprite approach, only less flexible.

Thanks for the help in advance #w{<3}
ROM Hack Manager - SMW Resources - SMW Toolbox
I completely overlooked the new PIXI version. I like the changes that were made there, but the new SpawnSprite is not backward compatible (just a note, not a complaint, and I like the new interface better).

Regarding drawing cluster sprites horizontally, the X high bit was indeed what I was missing in the equation!

Finally, I take your suggestion and stick to regular sprites for the spike balls, but I will also dive deeper on the workings of the collision routines you linked, they might come in handy at some point.

Thanks again!
ROM Hack Manager - SMW Resources - SMW Toolbox
Done, you can download it here.

A few notes:
- The behaviours you described should all be configurable through extra bytes (unless I forgot something). You'll find detailed instructions in orbinaut.asm.
- By default, it's configured for SP4 and palette 7 (F), but you can change graphics/palettes freely (instructions are in the readme).
- It requires 5 sprite slots, 1 for the orbinaut and 4 for the balls; I tried using cluster sprites for the balls but it didn't work out great :(
- It is SA-1 compatible.
- It requires PIXI 1.40, older versions don't work!

Let me know if everything is ok, or if there are any problems. If all is good, I'll submit it for moderation.
ROM Hack Manager - SMW Resources - SMW Toolbox
Oof, somehow I managed to forget power ups exist *facepalm*

Anyway, I solved the problem you raised, and a few others I found:

  1. Dismount Yoshi when colliding with spike balls.
  2. Make spike balls absorb player fireballs.
  3. Kill spike balls still attached to orbinaut if orbinaut turns into a coin (due to fireballs, silver p-switch, etc.).
  4. Include orbinaut's palette in bundle.

You can find the updated version here (I also updated the link in my previous post, to prevent people from downloading a bugged version).

I hope this version doesn't contain any other major issues #smw{^_^;}
ROM Hack Manager - SMW Resources - SMW Toolbox
From a quick look at it, ".loop" iterates 6 times. During each iteration, the loop loads whatever value is present at addresses "!ScoreCounterXPos" and "!ScoreCounterYPos", and it adds ".offset,y" (where y is the current loop iteration, from 0 to 5) to X and 8 to Y.

For example, let's imagine that

Code
!ScoreCounterXPos  = $0F01
!ScoreCounterYPos  = $0F02

and

Code
Address 0F01 = 10
Address 0F02 = 30


On the first iteration of the loop (y = 0), "LDA !ScoreCounterXPos" loads "10" into A, and we add ".offsets,y = .offsets+0 = 12" to "10", resulting in "22" being stored in address "$0200" (so, "22" is the X position). Similarly, "LDA !ScoreCounterYPos" loads "30" into A, but here we add a hardcoded "8", resulting in "38" being stored in address "$0201" (so, "38" is the Y position).

During the second iteration (y = 1) X will be "10 + .offsets,y = 10 + .offsets+1 = 10 + 20 = 30". Y will have the same value as the previous iteration ("38").

The same keeps going for each iteration.

The values stored in ".offsets" are independent shifts with respect to the left-most tile. This means that you need to change all the values if you want to modify the position, but keeping the same distance of 8 between each value. For example, if you want to set the initial offset to 18 instead of 12 you would have to change

Code
.offsets
       db 12,20,28,36,44,52

to

Code
.offsets
       db 18,26,34,42,50,58

To make the whole thing more flexible, you could define a constant "!ScoreCounterXOffset = 18" and use it as follows

Code
.offsets
       db !ScoreCounterXOffset, !ScoreCounterXOffset+8, !ScoreCounterXOffset+16, !ScoreCounterXOffset+24, !ScoreCounterXOffset+32, !ScoreCounterXOffset+40

I hope this answers your question :)

N.B.: All values, except for memory addresses, are expressed in decimal.
ROM Hack Manager - SMW Resources - SMW Toolbox
Even if "INC" without parameters is not an opcode defined in the 65816 specification, usually the assembler (Asar in this case) will treat it as "INC A", incrementing the value in the accumulator (the same is true for "DEC").

In this case, you load whatever value is stored at address "!TimerXPos" in A ("LDA !TimerXPos") and increase it by 2. This is roughly equivalent to

Code
LDA !TimerXPos|!addr
CLC : ADC #2

ROM Hack Manager - SMW Resources - SMW Toolbox
spooonsss already implemented this in a previous request, based on Kevin's disassembly. The sprite comes with a great degree of customization (either via extra bytes and defines in the ASM file).

You can change the color palette (by default green) to red by opening KoopaShellGreen.json with PIXI's CFG Editor and changing the Palette property from D to C.

If you want to use custom graphics, you can either modify the contents of GFX01.bin (but this will alter the appearance of all shells!) or enable property Use second graphics page in PIXI's CFG Editor and change what tiles to select with the !ShellTiles define in KoopaShell.asm.

If you disable Use second graphics page, the game will take the graphics from SP1 or SP2, if you enable it it will take the graphics from SP3 or SP4. If you use values smaller than 0x80 in !ShellTiles, it will be SP1 or SP3, if the values are greater or equal than 0x80 it will be SP2 or SP4.

Recap table:

1st graphics page 2nd graphics page
0x00-0x7F SP1 SP3
0x80-0xFF SP2 SP4

ROM Hack Manager - SMW Resources - SMW Toolbox
Probably that was the intent. As an exercise, we can check out how many cycles and bytes each instruction takes in the reference guide, and compare the two methods:

Code
INC		; INC A			2 cycles		1 byte 
INC		; INC A			2 cycles		1 byte
		; Total:		4 cycles		2 bytes

while

Code
CLC		; CLC			2 cycles		1 byte
ADC #2		; ADC #const		2 cycles		2 bytes
		; Total	  		4 cycles		3 bytes

So, the performance is the same (4 cycles), however the INC method only takes 2 bytes, compared to the 3 of the ADC one.

As a bonus, we can also notice that the first method modifies only the N and Z processor flags, while ADC changes N, V, Z, and C. This is not relevant in this case, but worth noting.

In this case, the double INC approach is preferable because it takes less space and it alters a smaller number of processor flags. However, if we had to add 3 instead of 2 to the loaded value, doing CLC : ADC #3 would be more efficient (both in space and performance terms) rather than doing INC : INC : INC.
ROM Hack Manager - SMW Resources - SMW Toolbox
I might claim this, but first I need a few clarifications.

In the video of Jump ½ there are the following variations:

  1. Skull Bomb, thrown: This bomb is throw with customizable horizontal and vertical speed (in a parabolic trajectory). Explodes when touching ground.
  2. Skull Bomb, falling: This bomb falls slowly, with a parachute. Explodes when touching ground.
  3. "Poké Ball" Bomb: This bomb starts flashing and explodes after a specific countdown.

From your description it seems you are requesting only (1) and (2), but not (3). The parachute (not included in the graphics) will be the same as the para-goombas. The included Walking Bomb graphics don't seem to be relevant.

About the Skull Bombs behaviour: they explode when either Mario, another sprite, or the ground touches them. They should have a "radius of explosion" (lasting until the last explosion graphics disappears), sprites in that radius are killed and Mario takes damage.

TL;DR You are requesting the Skull Bombs (thrown and falling), exploding on touch (ground, sprites, Mario), the explosion hit box lasts until the explosion animation is visible.

Did I understand everything right?
ROM Hack Manager - SMW Resources - SMW Toolbox
Just to avoid misunderstandings and prevent this thread from hanging indefinitely, has this been marked Claimed because you're testing it out? I'm not working on it, as I think that what spooonsss made is already more than enough.

If you think it satisfies the request, you can ask spooonsss if they can submit it in the sprites section (or if you can submit it on their behalf).
ROM Hack Manager - SMW Resources - SMW Toolbox
When you say sprite, do you mean its graphics? What program are you using?

If you are using YY-CHR, after you open a .bin file make sure to select 4BPP SNES/PCE(CG) format from the combo box on the left side.
ROM Hack Manager - SMW Resources - SMW Toolbox