VL-Tone’s Blog

Official TT64 Forum Opening!

Sun, 5 Aug 2007 00:15:37 -0400

At last, a real forum to discuss TT64 and SM64 hacking!

Found on the Justus League 2 board (which is a spin-off of the acmlm boards), the SM64 Hacking sub-forum will be home to TT64 discussion from now on. Other SM64 hacking topics will be discussed there, but since TT64 is the only SM64 level editor for now, it will be a the official place to talk about it and ask questions.

If you didn’t notice the link up-there, the forum can be found at http://jul.rustedmagick.com/board/forum.php?id=41

Please read the Rules/FAQ carefully before posting. I’ll keep comments open here for the time being, but from now on, the forum is where any TT64 related questions and comments should be posted.

TT64 Version 0.5b Is Out!

Sun, 22 Jul 2007 06:21:48 -0400

Here you go, version 0.5b is released. Mainly bug fixes, but includes two new features.

This panel is now found in the Texture Editor. It enables you to change Mario’s size. Click on the big Mario icon to make it bigger, and guess what the small Mario icon does? You can also edit the size value manually.

The High-Poly Mario option will force the game to use the high polygon Mario model all the time, even when he’s far from the camera. It’s useful for when Mario is big, but also nice even when Mario is at a normal size.

Note that making Mario bigger won’t make him run faster, and his collision sphere will stay small.

Giant Mario vs. “Big” Bob-Omb.

I updated to Director MX 2004 10.1.1 from version 10.0, so this should fix some crashing bugs in the application engine, as well as some other issues. It seems that this update fixed a problem where Shockwave compression wouldn’t be applied to saved applications, so the program is now almost 50% smaller. Unfortunately, this doesn’t change the zipped size by much, since the program is now already compressed internally.

Toad’s Tool 64 Version 0.5b is available at:
 http://homepage.mac.com/qubedstudios/ToadsTool64.htm  Note that a new version of the ROM Extender (1.2b) is now available. If you had problems extending ROMs before, you might try this new one, which can be downloaded at: http://homepage.mac.com/qubedstudios/Mario64Tools.htm

New features and improvements in 0.5b:

•Updated to Macromedia/Adobe Director MX 2004 10.1.1 (from 10.0) which reduced the size of the program by almost 50%!
•The update to 10.1.1 might also fix a few "crashing" bugs and some other issues.
•New feature to set Mario's size.
•A checkbox to force the high polygon Mario model to be used all the time.

Bug Fixes in 0.5b:

•Fixed a bug that caused a script error "#loch" when quitting.
•Fixed the "#forecolor" script error bug that would happen in certain circumstances when the ROM couldn't be open.
•The texture editor should now work correctly, it was broken in 0.4b, causing certain textures to be wrongly imported as 32x32.
•Also in the texture editor, saving the texture to ROM shouldn't cause a script error anymore.
•Reverting a texture from ROM should now update the thumbnail grid accordingly.

Other small bug fixes since v0.4b.

Keep those bug reports and suggestions coming :)

You can leave comments and suggestions, but I may not have the time to answer all of your questions.

Post Your Mods, Patches and Youtube Videos Here!

Wed, 18 Jul 2007 03:58:59 -0400

There seem to be quite a few Youtube videos of Super Mario 64 mods done with Toad’s Tool 64 already.

This page could act as a central hub where you can post screenshots, videos and .PPF patches of your mods.

Be creative! I’ve seen a little too much “Goombas outside the castle” mods, there’s so much more that you can do with TT64 :)

Still, don’t hesitate to post your mods here, even if you think they’re boring or include Goombas outside the castle :) It can also be just a screenshot or short Youtube video showing an interesting discovery, it doesn’t need to be a fully scripted and edited 10 minutes clip.

You can use the “Add Attachment“ button when posting a comment, to embed a screenshot or attach a .PPF patch file.

Please Don’t Post Links to ROMS!!

For Youtube videos, just post the link, ideally with a screenshot.

Have fun modding SM64!

This page should only be used to post mods, screenshots, videos and patches for SM64. Please use other blog entries if you have questions or bugs to report.

Toad’s Tool 64 Version 0.4b Released!

Tue, 17 Jul 2007 08:39:32 -0400

I worked all night for this release! I need some sleep now :)

Toad’s Tool 64 Version 0.4b is available at:
 http://homepage.mac.com/qubedstudios/ToadsTool64.htm  Note that a new version of the ROM Extender (1.2b) is now available. If you had problems extending ROMs before, you might try this new one, which can be downloaded at: http://homepage.mac.com/qubedstudios/Mario64Tools.htm

New features and improvements in 0.4b:

•TT64 can now display the collision map (but not edit it!).
•The object list and pop-up menu can now be sorted by alphabetical order.
•New interface layout brings the positioning widgets closer to the middle of the screen.
•The little menu icons in the parameter bar light up when selecting.
•Better lighting in software renderer
•Simpler object list, with an option to show the extra info found in previous versions.
•Auto-open default pop-up menus when selecting objects.
•Now uses the checksum to ensure the ROM is valid (can be disabled).
•Themes, if you get an overdose of glossiness, you can turn it off. Four themes are available.
•Some fixes and changes in the description labels.
•Improved documentation.

Bug Fixes in 0.4b:

•TT64 will no longer generate a script error when activating the wireframe mode in areas greater than 1.
•You can now Quit TT64 using the standard close box.
•Zooming with the camera widget now works correctly when the "Follow Selection" option is checked.
•The pop-up menu won't close when opening another menu.
•Fixed a bug where the 3d view would get incorrectly sized if the window was resized when the level menu was open.
•No more script errors when clicking on the empty part of the area selector.
•When pasting params, the object list and pop-up menu are now correctly updated.
•If the Drop To Ground button is clicked and the camera is in Orbit mode, the camera will follow the object as expected.

Many other small bug fixes since v0.3b. If I forgot your pet-peeve bug, please tell me.

Keep those bug reports and suggestions coming :)

You can leave comments and suggestions, but I may not have the time to answer all of your questions.

Version 0.4b Soon, Screenshot Of The New Interface.

Sat, 14 Jul 2007 11:24:54 -0400

I hope to be able to release version 0.4b tomorrow, but it could be Monday.

Click to view full size version

First thing I want to point out is that I got rid of the “glossy” effect that was prevalent in the interface. Somehow I had a sudden overdose of “glossy” effects, and when I removed it I realized how it was affecting readability. The interface is already busy, adding another level of visual complexity wasn’t a good idea ultimately. I changed the spreading ratio of the gradients so that they stand out more without the gloss. I remade the camera views buttons, and though they may have some glossy aspect, it’s not the same kind of gloss.

Aside from cosmetic changes, I changed the layout to bring the movement and rotation widgets closer to the middle. That will give you more room to move your mouse if your window is maximized.

As for new features, I already talked about the “Collision Map” feature, which is now part of the interface. I added the possibility to change the sorting order of the object list and the pop-up menus by numbers. The “123” option will sort just like it does now, by number/ID. The “ABC” option will sort the menus alphabetically using the descriptions.

This will be very useful to find the objects you’re looking for. I already changed a few descriptions so that things are even easier to find when in alphabetical order. For example, coins where labeled as “Yellow Coin”, “Red Coin” etc. I changed them to “Coin (Yellow)” and “Coin (Red)” so that they’ll be easier to find.

I fixed a few things regarding the yellow pop-up menu. As you can see on the screenshot, instead of tinting the whole parameter yellow when it’s selected, a 2 pixels border is used instead so you can see the original color of the item, and the little menu icon will turn yellow if you click on it to activate the pop-up menu.

So... that’s it for now :)

Keep those bug reports and suggestions coming :)

You can leave comments and suggestions, but I may not have the time to answer all of your questions.

TT64: Update Coming This Weekend (or Monday)

Fri, 13 Jul 2007 00:46:56 -0400

Sorry (again) for the late update, I was pretty tired coming back from work for the last week or so.

I’ll release Toad’s Tool 64 v0.4b this weekend (or Monday). It will include bug fixes, and a new feature: the ability to show the collision map. I cracked the collision data format a long time ago, but didn’t work much on it since then and didn’t implement it’s decoding in TT64 until now. I guess I didn’t want to face the challenge of eventually making it editable...

I have to admit that this feature (showing the collision map) should’ve been part of the first release, I would have avoided the embarrassing discovery that Bowser courses and Lethal Lava Land are hardly as editable as I thought, because the platform objects rely on the collision map to be solid.

Bob Omb Battlefield collision map

Bowser Course 3 collision map

In the screenshots, the normal level geometry and objects are shown as wireframe, while the collision map is shown as solid polygons. As you can see only a few platforms in the Bowser Course don’t rely on the collision map. These are usually moving/rotating platform. The behavior “Static and Solid” is misnamed, it should be renamed “Static” in v0.4b.

The color coding indicate various types of terrain, it’s only a coincidence that the grass part appears green in Bob Omb Battlefield. These have different purposes. Some will make the terrain more or less slippery, some make the terrain icy or hurt Mario (lava). Some are used for more specific purposes, like triggering special camera modes that are specific to some levels.

For example, the brown part on the top of the BOB mountain triggers the “wide angle” camera. Others will set the water current direction and force, or switch areas seamlessly (for example, in the water filled tunnel in Wet/Dry World, or for the various parts of the Tall Tall Slide). One of the most interesting type makes a wall’s collision attribute “vanish” when Mario has the vanish cap.

I may have discouraged a few of you by saying that I would only implement collision map and level geometry editing in 2008 or even 2009... Well, I’ve changed my mind. I will work on implementing this feature so it can be released before the end of 2007. It may well be in the next month or so, but it may be later, so to avoid disappointment my very conservative deadline will be December 2007.

Keep in mind that it will be limited to moving single vertices, or groups of vertices, modifying existing collision maps and level geometry. The collision map editing might be more interesting, since I’m planning to implement a way to change the terrain type of individual triangles, or arbitrary groups of triangles (something Mario Landscaper doesn’t seem to do, it seems it can only change the type of terrain for whole groups of triangles defined by the data).

I’m sure all of you would like to be able to import 3d geometry files to make all new levels. Unfortunately, this is the part that’s not as easy as it sounds.

Importing collision data wouldn’t be that hard, and my collision map editor would be used to assign terrain types to areas in imported collision data. But the level geometry format is much much more complicated than the collision data, and will require much more comprehension of all its subtleties.

Another thing I’ve been experimenting lately, is implementing the possibility of adding new objects in levels, and I’m also planning to convert all 0x42 and 0x43 objects to 0x24 so that you’ll have all the flexibility needed for all objects. Having only 0x24 objects in levels would also make the editing much less confusing. I successfully converted 0x42 objects to 0x24 in a level, but I’m struggling to do the same with 0x43 objects. I hope to find a solution soon.

Keep those bug reports and suggestions coming :)

You can leave comments and suggestions, but I may not have the time to answer all of your questions.

Electronic Hacking, The Beginnings. My Story... (Part 1)

Thu, 5 Jul 2007 12:10:48 -0400

Inspired by a thread on acmlm’s boards titled: The beginnings of romhacking, I decided to write about what lead me to the ROM hacking scene. Unfortunately the whole thing became too long to post on the board, and even for a blog entry, so I’ll have to splice it in multiple parts. Most of it is already written, so don’t worry TT64 fans, I won’t “waste” too much time on this. Note that the first part doesn’t include a lot of hacking stories. On the other hand, I hope it will interest at least some of you, since you’ll learn where I got my nickname :)

So here it goes:

For a start, my dad was interested in electronics since his teen years which happened during the 50's. At the time he built his own crystal-diode radio. He witnessed the apparition of the transistor, read magazines about it, built his own circuits for various things.

Later he bought a used military-type amateur radio emitter / receiver, and spent some time fixing it, ordering replacement lamps and parts. Somewhere in the 70s he even built his own analog synthesizer from scratch.

So when I was a kid I could ask my dad "how does the TV work?" and he could answer in great detail. I owe him a lot for my basic understanding on how things work. Also, since I was a kid we had this big book at home called "Encyclopedia of Movie and Television" dating back from the mid-70s that described just about everything in these two fields, including all the details about the NTSC, PAL and SECAM TV formats, movie sets, film coloring, special effects etc. Very interesting read.

One of my uncle (brother of my mother) was also an electronic hobbyist, though since he was much younger than my dad, experimented with newer stuff like the early personal computers and digital synths.

(Stock photo, not my actual uncle!)

The first video game I ever witnessed was a pong-type machine my uncle had brought to my grand-father's house. He had his own hand-made analog paddle built in a wooden box with a potentiometer. I was about 6 years old at the time, so that would be around 1980. I only have a very vague memory of it, but it was out-of-this world for me, I couldn't really grasp the concept of what a video-game was at the time.

The first piece of electronic I ever owned was a analog toy-synth that my uncle gave me. It was red/purple and in the shape of a grand piano. It could only play one very basic instrument, and was monophonic (one note at a time).

Then I got this very interesting gift when I was 9, called the Casio VL-Tone (Actually it's model VL-1 from the VL-Tone series, but everyone calls the VL-1 the VL-tone since the other models are not well known). It's the first thing I ever owned that was anything close to a computer...

As you might obviously guess, this is where I got my nickname. The VL-1 is a very special synthesizer. The story goes that Casio, which then made mainly watches and calculator, weren't so confident that they could sell the thing on its own as a musical instrument, and decided to add a calculator to the device since the chip that was as its core was multi-purpose.

The synth is very portable, as it's a foot long, is made out of white plastic and has an LCD screen for the calculator, but in the synth mode the screen also displays the notes you play as numbers, and the tempo value. (Portable digital music device in white plastic with an LCD screen... reminds me of something...)

VL-Tone’s LCD in synth mode.

It includes a 99-notes sequencer and introduced a nice feature: "One-key play" which enabled you to play the sequenced tune with the timing you wanted (actually with two keys if you wanted), and modify it when in record mode. So you could record some sequence by playing it on the keyboard, and if you made mistakes you could delete notes on the fly, and then redo the sequence with the right timing.

Another feature that set it apart from anything at this price-range for the time, was that one of the instrument was actually programmable. By setting a particular sequence of 8 numbers in the calculator M+ memory, you could create a particular instrument. It was known as the ADSR instrument, for Attack Decay Sustain and Release, but you could also set other parameters like tone, vibrato and tremolo. Three of the possible tones that could be used in an ADSR instrument were oscillating between two octaves, and a nice touch is that the oscillation was synchronized with the main tempo.

ADSR

Another particular quality of the VL-1 is that it has a resonance case behind the speaker, meaning that by "cupping" the speaker with your hand, you can introduce very nice variations in the tone as you play (like a "Wah Wah" sound).

Even though it was limited, being monophonic and having toyish sounds, it had some very powerful features for such a small synth. There was simply no other synth with a sequencer that was that small. So many composers used it as a draft tool that they could keep on the side of their couch, or travel with (it came with its own fake-leather traveling case). Groups like Depeche Mode and others actually used it in some of their tunes.

But the most well known VL-Tone based tune is the weird, minimalist song "Da Da Da" by a German band called "Trio". The main rythm heard all through the song is the "ROCK-1" built-in beat, and the Piano instrument is used for the melody. The synth itself is prominently seen in the music video. You can watch the video on YouTube http://youtube.com/watch?v=BMikAeK8rL0 . Over the years, some-kind of a cult evolved around the VL-Tone.

“Da Da Da!”

While the VL-1 was described as one of the first cheap digital synth available to the public, it was actually an hybrid. Digital circuits would control analog oscillators, proof of that is that when the batteries are low, the pitch would change as the note decayed and the sound could get distorted. This analog/digital hybrid circuit is very close to the NES sound hardware, and unsurprisingly, it sounds a lot like a NES.

A lot of reasons lead me to conclude that the Casio VL-Tone was actually used by many NES music composer as a draft tool. The VL-1 was very popular in Japan and I highly suspect Koji Kondo to have used one when composing music for games like Super Mario Bros. and The Legend Of Zelda. By having the possibility to program an instrument envelope and tone was very similar to what NES music composers had to do, and they could replicate the sounds they were looking for on the VL.

Koji Kondo

Also, using the one-key play feature, to set a very fast timing on a recorded sequence when the tempo was at its lowest, you could get it to play very very fast when you changed back the tempo to the highest setting. Actually at the time they were selling a little booklet that would make you use this technique to create everyday sounds like an helicopter, by entering a particular sequence of note, then making it play very quickly using this trick.

It's very possible that Koji used this technique on the VL to compose sound effects for SMB, like the sound you hear when entering a pipe (if you slow it down, you'll hear that this sound fx and many others from SMB are actually melodies played very quickly.)

But it was all speculation from a crazy VL-Tone fan like me until I realized this...

By some kind of coincidence, it seems that an actual VL-Tone instrument is used in the Hazy Maze Cave music for Super Mario 64! I only recently realized it, while working on the editor. You can listen to my own rendition of the tune, entirely made on a Casio VL-Tone: http://homepage.mac.com/qubedstudios/CasioVL-64.mp3 and try to figure out which instrument can be also heard in SM64. Here’s a clip from the original SM64 song: http://homepage.mac.com/qubedstudios/HazyMazeCave.mp3 (Note that this tune was the easter egg on the "easter" entry on my blog.)

So, that's about it for the Casio VL-Tone, now you know why it's my nickname on the web :) I had it a long time before I discovered the connection with SM64.

(To be continued...)

Back From The Land Of Magic Ponies

Tue, 3 Jul 2007 00:29:43 -0400

No I wasn’t really in the land of magic ponies, but I did take a nice relaxing vacation at my mother’s house in the countryside, where I was lucky enough to witness a full half-circle rainbow over a green mountain of wilderness. I would’ve loved to show you the whole thing, but it simply didn’t fit in my cellphone camera lens.

I’m trying to catch up with my emails right now, I’ll try to fix a few more bugs and make a new release soon. I’ll also update the ROM extender so that it ensures that the right version is extended (using a checksum verification) and implement better and more descriptive error messages. TT64 will also have some more checks added to avoid script errors when an “half-extended” ROM is read.

I’m planning to add a useful feature that will enable you to save level changes as a TT64-specific file. Eventually, being able to save changes as a .PPF patch will also be added, but having a TT64 save file format would also have its uses. For example, you’d be able to save changes to a specific level, then load that level in another ROM, so you could merge levels from multiple ROMs. Also, it would enable you to save changes without modifying the ROM and making backups of your mods without having to duplicate the whole ROM.

The format would essentially be “plain text”, containing text representation of how TT64 stores the level data in memory, using Director MX “property lists”.

A friend suggested something neat that could actually be feasible with this kind of save format. The idea would be to integrate a way in TT64 to publish, share and download level modifications, right from the editor.

Let’s say you make a cool mod and want other people using TT64 to access it, you’d press the “Sharing” button, choose which levels you want to include in your shared mod, write a title and description and click “Upload”. From that same Sharing panel you’d be able to access a list of all published levels, and you’d be able to download them with one or two clicks. With Director and a php server, it wouldn’t be extremely hard to pull off. Director can retrieve text from the web, and upload small text files through http-post, and make php queries.

It wouldn’t be extremely hard, but it wouldn’t be extremely easy either. For example, what if someone wants to delete one of his creation from the server because he made a mistake, or uploaded an improved version? A login/password system would need to be implemented, and that complicates things by a magnitude of x.

Anyway one can dream, even though I won’t work on that sharing feature anytime soon (if ever), I’d like to have your feedback about this crazy idea :)

In any case I’m planning on adding the level save feature pretty soon, since I think it would be of great help for you guys, even if some may not realize it. I’d like to have some suggestions about how it should work, for example, should it save changes to all levels/areas, or just the current one? Maybe have the option to do both?

One last thing, keep those bug reports and suggestions coming, my priority is still to eradicate bugs on TT64 :)

You can leave comments and suggestions, but I may not have the time to answer all of your questions.

Updated TT64 documentation.

Mon, 25 Jun 2007 14:24:23 -0400

I updated the documentation so it’s more complete now, but I had less time than I planned, so it’s still not like I want. But I have to go on vacation in a few minutes.  You can get the new documentation without re-downloading the whole editor by clicking on this link:
http://homepage.mac.com/qubedstudios/TT64Documentation.zip

So I will be gone until July 1st. Comments will be closed on the blog for this period. If you want to discuss about TT64 you may go to acmlm’s board in this thread: http://acmlm.no-ip.org/board/thread.php?id=1657

Please behave appropriately in the forums, or you may get banned.

While I’m gone you can still send me bug reports and comments via email at: qubedstudios (at) mac.com

Comments are closed for this week.

Version 0.3b Released!

Sat, 23 Jun 2007 07:39:17 -0400

Bug-fix release for Toad's Tool 64, now at version 0.3b.

http://homepage.mac.com/qubedstudios/ToadsTool64.htm

•A bad bug in Windows that was triggered when right-clicking causing TT64 to crash or refresh the window was eliminated.
•Some imported textures weren't correctly saved to ROM (creating a dot in the corner). This should now be fixed.
•The "Rotate Camera" button should now be hilighted as it should, when a level is loaded.
•Manually entering decimal values in the parameter bar would cause the wrong number to be entered instead. Also fixed.
•On Windows TT64 should now stop using CPU cycles when it's window is deactivated or minimized.
•Fixed a bug where clicking on cancel when opening a ROM would generate a script error.

Some people seem to have problems opening a ROM even if it was extended, for example generating a script error while loading in TT64. I guess that there are some variations in the ROM versions, and that even if the ROM extender works on a ROM, it doesn't guarantee that it will be compatible with TT64. In future versions I'll implement a more thorough check to ensure people open/extend the right version.

Bad news: it seems that levels that I thought would be very reconfigurable, (Bowser courses, Lethal Lava Land) actually are limited by the fact that they rely on the main level collision data. If you move platforms in these levels, the collision data won't move with it. Dealing with this will require some pretty complicated collision data editor. I guess that this problem will encourage me to work on it sooner than expected. But don't expect miracles, it's not as simple as enabling movement of individual vertices in the collision data.

The Documentation is still not finished, but I made a few changes (mainly the styles and layout).

I'm gonna leave town for 6 days starting Monday, instead of Sunday. But, I'm also gonna be outta town later today, and be back by Sunday afternoon/evening, leaving me Sunday night to finish the documentation before I leave for my vacations. I'll also try to improve the download page and FAQ before I go.

Today is the 11th anniversary of Super Mario 64, as it was released in Japan, June 23rd 1996, the same day as the Nintendo 64.

Happy Anniversary Super Mario 64!

Thank you to all these people that worked hard to bring this wonderful game to life:

Game Director
Shigeru Miyamoto
Assistant Directors
Yoshiaki Koizumi, Takashi Tezuka
System Programmers
Yasunari Nishida, Yoshinori Tanimoto
Programmers
Hajime Yajima, Daiki Iwamoto, Toshio Iwawaki
Camera Programmer
Takumi Kawagoe
Mario Face Programmer
Giles Goddard
Course Directors
Yoichi Yamada, Yasuhisa Yamamura
Course Designers
Kenta Usui, Naoki Mori, Yoshiki Haruhana, Makoto Miyanaga, Katsuhiko Kanno
Sound Composer
Koji Kondo
Sound Effects
Yoji Inagaki
Sound Programmer
Hideaki Shimizu
3D Animators
Yoshiaki Koizumi, Satoru Takizawa
Additional Graphics
Masanao Arimoto
Technical Support
Takao Sawano, Hirohito Yoshimoto, Hiroto Yada, SGI N64 Project Staff
Progress Management
Kimiyoshi Fukui, Keizo Kato
Screen Text Writer
Leslie Swan
Translation
Mina Akino, Hiroyuki Yamada
Mario Voice
Charles Martinet
Peach Voice
Leslie Swan
Special Thanks To
EAD Staff, All Nintendo Personnel, Mario Club Staff
Producer
Shigeru Miyamoto
Executive Producer
Hiroshi Yamauchi
CG Illustrators
Shigefumi Hino, Hisashi Nogami, Hideki Fujii, Tomoaki Kuroume, Yusuke Nakano
Package Designer
Wataru Yamaguchi
Manual Editor
Yasuhiro Sakai
Manual Text Translation
Kayomi McDonald, Hiroyuki Uesugi
Manual Text Writer
Phil Sandhop, Leslie Swan

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Toad’s Tool 64 Public Beta is Released!

Thu, 21 Jun 2007 14:04:07 -0400

I would’ve needed another day... But since I was threatened an angry mob of fans I had to release it today :)

So... Documentation is not finished, I’m late for work, but you can now download Toad’s Tool 64 Beta v0.1 at:

http://homepage.mac.com/qubedstudios/ToadsTool64.htm

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Toad’s Tool 64: June 21st 2007

Fri, 15 Jun 2007 14:36:01 -0400

There you go: June 21st is now the official release date for the Toad’s Tool 64 Public Beta. I may release it one or two days before that, but I keep the 21st as my ultimate limit for a release.

There’s a little catch though... I’m taking a week long vacation starting June 24th, ending July 1st. So while I’ll be there to provide some support during the June 21-23 period, you guys will be on your own for a week. I’ll have to disable comments on my blog during my vacations, to avoid spam, but I’ll start a thread on acmlm’s boards the day of the release, which is anyway where I’d want the discussion to move once the beta is released. Blog comments are not the best place to discuss a Beta release. It will still be a good idea to send me bug reports via email while I’m gone, I’ll look at them when I come back and make a list of things to fix.

(Click on the image for a bigger version)

This is the near final version of TT64’s interface for the Beta. As you can see I’ve made a few layout changes, and added some new features.

First thing you may have spotted is the “Acts:” widget, with the six yellow stars. This widget enables you to show only objects that appear in a particular act. Note that this only affects the 0x24 objects, which include the Act parameter. Invisible objects will be grayed out in the object list. Clicking on All will select all stars as once.

Another addition is the Hexadecimal checkbox. I wanted to avoid using any hexadecimal in the interface (except maybe the command numbers, 0x24, 0x42 etc. and the copy hex data button) but I realized that it would be useful for power-users that also do some hex editing using an hex editor. So I put it as an option. Hex numbers will be shown with an “h” to differentiate them from decimal numbers. I kept angles and position values as decimal, maybe I’ll add an option to also have those in hex, but I don’t feel it’s that useful.

Then there’s the “Launch ROM” button, which will launch the current ROM file, presumably in your favorite emulator (it’s equivalent to double-clicking the ROM file).

The last thing I added is the “Renderer” pop-up menu. It will display the current 3d renderer, and enable you to change it. The options will be: auto, openGL, directX7_0, directX5_2 and software. Note that the DirectX options won’t do a thing on a Mac. The default is auto, which normally should choose the best renderer it can on your machine. If some problem happens with the renderer it chooses, it will automatically fall back to “software”, which is a bad thing. The Software renderer is slow, and doesn’t support wireframe, which means that the selection boxes are filled, obscuring the object. Some other shader features aren’t available, which cause the scene to be too dark. So if TT64 automatically switches to software, you’ll be able to use the Renderer menu to try other options.

Some people concluded that since the Text Wrangler works with Vista, that TT64 would without problems. Director projects do run on Vista, but the problem is with the 3d stuff. It may cause Areo to switch off, and it could also fall back to the software renderer. I’ll try to get the answer to that question tonight.

(Click on the image for a bigger version)

The texture importer/exporter will be included in the public beta after all, but some features may be disabled. But from the fact that I only got a few comments upon announcing the feature, I guess that most people aren’t really interested in it, and would rather use the high-resolution texture feature of the 1964 emulator. Someone asked if it would be possible to change the background (sky) pictures with TT64, and the answer is: No, not in the first version. But that’s one of the first feature I’ll add in version 1.1b.

As I hinted in a comment, I added an interface to edit Mario’s colors. Note that the egg sliders are not positioned correctly on that screenshot, that because I took the screenshot without actually running the program.

So the main thing left to do is finishing the documentation, and designing the web page that will host the program.

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Anyone asking for a release date in any shape or form may have his/her comment deleted without notice, because duh, I just gave you a release date...

SM64 TextWrangler Update! Edit Level and Star Goal Names!

Mon, 4 Jun 2007 04:58:10 -0400

Someone in the comment section of the FAQ reminded me how important it would be to be able to change the name of the level “acts” or “star goals”. Since TT64 will be a great tool to completely change level goals, there is an obvious need to rename these.

So I worked overnight on finding the text offsets, then integrate them to the SM64 TextWrangler program. Version 1.1b can now edit Level names, and act names, in addition to the dialog text it previously edited.

Just like the dialog, the length of individual entries can vary, provided that the total length fits in its original space. Two progress bars and some counters help you manage how much space is left.

A little pop-up menu enables you to switch between “Dialogs”, “Levels” and “Acts” categories. Note that you have to save your changes for each category individually. For example you make changes in the dialog text, then switch to another category without saving, your changes in dialog text will be lost.

Aside from that, a few bugs were fixed, the “space left” counter should now work correctly, it had an “off-by-one” bug in version 1.0b (actually the bug was a little more complicated than that).

The new version can be downloaded at:
http://homepage.mac.com/qubedstudios/Mario64Tools.htm

The SM64 TextWrangler should be integrated into TT64 eventually, though probably not in the public Beta release.

Some little news about TT64: I started to write the documentation, this is my main project now. I also added one last “big” feature before the release, which is a “Drop to Ground” button and checkbox.

When you click on the button, selected objects will be dropped to the ground. If you click on the checkbox, it will have a more “permanent” effect, and objects will follow the ground as you move them around the level. Maybe I’ll make a short movie about it, it’s really nice to see multiple objects move that way and follow the terrain.

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Anyone asking for a release date in any shape or form may have his/her comment deleted without notice.

The FAQ...

Sat, 2 Jun 2007 21:35:59 -0400

So here’s the FAQ (Frequently Asked Questions) for Toad’s Tool 64. It’s also available as an html page at: http://homepage.mac.com/qubedstudios/TT64-FAQ.html

Feel free to suggest any questions that you think should be added to the FAQ, as well as pointing out typos or other mistakes.

Toad's Tool 64 FAQ 1.0

Q: When will it be released?

A: I said don't ask for a release date!! Oh... right, it's a FAQ!

I gave a few release dates last year, which I didn't meet, so to avoid further disappointment I stopped giving release dates. But if all goes well, a public beta will be released before the end of June 2007.

Q: For which platforms will it be available?

A: TT64 was built using Adobe Director MX 2004 on a PowerPC Macintosh. Director can produce both Mac OS X and Windows (95/98/XP) applications from the same project file. So the answer to this question is that it will be released for Mac OS X (PPC) and Windows (95/98/XP).

Q: What about Windows Vista?

A: TT64 should run on Vista, but may have problems with the 3d display view. Tests will be done on Vista in the next few days. The next version of Director MX due to the end of 2007 should support Vista and intel Macs natively.

Q: What if I have an intel based Mac?

A: TT64 should run on intel Macs, though I didn't test it yet. It will run under Rosetta, a pretty fast PPC emulator. Early reports indicate that 3d stuff in Director projects work well under Rosetta. The next major version of Director MX will be intel native.

Q: What are the minimum requirements?

A: It's hard to answer that one until the program has been tested on more machines. Loading the ROM and levels can take a few seconds on a slow machine, but overall I find that it's perfectly usable on my 1.25Ghz G4 Mac mini with a very low-end 32mb ATI Radeon 9200 video-card. The 3d display is responsive enough when you use the orbit camera mode, often displaying at over 30 fps. The fly-around mode can be a little slower when the whole level appears on the 3d view.

I would guess that the bare minimum requirements would be a 1Ghz cpu with a 32mb video-card and 320MB of RAM. But this is just a gross approximation, your mileage may vary. The editor itself will be around 12MB in size (decompressed), but will require an additional 15MB of space.

Q: Do you plan on releasing a Linux version?

A: I'm very sorry to say that this won't be possible. Director MX simply doesn't exist on Linux, and there's no simple way to recompile a Director project to Linux. It's not that I don't care about Linux, but Director is a development platform I know very well and started to use before Linux was even released. Besides, there's simply no equivalent to Director.

Q: What features will Toad's Tool 64 provide?

A: Features and limitations are described on this page: http://web.mac.com/qubedstudios/iWeb/Site/Blog/2A712E91-39F9-4773-B488-99DB40080712.html Some features, such as the text editing, and texture importing/exporting won't be part of the first public beta release, but should be integrated soon afterward.

Q: Can you add objects in levels?

A: Not in this version. For example, if a level only has 20 objects, you'll have to limit yourself to changing those 20. You can transform objects into others, copy and paste their parameters. The possibility of adding objects will probably be integrated to version 1.5 or so.

Q: Will you be able to modify the shape of the terrain and other polygon models?

A: No. The focus of the first release is being able to rearrange levels, by moving, rotating and changing objects found in levels. While this may seem limiting to some, you'll have to learn to appreciate what can be done with the editor, not focusing on what it can't do. Polygon shape editing may be added in version 2.0 of TT64, for which there's no timetable, and no guarantees that it will ever be done.

Q: Can I create new levels from scratch?

A: No, unfortunately, you'll have to work with existing levels. While many levels have a rigid polygon foundation that you won't be able to change, some levels are highly reconfigurable, since they are composed of individual platforms that can be moved, or changed to other types of platforms or objects. Levels like this include all three Bowser courses, Lethal Lava Land and RainBow Ride.

Q: Could I import/export new 3d models into SM64 using TT64?

A: No, you won't be able to modify polygon shapes, nor replace them with something else. Displaying the objects on screen is one thing, but that doesn't mean it would be easy to import new models. SM64 has a non-linear command-based model format, with many subtleties that are not supported by external 3d programs and formats.

Q: Can I put Bowser on the top of the Castle?

A: This won't be possible in TT64 1.0. You'll be restricted to a certain set of objects in each level, this is a limitation in the game engine, and hardware restrictions (RAM) in the n64. TT64 will take care of giving you a menu containing only objects that can be put in a particular level. While it means that you'll only be able to put objects types that already exist in a level, in many cases you'll be able to also put some objects that are normally only used in other levels (For example, you can put a Goomba on Castle Grounds).

Q: Will it be possible to swap object banks so you can chose which objects can be used in a level?

A: Not in version 1.0, but that will be one of the key feature of version 1.5. The problem with swapping banks is that you could instantly end up with a level full of objects that can no longer be used. Also, the editor will have to track down changes and update the level display accordingly when you change a bank. I'll try to implement a mechanism that will help you track which objects are affected so you don't end up with a crashing level.

Q: How easy will it be to use?

A: My goal was to make this program easy to use. Extensive documentation will be provided. A basic and expert mode will be provided for the command menu and parameter bar. In basic mode, you'll have a much lesser chance to make a level crash when you play it, even if you don't know what you're doing. The Expert mode will provide more flexibility for experimentation, but also more possibilities for something to go wrong when you try to run the edited game.

Q: How much will it cost?

A: Toad's Tool 64 is completely and totally FREE. But I will ask (not beg) for donations, for those who feel like it, to help cover the bandwidth costs and other expenses. If you don't donate, don't feel bad about it, I never did this with money in mind.

Q: Can I get the old SM64 editor prototype you released a long time ago?

A: No, sorry. I lost it when a plane crashed on my HDD in 2006. Stop asking for it :)

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Anyone asking for a release date in any shape or form may have his/her comment deleted without notice.

Toad’s Tool 64: Preparing An Eventual Beta Release

Tue, 29 May 2007 03:14:39 -0400

I’m thinking about a Beta release in the next few weeks. I’ll probably start with a private Beta phase that will last a week or so. Don’t ask me to be part of the private beta, I want people I know and trust to be part of it, and I’ll try to contact them when the time comes. The more you’ll bug me about it, the less chance you have that you’ll be part of it.

One of the main thing I still have to do before that is preparing documentation. It’ll probably be in html format since I want pictures to be included. I’m thinking about creating two main docs, one for beginners, one for experts. I also have to prepare a FAQ.

Another thing I may add to the editor before the release is a preferences panel, for global settings that will be kept even after you quit the program.

During the last week I rewrote a little part of the description database routine, which became too slow because it grew too large after adding all descriptions. The rewrite made a 50x boost in speed for that particular routine, and that made a big difference when displaying menus for things like behaviors and parameters.

I added a feature where the yellow pop-up menu behaves more like a pop-up menu, you can now close it, and it will pop right back when needed.

Here, the yellow menu is hidden, showing more of the red menu.

When the yellow menu is shown, you can close it with the X icon, but it will also close itself automatically when you select another parameter or object type. I’ll put a preference setting where it will also close itself when you select something in it. For now by default it doesn’t close when you select something, but that can be useful.

Other improvements: I added special cases to deal with coins and [!] Boxes.

Coins were a mess when displayed through normal polygon decoding routine, they weren’t colorized, and generated too much extraneous polygons (all frames of coins animation were displayed.) I added a special case where coins are replaced with actual “solid” polygon coins instead of a mash-up of ugly flat sprites, and have the appropriate color.

These are the new yellow and red coins, and there are blue coins too (not shown).

I tried animating the new coins with rotation, but it was wasting too many cpu cycles. I may add that as an option for those with cpu cycles to spare.

Now for the [!] boxes. The differently colored boxes are not separate models, the behavior code in the game choses which colored box to show depending on a behavior parameter. So I had to add a special case to handle them in the editor, and taking care of changing the model part when the corresponding parameter is changed.

So, that’s about it for now. I’ll work on the documentation, do some more debugging, and then... I’ll tell you about it :)

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Anyone asking for a release date in any shape or form may have his/her comment deleted without notice.

The Mystery Of The Painting Warps Triplets

Tue, 22 May 2007 01:59:18 -0400

I made an interesting discovery. I could’ve done it before since it wasn’t exactly well hidden stuff, but I guess I was too focused on making the editor work. Now that it’s more useable and that I started actually using it, I found some interesting stuff, like the beta Blargg, and now this.

So my discovery is that all paintings can lead to 3 different warp destinations, including different levels.
The destination can be different depending on if Mario enters the painting on the left, middle or right section. In the final game, all three destinations are set to the same place, so it doesn’t make a difference, but with TT64, you’ll be able to set different destinations.

The top-view of the castle first floor you see is an old picture from when I was experimenting with decoding the collision data. At the time I had discovered that there are 3 special collision areas on the floor in front and behind each level’s paintings. Each of them have a separate ID, and in the picture, arbitrary colors are assigned to those IDs.

I wasn’t sure what they were for, and ended up thinking they were there to determine the horizontal position of the ripple effect when Mario enters the painting. That’s because there’s seem to be only three different horizontal positions the ripple effect appears in the game, though vertically there’s no such restriction so it’s aligned with Mario’s height.

While it seemed odd that a complicated collision area scheme would be used to align the ripple horizontally, it’s the only explanation I could find at the time. When developing TT64, I noticed that there were three painting warp commands for each level in the castle (command 0x27). Somehow, I didn’t make the connection with the three collision areas, even though it’s obvious now.

When someone told me that he tried to hack a painting warp, and it only worked the first time, my first answer was simply going to be “I guess you gotta change all three 0x27 commands for this level”. But then it hit me... what if these three warps were connected to these collision areas, and that entering the painting in the left, middle and right section would independently lead to the three destinations defined by these three commands?

So I set the three 0x27 commands for Bob Omb’s Battlefield to three different levels, and lo and behold, it worked just as expected.

To get back at the picture, I’ll explain what the “001 i 000 Bob-Omb's Battlefield>1>10” means. You can disregard the first number, “001” in this case. It’s just the command sequential number, essentially meaning in this case that it’s the first 0x27 command read in that level script, this number is not part of the ROM data. The “i” means this command is “internal” thus part of this level script only. The “000” is the warp “input” ID. Then you have the name of the destination level, then after the “>” is the area number. In this case it can only be one because BOB only has one area. But for Cool Cool Mountain, it could be set to 2, leading to area 2, which is the Penguin Slide. The last number, in this case “10” is the destination warp ID which seems to be always 10 for the “Mario Start” warps, but other warp destination exist in each level.

There’s a small limitation on what can be done with this discovery. While it’s entirely possible to make one painting lead to three completely different levels, exits don’t work the same way. The level exit destinations (and all other warps) are set using another set of warp destination commands, 0x26. And there’s only two possible “normal exits” per level, one for when Mario dies, and one for when you complete a level successfully. I don’t know what command puts the paintings themselves in the levels, but all other warps, including level exits are positioned using 0x24 commands. In the screenshot below, both exits are at the same locations (the failure exit is command 35 in that list).

So that means, if you change the 0x27 painting warps to other destination levels, failing or completing a level will make Mario exit the painting of the original level instead of the one he entered. You could change the 0x26 commands (ID -15 and -16) so that it corresponds to the right painting. But the “problem” is that the level exits are not dependent on the painting Mario entered, but rather the level itself. Note that each area in a single level can have their own set of level exits. The Penguin Slide could have different failure exits than the main Cool Cool Mountain level for example.

All that complicated explanation to say that if you make two different paintings leading to the same area of the same level, you’ll have to chose which one of the two paintings will be the exit.

Still that will bring to all sorts of interesting hacking possibilities. You could set different exit for a success or failure, or you can mix up and move level exits to make some kind of a maze.

I think that the best way to utilize this discovery would be to make 3 different starting points for the same level. For example, entering the left part of the BoB painting could lead to the normal start, while the middle would put Mario on top of the BoB mountain, and the right part would lead to the floating island.

We can wonder what was the original intent behind this mechanism. It seems that during development, Miyamoto and the SM64 team wanted to have 3 different starting points depending on where Mario entered paintings. They dropped the idea somewhere along the line, and simply didn’t remove the mechanism, as it would have been too much trouble. It was simpler just to make all warp commands triplets lead to the same place.

One last thing, I won’t have to modify TT64 to accommodate this discovery. Currently, I’m beta testing TT64 myself (no public or private beta yet). There only a few minor interface bugs left.

The main things still left to do: integrating the ROM Extender, Text Wrangler, and finishing the Texture importer/exporter interface. I’m thinking about starting the public/private beta phase without these. In that case, it would mean only a couple of weeks before a public beta release, and a few more weeks for the official 1.0 release.

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Anyone asking for a release date in any shape or form will have his/her comment deleted without notice.

TT64: To Blargg Or Not To Blargg + Interesting New Docs

Tue, 15 May 2007 04:22:43 -0400

So I didn’t manage to do much with the Blargg yet, except putting it in the game, with no animation.

It has a mouth that can open, but it’s closed now, I haven’t found a suitable behavior pointer yet. (The butterfly behavior has some funny results though...)

If you want to hack it yourself into the game, open an extended ROM with an hex editor, go to 04771268 (decimal) and replace “24 18 1F 00 FD 44 00 02 11 94 00 00 00 5A 00 00 00 00 00 00 13 00 11 68” with “24 18 1F 54 F8 80 00 2D 18 76 00 B4 00 87 01 53 01 00 00 00 13 00 2A 48”

If you want to try to find the behavior code that could fit, you could use this very interesting document I’m just releasing: http://homepage.mac.com/qubedstudios/SM64Behaviors.txt It contains just about all possible behavior pointers, including some not used in the game. But good luck, there are hundreds of them. Fortunately, most known behaviors are labeled.

Hmm... I like that yellow text, let’s keep it that way...

That brings me to a good news: I’ve now labeled 99% of models and combos in TT64, only a few behaviors remain to be labeled.

Because of that, I was able to produce these very interesting and useful lists of objects:

This one lists all 3d models and their Geometry Layout pointers, by level.
http://homepage.mac.com/qubedstudios/SM64GeoLayoutPtrsByLevels.txt

This one is a list of all 3d models and their Geometry Layout pointers, sorted by ROM banks.
http://homepage.mac.com/qubedstudios/SM64GeoLayoutPtrs.txt

And this one adds Polygon data pointer lists to each Geometry Layout pointer.
http://homepage.mac.com/qubedstudios/SM64GeoLayoutPtrsAndPolys.txt

You may also need this doc, which lists all ROM banks with their TT64-specific ID number.
http://homepage.mac.com/qubedstudios/TT64ROMBanks.txt

Very geeky stuff... It gives a great overview of the game content and assets, now that models are labeled.

Other good news, doors are now displaying correctly. If you wondered why I didn’t publish any pictures of inside the castle lately, that was one of the reason... Doors were the wrong size, rotation was off and they were misaligned. Here’s the fixed version:

Some door knobs are black instead of yellow, but it’s much better than it was before.

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Anyone asking for a release date in any shape or form will have his/her comment deleted without notice.

TT64: Some Improvements And a New Demo Hack!

Sat, 5 May 2007 18:48:15 -0400

You can now blame The Simpsons, Futurama and Seinfeld DVDs for wasting my time and delaying TT64... You know sometimes, I just need to turn my brain off.

Anyhow, whatever, anyway, the important thing is that I post an update now.

Since the last update, I’ve improved the appearance of enemies and other animated geometry. Now each body part are shown using their internally defined offset. There’s still a big “cosmetic” problem that I already described: while the x,y and z offsets for body parts are included in the ROM data, the rotation values are generated on the fly by the animation code.

Bowser is pretty screwed up...

Yoshi is better, but is displayed horizontally laying on the ground.

Note that if you assign a behavior to Yoshi that doesn’t affect its body joints rotation values, he will look exactly like that in the game, proving that the animation code is needed to make a normal standing Yoshi. Unfortunately, Yoshi’s animation code makes him invisible if you don’t have 120 stars, or if he’s lower than a certain height (so that he disappears when he jumps off the castle).

Look it’s Peach! As suspected, she doesn’t have legs.

Peach is not part of the normal level data, she must be inserted by the game code. Thus I don’t know what behavior code she uses. So for now it may be possible to put her in the Castle Ground level, but using some other behavior that will make her look like this, or in some other glitched state.

Aside from that, I fixed a few problems, a good part of objects and behaviors are now labeled. I decided to make a hack/mod, using this as a way to test and debug the editor.

Hidden boxes making a staircase.

I added a staircase on the side of the castle using “hidden boxes” that appear when you activate the “purple [!] floor switch” that I installed just nearby. Other modifications include adding many enemies that don’t normally appear outside the castle like FlyGuy, Chuckya, Bob-Ombs and giant Goombas. There’s a mutated MIPS rabbit that attacks you, jumping boxes, [!] boxes with koopa shells and all caps. On the top of the castle, there’s a mutated inflating Yoshi that has some “gas” problems :)

Also on the top of the castle, there’s a warp pipe leading to Bowser’s first battle, where you can fight THREE bowsers at the same time! There may be some little modifications to one or two other levels, but don’t waste your time trying to find them.

Click the preview to see a Quicktime video showing off the mod,
or you can take a look at the Youtube version.

If you want to experience the hack yourself, here’s a PPF patch found at http://homepage.mac.com/qubedstudios/TT64Mod2007.ppf

To use the PPF patch you need an utility like PPF-O-matic on Windows, on the Mac you’re better off with PPFMaster (PPF-O-matic for Mac doesn’t work under Tiger).

The ips version doesn’t correctly patch everything, but if you want it, it’s still at http://homepage.mac.com/qubedstudios/TT64Mod2007.ips

Very important, the patch needs to be applied to an Extended SM64 ROM. To extend a ROM, use my SM64 ROM Extender found at http://homepage.mac.com/qubedstudios/Mario64Tools.htm.

Have fun!

Update: It seems that the IPS patch doesn’t work completely, that’s because the IPS patch format is limited to patch only the first 16MB. Since the Bowser level is after the 16MB part, it doesn’t get patched. Update on the update: I just added a PPF version of the patch.

Another thing: While digging through every objects possible in the game, I stumbled on a very interesting 3d model that is available in the “Bowser in the Fire Sea” level... a Blargg!

Here’s a Blargg as it first appeared in Super Mario World.

Here’s the object I found in Super Mario 64, incidentally in a Lava-filled level...

To me, it’s pretty clear that it’s a Blargg, with its mouth closed. Unfortunately since it’s not included in the level data, I don’t know its behavior pointer, but it’s very possible that its behavior code is still there. The only thing missing would be the textures. Once I’ll have labeled almost all behaviors, it’ll be easier to find the unused ones.

You can leave comments and suggestions, you can ask questions, but don’t get mad if I don’t reply.

Anyone asking for a release date in any shape or form will have his/her comment deleted without notice.

Lack Of Progress In TT64: Blame SPM.

Sat, 21 Apr 2007 01:22:43 -0400

That’s about it, to make a long story short: blame Super Paper Mario...

While I didn’t finish the game yet (I’m at 8-1), I’ll start working back on TT64 tonight.

Standard disclaimer: You can leave comments and suggestions, but don’t ask questions.

Anyone asking for a release date in any shape or form will have his/her comment deleted without notice.

TT64: New Video Preview!

Mon, 9 Apr 2007 15:27:50 -0400

I made a new video preview demoing Toad’s Tool 64.

(Click the preview image to play.)

This is a 65 MB Quicktime movie, so if you don’t have much bandwidth or don’t have this “evil” Quicktime thing installed, you can instead take a look at the YouTube video which is smaller in size, but also uglier.

It’s not a carefully planned demo, so some features are not shown, or not shown enough. Maybe I’ll do another showing some more details of the interface.

Note that the video was accelerated by a factor of 2-3x, because my screen-capture utility has a tendency to slow things down by a similar factor. So the acceleration compensates for the slow-downs, as normally, the editor will have framerates that are as smooth as the video shows (in most levels).

For once, I’ll allow questions to be asked, but only about the content of the video. (Such as “what’s that thing in the corner?”)

But as usual, anyone asking for a release date in any shape or form will have his/her comment deleted without notice.

Happy Easter Egg!

Sun, 8 Apr 2007 22:04:53 -0400

I’m sure you’ll be happy about this, I decided to work on a texture editor that will be integrated to Toad’s Tool 64, and I’ll add the possibility of loading textures directly from the ROM.

Here’s the prototype of the texture editor:

(Click to get a full size version)

So, it seems that there are (around) 857 textures in the game. That doesn’t include the HUD textures, the background and the menu interface. Maybe there are more, but for now that’s everything I could find, including this unused animated beta Yoshi egg. (Now that I think of it, there’s a unused animated beta flower texture that’s not included here because it’s not used by any geometry).

When I say “texture editor” it doesn’t mean it’ll include a paint program. Here are the basic features that will be included:

•Exporting a texture and alpha channel to a .png file. (This currently works)
•Importing a texture and alpha channel from a .png file. (Not implemented yet, but it will be trivial to do)
•Exporting all textures at once into a folder named “Textures” found in TT64’s directory. (It works, and only takes a few seconds).
•Importing back all the textures found in the Textures folder, you’ll have to keep their filenames intact.
•Saving a texture back to the ROM. (Is implemented and working.)
•Saving all textures back to the ROM. This will be easy to implement, but will take a minute or two.
•Reverting (Reloading) a texture from the ROM.

The .png export “Xtra” I’m using doesn’t seem to support the alpha channel, so the textures will be saved with both the image and the alpha channel side to side, meaning that the exported texture will be twice as wide as its source.

For example, here’s how the exported .png for the Yoshi egg will look like.

There are two types of texture used in Super Mario 64. For color pictures, the RGBA 5551 format is used. It means that 5 bits are used for each color channel, and only 1-bit for the alpha, for a total of 16-bits per pixel. The color textures are exported as 24-bit .png, and will be automatically down-sampled when you save them back to the ROM.

The other type is 8-bit grayscale, with an 8-bit alpha channel (also 16 bpp). You’ll be able to import color .png files into grayscale textures, and they’ll be converted automatically, you won’t have to worry about the details.

Originally I planned to include all the original SM64 textures in TT64, so the program wouldn’t have to load the ROM textures. I found that the texture loading routine was too slow. It’s only like 0.14 seconds per textures, but loading all 857 textures took 2 full minutes on my 1.25 Ghz G4. Since loading a ROM already takes 30-45 seconds, I thought it was adding too much. But that also meant that you wouldn’t have been able to see custom textures while editing.

But here’s the compromise I found. TT64 won’t include the original textures (making it smaller and “cleaner”) so it’ll have to load them from the ROM. But instead of loading them all at once when the ROM is loaded, each texture will only be loaded the first time they are needed. That’ll make loading a level a little longer the first time, but after that the textures will remain in memory so it’ll be quicker (until you open another ROM or quit the program). That way, if you only open a ROM to work on a few levels, you won’t have to wait too much.

The texture editor interface will include a thumbnail view, clicking on a thumbnail will give you a full view of the texture and its alpha channel. The thumbnail view will show the original thumbs for the textures that are not loaded, but selecting one will load it accordingly so you can edit it. The screenshot up-here is really a prototype, as I said more commands will be added, and some info such as the ROM location will be available.

Here are a few goodies for you guys (Happy Easter!)

First Easter gift, is all the textures in one single image.

(Click the image to get a huge 2048x1768 .png with alpha channel)

Click here to see an updated list of ROM addresses for all 857 textures.
It seems that the old list had a few “off by two” errors, it should be fixed.

And lastly, using the “Export All Textures” feature of my prototype texture editor, I made a zipped folder of all textures individually saved as .png files. You can download it by clicking here.

So, have fun!

BTW there is a real “easter egg” hidden in this page, can you find it? (Don’t get your expectations too high!)

Standard disclaimer: You can leave comments and suggestions, but don’t ask questions.

Anyone asking for a release date in any shape or form will have his/her comment deleted without notice.

TT64: Trees Fixed!

Tue, 3 Apr 2007 14:20:01 -0400

There you go... I didn’t want to “waste” time on fixing cosmetic glitches, but I have to admit that the tree bug was ugly, especially since it could be seen in the splash-screen.

There are still some glitches with the shadows, and with every texture that is layered on top of another model. While Director could have multiple layers of textures without these glitches, the problem comes from the fact that the layers (castle windows, tree shadows) are separate 3d models.

Here’s the updated splash screen, with fixed trees.

Big thanks to a very smart guy, Cellar Dweller, for providing me with the info I needed regarding texture clamping. While I figured out most of the SM64 format by myself, Cellar has provided me with some key info about the n64 polygon commands.

By fixing the “repeating texture” bug, I also partially fixed Goombas. There’s still a repeating glitch on the side, but fixing it would be too complicated. I think it’s good enough for now.

The other glitches with characters with animated limbs wont be fixed anytime soon, since it would require emulating the model animation engine. The default position and rotation for each limb don’t make it possible to build an accurate model. If you change the behavior of a character to a non-animated behavior, you’ll see what I mean.

So don’t count on accurate representation of animated characters anytime soon, and it may well never be fixed.

I don’t think I’ll spend much more time on fixing cosmetic issues, but will rather focus on debugging the interface, labeling objects and behaviors, and then integrating the text editor and ROM extender. After that, I should be able to release a public beta.

As for the “long” time it takes to finish this editor, keep in mind that I’m not working on it every day.

Update: The non-repeating texture fix introduced new z-ordering bugs in objects like [!] boxes, but I found it was an easy fix after all.

Standard disclaimer: You can comment here, but don’t ask questions, I won’t answer them.

Anyone asking for a release date in any shape or form will have his/her comment deleted without notice.

TT64 Now Resizable!

Sat, 24 Mar 2007 00:21:45 -0400

Good news everyone!

I’ve managed to make the Toad’s Tool 64 window resizable! I wasn’t sure if it was even possible with Director. It turns out it was relatively easy.

The hard part was reordering the sprites used in the bottom part of the interface so that they would all be part of the same range of sprite numbers (Unlike Flash, Director doesn’t support the equivalent of “layers”).

I used this opportunity to change the interface layout. I added a third “positional widget” so that object positioning and rotation can be done separately instead of having to switch between rotation and movement. Often I would find myself trying to move things when in rotation mode and vice-versa. Also, I added a new checkbox feature: “Hide Other Objects”. It’s only available when the “Selection Boxes” mode is set to “This Command”, meaning only boxes from the current command are shown. Activating “Hide Other Objects” means that not only the other boxes will be hidden, but also the objects. This will speed up things in Hazy Maze Cave which is very slow at selecting objects (the other levels are OK).

So back to the resizing feature, here’s a screenshot of the window at its smallest size, which is 790x500 (not including the window’s title bar). The screenshot is 800x600 to show you how it would fit in a small screen, it doesn’t include the Task Bar (Windows) or Menubar (Mac OS), but you see there’s plenty of space for them.

(Click on the image to see a full-size version)

The minimize button is not active, but it’ll be in the release version, I just forgot to activate it. Note that there’s a little bug seen here. The “B. Param 2” header for the yellow menu should be reading “B. Param 2: Message” so it includes the custom description label.

I added another very useful feature, the ability to resize the 3 menus and 3d view horizontally, by dragging the divider line.

Here’s an example where the menus have been extended to show more of the text.

(Click on the image to see a full-size version)

This menu/3d view resizing is live, but windows resizing is not. Live resizing of Director windows is supposedly possible on the Mac, but when I tried it froze the program. So resizing windows will use the good old method of showing an outline while you drag the corner.

Now here’s the HUGE screenshot for the biggest possible size, which I set to 1280x960, which fits in a 1280x1024 screen.

(Click on the image to see a full-size version)

As you can see, it’s very nice to be able to maximize the use of a big screen. It doesn’t seem to slow-down the 3d display by a noticeable amount. Just a little problem though... See that empty space in the lower-right corner? Maybe I could put Google ads there?

Nahhhh I’m kidding, I would never do such a thing. That “This Space For Rent” sign is a joke, you may contact me about it if you want but only for a real non-commercial solution to this problem, and you can also post suggestions down here in the comments. Maybe integrate a pong-game in that empty space?

The parameter bar interface was designed to be resizeable, but now I’ve fine-tuned the size of items so that for example B. Param 1 & 2 or X, Y and Z params appear on the same row. Making it resizable would break out this layout. Anyway the camera controls and other buttons in the bluish area of the bottom interface can’t really be resized.

To fill this space I need something that:

A) Can be resized.
B) Is not a feature that will be missed by people using the minimal width.

I guess for the time being I’ll put some image or pattern there.

There are other unused spaces in the interface that could be used for buttons and checkbox. Any suggestions for features?

One of the thing I’ll add is a display/menu called “Renderer”, which will show you which 3d renderer is currently used, and will offer you the possibility of changing it. On the Mac, there are two settings: “OpenGL” and “Software”. On Windows there are 4: “Software”, “OpenGL”, “DirectX 5” and “DirectX 7”.

I don’t know yet how TT64 will fare on Vista, since it doesn’t work too well with older DirectX programs. From what I’ve read on forums, the news are not too good about this... Some people say that switching to the DirectX 5 renderer eases the issue, so that renderer menu feature will be handy.

Official statements from Adobe say that they’ll have it fixed in the next version of Director, due by the end of the year. Also in this version there will be intel Mac support, so until then TT64 will run under Rosetta on intel Macs, and I hope the OpenGL mode will work on these...

The “Software” mode will be used when other fail, but it’s much slower, and doesn’t support things like wireframe, which will cause problems with the selection boxes in TT64.

Anyhow I’ll give you some updates about Vista and intel Mac support when I start seeding the beta “internally”.

So as usual, don’t ask any questions in the comments :)

TT64 Progress (Getting Closer)

Thu, 22 Mar 2007 13:48:34 -0400

Hello friends, welcome to this new update about Toad’s Tool 64: The Super Mario 64 Level Editor.

Good news everybody! The interface’s mechanics are pretty much finalized now, I’ve managed to implement the changes I was talking about in my last TT64 update.

(Click on the image to see a full-size version)

First thing you may notice, aside from the glitchy trees, is that I added a fourth row to the “Parameter Bar” interface. The editor is now 780x576, so with the window’s title bar it will barely fit on a 800x600 screen, the Windows TaskBar would need to be hidden. I’ve been thinking of dropping 800x600 support so I could make the window even bigger, the requirement would become a 1024x768 screen as a minimum. The decision is not taken, if anyone reading this only has a 800x600 screen, please leave a comment about it.

As you can see, the “B. Param” items are now larger, have a description label and a pop-up menu button. The “B. Param” labels themselves can now also be changed, in this case “B. Param 2” was changed to “Message”. The Text Wrangler is still not integrated, for now I’m using imported data to display in the Message menu and description. Integrating the text editor is one of the few last thing I have to do before the release.

Currently, I’ve created a set of three different types for the B. Params. They are named internally #labelz, #warpid and #msg. The first one, #labelz is the default one, it will make the description appear according to a custom label that is particular for this value and this behavior. It will also make the pop-up menu display a list of all the labeled B. Params for this behavior (and B. Param number). Take a Goomba for example:

Yes this is how Goombas will look like in the editor. A little glitchy, but it’s better than nothing :)

So back to the important stuff, the interface. The B. Param 2 in this case is renamed “Size” and its type is #labelz. If you click on the pop-up menu button for the Size param you get this menu with 3 items, “Normal”, “Giant” and “Micro”, corresponding to value 0,1 and 2. The pop-up menu (the yellow menu) for a B. Param of type #labelz only shows values that have a label. You can still change the value manually by typing the number value field in the Size param item. If this value doesn’t have a label it will be shown as “Uknown”. Let’s say you find that value 4 is a bouncing Goomba (it’s not). You can change the “unknown” description to “Bouncing” and it will then be added to the Size menu for this behavior. Capitche?

I’ll try to have most everything already labeled when it’s released, and the labelling is mostly for my own internal use, but I’ll keep the option for you to add or edit labels.

The “Macro Preset” item has an extended description of B. Params for the current object added to the main description, it appears between { }. This extended label is removed while editing the “Macro Preset” label. The reason it’s there is because I thought about hiding the B. Params in the “Basic” mode, but I’m still hesitant about that, I just added them back. BTW I will remove the “intermediary” Advanced mode for the Parameter Bar, and keep only Basic and Expert.

This extended description is also added to items in the object list which is useful, since the Object Combo descriptions don’t cover the B. Params anymore. Note that in the 0x42 and 0x43 I’ve removed the “Object Combo” param, since it was now a subset of the Macro Preset and Special Preset, which are referring to a list of Model/Behavior/B. Params combinations. The descriptions are still shared between Object Combo, Macro Preset and Special Preset items to avoid duplication, and the extended B. Params descriptions are added to items in the pop-up menu list for Macro and Special Presets to differentiate items using the same Object Combo description but with different B. Params values.

Ok... That stuff is complicated to explain! I hope it makes sense to at least one person :)

Now onto the #warpid B. Param type. It’s used for B. Params that refer to warps. When set to #warpid, a B. Param will display the appropriate warp description, based on its definition by a 0x26 or 0x27 command found in that level.

(Click on the image to see a full-size version)

When you click on the pop-up menu button of a #warpid B. Param, the pop-up menu will display a dynamic list of all possible warps for this area. The format for the description is: Levelname-Area-WarpID. In this case, this warp pipe is leading to the same level (Tiny Huge Island) but in area 2, to another warp pipe that happens to have the same number (52) as the current one. Area 2 is the “Tiny” version of the island, while area 1 (the current area) is the “Huge” version.

Let’s say you want this pipe to lead somewhere else, that’s not covered by the list of available warps for this area, you’ll have to edit the 0x26 or 0x27 commands.

(Click on the image to see a full-size version)

Note that editing the 0x26 and 0x27 doesn’t give you any visual feedback on the 3d view, it’s a “coincidence” that the top view is selected and that the corresponding pipe is selected with a yellow box. If you edit the Warp ID value for a particular 0x26 command, make sure warps in the level don’t refer to a warp ID that you removed. I recommend that you don’t change this number anyway. The useful parameters to change are the three others. You can select the Destination Level through a pop-up menu, the destination area, and the destination warp ID. The “Destination warp ID” menu will give you a list of possible Warp IDs found in the selected area of the destination level. For example if you choose the “Inside Castle” level, you’ll get a list of all paintings exits and entry warps. In this case the list shows all warps for Area 2 of Tiny huge island, which is the Tiny version. The Warps can be labeled, though none of them are currently, except the few that appear in this example. Warp ID -15 and -16 are reserved for when Mario completes a level (gets a star), or loses a life.

So lastly, the #msg type is used for B. Params that refer to text dialogs that will be editable with the Text Wrangler. As I wrote at the begining, the last major thing to do is integrating it to the level editor. When the #msg type is used by a B. Param, it’s description corresponds to an excerpt of the text, and its pop-up menu will display a list of all possible messages (look back in the first screenshot).

I integrated a way to change the type of a B. Param by entering #labelz, #warpid or #msg in the parameter label field. When you do so and press enter, the real label pops back. It’s more for internal development use, and it enables me to directly set the type without having to manually maintain a list of which B. Params are which types. Just be careful not to label a B. Param with something starting with #.

One other change that you might notice, is the striped pattern that appears in empty areas of the Parameter Bar, I find it makes the interface less empty in the basic mode, or when items don’t fill the bars.

I still wont commit to a release date, but you can deduce I’m getting closer than ever to this point.

Just a little reminder, you can post comments, but don’t ask any questions about the editor or SM64 itself, especially not “when will it be released?”

In the meantime, learn to be patient ;)

Zelda: Twilight Princess Late Review

Sat, 10 Mar 2007 05:48:15 -0500

Ah well, I can't help myself, I keep writing incredibly long comments and blog entries, I hope I'm not too boring.

Someone asked me in a comment to give my opinion about Zelda: Twilight Princess, and the reply I wrote was so long that I decided to make it a blog entry.

So here’s my late Zelda: Twilight Princess review.

When I first saw the trailers for the game, I wasn't a big fan of the "wolf thing". I didn't like Majora's Mask because of the constant transformation of Link into weird mutant characters. Also I thought "What the heck is this critter that's riding the wolf?".

When I got my Wii, I became more interested in getting the game, but still, I waited a month and a half to get it, I wasn't in a hurry.

So what about the game...

The good:

The architecture is incredible and very imaginative. Graphically, the game is beautiful. There are some parts of the game where textures are a little blurry, mainly in outdoor areas. But you have to remember that unlike those “ultra-realistic” games that put you in confined areas so that the engine can limit the number of polygons in a given scene, games like Zelda TP and the 3d Marios are designed in a way that you can see everything from a distance, and the camera can fly around with much more freedom.

I feel that most of the “incredible graphic games” on the other platforms have a claustrophobic feel, and Nintendo games give you a much greater sense of freedom. Also, remember that the game was built for the GameCube first, and that while the Wii is not 10x more powerful, it could have made a difference if the game was built for the Wii. But, as we say, gameplay is more important than graphics...

The wolf part is well integrated and didn't annoy me like I thought it would. The twilight realm is really nice, I love the glowing effect and the colors. That little "critter", Midna, turns out to be the most attaching character I've ever met in a video-game. Her character is gradually built to the point where you become attached.

At first, she's annoying and witty, but eventually when she gets in trouble, you feel for her. I must admit that Zelda:TP is the first (and only) game that brought me intense emotions. When Midna almost died, I was on the verge of crying. I still get the chills when I listen to "Midna's desperate hour" http://homepage.mac.com/qubedstudios/Midna's%20Desperate%20Hour%201.mp3 (Don't listen to the song if you never played the game.)

The Wii controls for the sword are a little awkward at first, I had a tendency to shake the controls continually when fighting, without knowing what I was doing, but as the game progressed, I got used to it. I love aiming with the Wiimote, it's harder than with a joystick, but it's like in real life: if you could aim a bow using a joystick in real-life, it would be easier than by holding it.

Overall I'd say it's one of the best 3d game I ever played :)

Still, it's not perfect, here's the bad:

I feel that the game holds your hand a little to much. While you can wonder around and do some side-quests, the game feels too linear, you have to do every dungeon in order.

In dungeons, there are too many occurrence where you beat every enemies in a room, a chest appear in the same room containing a key to open a door in that same room. I'd rather see doors lock themselves when you enter a room, then automatically unlock when you clear the room, like in Zelda III. It does happen in Zelda: TP, but only a few times. The key-in-the-chest thing happens much more often. When you find a key, it's too often obvious where you'll have to use it and you rarely (if ever) get more than one key at a time and there's always only one door in that area that's locked.

Another thing, there's too much money in the game. Even with the big wallet, you constantly have to put back ruppies you find in chests, very frustrating. There’s the Magic Armor that eats ruppies like there’s no tomorrow, but I never feel the need to use it.

In general, bosses are too easy. I beat most of them without using potions, and on the first try. They are interesting, and well designed, but I wish there was an option to make them at least twice as hard.

While many say the game is too short, I think that a game like that would feel too short at any length. Despite its flaws, it makes you crave for more and more. I beat the game over the course of a couple of months, as I wasn't playing every day, and it took me probably twice as much time as the average hard-core gamer. I don't play video-games as much as I did a few years ago, and I'm getting old :)

As for the replay value, as I said Midna is a very attaching character. In the latter parts of the game, she becomes more of a helper, often appearing in a shadow form, and she doesn't ride wolf-Link anymore, since it only happens in the twilight realm, that you can't access at that point except for the last dungeon. So it's an incentive to replay the game all over again and relive these emotional moments, and revisit the twilight parts again.

This game is unavoidable for any Wii and GC owners, you’ll have to play it from start to end to know if you like it, but chances are, you will.