Originally posted by VL-Tone

---

Yeah, but I would need to create special cases for these textures. I understand how useful it could be, but it would mean to have to design a special interface to deal with these.

---

Originally posted by VL-Tone

---

Integrating the text editor was always in the plans. Currently it's not integrated. The menus for signs and Toad will show you the text from the game, but won't let you edit it. Actually it only shows the original text, it doesn't load it from the ROM.

The main issue is that the Text Wrangler shares some function names but the functions are sometimes different. Also, TT64 uses a different Binary I/O Xtra (Director Plug-in), so I'll have to change the code so it uses the same one (using both Xtras at the same time creates problems).

It won't be that hard, but the fact that it's not straightforward kept me from adding it sooner.

---

Originally posted by VL-Tone

---

Having an automatic resizing feature was in my original plans. It wouldn't be that hard to implement. I'll try to keep that in mind

---

Originally posted by VL-Tone

---

I'll try to see what I can do about that preference thing. I guess I could change the startup sequence so that it jumps to the pref screen at the beginning, and disable the "enable flatworld" button, and "back to editor" until a ROM is first loaded.

---

Originally posted by VL-Tone

---

I thought about it, maybe a Luigi preset will be included.

---

Originally posted by VL-Tone

---

Well TT64 leaves an harmless preference file, but that's it.

---

Originally posted by VL-Tone

---

It wouldn't be "that" hard, I would just need to know where is the pointer for the beginning of the text data so I could move the text at the end of its MIO0 bank, at a place where expansion would be easier. I'll try to keep that suggestion in mind and eventually implement it.

---

Originally posted by VL-Tone

---

Unfortunately, the SM64 engine doesn't makes this as easy. You can't turn things solid just with a simple byte change, unlike when I thought when I started hacking the game. Objects need a collision map to be solid, which is in a different format than the textured polygon model.

Platforms in the Bowser courses and in Lethal Lava Land rely on the main level collision map to be solid, that's the problem we have. Moving the platforms without modifying the main collision map result in platforms that are not solid. Even if I make a collision data editor, it would be complicated to keep track of object movements and match the collision data changes. Furthermore, while some platforms can move individually, some of them are glued together in the collision map, and separating them in the collision map wouldn't be trivial, it would require adding new collision polygons.

You probably noticed that some platforms in other levels are solid by themselves, don't rely on the main collision map, and will remain solid if you move them.

Those have their own collision map, stored somewhere in the level data bank, or in the bank where their textured polygons are found.

I recently figured out that these collision maps are referred by the 0x2A commands found in the behavior scripts. The 0x2A command includes the address where this collision map is found. For example, the rotating grass platforms in Whomp's Fortress rely on their behavior to be solid. If you apply their behavior to another object, you'll notice that it does rotate, but that it has the same round platform collision as the original platform.

What I'm thinking about doing, is generate individual collision maps for each platform in the Bowser courses and LLL, then create new behavior scripts for each of them that will refer to their own collision map.

That would solve a lot of problems at the same time. That way, platforms would be really solid, and you could move them, swap them, duplicate them without having to modify the main collision map each time. I'd probably have to eliminate the original collision map.

If I used the rotating grass platform as a template to create these new behaviors, you could even make all platforms in the level rotate at the speed you want, or if you'd set their rotation to zero, they would be static like they are in the original.

Doing that would require some heavy modification of the original levels and data. The ROM would need to be patched with these modifications before it would be loaded by TT64. Maybe the ROM Extender could do that automatically, or TT64 itself.

---

Originally posted by VL-Tone

---

The N64 hardware has a very small texture cache, and this is the real limitation.

At best we could replace 32x32 textures by 64x64 versions. That would be relatively easy for textures that are contained in "texture-only" MIO0 data bank, but it would be much more complicated for textures that are contained along polygon data in the same MIO0 banks, since it would require moving the polygon commands around and change all the pointers and jump commands.

The high-resolution SM64 textures you've seen are possible only in an emulator using a specially crafted plug-in called "Rice video". This plug-in doesn't read the high-res textures from the ROM but rather from a folder. As far as I know it doesn't really increase the n64 texture cache, but rather intercepts the low-res texture before they're drawn on screen and replaces them with the high-res version.

---

Originally posted by GhostMaster3000

---

Make the ROM extender extend all n64 ROMs to help people hack other games

---

Originally posted by Stevoisiak

---

Originally posted by GhostMaster3000

---

Make the ROM extender extend all n64 ROMs to help people hack other games

---

Youd need a decoding of each individual game to extend it. When it extends the rom, the moved data needs to be moved to specific places, or it'll just end up as garbage.

---

Originally posted by VL-Tone

---

Originally posted by Blaster

---

When you click the maximize button on a widescreen display, Toad's Tool 64 doesn't maximize the window fully. It makes the window not resize fully across the screen. Dragging the edges of the window when small doesn't allow the window to fill the whole screen, just a square shaped part of the screen on the left side.

My suggestion is when you click the maximize button on a widescreen display, it maximizes the screen fully and also dragging the edges should allow the window to go across the whole screen.

---

What resolution is your screen? I think I put some maximum size value for the window, I may extend it, or remove the maximum. As for the dragging by the edges, I think it's a Director limitation, maybe it's fixed in Director 11, I'll have to check.

---