17 users online:  AmperSam, CircleFriendo, Doopu, DRACalgar Law, drkrdnk, Heitor Porfirio, JinRokhZenobi, JonoFeio1, Mario's GameBase, mizounimax, mothraLau, PuffleDreemurr, Quaza, RobloxFindTheMarkes,  sincx, Triple P,  Valentine - Guests: 68 - Bots: 215
Users: 66,272 (2,229 active)
Latest user: JestaJoke

Posts by MarioFanGamer

MarioFanGamer's Profile → Posts

  • Pages:
  • 1
  • 2
  • 310
  • 311
  • 312
  • 313
Basically, PIXI only reserves four separate tables for extra bytes but any more extra bytes and you have to read from the sprite level data instead. To help out with this process, the first three extra bytes contain the pointer to the actual extra bytes.

Basically, it results in code like this:
Originally posted by Valentine
Who’s Destin?

Originally posted by lolyoshi
I don't know who this Destin guy is, but he sure does sound wacky.

Mission acomplished!

It was quite a fun contest to build around the same paths which, as I've mentioned before, reminds me of the same sprites, different level idea we had in previous 24ho contests.

The only thing I was wondering (and seriously tempted to do) was to
use custom warps in such a way that it changes alongside level tiles and layer 1 tilemap while keeping it the same
but went against it by and have chosen a simpler submap (which in hindsight should have used a different pathing) as it's not only complex to code (so I wouldn't have had enough to time to finish designing my overworld) but also being very loophole-y. It does make an interesting idea for a full hack, though.

Interestingly, my fanjudging, while not without spoilers (as I did look into who made who), largely matches with the average opinions of the judges with only some outliers.

Edit: Also for completion, I've wrote down who used which submap:
FYI, the following submaps were used in the following submissions:
Here is the thing: Block interaction of sprites is somewhat weird as the only thing the general sprite<->block interaction handles is being blocked by ledges (and it doesn't even handle the speed), handling slopes, liquids and magma but every other, more complex interaction (like destroying turn and throw blocks or activating bounce sprites) must be handled within the sprite itself.

Which is precisely the problem here: This patch is no exception and if you want to make your ice block interact with, you must do so within the sprite. Simply checking for whether a sprite is a certain custom sprite ID doesn't work as it's never executed by the ice block.
The general procedure is to call GetMap16 at a certain position (i.e. ice block position + a certain offset) and check, if it's a coin and if so, collect it.
Originally a variation of MarioFan (which I initially used) but decided to add in "Gamer" as a form of differenciation.
For starters, it would help if you linked the track which causes problems.

Anyway, most likely samples. There are two potential causes for this:
  • The track explicitely excludes some of the samples (in which case it's meant for the overworld).
  • More likely, AMK, as part of an optimiser, doesn't samples which are unused in the track even though they're explicitely defined to be so.
To test this out, create a file Addmusic_options.txt in AMK's folder and put this into

Now you can run AMK with the sample optimisation turned off and check if all the sound effects are still messed up.

An alternative (if you're this advanced) open the folder in a command line (on Windows this means hold shift when you right click the folder) and type in (still assuming Windows) .\AddmusicK.exe -u <your ROM> (<your ROM> being a placeholder) in the command line.

If it still is broken, well, we simply need the track.
I won't fulfill it (right now) but as someone who's worked with code which synchs with them music, the way it works is that you can send two bytes of data with $F9 $xx $yy in the MML which then can be read from $7FB004 ($xx) and $7FB005 ($yy) in the UberASM code. The exact implementation differs since there is no one solution but the easiest would be to simply use $F9 $00 $00 and $F9 $01 $00 for on and off, respectively and store the value in $7FB004 to $14AF.
Minor correction: It should be $F9$00$00 and $F9$00$01, respectively since I confused which byte is stored where.

At its most basic, the UberASM code is simply this:
	LDA $7FB000+$04
	STA $14AF|!addr

Even better IMO would be to have the SFX be handled by the engine itself but that would necessate a more complex code alongside complicating the trackdata itself.
Moved to SMW Hacking Help because this clearly isn't a tutorial.

Basically, there is no option to modify the tweaker bytes of vanilla sprites and my short research doesn't show it as a planned function. Note that you can load a ROM in the editor but its only purpose is for viewing the tweaker bytes of each sprite, not for modifying them or extract a CFG/JSON for your own purposes.
For starters, you want to place the content of list.txt into [code] blocks for nicer formatting and prevent your post from getting stretched out.

UberASM will always look for the ROM specified in list.txt (that's the purpose of the line rom: SMW.smc and is incidentally the line where it throwns an error).

There are three options you can do:
  • Change your ROM to SMW.smc
  • Change SMC.smc into the name of your ROM (that's the most recommend option)
  • Remove the line and provide the ROM yourself through the command line (if you're a fan of command lines and scripts).
Assuming you have the coding skills for that (if not, create a request):
  1. Download the Rip van Fish disassembly
  2. Remove the code which checks for the distance between the player and itself
  3. Add a check whether the player is looking at the Rip van Fish and set the latter's corresponding place (not where the proximity check used to be, though, but rather before)
  4. Open the CFG file in CFG Editor and change the sprite's palette.
Yeah, I didn't realise I disabled more code than necessary in that I didn't realise that the !-blocks on the overworld are set by the same flag which set the !-blocks in the message. It's yet another bug I have to fix to the next update (which is more extensive, for that matter).

A hotfix is to move if !EnableSwitchPalace on line 269 between the STX $13D2|!addr and LDA #$20 so that it looks like this:
	STX $13D2|!addr		; Mark message as Switch Palace message
if !EnableSwitchPalace
	LDA #$20			; Don't mask out sprites.
	STA $43
	JMP DrawExclamationBlocks
I assume you use the latest version of YYCHR.NET. Basically, it will expand the currently loaded graphics file to 8 KiB if it is smaller than that. In practice, this should help users who have drawn something in the empty region which get discarded should (and it did cause some issues in the past in the original YYCHR), in practice, it's more of an annoyance because the warning comes up anytime regardless whether something in empty region is written or not (I'm pretty sure it's an unfinished feature, considering that the setting to disable the warning is ignored) so it's easy to expand the file by accident (which you did — you should click on "No" the next time the warning comes up).
There are two solutions: Grab a hex editor and trail off any bytes from address 0x1000 onwards or grap a different 4 KiB file and override it's content with yours.
LM = Lunar Magic i.e. the default level editor for SMW hacking.

On that aside, we discourage (unnecessary) bumping of threads such as this one which is more than a decade old, particularly in questions which have been solved for quite a while, especially when the posters are all inactive.
To spice things up, it has been moved.

  • Pages:
  • 1
  • 2
  • 310
  • 311
  • 312
  • 313