Views: 959,714,364
12 users online: Anas, BooTheBun, DasFueller, drkrdnk, Julintendo,  Kevin, Koopster,  Segment1Zone2, theGrandGoku, TheJank, Vivian Darkbloom, WhiteYoshiEgg - Guests: 71 - Bots: 142 Users: 53,127 (2,224 active)
Latest: Peter Games_Br
Tip: Unlike for traditional hacks and Kaizo: Beginner hacks, usage of tools such as savestates and rewinds in Tool-Assisted: Kaizo and Tool-Assisted: Pit hacks is encouraged, if not necessary.
Not logged in.
2x2 brick by GreenHammerBro
Forum Index - Valley of Bowser - Moderation Questions - Blocks - 2x2 brick by GreenHammerBro
Pages: « 1 » Link

File Name2x2 brick
Submitted:2014-08-02 12:10:30 PM by GreenHammerBro
Act As:130
Includes GFX:Yes
Description:Unlike the other one already hosted in smwc, I made my own version and improved
can be broken by kicked sprites, cape spin, and spin jump (on top of the block)
similiar to davros's smb3 brick.

Note that it doesn't work in most areas in a
vertical level; the tiles will shatter improperly.

Ok, the most important thing first. We call blocks like this 32x32 blocks. Why? Because we're going by pixels, not by "blocks". For example, a normal block sized sprite is an 16x16 sprite. Smaller ones are 8x8. and so on. So please rename it to 32x32 brick block, so that people actually know what they have here.

Now for the code:

I'm sorry to say it like that but the code is flat out horrible. It does work, but I can't let this pass wasting so many bytes and circles for nothing and nothing again.

	JSR shatter_all		;>shatter the block
	JSR block_erase		;>remove self
	JSR shatter_multiple	;>and shatter adjecent blocks
	JSR shatter_effect	;>show pieces

This! What a colosal waste. Why do you make so many subroutines? shatter_effect and shatter_effect are both only called once. No reason to not just put the code here instead of a subroutine. The whole shatter_all routine too. Why not just use a normal branch (BRA) to get here? After the code returns from the subroutine (in both cases where it's called) it just runs into an RTL next. No reason to not just branch here instead.

The only thing that appears to make sense as a subroutine is the "block_erease" one, as it is called multiple times. But, it too, is useless.
Why? Because this is what the routine does:

	REP #$20		;\set shatter position
	LDA $9A			;|(sprite pieces position slightly
	AND #$FFF0		;|to the side can happen)
	STA $9A			;|
	LDA $98			;|
	AND #$FFF0		;|
	STA $98			;|
	SEP #$20		;/
	LDA #$02		;\erase the block
	STA $9C			;|
	PHY			;|
	JSL $00BEB0		;|
	PLY			;/

You clear the subpixels. That in and for itself is a good thing to do. However, you do this before you call the "shatter_all" routine too, and after that you always only add/substract #$10. So there is no way for there to be any subpixels. If you take that away only this remains:

	LDA #$02		;\erase the block
	STA $9C			;|
	PHY			;|
	JSL $00BEB0		;|
	PLY			;/

Ok, not sooooo bad. But it can still be shortened. Because you keep pushing and pulling Y without ever using it inbetween. So if you just push it once before and pull it after the whole thing, it'll work just fine. Making this another 2 lines shorter. Now we're left with just loading A, storing to RAM and calling the JSL. The JSR to the subtrouine takes up 4 bytes, the subrouinte itself (without the RTS) takes up 8. Really no harm done in just posing the code as is.

	SEP #$20		;|
	JSR block_erase		;/
	JSR block_erase		;>fix vertical level
	REP #$20		;\remove block X-1,Y+1

I refuse to belive that just calling this method twice magicaly fixes vertical levels. Moreso because all the routine does is clearing the subpixels and removing the block. And once the subpixels are cleared, they ain't gonne be set again.

Originally posted by Readme
-If the player breaks at least two 2x2 blocks at the same frame (or
frame-exact simultaneously), the top part of the screen will flicker,
this is because there are a lot of block updates per frame in a level,
and the game had to handle a lot of block-change routines at once.
Not too big of a problem, because this is very hard to do.

(why the unnecessary line breaks?)
About this. it IS a problem. Also, I was able to do this 10/10 times (when trying to do it) so saying "it's hard to do" doesn't really make the cut. For one, as I menioned, your block does have a lot of unnecessary routines to handle, so yeah, you could say that the game has some stuff to do, however if you look at some bigger sprites or effect codes, this blocks are nothing in comparision. I find it hard to belive that those few routines are the reason for the fliker.

Next are the blocks for vertical levels.

	LDA $B6,x		;\prevent pirceing in vertical
	EOR #$FF		;|
	INC A			;|
	STA $B6,x		;|
	LDA #$01		;|
	STA $1DF9		;/

The only difference between them and the normal blocks is this code (from what I could tell) which only inverts the direction of a sprite and plays some sound. Given the block is set to act like 130, the sprites should bounce of on their own. So this becomes useless and the blocks are the same. Sorry if I missed something here.

Lastly, think you could give them some better names? I'm not talking about the 2x2 thing here but the (1)(2)(3)(4) thingy. I think giving them a name that makes the position more clear wouldn't hurt. Like 32x32_brick_UL (upper left)

Anime statistic on MyAnimeList:
400 animes completed ✓
6000 episodes completed ✓
100 Days completed ✓
... what even am I doing with my life?
The reason for the flicker is because the game is trying to update sixteen blocks at once using the stripe image format. Apparently, that runs past V-blank resulting in a flicker at the top of the screen.
Pages: « 1 » Link
Forum Index - Valley of Bowser - Moderation Questions - Blocks - 2x2 brick by GreenHammerBro

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2022 - SMW Central
Legal Information - Privacy Policy - Link To Us


Follow Us On

  • YouTube
  • Twitch
  • Twitter


  • Super Mario Bros. X Community
  • Mario Fan Games Galaxy
  • sm64romhacks