PIXI v1.2: Some Sprite Insertion Tool of Sorts - Resource & Tool Releases

I ported the dynamic sprites routine to PIXI. It's now a global routine just like GetDrawInfo and SubOffScreen.

Call it with %GetSlot()

Before calling it, use $02 to store the 24-bit pointer to the graphics.

Hacks:

While it seems good, there are a couple of things I'd like to point out:

- JSL'ing isn't very needed, you could simply use JSR or better, put the routine there. Going for the fastest option is always the best thing you could do in SNES.
- The DMABUFFER routine isn't very well optimized for SA-1, you're always adding an offset ($74BC) to make sure that the BW-RAM destination is always $418000 (plus $0200 per upload) because before calling the routine the code adds $0B44, which is the base address of dsx's sprites ($7F0B44).
- And lastly, correct me if I'm wrong, but wouldn't all of these SA-1 transfers would upload everything to $418000 without moving the destination address and without taking into account Dynamic Sprites slots?

Code

	LDY #$80
	STZ $2238
	STY $2238
	LDY #$41
	STY $2237

Every transfer has that as destination address, unless I'm misunderstanding SA-1 DMA and it actually works like that.

Good work on porting it, though.

I updated the routine to optimize in general. Specifically, the DMA routines were practically redundant, and could have been shortened down to a loop and take less space. I also touched up the SA-1 DMA routine with an if-statement. Speaking of the SA-1 DMA routine, I didn't make the routine for the SA-1 DMA. It was the product of converting a dynamic sprite through Vitor's Sprite Converter, so I have no clue how SA-1 DMA works. As far as I know, the routine works, even on higan.

Hacks:

There was nothing wrong with having them redundant. I think that was the fastest option available unless, somehow, using a loop is actually faster.

And okay, I should learn how SA-1 DMA works, someday.

I decided to try this tool again. We do evolve. Just so you know, there's no 'generators' file and the last 8 colors of the selected palette in your new .CFG editor are missing.
Edit: Your editor does work! I'll try to insert some sprite per-level now.

Originally posted by Rykon-V73

I decided to try this tool again. We do evolve. Just so you know, there's no 'generators' file and the last 8 colors of the selected palette in your new .CFG editor are missing.

The colors are just a visual clue to which palette you're selecting, for people like me who always forget which are red/green/blue/yellow.
Also, I didn't have any generators and you can't put empty folders in a zip, hence it was omitted.

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

Originally posted by JackTheSpades

you can't put empty folders in a zip

Huh, works for me

or you could just add an empty file named placeholder.txt. Or grab a generator off the section.

<blm> zsnes users are the flatearthers of emulation

The sprites do appear to be different per-level.
Some sprites really don't want to work.
The sparkling block and the dissasembly of the dino-rhino sprites(Sprite Tool version) don't work.
Numerous errors appear when I use PIXI and yes, I used the tool below:
Code converter or something

rather than "numerous errors", it would help more to know what error exactly.

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

Okay, I'll post the pictures:
This is for the sparkling block:

The last 3 are for the fire-spitting dino-rhino:

Any way to fix this?
Edit: How do I insert poison.asm into my hack?
Do I use asar like normal or does PIXI have an option to include it in my hack?

I can't find the dino-rhino in the sprite section but at least the sparkling block is already written for asar, so putting it through trashxas is probably just gonna kill it. Cause all of these errors are caused by the asm file being faulty.

Also, currently there is no option for the poison.asm but you can just patch it like any other patch. Just be careful not to reapply it if you change the sprite number afterwards.

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

The fire-breathing dino-rhino is in Romi's S[ritetool.
Edit: I can't apply poison.asm, due to the error below:

Code

poison.asm:14: error: Unknown command. [assert($85 ( C9)]

So I downloaded the tool from the Tools Section and tried to insert the Boomerang Bro (and Boomerang obviously) as a test and I got this:

Quote

Enter a ROM file name, or drag and drop the ROM here: Test.smc
15 Shared routines registered in "routines/"
An error has been detected:
sprites/bros/boomerang_bro.asm:267: error: Label "GET_DRAW_INFO_loop" redefined [.loop]
routines/GetDrawInfo.asm:45 (called from sprites/bros/boomerang_bro.asm:256): error: Relative branch out of bounds (distance is -655) [BEQ .loop]
routines/GetDrawInfo.asm:66 (called from sprites/bros/boomerang_bro.asm:256): error: Relative branch out of bounds (distance is -691) [BPL .loop]

Strangely enough, the Hammer Bro, Bomb Bro, and Shell Bro all insert just fine, so something bizarre occurred within the Boomerang Bro file.

mod edit: don't stretch tables.
Subconsciously Edit: Wait, are you telling me that the code block stretched the table? I honestly wouldn't have expected it to, but what do I know about the weird way this site is constructed.

You can fix it by replacing ".loop" with "LOOP_START" and add a colon after the standalone ".loop".

Originally posted by Rykon-V73

The fire-breathing dino-rhino is in Romi's S[ritetool.
Edit: I can't apply poison.asm, due to the error below:

Code

poison.asm:14: error: Unknown command. [assert($85 ( C9)]

My bad (or moderators bad?), just remove the parentheses from the assert command like this:

Code

assert !NUM < $C9

Originally posted by MarioFanGamer

You can fix it by replacing ".loop" with "LOOP_START" and add a colon after the standalone ".loop".

Honestly, I have no idea why this should work?
So, in case it doesn't (and probably the easier solution) would be to just put a random label after %GetDrawInfo(). Like:

Code

SUB_GFX:
	%GetDrawInfo()
RANDOMELABEL:
	LDA !1602,x
	...

The problem here is that, you're probably having the boomerang bro as the first sprite in your list, which means when inserting it sorta "pastes" the code from GetDrawInfo there. Since in there I also have a .loop label and there is no redefined main label since, it thinks to redefine the ".loop".
I guess I should update the shared routines to use less common sublabels (or better yet, find a way to actually avoid these conflicts all together)

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

Macrolabels. ?derp:

(I don't remember how they work, all I remember is they act quite fucky. But they could work here.)

<blm> zsnes users are the flatearthers of emulation

This is how they are called:

Code

macro include_once(target, base, offset)
	if !<base> != 1
		!<base> = 1
		pushpc
		if read3(<offset>+$03E05C) != $FFFFFF
			<base> = read3(<offset>+$03E05C)
		else
			freecode cleaned
				<base>:
				print "    Routine: <base> inserted at $",pc
				incsrc <target>
			ORG <offset>+$03E05C
				dl <base>
		endif
		pullpc
	endif
endmacro
!Aiming = 0
macro Aiming()
	%include_once("routines/Aiming.asm", Aiming, $00)
	JSL Aiming
endmacro

Given that, I might actually be able to just use sublabels instead. Which would mean that A) they require a main label to be used but given the way sprites are usually coded (wrapper for main function) there really should always be one (except maybe the INIT call) and B) They'd still fuck with sub-sublabels. Though that seems like generally less of a concern.

I guess so long as there is no pushlabel sort of command, this is the best we got. Plus, it's actually the same way GPS handles it, so yay for continuity.

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?

How come SpriteTip doesn't work with this?

Kinda in hibernation for a while. I hope to be back in full swing soon.

Recently updated to sa-1 and I must say:
At first I was kind of disappointed with your tool due to all the different bugs I noticed.
But every single one of these bugs got fixed in this forum and now I can say that you made a really nice tool!
Great work!

An updated version in the tool section would be nice though...

My Youtube channel

Currently working on:
Project C

Finished project:

BIG FAT NOTE

If you are using a patch to insert custom bounce sprites, you will likely run into issues at some point. They share a hijack.

PIXI

Code

; ---------------------------------------------------
; tool relevant information.
; I'd advice against changing stuff in this hijack unless
; you also plan to update the tool itself
; ---------------------------------------------------
org $02FFE2
	db "STSD"						;header!
	incbin "_versionflag.bin"	;byte 1 is version number 1.xx

Custom Bounce Sprites

Code

ORG $02FFE2			; |(random freespace in bank 02)
				; |
COIN_FIX:			; |This is not neccessary for this patch to run, 
	LDA #$02		; |so delete it if for some reason you don't want it
	JMP $91BA		;/

I'll update the Custom Bounce Sprites patch ASAP, it's the one that is less relevant, and notice you people when I do that. I just need a random freespace in bank $02 or rewritte that hijack (most likely to happen).

I was having tons of weird glitches and crashes on my hack related to sprites being on screen and I believe this is why.