Language…
2 users online: autisticsceptile1993, TheMorganah - Guests: 63 - Bots: 103
Users: 67,679 (2,002 active)
Latest user: Saya

Wild Mechakoopa v1.1

SMW Sprites → Wild Mechakoopa v1.1

LinkShow random

Submission Details

Name: Wild Mechakoopa v1.1
Author: Darolac
Added:
Version History: View
Tool: PIXI
Type: Standard
Dynamic: No
Disassembly: No
Includes GFX: No
Description: This Mechakoopa hops around with customisable period and maximum height. If the extra bit is set, the Mechakoopa will explode instead of recover after begin stunned.

Includes a lot of defines to customise:

-Custom palette for the extra bit version.

-Expanded palettes for the recovering animation (up to 8 different palettes).

-Customisable recovery time.

And a lot more. Check out the readme for the details

Based on imamelia's dissasembly of the Mechakoopa.

v1.1

What's changed:

-Now SA-1 hybrid.
-Added three extra bytes to customise the mechakoopa Y speed, X speed and palette.
-Fixed sprite-sprite interaction so now the mechakoopa updates his speed even in the air when interacting with another sprite.
Tags: castle enemy lorom mechakoopa sa-1
Comments: 3 (jump to comments)
Rating:
0.0 (0 ratings)
No rating
Download 4.67 KiB | 807 downloads

Screenshots

View all

Comments (3)

Darolac Author Link
Originally posted by Gamma V
It would be helpful to have a good set of "default" values for the first two extra bytes. As it is, you have to use trial and error to even get the sprite to move. These values would honestly have been better left in the .asm file, even if it means the user needs to put in more sprites for versions that move faster/slower than the default.

A json file with default values can be added to solve that. Unfortunately, I'm pretty busy rn, but I give my permission if someone wants to add this.
Gamma V Link
It would be helpful to have a good set of "default" values for the first two extra bytes. As it is, you have to use trial and error to even get the sprite to move. These values would honestly have been better left in the .asm file, even if it means the user needs to put in more sprites for versions that move faster/slower than the default.
 Sonikku From older version: Wild Mechakoopa Link
If you want a better method for facing Mario, I'd suggest replacing:
Code
if !Framesface == 1

LDA $C2,x	;
INC $C2,x	;
AND #$3F	; every 40 frames...
BNE NoSpeed	;

endif

%SubHorzPos()
TYA		; turn to face the player
STA $157C,x	;


This will cause the sprite to face Mario every #$40 frames, and run even when it is facing Mario. This means that if Mario jumps behind the sprite right when the timer becomes #$3F, it'll immediately turn to face him, which feels odd. I have rewritten this portion to make it fall more in line with the behavior of SMWs sprites with:

Code
%SubHorzPos()
if !Framesface != $00
LDA $163E,x	; \ branch if timer not set
BEQ CheckDir	; /
CMP #$01	; \ branch if timer not 1
BNE NoSpeed	; /
LDA $157C,x	; \
EOR #$01	;  | 
STA $157C,x	; /
CheckDir:
TYA		; \ branch if facing mario
CMP $157C,x	;  | 
BEQ NoSpeed	; /
LDA #!Framesface; \ set timer
STA $163E,x	; /
else
TYA		; \ set direction
STA $157C,x	; /
endif


This code will check if the sprite is already facing Mario, setting a timer when it isn't. When this timer hits #$01, it turns around. This allows the sprite to be slightly more predictable but still keeping the idea in place.

Additionally, it's unneeded and relatively easy for one to do themselves, but I'd recommend future-proofing this sprite by adding SA-1 and GIEPY support.