Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Puyo Puyo 1 / Dr. Robotnik's Mean Bean Machine #75

Open
radioshadow opened this issue May 2, 2024 · 3 comments
Open

Support for Puyo Puyo 1 / Dr. Robotnik's Mean Bean Machine #75

radioshadow opened this issue May 2, 2024 · 3 comments

Comments

@radioshadow
Copy link

So the way sprite data is stored is slightly different to Sonic 1 and 2. The way it works:

1 - Long Offset to Sprite Header
2 - Word containing how many sprites to load (0 = 1 Sprite | 1 = 2 Sprites | 2 = 3 Sprites | etc.)
3 - Sprite 1 Data (stored the same way as Attribute Table: https://wiki.megadrive.org/index.php?title=VDP_Sprites#Attribute_Table)
4 - Sprite 2 Data, Sprite 3 Data, etc.

The LINK is automatically assigned when generated. The game data just groups them with the same number. So ones with "0" will get generated first, followed by those with "1", etc.

Here's an example of the PRESS START in the asm file for the Puyo Puyo English translation I'm working on:

Title_Start:
					; Press Start
					
							; Set of Sprites
		  Set_of_Sprites	3		  
					
							; Pal | Tile | Priority | X | Y | Hori Flip | Vert Flip | Width | Height | Link
			Sprite_Piece	PAL_1, $3CA, High, -44, 0, No, No, Pixels_32, Pixels_16, 0
			Sprite_Piece	PAL_1, $3D2, High, -12, 0, No, No, Pixels_32, Pixels_16, 0
			Sprite_Piece	PAL_1, $3DA, High,  20, 0, No, No, Pixels_24, Pixels_16, 0

Correct me if I'm wrong, but I think Sonic 1 looks for "spriteHeader" in the asm, and "MS_Stand_End" tells the tool that is the end of the sprite data for that header.

I'm thinking that it would be best to look for each "Set_of_Sprites" text, which tells the tool how many sprites to generate.

Sonic 1 uses a "spritePiece" macro to create the data. In this case, the tool uses it to load the sprite data. Does this "spritePiece" macro need to be in the tool, or does the tool know where to locate it? Here's the "Sprite_Piece" I made, in case you do need to include it:

Sprite_Piece: 		macro pal, tile, pri, xpos, ypos, xflip, yflip, width, height, link

				; Pal | Tile | Priority | X | Y | Hori Flip | Vert Flip | Width | Height | Link
		dc.w	ypos
		dc.w	((width&3)<<10)|((height&3)<<8)|link
		dc.w	((pri&1)<<15)|((pal&3)<<13)|((yflip&1)<<12)|((xflip&1)<<11)|tile
		dc.w	xpos
		
		endm

If that could be added, that would be great. :)

@kirjavascript
Copy link
Owner

Hi! The macro needs to be included the same way that MapMacros.asm is included in the scripts directory currently

I'll look into this and try and get it into the next version!

@radioshadow
Copy link
Author

radioshadow commented May 9, 2024

So using the Sonic 2 format, I was able to load it in Flex 2:
a

Here's what it currently looks like:
b

So a "Puyo / Mean Bean" script would need to be added to:

  • Use long table entry instead of word entry: mappingsTableEntry.l
  • Make a note of the number of sprites (word value). Have it as part of the spriteHeader info.
  • Make a note of the Link ID.

For some reason, Flex2 likes to completely change the name of the labels:
c

So:
Puyo_Sprite_table > Map_ba3f
This is very irritating because the disassembly won't compile it changes. It would be nice if the other labels where kept the same. Also, the number of sprites and Link ID need to be there, along with using mappingsTableEntry.l.

Hope that helps add support to Flex2. :)

@kirjavascript
Copy link
Owner

Thanks!

Something I want to add is the ability to retain labels

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants