Register - Login
Views: 99798775
 Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies 		05-03-22 06:12:25 AM
Jul - Posts by VL-Tone
Pages: 1 2 3 4 5 6 7 8 9 10 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 427/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 04-08-09 03:37:41 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 04-08-09 12:39 AM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by wwwarea
Umm, I went back to page 7th and he said it will be release at the 15th... He marked out 7th and put it to 15th.


Well... hmmm... yeah... Sorry again.

I'll have 4 days off next weekend (from saturday to tuesday) because of Easter, so I thought it would be much more logical to finish it over the weekend release it just after that. Besides, messiaen just gave me the code to patch to enable extended RAM use (but don't blame him for the delay, I didn't exactly put any pressure on him to give me the code earlier).

Now, there's one thing that didn't help with the delay, is that I don't know exactly how to deal with a particular feature of the importer. Maybe you guys could help me figure out the best way to implement it.

Note: it's a very complicated problem that's hard to easily explain, and that's essentially why I stumbled and stopped working on TT64 two days ago, trying to find a viable solution...

Here's my problem:


When you want to change any parameters, or import an updated version of the .obj polygon file, the whole level data will be deleted and re-created. To avoid losing all your level objects (0x24 objects for example), I thought about having the 0x24 command list optionally saved so that when you "re-create" the level you can keep the existing objects. There's already a planned feature (which almost fully works now) which enables you to save to and load from a "level file" which will contain all the polygon importer parameters (scale, offset, terrain type, bank selections) and will also include the .obj data and the texture data inside the same file. So I planned to also include in the level files the 0x24 commands, which will be nice since a level file can be used to recreate the exact same level in a different ROM.

Here's the problem with that approach:

It's all about when the 0x24 objects should/can be saved to the level file. Logically, when you press "Save Level File" all parameters AND the 0x24 will be saved into the currently open level file. But 0x24 editing happens in the main level editor window, so you'd have to go back and forth between the importer and the editor to save anytime you make a change. Unless I add an option to automatically save 0x24 commands to the level file when the ROM is saved (either by pressing the Save ROM button, or with the auto-save option).

That's all fine, when the level you're editing happens to be the one that was created using the currently open level file (only one level file can be open at a time, and the "create/save level to ROM" button will create the level in the currently selected slot, replacing the currently selected replacing level). But what if you try to edit another custom level for which you don't have the level file open? Changes to 0x24 commands wouldn't be saved to the level file unless TT64 tracks where are the level files for all the custom level slots in a given ROM. One way to do that would be to save the file path of each one in the "File table" list that TT64 will be writing to the ROM.

But I really dislike the idea of having your ROM dependent on the path of multiple files possibly scattered around your HDD. What if you move one of the level files? It's simply too much things to track down and it complicates the process needlessly.

To avoid these problems entirely, the best thing is to use the existing 0x24 commands found in the ROM if you want to keep them when "re-creating" the level when importing or changing importation parameters. But if I only give this option, you lose the very useful feature of being able to use a saved level file to re-create the same level in multiple ROMs, mixing and matching levels if you want. It would be especially sad not to include the ability to save 0x24 objects to the level file when it contains everything needed to re-create a specific level.

My solution involves having three option when saving a custom level to ROM:
1. "Keep objects from ROM"
2. "Use objects from level file"
3. "Use empty objects".

Since option 2 would now only be really useful when wanting to move a level from a ROM to another, I guess I could let go of all the auto-save problems and only save the 0x24 objects to the file when the "Save level file" button is pressed. Still, there could be a problem where you'd import a level, go edit the 0x24 objects, save them to the file, go back to the editor, edit 0x24 objects in another custom level slot, and comming back to the importer to save, without realizing that you'd only save 0x24 objects from the last imported level into the last open level file... Saving the 0x24 objects to the previously imported level would require re-opening the right level file.

Ultimately, a solution to all these problems would be to use a single file for all levels of a given ROM, instead of one file for each level. But it would change the whole paradigm of the current importer, and I would have to create another complex interface to individually manage levels found in that file (to enable you to mix and match levels from multiple files into a single ROM). Furthermore, this single "levels file" could end up being relatively big, especially with the additional space that the extended RAM will provide.

Originally posted by luigiman1928
I have a suggestion for the Importer. Why not add the feature of adding Your own texture!

I'm not sure if that's what you're suggesting, but it was already planned to work like that. You'll have to import your own texture in the level importer interface.

____________________
(post in restricted forum)
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 429/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 04-10-09 05:41:40 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Ok since nobody here seems to be able to help me with my problem (probably because of my overly complicated explanation), I'll take a decision.

I'll keep the one file per level format, and 0x24 objects will only be saved to the level file when you press the "Save level file" button. Users will be responsible of having the corresponding level file open if they want to copy changes made to the 0x24 objects in the level file. Like I said, this feature will only really be useful if you want to copy a custom level to another ROM.

If you only want to update/change the polygon data or other importation parameters while keeping the original objects, while keeping the 0x24 objects currently in the custom level, the "Keep objects from ROM" option will be the best (and default) choice.



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


Posts: 430/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 04-13-09 01:18:17 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by messiaen
Once the first importer version is released it will be easier to give feedack on this, I suppose. It doesn't seems like this 3 options ("Keep objects from ROM", "Use objects from level file", "Use empty objects") will be overly complicated. However, wouldn't it be easier to make TT64 work straight with inidividual level files and have a "commit level" to ROM button which would ask then what level is to be replaced?

Anyway, modularity is a big plus and will be a nice way to work on team hacks, so I think you should discard having all the levels on a single file. Let the users manage their own mess .


That's exactly how it works now and how it was planned from the start. Each custom level has its own level file.

The only difference with what you suggested is that choosing the level slot and which level is replaced is done before clicking on the "Create and save level to ROM" button, instead of TT64 asking after you clicked the button.

I only considered having a single multi-level file as a solution to the problem of keeping the 0x24 objects in the file automatically in sync with those in the ROM, but I decided to continue with my original plan of having one file per level.



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


Posts: 431/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 04-15-09 03:38:08 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Stevoisiak
Just for a future refrence, try to avoid deadlines.


Yeah, I should've avoided setting deadlines for TT64 v0.6b...

Now, for you impatient lurkers, I'll try to release something before tomorrow (though it may be released around 4am EST), but it will be more than probably incomplete and buggy. This version will be clearly labelled as an "Alpha" version, probably as 0.6a1, and with "Alpha" written over the splash screen and logo, subsequent alpha versions will be 0.6a2, 0.6a3 etc. until it reaches the beta state (0.6b).

At least, you'll be able to try the interface and give me some suggestions and bug reports.


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


Posts: 432/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 04-16-09 02:53:54 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Stevoisiak
Well, one thing is with games, when they set a deadline, they have something playable when deadlines are announced. Sure they may not be able to put some things in by the deadline, but they have a releasable game.


Well, one thing is with these games, is that they cost money.


Anyway thank you for your "kind" words Stevoisiak, I'm out of here until I release v0.6b and I won't tell you when I get back, since there's no deadline anymore.

Bye bye.

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


Posts: 433/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 04-17-09 12:45:17 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Ok...

Calm down everyone...

I'm sorry to have created this drama. I just had worked 13 hours straight, and I had a very stressing work day yesterday. This comment by Stevoisiak just tipped me over the edge.

That being said, please don't tar-and-feather Stevoisiak and leave him alone about this. It was certainly not a nice thing to say from him, but I had my faults myself, and I certainly understand why some were a little angry after three missed deadlines.

So, I'm not gonna leave, and I'll keep you updated about TT64's progress, but no more deadlines. I will probably be out before the end of the month, but maybe not, I won't commit to a date.

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


Posts: 434/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 04-18-09 02:46:45 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 04-18-09 11:48 AM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Raccoon Sam
I don't really feel like skewing through 10 pages, so here's a few questions:
-What models am I able to overwrite with my OBJs? Only the level sceneries or enemies and objects as well?
-How is the texturing handled? OBJs don't parse the textures into the file, and even if they did, I don't think that's how the N64 handles them. Would it be better if I did a textureless model and applied textures in TT64 (assuming that's possible)?
-How are surfaces handled? Can I assign surface types to certain faces, like 'auto-slide', 'sand', 'metal', 'walkable regardless of angle steepness', etc?

Thanks in advance.


-In version 0.6b you'll be only able to import .OBJ files into the level sceneries. Importing into individual objects will be much more complicated to implement, as it will require creating new types of behaviors that can support independent collision maps ( solid independent objects require a pointer to a collision map inside the behavior script). Version 0.7 will support importing into enemies/individual objects.

-In version 0.6, there will be only one texture per level scenery. The texture will be imported manually into TT64 and will be saved into the .T64 level file. You should still create textured .OBJ files as texture coordinates will be required. Version 0.7 will enable importing models with multiple textures using .MTL files (which are texture/material files used by textured .OBJ models, which themselves point to .jpg, .gif or .png files). But since 3d programs sometimes have weird/different handling of textures for .OBJ files, version 0.7 will also have options to override and assign textures to groups, models and even down to the polygon level.

-Version 0.6 does include a pop-up menu to set the surface type of your whole level. Version 0.7 will be able to set multiple surface types down to the polygon level (just like textures and other parameters).




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


Posts: 435/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 04-18-09 07:25:51 PM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 04-18-09 04:28 PM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Gecko
The usage of one texture will open us the doors to sand, ice, slide or grass levels, for example.

I wonder if one will be able to distinguish geometry inside the level when only one texture is used. Does the engine create shadows?

Is the light source always the same or does it vary from level to level?
As far as I remember, the clock level uses fog. Have you found the corresponding level flag?

I think the question regarding creating new painting-level-entrys has already been asked, I'll probably recheck the thread.


The engine doesn't create real shadows by itself, but it does create live shading with a light source. And don't confuse the two: "shadows" are the dark areas projected by objects in the opposite direction as the light source, while "shading" is the fact that objects themselves will be less dark on the side of the light source. There are shadows in the game (such as under the bridge), but these are "baked" right into the level geometry and not generated live.

Fog is indeed used in some levels (including Bob Omb Battlefield), for now it will be turned off in custom levels in v0.6, but I'll probably add a way to turn it on or off in version 0.6.1 or so, as well as other global level parameters.

Creating new painting entrances would indeed be too much complicated as I explained, but you could create a hub level that would replace the castle, and use warp pipes and other kinds of warps to get to your levels. You'll have to be careful then to modify the exit warp (death or success) in your custom levels so that they point at exits in your hub levels instead of inside the castle.


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


Posts: 437/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 04-19-09 08:25:28 PM, in Super mario 64 war (last edited by VL-Tone at 04-19-09 05:26 PM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
lukas0075...

Did you read the FAQ?

And in case you missed it, you must get permission from VL_Tone or Metal Man before you can make a thread about an individual mod/hack. First, you'll have to demonstrate, by showing your mod in the dedicated thread http://jul.rustedlogic.net/thread.php?id=436 that your mod is worthy of having its own thread.


Did you get permission? No, then sorry I'll have to close this thread, and it will be soon deleted.

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


Posts: 438/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 04-19-09 08:30:01 PM, in Super mario 64 Mario can throw fireballs Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by lukas0075
hello the is link for video on youtube mario can shoot fire ball
http://www.youtube.com/watch?v=FVUgEl8roUQ
How to make mario shoot fire ball how to please help me !
:l


It seems that you didn't read the FAQ...

This hack was created by one of the members here (messiaen aka frauber), and was already posted here, where it belongs, in the MODs thread.

This thread has no purpose and will be closed and deleted soon.

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


Posts: 439/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 04-19-09 08:35:45 PM, in help me in super mario 64 war (last edited by VL-Tone at 04-19-09 05:39 PM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by lukas0075
Hello i have problem in toad tools
1 how to import music for game
2 how to make new objects on map
3 how to make new main screen in toad tools
PLEASE HELP ME !!!!!!!!!!!


You want help?

How about posting in the Toad's Tool 64 help / how-to? Don't you think it makes more sense?

This thread is closed and will be deleted soon.

lukas0075: In your first day here, you managed to post 4 threads that will be closed and deleted. You'll be welcome here, but only if you follow the rules. If you continue posting useless threads and not following the rules, there will be consequences (which will probably include a ban).




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


Posts: 440/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 04-19-09 09:30:54 PM, in Post your SM64 mods, patches and screenshots here! (NO ROM LINKS!) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Wow that's really nice Racoon Sam!

In terms of polygon count, the spiral slide level I made had 265 polygons and the game didn't show any signs of slow-downs. The reason I stopped there is that I was running out of RAM. But with extended RAM support built-in 0.6b, we'll have more than 10x RAM available per level. That being said, the N64 engine might slow down with too many polygons on screen. I would try not to go over 400-500 polygons in your whole level before we can experiment further, keeping in mind that it's a total guess, the N64 may well be able to display 2000 polygons levels without slow-downs.

As for water, I thought I wouldn't have time to add support for it in 0.6b, but since there's no deadline anymore, I'll try to implement it.




____________________
(post in restricted forum)
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 442/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 04-20-09 04:01:41 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 04-20-09 01:02 AM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by thatisnotedible
I don't mean to sound annoying or mean, but should we remove the "(Coming in April)" from the title, since there is no longer a deadline?

(It's like an OCD thing, if you know what I mean. =P)


Ok it's done...

On a related note...

Tonight I did something I was planning to do a long time ago but thought it would be too much work, which is integrating the SM64 Text Wrangler into TT64. The move went well, and I can already tell you that v0.6 will include the built-in Text Wrangler.

Why did I do that instead of working on the polygon importer? Well it's related because when you'll import your custom level, you'll surely want to give it a custom name, and same goes for the Act names. So instead of having to fire up the Text Wrangler, open the same ROM, then find where the level and act names are and modify them, you'll simply do it directly in TT64. And while you'll have access to the plain old Text Wrangler inside TT64, you'll also be able to modify the level and Act names for the custom level directly in the importer module interface.

And starting with v0.6, TT64 will display the real ROM level names in the main editor page (in the level select menu for example). You'll also be able to call up the Text Wrangler directly when editing a behavior that includes a "Dialog" parameter, so for example, you'll be able to select a Toad, then click on "edit" and edit his dialog text without having to search for it in TW.




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


Posts: 443/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 04-21-09 01:57:01 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 04-20-09 11:37 PM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Gecko

Thank you for taking the time to answer my questions!

I understand what you mean and those baked shadows always looked darker than everything else in the game.

Do you know if the fog changes anything enginewise, e.g. allowing more geometry to be used because it adds vis-blocking? Visibility blocking refers to the engine not drawing level geometry behind a certain distance such as the object vis-blocking (objects will pop up when you reach a certain distance).
Is there vis-blocking when creating two rooms which are completely seperated from each other or is the level geometry always fully drawn?

You told us that your spiral level almost reached the engine limitations. I've been creating maps for the half-life engine which has a lot of limitations and there you have to possibility to lower the number of leaves by upscaling the texture.

On this picture every square resembles a leaf.
If you scale the texture up or down, the leaf also becomes bigger or smaller. The more leaves there are, the more often a texture gets repeated and the more hardware ressources are used resulting in reaching engine limitations when a texture often gets repeated/when there are many textures and texture recurrences drawn.

This would usually mean that you aren't able to create huge levels, but look at Banjo-Tooie for example. Rare created huge levels by scaling textures up, maybe it's also possible with Mario 64.
There are some maybe unwanted texture recurrences in your spiral map. If you look at 1:58 in the video, you'll see that the texture is scaled down. If you're able to scale it up again, you will maybe be able to set some more polygons free. Additionally, you could scale the texture in the whole map up in order to free up polygons if this experiment worked.

Does Mario 64 have a debug menu? Maybe there would be a subitem showing you how many polygons are drawn helping you with the engine limitations.


The spiral level reached a RAM limitation, not an engine limitation. But since then, thanks to messiaen, I added support of Extended RAM in v0.6b and the limitation will become more about the polygon draw speed than anything else. I haven't tested what would be the limit without having that RAM limitation (because the importer is not fully functional at this point), but it should be higher than what the un-extended RAM allowed.

The texture system you describe is simply not practical using the standard polygon drawing micro-code in Mario 64. The main problem with the N64 is the very small texture cache, which is only 4k (only enough to store a single 32x64 texture at a time).

For Banjo-Kazooie and Banjo-Tooie, Rare completely bypassed the standard N64 drawing libraries with custom micro-code and found some work-around for the small texture cache, and doing the same with Mario 64 is not realistically feasible.

As for polygon count in existing levels, it should be trivial for me to count them using TT64...

Edit:

Here's the polygon count for almost every level according to TT64. It includes polygons from objects found in the level and not only the level geometry. 

 Haunted House        : 21831*

 Cool Cool Mountain   : 3828 

 Inside Castle        : 18658*

 Hazy Maze Cave       : 22521*

 Shifting Sand Land   : 5022 

 Bob-Omb Battlefield  : 8246 

 Snow Man's land      : 2984 

 Wet Dry World        : 3352 

 Jolly Roger Bay      : 5310 

 Tiny Huge Island     : 9154 

 Tick Tock Clock      : 4141 

 Rainbow Ride         : 6700 

 Castle Grounds       : 4028 

 Bowser 1 Course      : 5081 

 Vanish Cap           : 1092 

 Bowser's Fire Sea    : 3100 

 Secret Aquarium      : 424 

 Bowser 3 Course      : 5317 

 Lethal Lava Land     : 2356 

 Dire Dire Docks      : 1464 

 Whomp's Fortress     : 3832 

 Castle Courtyard     : 1826 

 Peach's Secret Slide : 2152 

 Metal Cap            : 1963 

 Wing Cap             : 954 

 Bowser 1 Battle      : 6394 

 Rainbow Clouds Bonus : 4196 

 Bowser 2 Battle      : 6466 

 Bowser 3 Battle      : 6664 

 Tall Tall Mountain   : 6141


*The Haunted House, Inside Castle and Hazy Maze Cave have much more polygons because they're using a "room" system, which only display the room Mario is in (and sometimes, other connected rooms) instead of the whole level at the same time. Doors are used to trigger the room set changes.

Here's an early animation I made of the Haunted House rooms:



Note also that these poly counts don't include sub-areas.


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


Posts: 444/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 04-23-09 02:37:48 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 04-22-09 11:39 PM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by BigBrain
Originally posted by "VL-Tone"

*The Haunted House, Inside Castle and Hazy Maze Cave have much more polygons because they're using a "room" system, which only display the room Mario is in (and sometimes, other connected rooms) instead of the whole level at the same time. Doors are used to trigger the room set changes.

Would this room system be non-trivial to add support for in TT64 once you've added the possibility to load more than one model into a level? Sounds just like some command which is called by the behavior scripts of the doors to me, so it seems to be pretty simple, but on the other hand I know nothing about ROM hacking


Well I'm still not sure how it works. I once understood how the hierarchy of room sets was working (actually, a very early unreleased version of TT64 had some widget to choose which room set to display), but I never found how the game switched between them. I thought it was doors, but its not.

You can make this simple experiment in the castle: remove all doors (except the front doors) by moving them out of the way. When inside the castle, you'll see that other rooms appear black until Mario gets close to the door.

The thing is, there's no special collision floor there to detect when Mario is in front of the door. And it's not simply a matter of Mario being close to the other room, because you'll see that you can make the other room appear when being in front of the wall, but only when you are close (left or right) to the door. So there's something that triggers the room change according to proximity, but not to the whole room, but rather a single point in space.

Another thing that's triggered by something unknown, is the camera modes inside rooms when you crosse the door frame. For example, in the castle lobby, the camera is fixed, but as soon as you crosses the door frame, it changes to a non-fixed camera.

Now that I think of it, the room change triggers coordinates are probably at the same place as the camera mode change triggers, and it would be very very useful if we could at last find where they are, as they will cause problems in certain levels being replaced by custom geometry. I tested flatworld replacing other levels, and there was some crazy unexpected camera mode changes happening when using levels like inside the castle and haunted house.






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


Posts: 445/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 04-25-09 03:35:22 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Seeing all the nice level models people built, and how some of them would need multiple-textures, I began to think about how I could easily add multi-texture support in 0.6b...

What I realized is that it wouldn't be that hard. I had big plans for 0.7b so you'd be able to manually set textures to groups of objects and even to the polygon level, right in TT64. The idea was that I wanted to avoid using the .mtl file and external texture files that come with them, simply because there's too much variation on how these are generated by different 3d programs (some use relative file paths for textures, some don't, and they use different types of bitmap textures which TT64 can't all import, and some programs have broken/insufficient support for .MTL files).

But in my planning to avoid using .MTL files, I overlooked a simple solution that doesn't require a complex interface to manually assign textures to groups and polygons inside TT64...

OBJ files use a command called "usemtl texturename" to specify which texture to use for the following faces found in the file. The texture name in the usemtl command is pointing to a set of material parameters in the external .MTL file which also includes the texture file path. What I could do is simply ignore the .MTL file, but still use the usemtl commands found in the .OBJ command.

TT64 would list the texture names found in the .OBJ file, and offer to associate each of them with a 32x32 texture which would be importer right in TT64. When building the N64 polygon draw list code, it's simply a matter of inserting a "texture change" sequence of commands to switch the texture for the following triangles.

Overall, it wouldn't be that hard to implement. The hardest part would be to conceive the interface for the texture list. And to avoid having to create some pop-up menu interface, I would ideally need to extend the width of the importer's interface to 1024 to add the texture list on the right side.

When I first released TT64, a few (very few) people still had 800x600 monitors (laptops) so I always tried to make the interface in these, but hey we're in 2009... If you don't have at least a 1024x768 monitor, well just too bad.

Now the texture list interface in itself is not that complicated to do. The texture associations would be saved in the .T64 level file along with the other parameters. To keep things simple, there would be a fixed maximum number of textures (maybe 12 or 15, what do you guys think?) per level. The complex stuff would be dealing with situations where the texture names, order or amount changed since the last .OBJ importation in a given level file.

Ok, now that I've over-explained myself again. Here's the deal: I found a way to easily add multi-texture support for the importer in 0.6b, but that would mean a few more days of work. But... since my "real-life" job is keeping me busy and I only have 2 days off per week where I can really have time to work on it, this means a few more weeks of waiting.

The poll still indicates that the majority is ready to wait more if it means that the importer will be more "full featured". But seeing you guys starting to get excited about creating polygon models in Blender, it's a little disconcerting not to be able to release it earlier. Still as you guys create more and more level concepts, it becomes clearer and clearer that the real fun would be to have multi-texture import...

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


Posts: 446/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 04-25-09 03:49:17 AM, in Post your SM64 mods, patches and screenshots here! (NO ROM LINKS!) (last edited by VL-Tone at 04-25-09 02:36 AM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Metal_Man88
Originally posted by vinnyboiler
It's the lack of spaming!


Yeah. Back in the old days you could hardly discuss findings on water levels without being attacked by people saying 'I WAHNT TO PUT PEACH AS PLAYABLE CHARACTERH' and 'YOU RAWK FUR SCRAMBLING TEH COLORZ.'


Man I remember having to put a "Geeky stuff" warning in the title of a thread



Ok... so about these nice level designs you guys submitted... It's really impressive stuff!

But it's getting clearer and clearer that multi-texture importing is where the fun will be. So, thinking about it, I realized that it wouldn't be that hard to add it to 0.6b. Read more and discuss about it in this post: http://jul.rustedlogic.net/thread.php?pid=123484#123484

Gecko: you're really good at level design, it's nice to have someone that experienced here

What I've noticed, trying to import the .OBJ file converted from your blender files, is that there's no UV texture mapping, and it's needed for the importer to work. I'll have to add an error message to warn people when the UV coordinates are missing.

Now, I have no idea how to create UV mapping in Blender. It looks to me like it will be the hard part of creating levels.



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


Posts: 447/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 04-25-09 05:21:59 AM, in Toad's Tool 0.6.0 (On hiatus for an indefinite amount of time) (last edited by VL-Tone at 04-25-09 02:23 AM) Link
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Originally posted by Gecko
It could be a z-coordinate, because the room behind the portal also is shown when Mario levitates above the portal and it makes perfect sense that the portal triggers camera movement, like you said. Therefore it could be the same system used for camera changes inside the levels.


I forgot to reply to this post...

I think that you mean a 2d coordinate on the horizontal plane? That would make sense, since the camera modes were switching in flat-world even though the floor is probably not at the same height as the floors found in the original levels.

That would explain why the castle is actually separated in 3 levels, so that the triggers don't overlap between the first, second floor and the basement.

Originally posted by Hectamatatortron
About the room loading and camera mode changing:

Surely you can set a breakpoint on reads of Mario's coordinates and find the assembly related to the process?

I wonder if the coordinates are used to specify a sphere (probably with fixed radius) rather than a point.


From what Gecko said and my own experiments, it could be more like a circle on the floor.

As for setting up a breakpoint and trying to find the code/coordinates by observing RAM, messiaen or yoshiman (yoshielectron) would be more qualified than me to do that.

____________________
Pages: 1 2 3 4 5 6 7 8 9 10 ... 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Jul - Posts by VL-Tone


Rusted Logic

Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

27 database queries, 47 query cache hits.
Query execution time: 0.279757 seconds
Script execution time: 0.085275 seconds
Total render time: 0.365032 seconds