Language…
16 users online:  Deeke, Dennsen86, eltiolavara9, Green, Hayashi Neru, Heitor Porfirio, Jolpengammler, LazyRuns, neidoodle, NewPointless, Pizzagamer9791, playagmes169, Serena, ShoopDaWhoop, SMWizard, YuriGamer - Guests: 259 - Bots: 327
Users: 64,795 (2,376 active)
Latest user: mathew

The SM64 Console Compatibility thread.

Originally posted by aterraformer
Since this is kinda.. uh resting, would anyone be willing to get Zelda's Birthday running on console? Like, importing the maps onto a 1.0 or 1.2 rom or something? Does that technology even exist? I dunno, worth a try to throw that out there.

>bumps thread
>informed that bumping is useless and annoying
>proceeds to bump thread with completely off-topic zelda thing
>that signature
Accurate. It's not that off topic and probably better to post here than make a new thread in the Misc. ROM Hacking section.
Your layout has been removed.
Originally posted by aterraformer
Accurate. It's not that off topic and probably better to post here than make a new thread in the Misc. ROM Hacking section.

This is the Super Mario 64 forum. What on earth makes you think Ocarina of Time is anywhere near relevant? There's no reason to avoid making threads if there's no good one already.

I don't want to see anything else about Zelda, or this derailment, in this thread. If the next post isn't about Super Mario 64, you're banned. If you have any further questions, PM me.

Originally posted by SmithJrBlaquaLuigi
whine whine

sigh. have you ever done anything useful
<blm> zsnes users are the flatearthers of emulation
Well IIRC OOT is built off of SM64 so...

In all seriousness though: Is there a list anywhere of hacks that do work on real hardware? From what I hear all of skelux's hacks work on real hardware. Not sure if that's true or not though.
Team CornersoftYoutube
*me bring my coat, grabs my phone and leaves the house so this thread wont bump anymore. Grabs the keys then lock this thread*
Originally posted by SmithJrBlaquaLuigi
*me bring my coat, grabs my phone and leaves the house so this thread wont bump anymore. Grabs the keys then lock this thread*

Was this post really necessary?

Originally posted by Kazeshin
Originally posted by Luigixhero
Well IIRC OOT is built off of SM64 so...

In all seriousness though: Is there a list anywhere of hacks that do work on real hardware? From what I hear all of skelux's hacks work on real hardware. Not sure if that's true or not though.


no SM64 hack works on the real hardware, aside from TT64 only hacks that have been through my fixing program and that thing macN64 made.


Eh, are you sure?

And I know for a fact that SM64 Star Road does not work on the N64. Blackscreen when you load it on a flashcart. Probably because of memory issues.
Originally posted by SmithJrBlaquaLuigi
I'm starting to get annoyed very quickly.

I'm more annoyed. I told this thread very clearly to quit talking about the bumps and offtopicness. I also told you, SmithJr, multiple times to quit trying to set or enforce the rules in this forum. 72 hour ban for disobeying multiple direct moderator instructions.

If any further posts are not strictly about Super Mario 64 console compatibility, I'll start editing and deleting them.

e: Oh, and every post since mine, other than yours and half of Mayrio's (which I'll accept since the other half is relevant), are on topic. They're also no more than a day or two after the previous one, which means it's not a bump.
<blm> zsnes users are the flatearthers of emulation
Well, I came to that conclusion because in most hacks you have to extend the memory in Project 64 in order to play it. Don't just assume it was a "wild theory" of mine #ab{;)}
Then I suppose N64 emulators aren't accurate enough(like hacks you can only play on zsnes because of broken addmusics).

Sorry for sounding like an idiot.
Can anyone help out a Java newbie? I'm trying to use Kaze's fixing program (that was posted here earlier): http://pastebin.com/HYvAJr9h

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:
Quote
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?
Originally posted by macN64
Can anyone help out a Java newbie? I'm trying to use Kaze's fixing program (that was posted here earlier): http://pastebin.com/HYvAJr9h

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:
Quote
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?


I'm not even sure what Java compiler Kaze ever got that to build an run with. You need to do a few things:
1. main() must be static and take "String args[]" parameter
2. you can't access those class variables in static method, move code to processing method and have main create instance of class
3. make all class members private (and not static)
4. make it useful by providing file name on command line

My quick version (untested): http://sprunge.us/LbBA

Also, if C is more of your thing, I'd recommend taking a look at the source code for sm64compress fixer that I linked to in a previous reply. This aligns all MIO0 blocks, makes the sound fixes and is well commented.
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: youtu.be/gG1NlfteX1c
(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: https://youtu.be/lsZ3p05I1lg

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
yeah, i would think its a layering issue within SM64s graphics and not console related - when you use specific layers beneath each other, those effects will occur. i'm not too sure which layer water uses or if even all layers are useable; here's something from my experiments:
setup: have a wall1 and a a smaller wall2 closely infront of it.
wall1 uses layer 1;

if wall2 is layer 2: no weird striping, but on far distance, it goes through wall1 when it shouldnt

if wall2 is layer 4: striping on large distances, really nasty looking

if wall2 is layer 5: same as above

i could imagine that the glitch where one of the 2 triangles that form the water disappears is caused by a combination of angle and the distance of the water vertices, ive had similar things happening with large objects.
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
0xFC G_SETCOMBINE
Performs combining operations (ex. multi-texturing)

Syntax: Unknown

Examples:
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”.

So...
Code
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.
Video: https://www.youtube.com/watch?v=ROgEQHsqSRM

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. :)
that is a pretty cool find. looking at how the FC commands in the original are set, it is weird that frauber chose FC 12 7F FF FF FF F8 38 out of all things. for instance, looking at bowser puzzle pieces or any other object that ive looked at, they use FC 12 7E 24 FF FF F9 FC...

also, dont worry about the breaking the fog thing, youve said fog works fine on console, and there is a really easy criterium if a DL is using fog, so if we were to correct all these things with a tool, it would be no issue at all.
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.

These are the 6 FC commands that I'm currently using in my importer.

Code
FC 12 7E 24 FF FF F9 FC // Solid RGBA16 texture
FC FF FF FF FF FC F2 38 // RGBA16 texture with alpha bits (Fog enabled)
FC 12 18 24 FF 33 FF FF // RGBA16 texture with alpha bits (Fog disabled)
FC 12 2E 24 FF FF FB FD // Semi-transparent RGBA16 texture
FC FF FF FF FF FE 7B 3D // Solid RGB Color
FC FF FF FF FF FE FB FD // Semi-transparent RGB Color


Can anyone check if these will work on console? I currently have no way of testing it.

Here is a bps patch containing an imported level to Bob-omb battlefield and Whomp's Fortress. The WF version has fog, while BBB doesn't.

.bps patch (Use a 8MB ROM)

Hopefully they should end up looking like this: