 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by VL-Tone |
| Pages: 1 2 3 4 5 6 7 8 9 10 |
| User | Post | ||
VL-Tone Red Cheep-cheep Level: 23  Posts: 121/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| There is a very very basic Mario 64 editor on my page, it only works on Level 1, and only can move and rotate objects, change their type and behavior. You cannot change the level geometry, only objects in the level. Not all objects are editable, trees, coins and other objects are not editable now. Actually, it's more of a hacking tool for now, and you need to know at least hexadecimal to use it. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 122/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
(Extra space added to get around layout bug) If you look earlier in the thread, you'll see that I discovered that already, the three next pairs of bytes after the xyz coordinates are rotation angles in degrees (16 bits signed integers). They are for rotation around the X, Y and Z axis. For some behaviors, like most animated enemies, changing rotation values may not have any effect on particular axis since the behavior code takes over these. It seems that you discovered that the Mario start behavior only allows rotation around the Y axis. Anyway welcome aboard the Super Mario 64 hacking train  , don't hesitate to add new things you found.About the 0A value it's a parameter for this particular behavior, did you really try all the other 255 possibilities? I updated my editor so that you can see and edit the rotation values as signed integers (it means they can be negative values), instead of hexadecimal.  Also, I discovered many interesting things today in the ROM. HyperHacker mentioned in the first post in this thread: "2AC0EE - some kind of pointer table?" Actually I figured out this pointer table, it starts at 2AC094:
This list looks like it's actually part level layout data for some level... Could this be from the inside of the castle, and those are the pointer addresses for all paintings and levels found there? Edit: it sure is ! I just confirmed that you can swap around each of these "10 00 0E 00 " delimited groups to make any painting warp to any level! For example, if you replace 10 00 0E 00 40 00 60 5A 40 00 B0 5F 00 0E 64 02 04 07 00 00 with 10 00 0E 00 3F 00 90 B9 3F 00 B0 C2 00 0E B8 02 04 07 00 00 at $2AC0F8 in the ROM, you will enter Shifting Sand Land instead of Bob-ombs battlefield when you jump into the Level 1 painting! I'll continue documenting which pointer is which level. The only thing is that when Mario dies, it get ejected out of the swaped level instead of the original, so the "exit level" pointer may be part of the layout data. It seems that the level layout data pointed by this list really describes the whole scene, loading geometry, textures and positioning objects like enemies etc. Some objects starting with length 0C load (decompress) MIO0 files in RAM banks, these 0C object's last 8 bytes are two address, that are sometimes MIO0 files addresses. After these 04,08,0C and 24 bytes long commands, comes another list of another kind of objects. They are usually 4 bytes objects Here is the list of other kind of objects for level 1 (which is just after the other list with 1824 objects). It starts at 405E9C in the ROM:
The "15" objects are 8 bytes long and their last 4 bytes are pointers to each entry points to every parts of the level geometry inside bank 7, the current level data bank. These kind of pointers are what I had to found manually inside each MIO0 files, and that's why I couldn't decode all levels yet... I guess that will change now since we have pointers to just about every levels and every meshes inside the MIO0 files (Edit:Is it just me or Cymoro's layout causes it's "edited:" messages to spill over the top of my message?) Yet another edit, I forgot to reply to HyperHacker: Since your post was before my new release, I guess your problem was for version 0.23? Maybe 0.25 will fix it, but I really don't know. Could you tell me one thing if you still have this problem: is the sky very pixelated (squarish pixels) or is it blurry like it's supposed to be? (edited by VL-Tone on 07-19-05 01:02 AM) (edited by VL-Tone on 07-19-05 01:10 AM) (edited by VL-Tone on 07-19-05 02:20 AM) (edited by VL-Tone on 07-19-05 03:02 AM) (edited by VL-Tone on 07-19-05 03:06 AM) (edited by VL-Tone on 07-19-05 03:16 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 123/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| HyperHacker, my guess is that you didn't open the right version of the ROM...I'll implement a check function that will warn you if you don't have the right version. As for the slowness, I'll look for the problem, but I think that my program is a little too sensitive to CPU usage by other applications. On the more positive side, I documented all of the levels in the pointer list that starts at 2AC094 in the ROM!
So far, no lost levels found  A few weird things happens though when you replace level 1 with some other levels. For example, Mario starts the wing cap course without a cap, so he'll fall down and die! If you replace level 1 with a Bowser Platform , you'll find that Bowser doesn't greet you and is in "tired" mode and won't attack you until you grab it's tail at least once. If you replace level 1 with the castle interior, you'll start in a weird place, in the little box behind the Princess secret slide painting. If you replace it with the castle backyard, Mario will be seen jumping out of the fountain, with little Stars around him, but then the game freezes. Another thing, I didn't find the Penguin slide in the list, I guess it's because you can't access it directly from inside the castle. Edit: Thomas, the short answer is: yes, we are decoding and editing Super Mario 64 (edited by VL-Tone on 07-19-05 04:31 PM) (edited by VL-Tone on 07-19-05 04:32 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 124/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Cymoro, what I did to document all these is exactly that: to replace the line for Bob-Omb's Battlefield with each of the other lines. So yes when I entered the Bob-Omb's Battlefield portrait, it was going to other levels instead. As I mentioned before, when you die or exit a level by getting a start, Mario jumps out of the portrait of the level he was into, not the original level (not the Bob-Omb's Battlefield portrait in that example) So your question is actually to know if instead of being ejected of the painting you could go directly to another level? It's probably possible, as the layout data for each levels likely contains the address of the castle insides, with a parameter that tells which painting to exit from, this could be replaced with another level address. I'll have to check for that. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 125/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
There is a star in the courtyard?  There must be some parameters that set which start point is used, something in parallel with the act number, since both can be used independently. I forgot about the mountain slide but this pretty much confirms that the list I found is really all the possible exits from inside the castle, being triggered by the paintings and some doors. I would guess that the go-outside-level-door command inside the level layout data sets a position, then gets the destination level address found in that list, but the painting warp command uses the destination level's included Mario start position.(edited by VL-Tone on 07-21-05 04:13 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 126/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Ok you got me there HyperHacker  Thank you for reminding me that information, It's been a long time since I got all 120 stars in the game, maybe I should do it again, it would refresh my memory I have less time these days though to continue hacking the game. My next project though is to make a program that will generate a list of all the possible "1824" objects in the game. I'll make my program group them by type, so that each possible behavior associated with each type is listed. I'll also make another sub list for objects that have the same behavior but different parameters, so that we can have an idea of possible parameter values for each behaviors.Here is a little picture to keep less technologically inclined people interested!  This is the low polygon version of Mario's head. In case you didn't know, Mario switches to a low polygon version when he's far enough from the camera. Now you can see how ugly this version looks when seen up close |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 127/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Hey that's neat stag019 What address does this GS code change, and is it in RAM? I didn't find anything yet regarding to object scaling in SM64, so this may help to find the scaling byte(s) location for Mario. Edit: Here is a list of all object commands found in all levels, their length, and the number of times they are used. It confirms that in reversed byte order, the second byte after the length byte is the command number, with normal bytes order that is the first byte, the length byte being the second. It also shows that there are a lot of commands that we don't know anything about yet
(edited by VL-Tone on 07-22-05 06:02 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 128/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| HyperHacker: Yes it looks like some kind of "macro-asm" commands, actually it really makes me think about the StarFox level format. This shouldn't be surprising since Miyamoto said that Mario 64 evolved from experiences they did with the FX chip. zidapi, we'll have to investigate the Japanese version then Maybe the space used for extra voices in the US version are filled with "lost levels" in the Japanese version?Darkflight: all commands for the Bowser level are loaded when swapping levels, since the address points to the start of the level data. I would guess that values that activate Bowser are set before jumping to this data . My latest findings: There are 286 different type+behavior combos used in the game for the command 24, and these should be documented. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 129/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| HyperHacker: What do you mean by "valid commands"? As for the byte order, I started hacking Mario 64 with the idea that all n64 ROM formats were byte-reversed. Then I found out it wasn't true, I already had many things I worked on and documented using the reverse-byte order. Also, someone earlier in the thread mentioned that we should stick to one format. Since the majority of what was posted by me and others in this thread was in reverse byte order, I decided to continue using it. Do I find it easy to work with? Heck no... Should I switch to "normal" byte ordering? I guess that yes... I was about to ask people here what would be the implications of it, before you mentioned it. I'm pretty sure that this phrase from my earlier post: "It confirms that in reversed byte order, the second byte after the length byte is the command number, with normal bytes order that is the first byte, the length byte being the second." incited you to make this comment stag019: I didn't know that about the GameShark, I thought that it could also affect ROM values like the original NES Game Genie. It seems that the game switches to the low poly Mario when far enough from the camera. I guess that someday we may find the distance value associated with it. Edit: Take a look at this early Mario 64 hacking reference document I put together last night http://pages.infinit.net/voxel/Mario64HackingDoc.txt It includes a sorted list of all 286 object type/behaviors combinations used in the game, along with possible parameter values. (edited by VL-Tone on 07-23-05 11:15 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 130/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
HyperHacker, I kind of knew that this was the kind of list you wanted, I wanted to tease you a little I guess many things are loaded directly from the ROM and into RAM, but some aren't, as they are the results of some calculations, the best example of this is the MIO0 files which are loaded in RAM but cannot be found (decompressed) in ROM. About byte ordering, you are right... I guess I waited for someone to push me into "switching". I found though that the most common ROM versions are .v64 and .n64 which have the bytes reversed. Anyway there are tools to reverse the byte order that ROM hackers should be able to use So I announce officialy, I'm officially switching to normal byte ordering.Behaviors really look like they are pointers, and that's how it worked in StarFox. I didn't even check if those point directly to things in ROM yet, so you might take a look at that. Cymoro: Great findings! That way we could blow out groups of things based on some trigger. (and they don't even have to look like gates). I don't know where we can find the trigger though, it might be in the "log" object which is not a type 24 command. Lol at Mario being thrown in jail Hopefully you can exit the course even if you never finish it before, unlike SMW?Cool that you started to document the objects! Make sure that you identify the look and the behavior of objects as two things. I'm working on integrating this list into my editor so you could try every combinations simply by clicking arrows or choosing from a list, it will be faster than doing it "by hand". I just managed to implement textures in the rooms inside the castle (pictures of that soon). Interesting thing, only the "fake" paintings appear, the real ones must be placed there with some object command. I also have some problems with the second floor and basement not being at the right position relative to the first floor. Just like the Castle Grounds tower, it's position is offset by some object command. I'm confident that I'll find the offset coordinates for each portion of the level geometry somewhere in the level layout data. Ok now I just got back from work and I'm hungry, so I'll cook myself a supper and eat it I have a few other things to add that I found, so I'll either edit this post or reply a little later tonight. (edited by VL-Tone on 07-25-05 12:08 AM) (edited by VL-Tone on 07-25-05 12:08 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 131/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Oh so you cannot exit courses unless you finished them at least once in Mario 64? This means they had to design level to make sure that there was no way of getting stuck, which is anyway always a good thing to do when designing a video-game Ok dinner is ready! *VL-Tone goes to eat. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 132/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
First, I hope these are not too many big pictures, the total size is about 1 meg so it shouldn't be that bad for people on 56k. I remember the days when I was on 14.4  , now I'm spoiled by 4 megabits/sec cable...Anyway if you think I should move some of these pictures to the screenshot sticky thread don't hesitate to tell me. I think these pictures are a worthy part of this thread, and I had a hard time deciding which one to keep, because there are so many new interesting angles to be seen. I'm also under the impression that I'm not the only one who wanted to see the insides of the Mario 64 Castle from these surreal angles since a long time So, to save you a few clicks, here are the screenshots:First, let's look at a familiar view angle...  Hmm... I remember seeing that picture before... But look there are no doors?   This one is taken outside the castle lobby. Please don't mind the star door floating there  Here is a view from far far away! You can see the little rooms for each level paintings. For those who saw or played SM64 DS, you've probably seen something like that before as the overhead map of the castle lobby hub that appears in the bottom screen.  This is the second and third floor, and the basement. Weird, there are two rooms that look almost identical, but are different... like if they were...mirror versions! I wonder why this could be  Bigger version http://membres.lycos.fr/nes3d/Mario64CastleMirrorRooms.jpg Seriously, like many people here probably already figured out by deduction, the N64 cannot create a true mirror surface at a large scale like the mirror room (actually, real ray traced mirrors are not even possible even in current generation consoles at a useable framerate). When Mario is inside of this special mirror room, surprise surprise: there are actually two Marios! One being in the other mirrored room mimicking the first one. The paintings in the mirror room though are fake, you cannot enter them. There is a semi transparent polygon plane with glare effect in the middle of the room that act as a barrier between the two Marios. All to create the illusion of a mirror. Maybe there is a simple object command that makes the mirror Mario appear? I would guess you can also set the position and the Y angle of the mirror. What if you put many virtual mirrors at different positions and angles inside the same room, does it mean that you cam make dozens of Marios appear at the same time? That would be really really fun to try: do you remember the Mario 128 demo? Let's try how many the n64 could display without dropping too many frames  Another view of the 2nd and 3rd floors and basement. Some paintings are missing, only the non-enterable ones appear.  Here is the Tick Tock Clock tree, with the painting and the clock hands missing... The latter are part of the same geometry data but not at the intended position.  The last level entry with the night sky texture, and the infinite stairs? Since they were infinite, it was taking an infinite amount of time to render the stairs on my computer, so I decided to transform it into a finite height stairs instead Hopefully that's it for now. The basement was a little bland without the paintings so I didn't put many screenshots of it. I'll try to add all the castle rooms to my demo soon, as they are not included now, only the Castle viewed from the outside and three other levels are currently available. (edited by VL-Tone on 07-25-05 07:43 AM) (edited by VL-Tone on 07-25-05 07:55 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 133/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019 Oh well I decoded the castle interiors for nothing then I think the virtual Mario(s) would'nt be affected by scenery... So that would make it hard to do a Mario 128 thing on terrain that is not mirrored. I would guess that the barrier and glare effect is one object, and the one that makes a virtual mario is another. As for the F, I suspect it's two of these platforms:  There is just one in the geometry data, unpositionned, meaning it's near position 0,0,0 and its probably repositioned by level layout data. There is also just one of the two pillars appearing at position 0,0,0 (not shown here) and one half of a star door . This means the game can clone multiple instances of these in a level. This still doesn't explain what are they doing there. And how did you change the sign into 3 pink bob ombs? Is it near 405722? And what value did you change? Remember the object image type list you did while I was on vacation? I just realized yesterday that 405724 is part of the level 1 compressed MIO0 file... That's why I couldn't figure it out! So coins, trees and some other objects are part of the compressed file.The sign value (34) at 405724 in the ROM is found at 1129B in the MIO0 file. I currently investigating the format inside the file, it seems much more ordered I wonder why there are objects inside and outside the MIO0 file... Sukasa: great finds with the GS codes! These will be very useful keep them coming , too bad I cannot use GS codes (don't ask). What makes mario being squished though is not simply on the fly geometry modifications. There are different version of the Mario geometry inside its MIO0 file, about 5 predefined squished versions of Mario of different height...Cymoro: to make the bob-omb appear in every act, you changed the act number to FF right? And yeah there are tons of things that could be done, even only with the "24" objects found outside the MIO0 file. I'm currently implementing the newer object list (types and behaviors combos) in my editor, that will make it much more powerful, maybe I could add an IPS patch save option. But we should document the objects before starting to hack around levels. zidapi: I forgot to reply to you sorry! Originally posted by zidapi That's very usefull to know! It means that this is the master level list. Is there an IPS patch to activate the debug menu? It would be very interesting to dig up the Japanese version and list the MIO0 files, I would also think that there is much more beta stuff in there (things that were removed to make place for the extra voice in the US version) Ok now here is a revised version of the MIO0 file description list (US version):
The list is still not as detailed as it should be and there may be some little mistakes here and there. (edited by VL-Tone on 07-25-05 09:52 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 134/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019 Ehmm... it's not the star door... It's the red platform under it. Put two of these side to side, and with some messed up face culling you get an F if seen from a particular angle. You can see that the red platform has the same proportions.  |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 135/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Is this the Yoshi Beta egg you were talking about?  This is extracted from the Mario 64 ROM, it looks better in 32-bits though, since I had to reduce the number of colors to 256 for the animated gif. Here is the 32-bit unanimated version:  Been busy these last two days, but I had time to release a new version of my level layout editor.  It's also in my sig, but the editor is at http://membres.lycos.fr/nes3d/M64EditDownload.htm This new version features a revised interface, with bytes shown in a normal order, and most importantly, includes a browseable list of "combos" which is the name I decided to use to describe the type/behavior/parameters combinations found in the game. The weird colored triangles with plus signs are buttons that will copy parts or the whole combo to the currently selected object (don't forget to save the object after copying). You can also reverse the arrows direction and copy object values into the combo fields so that you can use it as a clipboard to copy values between objects. Another improvement is that you can now edit the "act" byte by clicking on the stars, enabling or disabling the object for this course. Obviously, this thing will be much easier to use once we have a list of what all these combos are, and the interface will feature a pop-up menu to chose them. Also, I'm about to add support for other levels. (edit: ehmm I just realized that the "behavior" text is misaligned in the interface... I don't know how it got through my testing... I don't think I'll re-upload a fixed version just because of that) (edited by VL-Tone on 07-27-05 11:00 PM) (edited by VL-Tone on 07-28-05 01:16 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 136/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019 That wtf is the gate used to enclose the star and block the tunnel entry. It's part of the level geometry, but in the game it's cloned and positioned at two places in the level using two $24 objects. The tilting platform is also one of the polygon mesh in the level geometry that is positionned by a $24 object. Maybe I should have removed the gate (for now) from my editor. As for the act value being wrong... I know it's loaded correctly, and that the binary conversion workst. I already noticed the imperfections, but forgot to mention them, I don't have any idea now why it happens, since the stars are right most of the time. I started to do the anim for the beta flower, but now I have to go work, so probably later tonight you'll see it! |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 137/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019Originally posted by ImajinWell, I aimed at actually trying to answer this. I tried searching the rom for 0031E1D0 and got Four results. The first one didn't do anything, the second one (48D040) changed the LLL textures. However, I tryed to change it to 0032D070, and instead of getting the grass texture, I got the inside castle textures, like when you change 405CD7 into something odd. Can someone get this right? The 0031E1D0 that should be changed is at 48D040 which is inside the LLL level layout data, inside a 12 bytes command (0C) of type 1A. If you look at my SM64 ROM hacking doc http://pages.infinit.net/voxel/Mario64HackingDoc.txt You'll see that 48D040 is between 48C9B0 and 48D930, the level layout for LLL. So instead of doing a ROM wide search when you want to find textures addresses you should refer to this list, and look only into the range for that particular level. But anyway it couldn't work because the Bob-omb's Battlefield textures are a little smaller than the LLL textures, so this particular swap only works the other way... |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 138/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019 Whomp's Fortress textures (at 00357350) and LLL textures decompressed MIO0 files are exactly the same size, so you could swap those instead. Note that the level geometry for these levels also include some textures so that not all textures will be swapped. So change 0031E1D0 to 00357350 at 48D040 and you should get most WF's textures in LLL. As for your question "It uses the same textures, right?" what exactly were you talking about? |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 139/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019 No they don't In the linked image, at left is Whomp's forteress textures, and right are the Bob-omb Battlefield textures http://membres.lycos.fr/nes3d/WhompBB_Textures.jpg These textures seem shared by other levels too (as there are no cactus in level 1) (edited by VL-Tone on 07-29-05 01:07 AM) (edited by VL-Tone on 07-29-05 02:08 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 140/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by stag019 Hmmm ok. That's weird indeed The answer might lie in the 4 bytes pointer just after the 0031E1D0 which is 326E40, which is at the end of the compressed MIO0 file in the ROM I think I now understand the 1A command (same class as command as 24). Whomp's Forteress at 49DFD4 The 0009 is without any doubt the RAM bank into which the big texture data is loaded for these two level. Inside the geometry file for both levels, bank 0009 is referred by the FD command, which loads textures into the RSP for polygon use. |
| Pages: 1 2 3 4 5 6 7 8 9 10 |
| Acmlm's Board - I2 Archive - - Posts by VL-Tone |
