Jul -- Posts by VL-Tone

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 510/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 08-25-09 04:21:06 AM, in Beta Stuff Thread: Beta Trampoline and other stuff

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

This is a nice find Bob-omb8194, though I'm not sure it was intended for the beta shells. Still, it could be a very useful/interesting behavior to play with.

Originally posted by Dopeboy175
So... Can I use this same method to swap the sky texture's, well with the 0x17 copy data to ram bank?

You could, but you'll have to hold the alt/option key when clicking on the offsets to be able to change them.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 511/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 08-25-09 04:28:04 AM, in Help/Questions about Toad's Tool 64 and SM64 hacking

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by VideoGuy
The cannon and the door to the cannon are two separate objects, I believe. So be sure you have both of them or else it won't work.

Actually, cannons that Mario can enter look like canon doors in TT64. The actual cannon object is spawned by the door when the pink bob-ombs trigger the signal. You don't need to put both objects. Only the trap door is enough.

The cannon objects that are visible in TT64 are bubble-shooting cannons and or disabled cannons.

I hope it makes sense...

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 512/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-05-09 02:24:38 AM, in Mario 64 'C' header files

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Really amazing stuff messiaen! Possibilities could be endless!

You know what would be nice? It's probably too much work, but it's one of my dreams that one day we'll have a BASIC-like interpreter that includes all the standard SM64 game engine functions so more people could program custom behaviors in SM64.

Still, I certainly hope that your efforts will inspire others to program behaviors in C. I know I would, if I had more time and didn't have TT64 to program.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 513/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-06-09 10:42:21 PM, in Le pub français ! The French Pub! (last edited by VL-Tone at 09-06-09 07:43 PM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

C'est pour ça que je ne veux plus avoir d'animal de compagnie, ils vivent moins longtemps que nous et c'est vraiment triste quand ils nous quittent, surtout qu'on s'attache facilement à ces petites bêtes.

J'aimerais bien avoir un hamster (je trouve ça tellement "cute"!), j'en ai eu deux quand j'était plus jeune. Mais les hamsters vivent seulement un gros maximum de 2 ans et je n'ai pas envie de voir mon hamster mourir

Et FieryIce pour te consoler, au moins tu n'as pas un ancien chien, ça serait plus difficile à prononcer

(essayez de dire "ancien chien" 10 fois de suite sans se tromper!)

Oh et pour ceux qui ne le sauraient pas le français est ma langue maternelle, je viens de Montréal (Québec) comme Acmlm.

Je trouve ça vraiment bizarre d'écrire en français sur ce forum!

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 514/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-09-09 02:14:24 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Here are some progress updates:
I've modified the "custom level file" format to take the multi-texture aspect into account.

Here's how a typical file might look:

*** Toad's Tool 64 Custom Level File

version :1

clevelenabledf :1

currentclevel :1

currentreplace :0

clevelkeepobjects :0

objoffsetx :0

objoffsety :0

objoffsetz :0

levelscale :478.3796

dfoffset :-8000

numobjects :150

bank1 :4

bank2 :15

bank3 :19

mtl_start :1

mtl_name :Material_859F5764577B5A2C81347

mtl_collistype :2A

mtl_usealpha :0

mtl_texturescaleS :50

mtl_texturescaleT :50

mtl_texturedata :32

783010FF783010FF70281...

The hex part at the end of this example is the beginning of a texture data encoded in hex. Each material will have its parameters and bitmap data included between "mtl_start" and "mtl_end" commands. At the end of the level file there's the "objfile" command which is followed by the .obj data the user imported in this level.

Here's an example of a complete custom level file: http://homepage.mac.com/qubedstudios/clevelfileexample.t64.txt

As I've explained before, custom level files will contain all the data needed to reconstruct a custom level, for example if you decide to put you custom level in another ROM, and it's also useful for when you reimport an .obj file while keeping the rest of the parameters intact.

Something that is still missing in the file is the level object list (ie. 0x24 objects) since I'm still not clear about how I'll implement the "Keep existing objects" system.

Also, custom backgrounds (sky) for custom levels won't be included in the custom level file, as they would take too much space encoded in hex. Unlike the rest though, these won't be erased each time you re-save a level to ROM, but you'll have to reimport them when moving a level to a different ROM (or slot).

Other stuff I've worked on:

Creating a widget for the material list that also include thumbnails besides the name, since Director doesn't include a standard scrolling list widget that can include graphics.

Still missing is the scrollbar, which I'll have to code myself. While I'm doing that I might as well create my own re-usable scrolling list widget that I could use for other parts of the interface, like the object lists in the level editor module.

Since I've upgraded to Director 11.5 I've had problems with the .fontstyle function when trying to set the style and color of individual lines in text lists (noticed how the command list is all red in the latest screenshot of the level editor interface?). Using a custom list widget would give me better control over that and I could use actual highlights for selected items instead of simply underlining. I could also add icon previews in the object list, and an optional icon-only grid menu to select objects.

Speaking of the object list, I've experimented with a search/filter function for the yellow list and it turns out it would be relatively easy to implement (with or without the new scrolling list widget). So let's say you are looking for Yoshi, instead of scrolling down until you get to the Yoshi item, you could just type "Yoshi" in the search field, and it would filter out everything except lines containing the word "Yoshi".

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 515/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-09-09 03:22:34 AM, in Help/Questions about Toad's Tool 64 and SM64 hacking (last edited by VL-Tone at 09-09-09 12:23 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by BigBrain

So, basically my main questions boil down to:
1. Was the general procedure I described correct?
2. Where are the RAM segment IDs and their ranges defined? - EDIT2: Does RAM segment number X start at 0x0X000000? I'm a bit confused right now, since I though that the whole RAM is mapped to the virtual address 0x80000000 ... Or is the virtual starting address of a RAM segment just 0x8X000000, then?
3. Is ROM data always copied to the beginning of a RAM segment?
4. How do I know which RAM segment offset to use for 0x22 commands? - this question is obsolete if the answer to Q3 is 'yes'.

EDIT: Having thought a bit more about RAM segments, I guess that bascially the whole N64 RAM is divided into x continuous _segments_ of memory with the same size.... If that and Q3 are the case, I just need to know what x is and I'm fine

1. You got the general procedure right.
2. The engine manages the segment data and a table which determines where is the data for each segment. I forgot where this table is, but the point is, you don't need to know where it is unless you plan to do some low-level ASM hacking.
3. Yes. Like I said, forget about where the actual segment data is copied in RAM.

Example:

You have this command in the RAM loading sequence:

17 0C 00 0F 00 20 08 D0 00 20 14 10

Which as you know, takes (uncompressed) data in ROM from 0x2008D0 to 0x201410 and copies it in segment 0x0F.

Now, here's a 0x22 command that would be found somewhere after the 0x17 command:

22 08 00 8C 0F 00 00 00

This command will associate the geometry layout script at offset 0x000000 of segment 0x0F to object ID 0x008C.

In this example, you'll find that offset 0x000000 in segment 0x0F contains exactly the same data as found in the ROM at 0x2008D0.

Essentially in this case if you treat "0x0F000000" as a pointer: 0x0F000000=0x2008D0, and 0x0F000010=0x2008E0. The same logic applies to behavior pointers (found in segment 0x13) and any commands that use a segment numbers. Pointers starting with 0x80 on the other hand are pointing directly to a RAM address.

The data loaded in RAM by the 0x17 command is as far as I know never modified so it always reflects its ROM equivalent.

But... For 0x18 and 0x1A commands it's a different story.

The data in the ROM is compressed so the content is actually different in ROM that what's copied in RAM since the RAM portion contains the uncompressed data. Offsets in commands using segment numbers refer to position in the uncompressed data.

The ROM extender copies uncompressed data at the end of the ROM and transform all 0x18 commands into 0x17 commands so they point to the uncompressed data. So you won't have to deal with any 0x18 commands in an extended ROM.

For some reason I couldn't do the same with 0x1A commands which also referred to MIO0 compressed data (always texture data). The solution was to create a "MIO0 wrapper" for each 0x1A segment. If you look at the data referred by a 0x1A command in an extended ROM, you'll see that it begins with a MIO0 header. The actual data is found a little further down, but uncompressed.

The MIO0 format includes a table which determines which part of the data is compressed. The ROM extender creates a MIO0 header that indicates that zero part of the data is compressed, meaning it's simply %100 inefficiently compressed. That means that TT64 can still access the data uncompressed while remaining compatible with the 0x1A command which expects valid MIO0 data.

Bytes 9-12 of the MIO0 header for MIO0 banks found at 0x800000+ in an extended ROM will tell you where to find the uncompressed data. So when dealing with 0x1A segments, you'll have to add this offset.

For example, for the segment found at 0xB10600. At bytes 9-12 of the header indicate that the uncompressed data is found at 0x00000CCF. If you add 0x00000CCF to 0xB10600 you get 0xB112CF which is where (in the ROM) the uncompressed data begins, and where offset 0x000000 will correspond in the matching RAM segment.

In an extended ROM there's also a big MIO0 bank at 0x800000 containing "uncompressed" data. This one is loaded in RAM by some ASM command (instead of a 0x18 or 0x1A command). I'm still not sure in which segment number this data is copied, but it's not referred directly by the main level/geometry/polygon scripts (this bank contains the dialog text and icons used in menus etc.)

Don't hesitate to ask if you have any other questions.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 516/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-09-09 03:32:20 AM, in Post your SM64 mods, patches and screenshots here! (NO ROM LINKS!) (last edited by VL-Tone at 09-09-09 12:33 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Nice to see you making that much progress in custom SM64 hacking gamecrazzy!

I was wondering, what's the problem with multiple custom areas in TT64? Is it that they create an error while loading the ROM or is it that you can't access them because of the hard-coded area selector numbers?

At this point unfortunately it would be complicated to add multiple-area support for the importer, as the whole system is based on the idea that there is 1 custom level file + 1 .obj file per level slot.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 517/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-09-09 05:42:33 AM, in Stuff inside the checksum protected area (Title Screen, etc.) (last edited by VL-Tone at 09-09-09 02:42 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Our good friend yoshiman (aka yoshielectron), the super SM64 RAM hacker, stumbled on the table that determines the content of "!" boxes.

You can check out his video where he tells us where in RAM the table is located in the different versions, and shows us some cool things to do with it.
<object width="425" height="344"><embed src="http://www.youtube.com/v/QkgwHezZk54&hl=en&fs=1&" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="425" height="344"></embed></object>

Of course, being a ROM hacker, what interests me is where the table is in the ROM. Turns out it's in the checksum protected area at 0x0EBBA0.

Here's the table content:

00 00 00 87 13 00 3D B8 -- Wing Cap

01 00 00 86 13 00 3D D8 -- Metal Cap

02 00 00 88 13 00 3E 1C -- Vanish Cap

03 00 00 BE 13 00 1F 3C -- Koopa Shell

04 00 00 74 13 00 09 A4 -- One Coin

05 00 00 00 13 00 09 64 -- Three Coins

06 00 00 00 13 00 09 84 -- Ten Coins

07 00 00 D4 13 00 3F DC -- 1up Mushroom Static

08 00 00 7A 13 00 07 F8 -- Star 0

09 00 00 D4 13 00 40 10 -- 1up Mushroom Runs Away

0A 00 01 7A 13 00 07 F8 -- Star 1

0B 00 02 7A 13 00 07 F8 -- Star 2

0C 00 03 7A 13 00 07 F8 -- Star 3

0D 00 04 7A 13 00 07 F8 -- Star 4

0E 00 05 7A 13 00 07 F8 -- Star 5

The first byte is the byte used by the second behavior parameter of the "!" box itself. Bytes 2-3 are behavior parameters you want to pass to the object being spawned by the box (for example, byte 3 determines the star number for the star objects). Byte 4 is the model ID, and the last 4 bytes are the behavior pointer.

If you put TT64 in hexadecimal mode you'll be able to find values for the model ID and behavior pointer that are suitable to spawn any object you want, as long as it's available in the level you plan to put the box in. (note: in TT64 0.5.x the first byte of the behavior pointer i.e. 0x13 is omitted).

Of course, as with other stuff in the checksum area, if you change something there you'll have to either:
-Disable the checksum (look in this thread to see how).
-Recalculate the checksum.
-Use an emulator that doesn't mind if the checksum fails.

Now if we were to relocate this table where we have more space, we could probably have up to 256 different kind of items available for "!" boxes.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 518/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-10-09 04:13:55 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

I'm sure your suggestions are well intentioned Stevoisiak, but the problem is not there.

I've asked about my .fontstyle bug problem on director forum, and they couldn't really help me, as it's a bug introduced in Director 11.5.

Aside from that, I don't have any problem coding, I rarely get stuck asking myself "which command can I use to program feature X?", and when I have to I do ask/look for answers. I've been programming with Director for 15 years or so, starting with version 3.1.

Maybe I make some issues sound harder than they are, because my main problem is the lack of time and energy I can devote to TT64. Some of these issues can be resolved in an hour or two, but that's a lot considering the amount of time I devote to programming outside of my job.

In theory, a second programmer could help about the lack of time issue, but in practice I would probably spend more time explaining what I want and how TT64 is programmed than doing it myself.

But most of the problems I've had while building the importer have to do with interface and technical design choices, and other Director programmers wouldn't be better than you guys at helping me with these decisions, since they don't know anything about TT64 and the limitations of the SM64 format. That's why I've been exposing some of my interface design dilemmas on this forum instead of on a Director forum.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 519/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-30-09 05:45:52 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 09-30-09 02:47 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

I would love to give you guys a release date, but I can't. Sorry.

Here's some little progress update though.

Nothing much, but it will get me going on finishing the rest. As I explained in a previous post, Director 11.5 has some pretty buggy built-in scrolling text fields. I had problems with the coloring and underlining of specific lines, as well as other glitches, like text lines being chopped off.

I had to create my own custom scrolling field widget anyway for the material/texture list in the importer which features little preview icons, so I decided to create a more universal scrolling list/menu field from scratch so I could replace the buggy lists in the main level editor interface.

So here's the result:

I've programmed the whole scrollbar/list mechanism myself, which gives me much more control and helps me get around bugs and limitations of the built-in text fields. Unlike the built-in scrolling fields, mine have proportional scrollbars and live scrolling. Also, as you can see I can have "real" highlighting instead of having to use underlined text like I did before. The actual scrollbar graphics are a little ugly, but that can be easily changed.

I'll try to work on TT64 more in the next few days. Someone just donated $1 today, which is not "a lot", but it means a lot to me., symbolically. (Just so you know, I don't do this for money but I really don't get donations often, I actually only got three donations in 4 years so this one was a nice surprise.)

messiaen: I deal with it in a pretty "dumb" way.

1) The code reads/decode from the .obj file, storing in a list variable (array) the information about each vertex (xyz position, texture coordinates and normal coords), and face data (triangles) in another list variable.

2) Another routine creates an intermediary version of this data that takes into account the cache limitation, re-indexing the triangle data while grouping it in smaller chunks. This "new" data is then ready to be encoded in GBI commands.

2a) This second routine first creates an equivalent to the vertex cache.
2b) It loops through the triangle data.
2c) For each of the 3 vertex index number for each triangle, it checks if the corresponding vertex info (xyz, texture coords and normals) is found in the current vertex cache. If it is found, the corresponding index position in the cache is added to the "new" triangle data item. If it's not found, a new entry is added to the cache containing the vertex info, and the last index position is added to the "new" triangle data item.
2d) If the cache is full (more than 16 items) then the cache data and its corresponding re-indexed triangle data is added to a list.
2e) The process repeats until the end of the triangle data is reached.

3) The third main routine converts the intermediary data into GBI commands.

This method creates a highly unoptimized output. Sometimes it will save space by not storing the same vertex twice if its used by triangles that happen to be in the same chunk, but sometimes, vertices may be stored multiple times.

You can't totally avoid repeating vertex data when you have a small vertex cache. There are ways to optimize the conversion, but optimizing data for small vertex caches is almost a science in itself. Complex algorithms exist to achieve some optimization, but last time I checked they were too complicated for my tastes. Search for "vertex cache optimization" on google to see how complicated it can get.

By rearranging the order in which the triangle data is feed into my second routine, it would be possible to generate a smaller output. The challenge is to find what would be the optimal order. Many completely different sequences might produce the smallest output, and there are so many possibilities.

Luckily, the results produced by my "dumb" method might not be that bad, as 3d programs tend to save triangle data in a certain logical order, putting connected triangles one after the other.

Anyway I hope it all makes sense, since I'm a little tired

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 520/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-02-09 04:00:55 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 10-02-09 01:02 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

I've I said previously, I work a lot at my "real job". Outside of my job I don't have much time for myself. When I do have time off, I may decide to work on TT64, but I may also decide to relax and watch a movie or some TV episodes, surf the net, or see my friends on the weekend. Considering how much I work at my job, I don't think anyone could consider that laziness.

If I set a release date, I will be "forced" to work on TT64 to meet that schedule, even when I'm tired and I feel like doing something else.

I'd rather not set any date and have people wondering when it will be released, or maybe even lose interest, than set a date where hype will be built, the pressure will accumulate, and have a possible huge disappointment if I don't meet that date.

It will more than probably be ready before the end of the year, but I'm not giving any guaranty, and I don't want to see anyone waiting december 31st for a release if it's not out before then.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 521/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-02-09 05:04:11 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 10-02-09 02:06 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Hey that's a nice start messiaen, it reminds me of my first few experiments since I had some similar results at first. I like some "healthy competition"

, it will probably give me some motivation to work more on that thing.

Does your .obj file only contains triangles? Looks to me like it contains four sided polygons too which would explain how a bug could cause half the triangle to not appear.

You must separate these 4 sided polygons into two triangles. Maybe that's what you already did, but I'm guessing that you got the vertices order wrong. I remember struggling a little to find the right vertices order needed to split the four sided polygons into two triangles.

TT64 0.6 BTW will support .obj files containing 3 or 4 vertices per face, but not more than that (some exporters will also export some 5-6 sided polygons). Note that most .obj exporter include an option export only triangles.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 522/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-02-09 05:51:15 AM, in Game Genie! (last edited by VL-Tone at 10-02-09 02:53 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

I hope I'm not hi-jacking this thread with ultra-geeky stuff, but all of your talk about the Game Genie reminded me of this:

I was too poor to get a Game Genie, so I "circuit bent" my NES, before the term "Circuit Bending" was even invented

http://en.wikipedia.org/wiki/Circuit_bending

I had my NES opened, with the case removed, and I would create short circuits between pins on the back of the cartridge connector and create all sorts of weird glitches

More precicely on by inserting some paperclips on the top of the long metal pins you see in this at the bottom right of picture:

The paperclips were connected to some wires and a push-on switch, so I could trigger the glitches on command.

After a few experiment, and by looking inside the cartridges themselves, which had a ROM named "PRG" and another "CHR", I quickly understood that half of the cart connector was used for graphics (CHR) and the other half for the game program (PRG).

At first I could only create graphic glitches by short circuiting the CHR pins, some similar to some Game Genie codes, affecting only the graphics and not the gameplay. But doing any kind of short circuit on the PRG pins would result in an instant crash/freeze of the game.

I experimented a few things, like putting a diode or a potentiometer between the two wires. I found that I could trigger some program changes by connecting a CHR pin to a PRG pin going through a potentiometer fined tuned to a very precise value (it doesn't make sense since it's all digital, but it worked!)

Once, I found a combination of CHR and PRG pins that would trigger weird programming changes when I clicked the switch (it would affect Mario's position), and then realized that the potentiometer was disconnected, so there was no way that the current could pass between the pins since they were not connected together! (scary!)

It must be some weird electrical phenomenon, but by using two coupled wires of the right length and size (I used some typical 110v type wire, about a foot long) with some mini push switch in serial on one of the wire, the CHR digital signal would affect the PRG signal in a way that it would not crash the game (most of the time).

With that switch, I could cause a lot of weird things to happen in SMB, in real time:

I could push Mario against walls to the right, until he would walk right through them. Hitting the switch would sometime throw Mario violently to the right of the screen. I used to tease my friends with that while they were playing

Some pin combination could also cause changes in the level structure, sometimes changing the memory pointer determining where the level data is currently read. That would warp Mario to strange semi-random worlds. Because of the way the SMB level data is stored, random data would cause weird but mostly playable levels to appear. When I hit a part where Mario was blocked by a wall, I would hit the trigger to make him walk though walls.

I mostly experimented with SMB since it was giving me the best results with program changes. I also did the same thing with SMB 2 JP (aka Lost Levels) which I had as a pirate famicom cart with an adapter.

Anyway, that was a lot of fun!

I did eventually get a real Game Genie and had fun hacking codes to find similar semi-random worlds and glitches.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 523/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-05-09 07:32:08 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Well messiaen, that sure lit up a fire under my ass to get me to work on TT64

So I worked on it tonight. I finished the integration of the new scrolling field widget in the interface. I've added the code to deal with what happens if you re-import an obj file with additional or different material names. In that case, materials that didn't have any parameters saved in the level file will simply get default parameters.

At this point, the main thing missing is dealing with custom sky background for imported levels. I'm still not sure how present it in the interface.

Another thing that's left to be done is the "keep existing objects from ROM" option. This option would keep the 0x24 objects (as well as 0x26 warps, 0x36 Music track and 0x31 Terrain type) that are currently in the ROM level slot when a level is re-saved to the ROM. I also wanted to have a "Use objects from level file" option where objects previously saved in the level file would be used instead.

Aside from that, there not that much left... Maybe some error checking, and an interface to warn the users that the ROM will be re-extended and patched if they want to use the importer. And then it will be mainly debugging.

Originally posted by messiaen

I'm having trouble with some trivial things. First, when converting the floats in the .obj file to shorts, I just multiply it by a random scaling number in the hopes of not losing too much precision. Is this how you do it? It seems to be working. To deal with texture coordinates, I multiply "vt" values by the same scaling number and then by * 32, which will move the number 5 bits to the left to get the appropriate float format. Not sure how well it works, I haven't found yet a triangle-only nice .obj file with vexture coordinates.

For vertices coordinates, I normalize them by dividing them by the biggest value (so that the maximum value becomes 1.0), then multiply by the scaling factor. For texture coordinates, I have a 10.5 float conversion function, but I'm still not sure about the scaling of those textures, if the number is too big or too small, I get texture glitches.

Originally posted by messiaen
Since any kind of vertex cache optimization is beyond the reach of this proof-of-concept crappy importer, I have come up with an alternate optimization method for display lists. The vertex cache is always set to that the triangles will be always 1/2/3 4/5/6 7/8/9 10/11/12 13/14/15. Instead of writting this tons of 0xBF triangles, I just call an "master" display list using the 0x06 jump command. Hacky but works .

That's a nice idea which could save a lot of space. But what I was wondering is, would it make it faster? I assume that the drawing list commands are read each frame? If yes, then I guess that about the same number of commands would have to be read with your optimization method. I may implement it eventually even if it's only to save ROM space, but for now I don't want to mess up with my importer code since it does work nicely.

Originally posted by vinnyboiler
Vl-Tone if you don't want people to loose intrest you could release a few OBJ's as levels. That would really get alot of intrest in your work. It dose not have to be master peices heck you could even just realese some of the old SM64 rom files cramming your laptop as patches.
Please

I guess I could do that, but that would only increase the hype, and the number of people asking "when are you gonna release version 0.6?".

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 524/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-05-09 07:25:40 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Welcome back Gecko

I was wondering, could I use your level to make a Youtube video? I'll give you credit for sure.

Originally posted by messiaen
Nice to see you got motivated . I guess I'll release my little tool (without the buggy material support because I won't have time to work on it this week) so people can have an idea how their .obj files work. The entire level will only use one texture, hopefully with correct texture coordinates.

It will be useful so we can see what kind of problems can arise with different .obj files.

Originally posted by messiaen
One problem I am having is with culling. Usually the face order is correct, however in some cases I have to reverse it to avoid back faces showing instead of the front faces. In one model I made with SketchUp, only a particular part of the mesh was exported with a different face order, but that was perhaps my fault when modeling it and moving some vertexes around.

I'm not sure about that, once I got the thing working properly, I didn't have any culling problems.

Originally posted by messiaen
I looked how you laid out your level file. Are materials tied to specific collision types? I think the best way to go would be to give control over each individual collision triangle. Most of the time, collision type 0x00 will do the job for different angle possibilities. Also, when in the collision mode, what about having an option to disable the lightning? Since collision triangles are sorted by colors, sometimes the lightning can change too much the colors.

Yes the collision types are attributed to materials. I originally planned control over each triangle for all parameters, but that was for version 0.7b. At this point adding that would require some major reworking of the interface. Anyway, you can have control over each collisions triangle by assigning materials to specific triangles in your 3d program. And if you want to have one texture using different collision attributes in different triangles, just create two or more materials with different names that use the same texture.

As for lighting in the collision mode, I think I'll simply disable it, as lighting is not useful anyway for this.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 525/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-11-09 12:00:56 AM, in Mario 64 Level Importer

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Breegullbeak, would it be possible to get all the .png textures for this file? I would like to try to import the model in TT64, and it's currently dependent on finding texture files. I guess I could patch it so it uses some random textures instead, but it would be nice to try with the real ones.

messiaen: What does your program do with .obj files that do not have texture coordinates or normals?

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 526/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-11-09 02:30:51 AM, in Mario 64 Level Importer (last edited by VL-Tone at 10-10-09 11:34 PM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by messiaen
By the way, how do you handle normals?

That's funny, I was just about to ask you the same question

Normals don't seem to work properly in my importer and I was just investigating that a few minutes ago. I'll get you back on that once I tested Breegullbeak's model.

Breegullbeak: Could you please zip all the textures in one zip file? Downloading each one individually from mediafire is a pain...

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 527/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-11-09 03:39:02 AM, in Mario 64 Level Importer (last edited by VL-Tone at 10-11-09 12:52 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by messiaen
Originally posted by VL-Tone
That's funny, I was just about to ask you the same question Normals don't seem to work properly in my importer and I was just investigating that a few minutes ago. I'll get you back on that once I tested Breegullbeak's model.

Haven't tested much, but perhaps maybe a logical method would be to normalize to 1 dividing by the max value, like you are doing for texture coordinates and them multiplying by 255.

Well that's what I did, except that as far as I know the normal values are signed, so it's a matter of getting values ranging from -128 to 127 (or is it -127 to 128? Damn off-by-one errors!)

Using the "rainbow effect bug" to visualize the normal data as colors, I thought for a moment that my normal data was seriously wrong, but color data is not signed so that was simply a bad interpretation on my part.

Nevertheless, my real problem is that the vertical walls (with the brown texture) in Gecko's level are way too dark. Also, when seen from the top (when Mario is falling when he starts a level) the whole level is also anomaly dark. And when I add objects in my level, a weird thing happens with lighting over the whole level geometry. It changes in very noticeable steps from dark to light depending on the camera angle. At some angle the vertical walls look nice (light enough) but it doesn't happen smoothly at all.

Edit:

Well I found the bug: I was setting the one of the two gouraud shading color twice by setting 0x0386 two times instead of setting 0x0386, then 0x0388.

____________________

VL-Tone
Member
Super Mario 64 forum moderator
Level: 53

Posts: 528/621
EXP: 1136484
For next: 20635

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 10-11-09 06:10:04 AM, in Mario 64 Level Importer (last edited by VL-Tone at 10-11-09 03:10 AM)

Link

Time: One second ago - Date: Tomorrow - Weather: Sunshine - Mood: Moody Answer to the universe: Yes

Originally posted by Gecko

VL-Tone, while using TT64, I thought it would be useful having following tools and/or changes:
1. newly added objects should have all star acts enabled or there should be one button for enabling all acts at once
2. copying existing objects by clicking on a button, making the new object appear at the same place
3. copying and pasting coordinates of object like it's already possible with parameters, e.g. you'd like to add a coin upon a platform or tree
4. after I received a "script not found - continue?" error, I could not save the latest changes, pressing on the button would not change anything
5. after pressing the "save" button it would be nice having a response from TT64 like "game saved" or simply "saved".

Maybe some options already exist and I've simply missed them.

Hey it looks like a fun level Gecko!

I added numbers to your suggestions so I could address them more easily:

1. This is definitely planned, I was thinking about these two options just a few minutes ago.
2. This is already implemented in v0.6b. You can copy/paste/duplicate/clear whole objects.
3. You can already select the x, y and z coordinates at once using the shift key, then use "copy parameters". But TT64 will also features "align" buttons that could help you align a coin with a tree.
4. Unfortunately, if you get a script error, it's the equivalent of a crash, don't expect the program to work normally if you click continue. There is an option to "Auto-Save" in the preferences, it could help you to prevent losing work.
5. The save button text turns from red to white when you save (if the button is not red then there's no change made since the last save).

BTW I just made a nice demo video using your other level, I'm about to upload it to Youtube.

____________________

Register - Login
Views: 99798769	Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies	05-03-22 06:12:18 AM

Query execution time:	0.272439 seconds
Script execution time:	0.096326 seconds
Total render time:	0.368765 seconds