The Overworld Design Contest ends in
Views: 897,751,858
11 users online: 7 up, Cheolpeoduck, h.carrell, mae_86, Missingno255, MLGKuba11, mr_cool, Phyll, Ragey, Schwarti, TheTaze - Guests: 65 - Bots: 73 Users: 50,366 (2,286 active)
Latest: theray
Tip: Add decorations to the overworld. Don't leave large empty grass or sea regions.
Not logged in.
Posts by macN64
macN64's Profile - Posts by macN64
Pages: « 1 2 »

First of all, thank you shyguyhex for showing an interest in helping to get SM64 hacks running on real N64 consoles. It would be incredible to play all these wonderful new levels on the real thing after all these years.

Before I continue, please be aware that I don't know very much about SM64 hacking and have never used a PC emulator. I'm just a guy with a flashcart. So please try and bear that in mind (go easy on me!)

Unfortunately, I'm having some trouble using this tool. I didn't get very far using either drag and drop method - the program either “stopped working” shortly after beginning or repeatedly displayed “could not open file”. I achieved my best result by right clicking the program and running it as an administrator. Next, I would manually type in the root to the Super Mario 64 ROM (“F:\Super Mario 64 (U) [!].z64”) and then press enter. When the tool asks whether or not to “Remove main CRC from ROM bootcode”, I first chose the 'no' option and let the tool finish it's work. Then, I restarted the tool and went through the whole process again, this time choosing the 'yes' option, so that I had 2 files at the end, one with the CRC removed and the other with the CRC left in.

Sadly, when I tried both files on my N64, they just displayed a black screen after booting up. For comparison, VL-Tone's old extender produces files that seem to work correctly up until the file select screen, where it freezes on a white screen.
When I tried patching some copies of the two files with some ppf patches, the result was the same, just a black screen immediately upon booting.

Do you think you could walk me through a specific example, showing the steps needed to make a SM64 hack work on a real N64? It would be really great if every step was covered, from downloading a specific patch (say, Super Mario 74), to correctly extending the ROM with this new tool, then finally applying the ppf patch (assuming that is in-fact the correct order!). I want to be sure that I'm not missing out anything important.

Finally, thank you for taking the time to read all this, and thank you once again for making this tool in the first place. Much appreciated!

(tl;dr – I'm struggling a bit with this tool. My understanding is that it would let me play some SM64 hacks on my N64 (using a flashcart). Could somebody please walk me through all the steps needed to get a SM64 hack running on a real N64 console? Thanks!)
Great to hear that you're still working on it, and encouraging to hear that an earlier build got a hack running on the real thing. I'm really looking forward to trying out future builds. #tb{^V^} Thanks again, and good luck!
Do you suppose you might come back to work on this in the future sometime? (I hope so! #tb{:(})
Hey guys,

Back in December/early January, I was screwing around with XVI32, trying to get more hacks working. One of the issues I encountered was with the "Additional music settings and sequences", but I think I've sort of managed to identify what part caused the problem.

My test subject was the Year of the Plumber C3 Demo.

When you run the pre-patched hack on console, this is what you get:

I put together a fairly lengthy xsc script (to use with XVI32) which did a few things:
1 - Fixes MIO0 data (replicates what Kyle describes here, which itself follows Vertrex's notes)
2 - Skip the CRC Check (as described here)
3 - Fixes the VI (as I describe here, last post)

If you take the pre-patched YotP demo, apply this script to it, then save it out as a new file and run it on console, this is what you get:

This is, I'm pretty sure, what queueRAM was describing here:
Does it run?
No. Title screen shows, but the audio sounds very wrong. After pressing 'start' to try to get to the main menu, screen glitches and system locks up. Can't even reset, need to power cycle. As I find time, I'll individually apply some of these changes to help narrow down which is the problem one, but they are mostly dependent on each other. If anyone has better ideas, please help me here.

Back in December/January, I basically went through the same process as queueRAM, and also identified the "Additional music settings and sequences" modification as causing issues. Then I compared a ROM at stage 4 (Music volume bug fix) which worked, and a ROM at stage 5 (Additional music settings and sequences) which didn't work, and I noted the differences.

When comparing the differences, it looks like there's huge amount of changes, but it really all broke down into a few "blocks" of varying sizes:
1 - 3 small clusters at $D4716, $D476A and $D4786
2 - A little bit at $D48B4
3 - About 20 lines of code at $7F0000
4 - About 100 lines starting at $7F1000
5 - Several thousand lines, starting at $3E00000

A bit of trial and error later, it seemed that only blocks 1 and 2 needed to be changed back in order for the ROM at stage 5 to run. Reversing these two blocks in the YotP Demo also allowed it to run. Here's the script:

REM /////////////////////////////////////////////////////////////////////////////////////////
REM Undo the Music Changes

REM Fixes 3 sets of 2. 000D 4710, 000D 4760, 000D 4780
ADR $D4716
ADR $D476A
ADR $D4786
REM ^^ Just a black screen when booting, if this is missing

REM Fixes 7 pairs on line 000D 48B0
ADR $D48B4
OVERWRITE 0C 0C 5C 10 24 05 01
REM Ah ha, this is the culprit! ^^

Now, when you run the YotP Demo after running both scripts (I've only posted the second one here, the first is rather lengthy), this is the result:

The game more or less works now, though there's still the usual missing texture issues in one stage. The audio "works", but most of the instruments are wrong (also note how chain chomp sounds like a monkey, and vice versa).

As you can probably tell, I'm pretty much in over my head here, and I don't have an understanding of why these changes allow the hack to run, only that they do.

I hope what I've posted here will be helpful to you, or will at least narrow things down a bit. :)
I think I've finally solved the mystery of the texture glitching. It seems to be caused by the absence of fog. See for yourself:

The level model is completely mangled, but you can still see which levels are textured and which are not. Here's my notes of what changes were made with each import:
Originally posted by Level Import Notes
1. Bob-omb Battlefield
Fog: None
Music: Bob-omb Battlefield
Background: Bob-omb Battlefield
Textured?: No

2. Whomp's Fortress
Fog: None
Level Music: Bob-omb Battlefield
Background: Rainbow Ride
Textured?: No

3. Jolly Roger Bay
Fog: None
Level Music: Dire Dire Docks
Background: Jolly Roger Bay
Textured?: No

4. Cool, Cool Mountain
Fog: Intense White (FF, FF, FF)
Level Music: Snow
Background: Cool Cool Mountain
Textured?: Yes!

5. Big Boo's Haunt
Fog: Intense Black (0, 0, 0)
Level Music: Haunted House
Background: Haunted House
Textured?: Yes!

6. Hazy Maze Cave
Fog: Subtle 1 Black (0, 0, 0)
Level Music: Hazy Maze
Background: Bowser First Battle
Textured?: Yes!

7. Lethal Lava Land
Fog: Subtle 1 White (FF, FF, FF)
Level Music: Lethal Lava Land
Background: Lethal Lava Land
Textured?: Yes!

8. Shifting Sand Land
Fog: Subtle 2 Yellow (EE, FF, 00)
Level Music: Lethal Lava Land
Background: Shifting Sand Land
Textured?: Yes!

9. Dire, Dire Docks
Fog: Moderate 1 Blue (00, 00, FF)
Level Music: Dire Dire Docks
Background: Jolly Roger Bay
Textured?: Yes!

10. Snowman's Land
Fog: Moderate 2 White (FF, FF, FF)
Level Music: Snowman's Land
Background: Cool Cool Mountain
Textured?: Yes!

11. Wet-Dry World
Fog: Moderate 3 Purple (8C, 00, 8A)
Level Music: Hazy Maze
Background: Wet-Dry World
Textured?: Yes!

12. Tall, Tall Mountain
Fog: Moderate 4 Green (00, FF, 00)
Level Music: Bob-omb Battlefield
Background: Bob-omb Battlefield
Textured?: Yes!

13. Tiny-Huge Island (Big Painting)
Fog: Intense Yellow (FF, FF, 00)
Level Music: Bob-omb Battlefield
Background: Bob-omb Battlefield
Textured?: Yes!

14. Tick Tock Clock
Fog: Very Intense Black (00, 00, 00)
Level Music: Slide
Background: Shifting Sand Land
Textured?: Yes!

15. Rainbow Ride
Fog: Hardcore Pink (FD, 99, FB)
Level Music: Slide
Background: Rainbow Ride
Textured?: Yes!

Originally posted by queueRAM
I also have a tool that I've put together to align all the MIO0 data to 16-byte boundaries, update the pointers in all the levels, make this 3D-to-7B change if needed, and updates the header checksum. It's a hacked from my sm64compress tool that's still a work in progress.

It works like a charm. Here's another video of Year of Plumber which I've used that version of sm64compress on, then fixed the VI and (re)fixed the checksum:

Music sounds much better now (chain chomp and monkey voices are still reversed, not sure if that's connected?).

Getting there!! #tb{^V^}
A couple more videos for you.

The first is a better version of this one, showing the effect of fog on textures:

All my imports thus far had been made using either Importer 1.9s or v16 (old). I thought I'd try making similar imports with the most recent release, and, well, this happened:

Originally posted by readme.txt
Changes in 1.9.2S:
*Increased 3D draw distance, no clipping in large levels
I'm thinking this might be the culprit?

Issues with 1.9.3S aside, do you think it would it be possible to add fog effects to levels that have already been imported into the rom? If so, it may then be possible to fix a lot of hacks that have already been released.
I'm not sure if it's just me experiencing this, but the Skip Mario Screen tweak seems to be causing issues for me. The save file used here has some stars (you can hear that I make it into the Cool Cool Mountain painting).

I tried again to double check, making minimal changes to the file.

Here, I took a vanilla “Super Mario 64 (U) [!].z64” and made two copies – one I called “Vanilla.z64” and the other I called “Vanilla+Skip.z64”.

I then took Vanilla+Skip.z64, and changed the following lines:
269F4C: 01 10 00 14 00 26 9E A0 00 26 A3 A0 14 00 02 0C
269FD8: 01 10 00 14 00 26 9E A0 00 26 A3 A0 14 00 02 0C

I then compared Vanilla.z64 and Vanilla+Skip.z64 using VBinDiff. This image shows the only differences found between the two files (in red). I haven't touched anything else (I even left the checksum parts alone).

Vanilla+Skip.z64 had no previous save file when I tried it (you can hear Peach and Lakitu).

Does anyone else experience this?

I'd also like to bring up Star Road here. Star Road skips the Mario Screen using a different method (I assume), as 269F4C looks unchanged from a normal, unaltered Rom, and 269FD8 looks like it contains a variation of what is normally there in an unaltered Rom*. For me, the skipped Mario screen doesn't cause any issues on console. However, when I get a game over, the problem returns.
*Star Road 269FD8: 1D 04 00 00 01 10 00 14 02 FB 00 00 02 FB 04 90

Well, this is what I experience anyway.
Thanks for the help Kaze. I hope I put this in correctly (sorry if I goofed). It now looks like this:
269F4C: 1D 04 00 00 05 08 00 00 14 00 02 0C 20 04 00 00
269FD8: 1D 04 00 00 05 08 00 00 14 00 02 0C 20 04 00 00

Unfortunately, I get the same result as before - the game continues, but nothing appears on screen.
Thanks again for your guidance Kaze. After some trial and error, I think I've got it working.

269F68: 05 08 00 00 14 00 02 0C
269FF4: 05 08 00 00 14 00 02 0C

Looks ok to me. :)
I've had a little play about with the editor, and it works fine on hardware:

I also put together an N64 compatible "Quick Start" ASM file for sm64.gen.z64 output files, that allows you to launch right into your current level upon starting the game:

// *********************************************************
// *** N64 Compatible Quick Start for Jedi's SM64 Editor ***
// *********************************************************
// (To be used with CajeASM by Tarek701)
// (Copy this text, paste and save in notepad, then use it as the ASM file)

// Super Mario 64 Editor (Unity) Output Settings:
// - Start Game in Current Level (Requires skipping Peach and Lakitu)
// - Skip Title Screen
// - Skip File Select Screen

// Then apply this ASM file in CajeASM. It does the following:
// - Fixes "Start Game in Current Level" by skipping Peach and Lakitu
// - Skips the Mario Head Screen at the begining of the game (N64 Compatible)
// - Skips Level Intro Text

// Peach Skip
.org 0x6BD4
ADDIU R0, R0, $0009

// Lakitu Skip
.org 0x6D90
ADDIU S0, R0, $0000

// Skips Mario Head Screen at begining of the game (but not after a Game Over)
.org 0x9114B8
TGEI T0, 0x0000
BNEZ R0, 0x00911CF0

// Level Intro Text Skips
.org 0x4B7C
ADDIU R0, R0, $4B3D
.org 0x4924
BEQ R0, R0, $00004940

The only thing "new" here is the Mario screen skip method used, which is based on the alternative Mario Screen Skip posted here.

If the editor is still being worked on, incorporating something like this into a future version (if possible), could help to keep it hardware compatible.
Originally posted by queueRAM
Just to be clear, are you using CajeASM after the sm64.gen.z64 ROM is built?

Yes, I'm using CajeASM after sm64.gen.z64 has been built.

Round about the time of the editors release, Jedi was keen on having SM64 launch into the currently worked on level straight away (so that you could see your results in an emulator as quickly as possible). I flagged up to him the issues I had with the “traditional” Mario screen skip on console, in the hope that his editor could be kept console compatible.

When I tried out the editor a few days ago, the “Skip Mario's-Head Minigame” output option had the same effect, for me, as the “traditional” Mario screen skip on console (black screen, but the game keeps running).

This ASM file I put together was a bit of a belated attempt to try and help towards getting SM64(.gen.z64) to launch straight into the current level in a way that still worked on console. It looked to me as though that problem hadn't yet been solved, but, as it turns out, you were already way ahead of me!

Originally posted by queueRAM
Also, have you seen the skip screen patches I've prepared as examples for n64split? I added the skip lakitu and skip peach methods based on your work a little while back. My skip Mario head patch is different because it just removes them from the level scripts instead of editing the ASM.

I hadn't seen those patches, no. I can't really “read” the code (I'm not a programmer, my ASM file was just altered bits copied from LemASM), but it all looks and sounds pretty elegant! It looks like you've got things taken care of.

I'm guessing that the “Skip Mario's-Head Minigame” output option in the editor isn't using your patch, since it doesn't work on console for me. Is that right?

Originally posted by queueRAM
Unfortunately, none of us have heard from Jedi in a while, so not sure if he is still working on it. I may take up the reigns of updating his new level editor once I officially release n64split.

That's a shame. Well, best of luck with n64split in the meantime.
Can anyone help out a Java newbie? I'm trying to use Kaze's fixing program (that was posted here earlier):

I've just being following some Youtube tutorials so far. I think I've got JDK installed successfully, and the code compiled. But when I then type "java interpretescript" into the command prompt and press enter, I get this error:
Error: Main method not found in class interpretescript, please define the main method as: public static void main(String[] args) or a JavaFX application class must extend javafx.application.Application

I'm not really sure what I'm doing here. Any suggestions?
Thanks again queueRam, your quick fix worked fine. I was just curious to see if this did anything much different than before.

C is not my thing, unfortunately, although I do intend to try and learn it at some point. Your sm64compress fixer is great though, it makes testing things on console a breeze!
It seems that alpha textures are properly displayed on console, even without the presence of fog:
(one block has a non-alpha texture, for comparison)

Once again, this was done in Level Importer 1.9S. Hacks made with some of the earlier level importers don't seem to display alpha textures correctly on console, but whatever caused that issue has seemingly been fixed in later versions.

Hope this gets us a little bit closer to finding a fix for the black/white texture issues. :)
I've been looking into water boxes a bit.

On N64, water often looks weird and contorts at some viewing angles. Calignous Cove from Green Stars, in particular, suffers pretty badly from this. This reminded me of the effects you see when a texture repeats too many times on a surface, so I had thought the water glitching might have been caused by the water texture being repeated too much.

However, it looks like this isn't the case. It looks more likely to be that the glitching occurs when the water box is too big (I guess?).

Here's a long, tedious video of my various experiments:

And here's my tidied notes:

waterbox6 = water texture scale=1, texture looks more stretched
waterbox7 = water texture scale=32(max), small texture many repeats.
waterbox9 = new model, big plane below to enlarge the level boundary, x(-7000) y(-7000), x(7000) y(7000), texture scale 32
When you spawn in level (up high), and hold R to hold the camera in place, the water contorts as you walk around.

waterbox10= same as before, but texture scale 2, also contorts when camera held up high.
So, water warping not texture related as I had thought.

waterbox11= 4 water boxes, various heights, all texture scale 16
No warping, by the looks of things.

Waterbox 12 = 4 boxes of same height
Waterbox 13 = 4 boxes of same height, low texture scale
Thanks for your input Kaze, as ever.

I gave a few of my tests (waterbox9 and waterbox10) a spin on Nemu, and I didn't encounter any water glitching, maybe it's different on other emulators.

I hadn't come across layers in SM64 before (didn't know what they were). I've now had a look at this page on origami, and I think I've got a better idea of what you mean now. I might have a go at trying to replicate your wall experiment setup sometime.
I think I've had a breakthrough. O.O

Following on from finding that alpha textures work without fog (video link), I wanted to try converting a solid texture into an alpha one in hex. Looking at this thread, here seemed like a good place to start:

Originally posted by cpuHacka101
Performs combining operations (ex. multi-texturing)

Syntax: Unknown

FC 12 7F FF FF FF F8 38 - Standard usage for solid RGBA textures
FC 12 18 24 FF 33 FF FF - Standard usage for alpha RGBA textures

I wanted to isolate and change that one solid textured block in mostlytrans.out.z64 (seen in the video above), by replacing “FC 12 7Fs...” with “FC 12 18s..”, semi at random, but I wasn't getting anywhere. So I thought, “alright, let's just try replacing all the “FC 12 7Fs” in the rom, it'll probably break everything, but whatever, let's see how it goes”.

Find All: FC 12 7F FF FF FF F8 38
Replace With: FC 12 18 24 FF 33 FF FF

And... it actually worked really well! Where we once had flickering between black and white, we now have textures! It also works with other hacks too. That being said, one side effect I've noticed, is that it basically breaks levels with fog effects – everything turns black and blue.

As an aside, this also seems to fix custom title screens. My guess is that the title screen objects would also flicker between black and white depending on the viewing angle, and that the angle the title screens were viewed at always showed them as being black. A black title screen object on a black background made it look like the object was missing altogether.

This probably isn't the correct way to go about fixing the textures, but hey, it works! It's a starting point, at least. :)
I tried replacing FC 12 7F FF FF FF F8 38 with FC 12 7E 24 FF FF F9 FC instead, and the effect looks the same as what you see when using FC 12 18 24 FF 33 FF FF (textures display, except for in foggy levels). So I guess that could be used as well/instead.

Good to hear that broken fog levels won't be an issue, in future. :)

I'm hoping to finish comparing different Level Importer versions and post my findings soon. Some Importer versions fix bugs, while other importer versions introduce new bugs. I've brought up these bugs before, but I want to be more systematic about it – find specifically what importer versions they occur in.
Here you go:

It froze after the Mario screen as you can see, so I still had to do the MIO0 realign thing myself (step one in this post). So, ImportTest2.z64 is just ImportTest.z64 after doing the realign thing. Not sure if that was intentional or overlooked or what, but I thought it was worth mentioning. I can also see the same sort of warping/distortion I've seen in the more recent Level Importers (from at least 1.9.3S onwards)(video link).

Hope this helps and good luck with your importer. :)
Nice! This is something I've been looking into (by comparing test roms), but your find and replace solution is much better than what I'd been doing. It never occurred to me to take the other bytes round about into account, so that you could do a simple “Find-All, Replace-With” to fix it. So thanks for that Davideesk! :D

Doing something similar, I think I've now got a working fix for the missing alpha textures in older hacks:
Find All: 15 06 00 00 0E
Replace With: 15 04 00 00 0E

Before and after video:

As usual, I don't know why this works, only that, seemingly, it does. #tb{^^}

Edit: Kaze tells me the number I change here is generally to do with the drawing layer. 06 is seemingly for water, and 04 is for alpha. Thanks Kaze!
Pages: « 1 2 »
macN64's Profile - Posts by macN64

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

Copyright © 2005 - 2021 - 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