 Register - Login |
||
 |
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies |
|
| Jul - SM64 Hacking (Archive) - FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!) |  -  -  |
| Pages: 1 2 3 | Next newer thread | Next older thread |
| VL-Tone Member Super Mario 64 forum moderator Level: 53     Posts: 197/621 EXP: 1135505 For next: 21614 Since: 07-27-07 From: Montreal, Canada Since last post: 4.7 years Last activity: 1.2 years |
|
||||
|
| messiaen Catgirl Level: 68 Posts: 17/1085 EXP: 2594042 For next: 134758 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| Well, don't worry about it, there are still lots of things I can experiment with and learn from the documentation. However, could you or someone else confirm the possible FlatWorld 0x21 and 0x22 command listing bug I ran into? [I describe it in the first half of my last post] -- Edit: Hey, look at this, I was just 2 bytes far from getting TT64 to show my model! I went back to my old ROM which had custom Geo Layout for the Platform [the one I uploaded the Hex Data], and my silly error was that I forgot to change the first 0x80 command, which OF COURSE must point to the same entry point as the 0x10 jump command. 80 08 00 00 0E 00 01 70 <------- Special command only used by TT64 to skip to Object Layout (Important) My commands gets listed as 0x22 Number 075 , "Unknown". However, I still think there is something wrong with the listing, as there aren't 75 0x22 commands in the FlatWorld level.  Ops, I have to set my platform vertexes Y values to 0, otherwise I'll get 0x24 Y + vertex Y = double trouble in setting object positions  . This now uses a 0x22 Geo Layout pointer.HOWEVER, now that my 0x22 model shows in TT64, it won't show up in the game!!! --- Looking at "Tall Tall Mountain", I realised that many static platforms are in fact 0x43 objects, so maybe this command would be more appropiate for my current purposes. However, this is still undocumented in Mario Hacking Doc 1.5. For now, I'll see what behaviours these 0x43 platforms use and see if they fit on my 0x21 working platform (0x22 doesn't show up yet in the game). Ops, too bad, they use Static & Not solid behaviour, which looks almost like a "null" script but however it does accomplish something in my platform: it crashes the game whenever you walk near it, as most behaviours. |
| VL-Tone Member Super Mario 64 forum moderator Level: 53 Posts: 198/621 EXP: 1135505 For next: 21614 Since: 07-27-07 From: Montreal, Canada Since last post: 4.7 years Last activity: 1.2 years |
|
||||
|
| messiaen Catgirl Level: 68 Posts: 19/1085 EXP: 2594042 For next: 134758 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| Thanks VL-Tone, indeed it was the Geo Layout which was preventing the game from showing the platform. The good news is that now with a working geo layout, the 0x2A (behavior script) collision command works, so I have moveable collision!  0x24 Platforms with custom mode and moveable collision (custom behavior). --- What do you mean by drawing distance? Is this the distance from which the object is visible (this is what I think CellarDweller meant by "Disappear distance" on behavior thread) or is this some kind of distance between where you place your 0x24 object and where it is really drawn? If you mean the former, I'm experimenting on this, but so far I haven't reached a conclusion. Changing the values indeed effects minor changes in disappear/visible distance, but they are very difficult to notice. I'll take a look at other geo layouts, especially in platforms which have to be visible from very far to see what values they use for this. It seems, however, that behavior scripts also do affect this, but there still lots of testing to do to confirm this. When I was still using the 0x21 pointer and rotating between a few behaviors to see if my 0x2A command worked (it doesn't in a 0x21) I remember noticing striking differences in the drawing distance. -- Update: I got the 0x1D scale command to work! It only works when precedeed by a 0x14 command. However, I have no clue how to determine what is the "normal" size value. Unlike Mario, "40 00" in the last bytes will give me a shrinked version. Also, the collision data vertexes needs to be manually scaled, unless there is a behavior script command which also scales the collision. Eventually, TT64 could adjust the 0x1D command on its interface and adjust collision data for it (scale the polygons), but sure there is a long way to go before this. Here is my sample Geo Layout with 0x1D scale command: 20 00 01 F4 04 00 00 00 14 00 00 00 00 00 00 00 04 00 00 00 1D 00 00 00 00 00 40 00 04 00 00 00 15 01 00 00 07 00 00 E0 05 00 00 00 05 00 00 00 01 00 00 00 --- One bug concerning the red box when selecting custom 0x22 models: This is what get when you first decode the geometry:  This is what you get when you close TT64 and open the same ROM again:  Wireframe mode shows correct polygons/collision in both instances. |
| Stevoisiak Member Level: 38 Posts: 63/283 EXP: 345476 For next: 24971 Since: 11-22-07 From: New York, Long Island Since last post: 12.3 years Last activity: 5.6 years |
|
||
| Ok. Messian, you have done what I have been hoping would happen ever since I saw that video where someone moved the level terrain as a whole object. (Man that sounded weird) Could these newly made objects be implemented automaticly in either the rom extendor or Toad's Tool itself? |
| messiaen Catgirl Level: 68 Posts: 26/1085 EXP: 2594042 For next: 134758 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| Uh, perhaps you missed this? This is the concept of "Platform Battlefield", a empty level (it contains no terrain like Flatworld, just death at the bottom of the level) where you can move solid custom objects around. See more in the dedicated thread. -- Edit: Indeed there is a command the scales collision data! Check out the Behavior thread Edit2: Also, I have been experiment with the 0x20 Geo Layout command, and indeed it determines drawing distance (how close you need to get to the object so that it is drawn). The range of values are 0000 - 07FF. Anything beyond hex 8000 (dec 32768) will make the object invisible (probably some negative/positive values issue). |
| Stevoisiak Member Level: 38 Posts: 64/283 EXP: 345476 For next: 24971 Since: 11-22-07 From: New York, Long Island Since last post: 12.3 years Last activity: 5.6 years |
|
||
Originally posted by messiaen Not what I ment. I meant that video made me think, "Hmm, maybe the terrain objects could be divided into individual physical objects" Which, is what you did. |
| messiaen Catgirl Level: 68 Posts: 40/1085 EXP: 2594042 For next: 134758 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| Well, it is possible to "rip" parts of the level terrain of any level and make them individual models in Flatworld (and flatworld only), however this would be very difficult. It would be easier to get geometry that is already invidualized in 0x43/0x24 objects to load in Flatworld. But then, there is the texture problem, that is, only a certain set of textures are loaded in each level. I'm trying to get the mushroom platforms in my experimental level, but that will require some texture editing/swapping. Also, I will have to generate collision data for it (convert the polygon commands into collision triangles), because finding it in the actual ROM would be very difficult. Fortunately VL-Tone did a wonderful list of geometry layout/polygons for the individualized 0x43/0x24 geometry, but even then it is a bit hard to follow, because there are lots of jumps in geometry data. Usually, each texture command jumps to a pollygon command which load vertex from other part of the ROM. What I'm in doing is making this geometry more linear, suitable for copying/pasting with less repointing. I hope that works! Also, I'm wondering if anyone knows how to change the background in Flatworld? I think I already tried changing all level commands and geometry layout for the terrain, but couldn't find how to do it. Maybe this is loaded before the level data ? One thing I found by experimenting is that the first 0x08 command in the Level terrain Geo Layout is some hardware command that initializes the N64 display. 08 00 00 0A 00 A0 00 78 00 A0 00 78 Hex A0 = 160 (dec) Hex 78 = 120 (dec) Maybe A0 x 2 and 78 x 2 = 320x240. If you use smaller values, you will play in just part of the screen. Bigger values will give you some kind of zoom, but Mario is not centralized. Unless you really want a whacked hack, it is better leave these untouched. --- Big Mushroom Platform polygon commands/vertexes. Tomorrow I'll try using these as a custom model in my experimental level. |
| rstewart215804 User Crazed Mario 64 Hacker!!! Level: 11  Posts: 9/18 EXP: 5578 For next: 407 Since: 09-13-07 Since last post: 13.2 years Last activity: 11.7 years |
|
||
| The background is loaded into bank 0A with the 0x17 level command. By changing the starting and stopping values you can change the background. Backgrounds are comprised of one or more 32x32 bitmaps and 320 bytes. The 320 bytes a list of 80 pointers that are 4 bytes long... [0A][00 08 00] 1: Bank 2-4: Offset in bank for bitmap Each pointer pointes to a single bitmap. The pointers are arranged into 10 tiles horizontally and 8 tiles vertically. The game uses the two extra horizontal tiles to wrap the texture around. This list of pointers (From Bob-omb Battlefield)... 0A00 0000 0A00 0800 0A00 1000 0A00 1800 0A00 2000 0A00 2800 0A00 3000 0A00 3800 0A00 0000 0A00 0800 0A00 4000 0A00 4800 0A00 5000 0A00 5800 0A00 6000 0A00 6800 0A00 7000 0A00 7800 0A00 4000 0A00 4800 0A00 8000 0A00 8800 0A00 9000 0A00 9800 0A00 A000 0A00 A800 0A00 B000 0A00 B800 0A00 8000 0A00 8800 0A00 C000 0A00 C800 0A00 D000 0A00 D800 0A00 E000 0A00 E800 0A00 F000 0A00 F800 0A00 C000 0A00 C800 0A01 0000 0A01 0800 0A01 1000 0A01 1800 0A01 2000 0A01 2800 0A01 3000 0A01 3800 0A01 0000 0A01 0800 0A01 4000 0A01 4800 0A01 5000 0A01 5800 0A01 6000 0A01 6800 0A01 7000 0A01 7800 0A01 4000 0A01 4800 0A01 8000 0A01 8800 0A01 9000 0A01 9800 0A01 A000 0A01 A800 0A01 B000 0A01 B800 0A01 8000 0A01 8800 0A01 C000 0A01 C800 0A01 D000 0A01 D800 0A01 E000 0A01 E800 0A01 F000 0A01 F800 0A01 C000 0A01 C800 produces this texture...  ____________________ Just you wait until next time. Until then, keep that Control Stick smokin’! Buwaa ha ha! |
| messiaen Catgirl Level: 68 Posts: 43/1085 EXP: 2594042 For next: 134758 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| Thanks a lot rstewart, I'll experiment swapping the backgrounds between levels. This is how my mushroom platform is going:   I have to recheck everything, because I think some triangles are missing. For the textures, I just swapped the whole texture bank for now. I'm now building the collision for this. Before turning this into a specific collision behavior, I'm writing the collision data in the level collision pointed by the 0x2E command. This way, I can see the collision in TT64, because it can't read (yet?) collision from behaviors. However, I have a question concerning level collision. Flatworld collision is very simple: 00 40 00 04 <------ Loads 4 collision data vertices [followed by 4 vertices X,Y,Z] 00 00 00 02 <----- Loads 2 "0000" collision triangles 00 00 00 01 00 02 <----- triangles 00 00 00 03 00 01 [Now here comes my mushroom collision, one 00 40 00 0F command followed by vertices and chunk of triangles. After this comes the "end commands" 00 41 00 42]. Now when I open TT64 my collision triangles are all messed up, because in the second chunk of triangles, he used also some of the previous loaded vertices. This is a picture of what I get:  See how not just the new vertexes but also the previously loaded are used? (the ones that make the big "death at the bottom" giant plane) If I point my collision data to start at the second 00 40 vertices/triangle chunk, I get correct collision data (incomplete at the moment):  So, there must be a command that resets the vertex cache and goes between the 00 40 load vertex chunks, is that right? Edit: Nope. I was looking at the collision data from Castle Grounds, and it seems that there is just one HUGE list of vertices and collision triangles. Now I see why 0xBF use just one byte for each triangle vertex pointer while collision triangles use two. --- Edit 3: Ah, my mushroom now looks better . The stem always looked a bit akward (look at the colors in the first screenshot. It is also a bit transparent). If you look at the Geo Layout (check earlier post), you'll see that the polygons are divided in two "drawing layers" (as VL-Tone calls in the Hacking doc). Since the geometry is composed of jumps and I'm importing this from another level, the second drawing layer (in fact, number 5) which draws the stem of the mushroom must have different properties than the first one, setted somewhere earlier in the data or maybe some global properties set in terrain geo layout. I unified the polygons in just one drawing layer. It looked better (more solid), but the colors were a bit messed up.Then I erased this "FC12 1824 FF33 FFFF" command on the beggining of the second layer data and things turned out even better. I may have been a bit lucky, but it worked, and now it looks way better.  Enough of the mushroom saga, I hope you appreciate my effort for this, as the pratical results will surely be interesting! --- Last edit for this post: I finished the collision for this. Converting any 3D model into the collision data format should not be too difficult (just time-consuming) and could be possibly done automatically. If there is interest, I can post more detailed information. Download big mushroom collision data. One absolutely great thing is that the "0000" collision triangle is somewhat flexible. If there is inclination, it will act like a hill, and if there is too much of it, you won't be able to climb it or it will turn itself into a slide. I first realized this when I made the first "height terrain" level, but it amazed me how well my mushroom collision worked. -- New video !! <object width="425" height="350"> <embed src="http://www.youtube.com/v/6lBRXHZrc_g" type="application/x-shockwave-flash" width="425" height="350"> </embed> </object> |
| Stevoisiak Member Level: 38 Posts: 68/283 EXP: 345476 For next: 24971 Since: 11-22-07 From: New York, Long Island Since last post: 12.3 years Last activity: 5.6 years |
|
||
| Wow! It almost seems like you need a more flexable version of toads tool! You rock! |
| messiaen Catgirl Level: 68 Posts: 47/1085 EXP: 2594042 For next: 134758 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| TT64 is already a very flexible and powerful tool, and Flatworld Battlefield gives you a lot of freedom to experiment and learn. When I say that the collision data for individual models could be generated automatically, I mean just the collision code itself (like the one I uploaded). Getting into the ROM as moveable collision is another matter. This is easy to do Flatworld, as there is a lot of empty space in its 'banks', however it would be very complicated in "real" levels. Regarding the mushroom platform, I always thought some polygons were missing, but I discovered that I didn't chose the best mushroom model. If you look at the Tall Tall Mountain level, there a few different kinds of mushroom:  The first one is the "Big Mushroom Platform" (the one I used) and the second one is the "Mushroom Platform". The big problem is that if I enable culling, this is what I when I go under the big mushroom platform:  This is how it will look in-game, if you go under it. This is not an issue in the Tall Tall Mountain level, because you won't be able to get under these mushrooms because of where they are placed. Also, if the lower part was "closed", like the second Mushroom Platform, this would solve the problem. If I knew the command (if there is one) to disable culling, this would be the best solution. For now, I just duplicated all the polygon triangles in reverse order. That is, switching clockwise triangles to counter-clock, and vice-versa. This is just a matter of swtiching the two last vertexes in each triangle. As the collision data is also sensitive to culling, I will also have to do this for collision. |
| Stevoisiak Member Level: 38 Posts: 70/283 EXP: 345476 For next: 24971 Since: 11-22-07 From: New York, Long Island Since last post: 12.3 years Last activity: 5.6 years |
|
||
Originally posted by messiaen Yeah, but sometimes, as like with the platform, ahhh, never mind. So, I have an idea! I think adding these new objects to the game should be a built in feture with toad's tool. It could be like the flatworld button, except it can add objects to the rom. (Posibly, it could also take care of some objects not working in other levels) |
| messiaen Catgirl Level: 68 Posts: 55/1085 EXP: 2594042 For next: 134758 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years |
|
||
| I was looking at the ROM Banks loaded at Flatworld and noticed that there are some objects actually loaded that don't have a 0x22 Geo Layout pointer command. For instance, if you want to add the Warp Pipe in Flatworld, just replace one of the 0x22 commands with this: 22 08 00 12 16 00 03 88 I still have to test if you really need to replace 0x22 commands, it would be much better just adding a bunch of them. Edit: Another interesting fact about Flatworld. The terrain is already set to the maximum size. You can expand the polygons further, but the collision will not work. Thinking about it, most of the levels on Mario are really more vertical, whenever you need more space the game seems to use "areas" (sometimes smoothly connected, such as the Tall Tall Mountain Slide). I don't know if the terrain limits are absolute or relative or if there is a command that determines this, but in Flatworld they are 8192 and -8192, horizontal and vertically. |
rezapeza Level: 35 Posts: 13/252 EXP: 255655 For next: 24281 Since: 02-16-11 From: Noway Since last post: 11.0 years Last activity: 10.8 years |
|
||
| this really helped me, in hacking! obstacle course all the way! I just wish i was a better programmer so i could fix something and make it even harder ____________________ I can't wait for for my hack to be complete! |
ShenoxVII (in all seriousness, you're a prick) Level: 24  Posts: 45/111 EXP: 75917 For next: 2208 Since: 10-09-10 Since last post: 9.0 years Last activity: 9.0 years |
|
||
|
Where is the download link, I looked on homepage, I see no v0.5.98b
|
| Zero One 5170    And as we fall the spirit carries on, That a hero'll come and save us all, As we call the ones we left below, We all dream of the day we rise above Level: 129  Posts: 2827/5173 EXP: 24545464 For next: 504190 Since: 05-24-10 From: Delta Quadrant Since last post: 1.6 years Last activity: 121 days |
|
||
|
| ShenoxVII (in all seriousness, you're a prick) Level: 24 Posts: 46/111 EXP: 75917 For next: 2208 Since: 10-09-10 Since last post: 9.0 years Last activity: 9.0 years |
|
||
Originally posted by Zero One Then why was this thread in front and had something about it not being 6.0 because it is beta or something. So is there a real of a new toad tools or not. |
| Lyskar 12210  -The Chaos within trumps the Chaos without- Level: 192  Posts: 8382/12211 EXP: 99235681 For next: 637890 Since: 07-03-07 From: 52-2-88-7 Since last post: 7.4 years Last activity: 7.3 years |
|
|||||||||
|
||||||||||
| Pages: 1 2 3 | Next newer thread | Next older thread |
| Jul - SM64 Hacking (Archive) - FlatWorld Battlefield, Take Two (New flat empty level template! TT64 v0.5.98b!) | - - |
 |
Acmlmboard - commit 47be4dc [2021-08-23] ©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al. Warning: You are using TidyHTML mode! Pages MAY and probably WILL break. To disable, click here or append 'xxx-off=1' to the URL!  |
| Query execution time: | 0.093567 seconds |
| Script execution time: | 0.042045 seconds |
| Total render time: | 0.135612 seconds |
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
