messiaen Catgirl Level: 68 Posts: 62/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-01-08 03:36:22 AM, in Brainstorming ideas for Mushroom Battlefield Link

Hello people. For the past month I've been studying a lot the SM64 documents and testing the possibilities of Flatworld. I think that now I have sufficient knowledge to try (at least, start working on) a full 6-level stars from scratch. This level will use models from a variety of levels and probably the texture set of Bob-Omb's Battlefield / Shifting Sand Land. The only sure thing for now is that it will feature mushroom platforms of all sizes , as this will be the main concept of the level. Other things I have ready is the grass platform from Whomp's Fortress and a solid Green Pipe (without warp). I want it to have a "classic" SMB feel, if you know what I mean. In this Mushroom Battlefield Test video I posted earlier on the Screenshots thread you can see some of the elements I have to begin working with, but this is still the very beggining. The purpose of this thread is to brainstorm ideas regarding buiding a level from scratch. The closest experience I have to creating 3D levels is Duke Nukem 3D edit, but that`s more a "2.5D" game. So, I'm open to all suggestions. What kinds of things would you expect in a level with this theme? What kind of puzzles and goals? What objects from the game (any level, no limitations on this) would you think fit on this? How can I obtain variety within the level? The geometry can change significantly for each star, because almost everything will be made of 0x24 objects. Remember that these objects can be rotated along all 3 axis and scaled as much as you want, so if you have interesting ideas with giant/micro objets, speak! Don't be inhibited to post your ideas!

messiaen Catgirl Level: 68 Posts: 63/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-01-08 05:17:30 PM, in Brainstorming ideas for Mushroom Battlefield (last edited by messiaen at 05-01-08 04:32 PM) Link

Thanks for ideas, I guess the tower idea could be somewhat adapted to a Giant mushroom, which requires some platforming to reach it. So one act could be vertically while others would require more ground work. I'm not only using mushroom platforms and grass platforms, that's what I have ready for now. Importing geometry from other levels and building movable collision when needed takes some work, so I need some design ideas of what I want to achieve otherwise I'll just waste time on objects I won't use. So, play M64 a bit, browse levels in Toad's Tool and share your ideas! 2D drawings are fine. I'm taking a look about how areas are handled. If I get this to work, the level may feature an underground area, acessible by a pipe. If it is possible to change the loaded banks, it may feature a lot of textures/enemies/objects from Hazy Maze. I hope my work shows that there is still a lot of things we can do in TT64 and with the documents produced by VL-Tone. If nobody cares to read things and experiment nothing will happen. --- One of things I'm trying to decide is if I want to use the "island in the air" level style, such as Whomp's Fortress. Here is a test collision map: The yellow plane is the "death on the bottom", while the white is the terrain. So, when you walk in the limits of the grass, you will fall and die. I guess I should follow the Bob-Omb level and just keep it like Flatworld. However, the template could be used in the future for a platform oriented level. --- Using parts of level geometry may be easier than I thought. I was looking at the Bob-omb level terrain geometry layout, and the terrain is splited into 5 jump commands. I used TT64 to render these layers as separate 0x24 objects in Flatworld and found some interesting things: First, one of the layers is composed of all "tree shadows". Getting a invidual model will be very easy. I won't do this now because I'm keeping my 0x24 spots for more useful things, such as this: This is the warp tunnel at the Bob-omb mountain. This will be very useful, as it can work both as a tunnel or as a hole in the ground. There also a bunch of other objects I could get from the terrain in Bob-omb, but these would require more work. For now, the tunnel will surely get in my level.

messiaen Catgirl Level: 68 Posts: 64/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-02-08 06:34:38 AM, in Behaviour Scripts (last edited by messiaen at 05-10-08 02:10 PM) Link

I guess the "mouse pointer" could be easily found by investigating the 0x22 geo layout commands which define models pointers in each level, if you want to change that. But what I was indeed searching is the 0x0C call that commands and sets the mouse on screen. Also, I don't have if you have experimented with the "collect star" 0X0C calls, but if you use all of them on an object, the model of that object will be replaced by the star. That is interesting, because so far this is the only case of an 0x0C I found that actually changes the model. As for the 0x08 command, I don't think we are talking about the same thing. I'm talking about the 0x08 command before 0x0C calls you found in the behavior scripts (check VL-Tone's reference file), while you are probably talking about the 0x08 inside the 11 01 right? From what I gather, the 0x0C calls inside a 0x08 "loop" constantly update the objects information, and you can do interesting things with this (I'll talk about some experiments I've been doing in a later post). >yoshiman: From what I've seen, every object has a pointer to the behaviour script for initialization and then two more (often the same values) that point to a position in the behaviour script to be called often, usually a 0x0c call as to update the object. The first pointer to script initialization is probably set by the 0x24 level command, like the ones I posted in my other post. It is the relative offset position of the behavior start in the behavior bank (0x13). Regarding the other pointers, I'm not sure. Could you post some examples? There are behaviors who use 'jumps' in the data, as this saves space for minor behavior changes, but these are very few and probably not what you mean. --- I found the "parameters" indexes! Whomp King Behavior is the same as regular whomp's, except for this: 10 2F 00 01 <--- 2F = sets parameter 1 -> 1 10 3F 00 03 <--- 3F = sets paramater 2 -> 3 This has the same function as the parameters bytes of the 0x24 command. I guess this just shows again how patchy SM64 is! King Bom-omb uses this "internal" set parameter command: 10 3F 00 03 <--- parameter byte 2 I tried changing this to other values, but didn't noticed any different effect. --- Here is why the "TH Island Top Trap Behavior" 0x0C call also produces the "solid" behavior: void func802A6CF4() { [...] goto pc803839CC; [...] }

messiaen Catgirl Level: 68 Posts: 65/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-02-08 09:50:41 AM, in Brainstorming ideas for Mushroom Battlefield (last edited by messiaen at 05-02-08 06:57 AM) Link

This looks nice . It's doable, and indeed VL-Tone already tried doing a bit of this on Bob-omb's Battlefield. (Video). With Flatworld, however, you could set a very narrow terrain and with good scaling the result would be very nice. However, let's focus on entirely original designs/ideas. Another possible object to use is the tilting bridge from Bob-omb, probably as a static object connecting some floating platforms. There is, however, something that bothers me. Both the tilting platform and the grass platform are solid, but their solidity data is neither defined by a 0x2A behavior pointer or in terrain collision. I remember reading somewhere that 0x43 objects do have some different kind of collision pointer, and even though the bridge is a 0x24 this may be related. As a last resource building anothet set of collision for these specific objects won't be very dificult. I'll see if today I can further deconstruct the geometry of Bob-omb. One of the "polygon layers" holds most "objects" and finding specific locations for these won't be difficult, I'll just feed TT64 with the geometry jumps of that specific "polygon layer". If other people are willing to help, we can do a entire polygon pointer map of the Bob-omb level, at least for the most discernible objects, but this should be done probably in another thread .

messiaen Catgirl Level: 68 Posts: 66/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-02-08 10:51:50 AM, in SM64 RSP Commands (last edited by messiaen at 05-03-08 07:16 PM) Link

I found this very useful bit of information by Cellar Dweller about commands 0xB7 and 0xB6: --- SetGeometryMode and ClearGeometryMode are 0xb7 and 0xb6 respectively. There are no parameters in the first 32 bits. The lower 32 bits contain the flags that are to be set or cleared. 0x00000001 - use Z buffering 0x00000004 - use shading 0x00000200 - enable smooth shading(otherwise use flat shading) 0x00001000 - cull front facing triangles 0x00002000 - cull back facing triangles 0x00010000 - enable fog 0x00020000 - enable lighting 0x00040000 - generate texture coords using the normal 0x00080000 - generate texture coords (not sure how this works) --- Searching Google for info I found this Mupen RSP_GX plugin source. In the beggining of the code there is a list of RSP commands. The 0x40000 flag seems interesting, maybe I can use this to generate better texture coordinates for custom geometry. I searched for the ROM and it is used a few times, so I may investigate further. The 0x800000 is never used, maybe it only works with newer games/RSP version?

messiaen Catgirl Level: 68 Posts: 67/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-03-08 06:23:27 PM, in Brainstorming ideas for Mushroom Battlefield (last edited by messiaen at 05-03-08 04:16 PM) Link

Like I said, I'm focusing on a original level I hope to achive some good balance between interesting puzzles - some of them created by heavy behavior editing -, exploring things around and maybe some difficult jumps for one of the acts. One thing I fell like implementing is the "bring" the key to the lock from Super Mario World. Maybe this would give more sense to some difficult jumps, I'm really not a fan of sheer difficulty and there are other mods that explore this very well. Another one is possibly some fake walls', actually polygons without collision, or maybe just one side collision (you can get in but you can't get out), creating some secret areas. Keep coming with ideas!

messiaen Catgirl Level: 68 Posts: 68/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-04-08 06:13:36 PM, in Brainstorming ideas for Mushroom Battlefield Link

That is a good idea, but it would require a lot more research on water. Right now I feel more like working on implementing a underground area and/or "cave" on the level. I don't think it is possible to switch banks, so maybe the cave idea is easier (the entrance would be the warp tunnel). I'm trying to bring the Yoshi model into the level (I'm creating a custom behavior for him), but so far it didn't work. I checked the loaded banks and there seems to be nothing wrong, but I have to look further if he uses some specific level bank pointers (from the Castle Grounds). Since everything will be movable collision, once the hex editing is done it will be easy to create the actual level, so I may create a little hack with two or tree levels. One idea I have is to replace the castle grounds for something a bit different, such as a forest with warp pipes that lead to the levels. I guess this could be made by changing more of the 0x10 level bank pointers and/or some of the jump condicionals of the main level script.

messiaen Catgirl Level: 68 Posts: 69/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-05-08 11:35:14 AM, in Brainstorming ideas for Mushroom Battlefield (last edited by messiaen at 05-05-08 08:39 AM) Link

I haven't played Super Mario Sunshine - in fact, my last Mario game was Mario 64! - but I absolutely loved your idea, as it may bring some innovative gameplay into the level. It could be implemented in one of the "indoor" areas. I will test how the Koopa Shell behave in some collision terrains, the idea is that if you lose it you die. The race could have a lot of moving obstacles/jumps and the terrain will be very narrow horizontally, like a slide level. I guess playing again NES Battletoads Level 3 will give me some ideas! I'm experiment a bit with the 0xB7 set geometry mode command, and I had also the idea of creating a limited time maze puzzle. Basically you step on a "!" switch and culling settings will change for all 0x24 objects, unveiling a hidden path of fake walls. Too bad my time will be very limited for the coming weeks, I really needed a full day on SM64 to experiment more.

messiaen Catgirl Level: 68 Posts: 70/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-05-08 09:37:12 PM, in Brainstorming ideas for Mushroom Battlefield (last edited by messiaen at 05-05-08 06:43 PM) Link

This is an important issue, but I'm not very worried by it. So far, I know two ways to control drawing/disappear distance: in the geometry layout, which sets global properties for a model and in the behavior, which may override those global settings for a specific object. Unfortunately, N64 has its limitations so I can't set them all of them to maximum vales, otherwise the level may get too slow. I should test more with this, because my mushroom platform uses twice as many polygons as it really needs to. Choosing the most important objects will be one of the last decisions, because if I need something to show up all the time, I may hard code it in the level terrain/collision data. If I don't leave too many blanks spots in the level, this will hardly be a problem, because there will be always objects drawn on screen and you will never get the "emptyness" effect. Now that you mentioned red coins, I will study the geometry layout/behavior of this, because these objects can be viewed from very far. Maybe there is some command besides the ones I know that set this, so this could be useful for important geometry.

messiaen Catgirl Level: 68 Posts: 71/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-08-08 11:27:33 AM, in Brainstorming ideas for Mushroom Battlefield (last edited by messiaen at 05-08-08 08:42 PM) Link

Some of these ideas are probably too hard for now, but don't refrain from posting them. Behavior editing is surely limited, but I believe there are several cool things you can do with it. My idea for the Koopa was not exactly a race, but something inspired by the SMW World hack "Brutal Mario". In that fantastic hack, there is a level where you have to catch Yoshi (you can find it in the "Features Hacks" section of SMW Central). I tried to implement this by making Koopa-the-Quick just wander around Flatworld in 2x speed (that's HARD to catch, but not impossible) and when you kill him you get a star. However, I think I did not make the right choice concerning the code that gives you a star when you kill him, because his animations became glitched and he almost didn't move. I will try later something different, there are behaviors commands that spawn "sub-objects" so I may try something related to this. And just a little update on getting geometry from levels: I managed to get that Warp Tunnel fom Bob-Omb as a separate object, but now there is another step towards making it fully usable. Unlike 0x24 objects, level terrain vertexes are absolute, not relative. That is, if a place that tunnel at (0,0,0), it will be drawn exactly on the position it was on Bob-Omb Battlefield. I need to convert all vertexes so that it is centered at (0,0,0). This is probably simple, I just didn't spend time yet thinking the math side of it , or if I should get a 3D program that could make this for me. I'm also looking more at the drawing/disappear distance problem Me-Me talked about. Even with maximum values, this could be still a problem when you go to the edge of the terrain. I'm curently trying a few things to overcome this problem: 1 - Looking at the specific behavior of objects that can be viewed from VERY far (red coins, stars). 2 - Looking at the level terrain Geo Layout. After all, level terrain is yet another object called by a 0x22 pointer, maybe some of the Geo Layout code determines that it is drawn all the time (no success on this yet). 3 - "Special 3D objects" such as bowsers platforms can be viewed just like level terrain (no drawing distance limitations). However, their collision is not movable and these commands are not very documented, but maybe this is worth looking, IF they have 0x22 pointers. ---- New video! This is the custom Koopa behavior. Can you catch the star? <object width="425" height="350"> <embed src="http://www.youtube.com/v/85DxCZvCEdk" type="application/x-shockwave-flash" width="425" height="350"> </embed> </object> This is the same, combined with a new FIXED camera behavior. This is still very experimental, and it basically uses a function to interrupt the camera I tracked with the Nemu disassembler. If someone knows how to change the initial camera setting, so that the camera starts very far from Mario, this could be very useful to create a "minigame" inside M64. <object width="425" height="350"> <embed src="http://www.youtube.com/v/lUenNm1l2Ig" type="application/x-shockwave-flash" width="425" height="350"> </embed> </object>

messiaen Catgirl Level: 68 Posts: 72/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-09-08 11:29:27 AM, in Experimental Platform Battlefield v0.4 RELEASED (Mac patch included) (last edited by messiaen at 05-09-08 08:33 AM) Link

Some things to check: 1 - Did you patch this to a Super Mario 64! (U) extended ROM, without Flatworld enabled? 2 - Did you delete the M64GeometryDataFlat.m64 file and opened the patched ROM again ? This will force TT64 to decode all the polygons from the game, and if you don't do that you won't be able to see the blocks. 3 - Some people on MACs couldn't use these patches even with the same original ROM as me. Quoting VL-Tone: "I just realized that the Windows version of the ROM extender produces a different output than the Mac version. The Mac version fills the empty spaces after the first 8MB with "FF"s (as planned). The Windows version, for some obscure reason, is padding with "01"s instead..." This could be reason for this. Actually, also for some obscure reason I used a bit of "FF" bytes to fill some empty spaces in Bank 0x0E, I may try changing these to "01" and see what happens for Mac users. If there is still interest on this, I may release a third version with a fix for the "goomba" problem, some extra blocks for re-texturing and maybe fixed texture coordinates. Linkin800: I'm curious to see how did you overcome the texture problem. Could you post some screenshot?

messiaen Catgirl Level: 68 Posts: 73/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-10-08 01:42:09 PM, in Brainstorming ideas for Mushroom Battlefield Link

Areas probably won't be an limitation. I looked at the "Cool Cool Mountain" Level script and it it seems all I need is to make two sets of Level Terrain/Collision/Terrain Geo Layout/items/warps delimited by specific "Start' and "End" area commands. The "entry point" is the same for both areas. I haven't tried implementing these yet, but even if TT64 doesn't recognize my areas, there area always ways to trick it , such as creating a temporary entry-point for the second area and changing one of the "Level jumps", so that when I open Whomp´s Fortress Level, I'll get the second area of my level). Your snow/lava idea is way too hard. because I can't load both textures set at the same time (look at the Textures thread and you'll see I posted a list of the texture sets used). However, the idea could be somewhat applied to a grass/desert settings, to get different "seasons" inside a level. That could be a interesting theme to explore. I don't think a dungeon (this idea didn't came from me) would fit my level, I'm thinking more about a mountain interior or something else which I won't talk about, because I don't want to spoil everything .

messiaen Catgirl Level: 68 Posts: 74/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-11-08 01:34:56 PM, in Behaviour Scripts Link

Hi VL-Tone, thanks for your kind words on some threads. From what I have done so far, I have the felling that an integrated behavior would be such a nightmare to design! Is it worth the trouble? I am even thinking about the possibility of using the Bank 0x07 to store level-specific behaviors for my custom level, because I may ran into problems when extending Bank 0x13 too much. I have been experimenting with Nemu's disassembler and reading a few ASM tutorials, and I think that with some simple modifications we can get interesting effects. For instance, supressing a few traits of a specific behavior. Also, by comparing the codes we can find some shared functions (JAL calls triggered by conditionals), which could be used for "frankenstein" behaviors.

messiaen Catgirl Level: 68 Posts: 75/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-11-08 02:16:04 PM, in Brainstorming ideas for Mushroom Battlefield Link

weckar: There is the possibility of importing/inserting new textures, and that's what I did to get the mushroom texture on the level without changing the loaded Bob-omb/Shifting Sand Land. Your swamp idea is very good. In fact, I may change the "Terrain Type" of the level to the one used in Shifting Sand Land to accomplish that. Thinking about it, this kind of collision can be used for the "Koopa Shell" racing. RJWaters2: I have to play that level again to remember how Ukiki is used in the game, but I think the Little Penguin/Mother behavior will be used for that.

messiaen Catgirl Level: 68 Posts: 76/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-11-08 06:37:26 PM, in Experimental Platform Battlefield v0.4 RELEASED (Mac patch included) (last edited by messiaen at 05-11-08 06:57 PM) Link

Actually, this is a different project than the "Mushroom Battlefield" level, which I won't release before ready. Like I said before, if someone wants to use this "Platform" Battlefield as a "template" to their own level, feel free to do it as long as you give me some credits. I just have to do a bit more testing on this before I release the "Goomba" fix. I'm not sure if some other objects (such as King Bob-omb) will work, but it would be nice if someone could test it. Also, I'll include the "Warp Pipe" model and the "Solid Pipe" Behavior. Edit: I did some tests, and the problem was not related to the level collision, but to the platform behavior. It seems that I need to set a RAM variable for other objects to recognize the solidity of the platform.

messiaen Catgirl Level: 68 Posts: 77/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years	Posted on 05-11-08 10:17:34 PM, in Brainstorming ideas for Mushroom Battlefield (last edited by messiaen at 05-12-08 08:34 AM) Link
	There are memory limitations and possible conflicts between banks which use the same ID, so you won't be able to load everything at once. Edit: This post was too confuse, so I just left the essential .

messiaen Catgirl Level: 68 Posts: 80/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-12-08 04:48:50 PM, in Brainstorming ideas for Mushroom Battlefield (last edited by messiaen at 05-13-08 09:37 AM) Link

I'm experimenting with some types of collision which affect the initial camera setting in order to get a interesting fixed camera angle. Now this is a beautiful image of the Bob-Omb background: Edit: Another screenshot, this one showing 0x24 objects viewed from the very edge of the terrain. I don't know how this may affect the peformance, so far the level is OK but there are still less than 50 objects in it. Most likely, there will be some balancing to do as the N64 hardware is very limited.

messiaen Catgirl Level: 68 Posts: 81/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-12-08 11:24:01 PM, in Behaviour Scripts (last edited by messiaen at 05-12-08 08:27 PM) Link

Too bad I can't seem to open the extended ROM on Nemu. Is this happening with other people also? It would be a good idea to update the Behavior document, because a lot of the behaviors called "unused" are actually used by sub-objects. For instance, the behavior at 0x0254 is used by a sub-object created by Bob-Omb. The same happens with the Waving Koopa Flag. No mater what model you place with the Flag behavior, the Waving Flag itself will be created by this command: 29 00 00 00 00 00 00 6A 13 00 45 F8 6A is the Waving Flag Model, as defined by the 0x22 Geo Layout pointer and 45F8 the behavior pointer. Now the star behavior is another case, because the fixed model is actually hard coded in the ASM. By the way, here is the JAL call inside the star behavior which stops the camera: 8029000C. I was also looking for other very common JALs which are shared by a lot of objects (inside the ASM, not in the behaviour code) and these are some adresses I found: 803839CC 80383BB0 80383CB4 80383D1C Now the 803839CC we already know as the "solid" one and it works along with the 0x2A collision data pointer. What could be others? These could be very general effects which could be directly linked to the behavior 0x0C command, creating more possibilites without modyfing the coding itself. Also, to throw yet another variable in the behavior maze: the first 4 bytes of each behavior define some kind of general attributes. Used values are 04, 05, 06, 08, 09, 0A, OB and 0C. The behaviors which start with the "00 0C 00 00" usually consist of a few "set RAM variables" followed by a 0x0C call. If you set, for instance, the first bytes of the "Koopa Behavior" to this, he won't be able to interact with you, nor his collision sphere will work.

messiaen Catgirl Level: 68 Posts: 82/1085 EXP: 2596326 For next: 132474 Since: 11-20-07 Since last post: 8.1 years Last activity: 7.2 years

Posted on 05-13-08 01:45:10 PM, in Half-Precision Floats to Hexadecimal ? Link

Hi, could someone point me to a program which converts Half-Precision (16 bit) Floats to Hexadecimal? I searched Google and could not find any program for this kind of operation. This one can convert decimal to 32 and 64-bit floats and give the result in hex, but won't output it in half-precision. I am searching this to be able to do correct texture coordinates on N64 and understand better values stored in floats.