 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| Calendar
| Chat
| Online users Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album |
|
| | ||
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
| Pages: 1 2 3 4 5 6 7 8 |
| User | Post | ||
VL-Tone Paratroopa                  Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
There you go, I've got it working too! 
Thank you very much Cellar Dweller for this help, even though I should have figured this out before... The first polygon data I stumbled upon was the solidity data, but didn't manage to get conclusive results at the time so I focused my efforts on the textured polygon data. Edit: I hope I'm not sounding like I want to keep the credit all for myself and minimizing your efforts Cellar. You are a better programmer than me and have a much cleaner/modular approach, and since the beginning you have been more than useful 
Ok here is a second picture of solidity data, that one inside the castle (first floor). 
Look at where paintings are... weird eh? There seem to be 3 separate areas defined both in front and behind, for a total of 6 different solidity values for each painting. I really wonder what they are used for... why 3 in front and 3 behind? If I remember correctly these are defined by commands Dx or Fx. From what I found, command 79, 85, 1D and 21 are followed by lists with items that are 8 bytes long instead of 6, so they include an extra 16-bit parameter. The first 6 bytes are a triangle like other commands. Command 0x88's items are 12 bytes long, and also contains a triangle. Command 0xA0 is only 4 bytes long. I started decoding the other sets of objects that is found after 0x43 and before 0x42. Very interesting stuff in there, as predicted it includes Bowser, trees and other stuff like doors. In these objects I found the command that places the castle main tower on top (I had to do it manually before). The problem I have is that I cannot find the link between its object type value (0x65) and value 0x03, which is the value defined by the 0x22 command for the tower... It doesn't seem to use the same set of type/behavior/params macros that command 0x39 object use (found at EC7E0). (edited by VL-Tone on 01-21-06 01:34 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| I considered this possibility, but I thought it was a weird way to detect that, and from memory I was pretty sure that there was more than 3 different horizontal positions for the ripple effect. But after reading your post I decided to check... And it seems that you are right Lordlazer!
There seem to be only three possible horizontal positions for ripples in paintings, but the vertical position seems to be more precise. The 3 areas in front are for when Mario enters the painting, and the 3 areas at the back are for when Mario exits paintings. But you shouldn't have to worry about posting in this thread. If you have questions about the Mario 64 editor, even basic things, don't hesitate to ask them in this thread, at least until I decide myself to post a more official thread... From what I found, these areas define the terrain type in some instances and are there to detect if Mario is stepping on a specific floor part in the level, to trigger some specific event. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by Lordlazer I don't know much about the GTKRadiant editor so I couldn't tell. I guess you can create levels from scratch? The first release of my M64 editor won't enable you create new model geometry, I may add a way to edit the geometry shape by moving vertices, but I'm still not decided if I will include that in the first release. As its basis, geometry editing (not importing) would be a simple feature to add, but to be useful, it should be more than being able to move individual vertices. Selecting and moving multiple vertices at the same time would be very useful, and scaling and rotating groups of vertices would be very practical. I'm thinking about implementing a way to match the geometry vertices to the solidity vertices so they would move in tandem. Though it would be very cool to be able to create entirely new geometry and importing 3d data into Mario 64, I feel that this is too much of a task for me, and even with Cellar Dweller's approach, I'm betting that it will take years until we achieve that. There is much more things than vertex and triangles in the geometry format, there are pointers and other stuff that no 3d program deal's with. The format is actually a series of graphic processor commands, that have to follow specifications. An importer or geometry creator would need to keep track of many things to make sure the texture or triangle cache doesn't overflow for example. With the many limitations of the chip and engine, many things could go wrong. We may have much more space for levels by extending the ROM, but memory will still be limited. Making sure a level doesn't make the game crash will require taking many variables into account. Sure, individual issues will be dealt with, but the sum of them may mean a lot of work ahead of us. I may be a little pessimistic about this: To build Mario 64, Nintendo used a 3d program called N-World by a company called Nichimen. There was a plug-in to export models to N64 graphic commands format, so it may not be so hard to replicate similar functionality. Edit: By the way Nichimen is now called IZware http://www.izware.com/, N-World was renamed Mirai a few years ago, and IZware's products were used to animate Gollum's face in LOTR. I'm currently looking for more information about N-World, here is one of the interesting pages I found on the internet archive: ress/n64-exp (edited by VL-Tone on 01-23-06 11:19 PM) (edited by VL-Tone on 01-23-06 11:35 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Lordlazer:
I'm not sure how mesh are used in the Quake editor, but meshes can be 3d, and the term mesh can apply to just about any 3d polygon group. So yes the Mario 64 levels can be described as 3d meshes. The editing would work by moving around vertices, thus changing the shape. I guess the equivalent of brushes exist in Mario 64. Some levels, like Whomp's Fortress, or Wet Dry world (area 1) rely on level objects for platforms and many level elements. The Whomp's Fortress tower for example, is an object. You could move the tower, or put three of them if you want, by changing other object in the level into towers. The rotating platforms in this level are also individual objects you can move and tilt, and "duplicate" them at other positions. For fun, I once made the tower use the rotating platform behavior so the whole tower would rotate! It worked, but for some reason the tower lost its solidity. Here is how mesh editing could look, though a wireframe view could be an option. Vertex are represented as red spheres in this example. Each of these spheres could be moved, enabling you to change the shape of the Secret Slide for example. 
Maybe a slide editor could be a start
Cellar Dweller thanks for reassuring me, I get a little paranoid sometimes. 
Very cool that you found the geometry layout command's function table, this is one area I don't know that much about yet. I know just enough to decode levels and simple objects. Mario has an incredibly complicated geometry layout, and by understanding it more we'll be able to replace Mario with other characters. (But it obviously has more uses than that, as every object and level part has geometry layout data) Like I explained earlier in this thread, command 0x02 is used in the level geometry layout to jump to different room sets in multi-room levels (Boo's House, Inside Castle and Hazy Maze Cave). In this case, each 0x15 commands point to a particular room GBI polygon commands. I don't know how the game identify room sets though, as no command seem to indicate room sets numbers as is. I didn't know about the second byte use though, but in levels, it's always 0x01. Command 0x03 is used to jump back to the stored address. Now, take a look at Yoshi's Geometry layout data, which is way simpler than Mario:
I know that the 0x15 command points to polygon data, command 0x13 also point to polygons (but not always) and I don't know the use of the first 7 parameter bytes. I added indentation for the 0x04 and 0x05 commands, which seem to act like parenthesis surrounding sub-groups, forming a hierarchy. This may well be something akin to bone hierarchy? Or maybe it's some sort of BSP tree? It's unclear how the game keeps track of each body part. Everything else I found in the game has somekind of ID attached to it, not in this case. Maybe they are referred as positions in groups and sub-groups? Yoshi really has two heads , one with the eyes opened, and one with the eyes closed. Mario has 8 of them for its animated eyes. Ultimately, all heads refer to the same vertex and triangle sets, but with different textures. They are loaded sequentially one after the other using 0x15 commands, and with no ID attached to them.
One possible scenario is that these ID's (and their polygon data pointers) are created and stored as the geometry data is read, then referenced by bone animation routines. By the way, this Alias document is full of very interesting stuff! What's funny is that it's not even from the internet archive, this site is still working even after all those years! Edit: added screenshot that I struggled to upload at photobucket earlier. Another Edit: Some phrase made no sense...yeah it's late... and why is there a blank 3rd page on this thread now? (edited by VL-Tone on 01-25-06 04:18 AM) (edited by VL-Tone on 01-25-06 04:23 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by UZI in my pocket Yeah I already found it, as you can see I posted there as v-twin. Anyhow, he cannot prove anything anyway... I can find if these guys start to link to my page by looking at referrers, so I don't think they can do much without me knowing it... |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Welcome to the board spydark!
Pardon my ignorance, but what is VGDC? I guess that the VG means Video-Game, but the DC... DreamCast? Could you please post the thread url so I can take a look? I'm not sure if I'll include the possibility of editing the warps in the first release. What you are asking would be possible for all levels except the last one. The end sequence is more custom stuff, and I don't know much about it yet. I'll experiment to see if it's feasible. ---------------- BGNG, you are right it's no big deal, and even if some people used my nick to claim the editor is theirs, it would only spread the name
So please people, don't start a war on the moviecodec thread.... But yeah this is one of the reasons I won't release the source code of my editor. Like you tough, I'll publish a document with all the info necessary to build an equivalent editor. If someone wants to copy my editor without crediting me, at least they'll have to work for it |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| For those who didn't see it, here is the video I made to "prove" that I was working on the editor:
http://www.youtube.com/w/Super-Mario-64-Mod-2006?v=LC2SIXvs1mo HyperHacker, I first thought about putting my name in a texture as a proof, but I thought it was too easy, and there are already tools to do it. But yeah I get your point, I could have used it as a kind of watermark in the video. The watermark I put is not always easy to view, mainly because of youtube's re-compression. But even if he grabbed some image where they are hard to see, I'll can always point to my entire video as the source of the screenshots, and at times in the video the vl-tones are easy to spot. Anyhow, this Alan guy is a troll, and I guess I fell for it...But that got me into producing this fun little movie
---------- proffessor_gad, welcome to the forum, I hope you are not still doubting
The space limitation regarding geometry creation, are a RAM limitation, not ROM space. SM 64 cannot use the RAM expansion pack as is, so we would be limited by existing space. But this is one of the reason why it will take some time until this is possible. Currently, I decode the level geometry to display the level and objects in the editor. But there are many things I don't take into account when decoding the data, so creating valid polygon data is more complicated. Also I would have to either write a 3d creation/editing program (not a small task), or write an importer to import standard 3d files from an external 3d program. The problem with the latter is that there are many things (like pointers etc.) other 3d programs cannot generate that are essential to the game. So that's why it will take some time before we can create entirely new levels. ---------- Cellar Dweller, I have a quick question: Do you know the hex equivalent in SM64 for the GBI geometrymode and cleargeometrymode commands? I started to implement texture coloration, some vertex have a an RGB color value, while some contain a vertex normal. From what I've found these two GBI commands can be used to switch between vertex based coloration and Gouraud shading (which uses the normals). (edited by VL-Tone on 01-29-06 10:49 PM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| proffessor_gad: yeah I knew about this, the Mario model was extracted using an emulator that can export the current 3d scene to a file. Note that the textures pict you posted differs from how the textures are stored in the ROM. The skin color and cap color (red) under the M logo are not included in the original texture.
spydark and others asking to be beta testers, the program is currently in alpha state and couldn't be used by a beta tester. It will take a few weeks until I provide a beta version to test. I'll keep your names in mind when I'll begin the testing
Hosma293: yeah I thought about making an exporter, it wouldn't be that hard, I did one for my StarFox level editor, though it didn't include textures. Like I just mentionned, there is an emulator that I forget the name of, which can export 3d models from n64 games. Spazzup™: Aside from me and Cellar, other people deserving a kudos are: BGNG for reverse-engineering the compression format (MIO0) since without that this wouldn't be possible. HyperHacker, Stag019, ChickenLump and others also made great contributions. If I forget anyone, sorry
Without bragging about it, I did find 80%+ of what was found in SM64, others could have done it too, but I had a head-start, having worked on a StarFox level editor pretty much on my own and SM64 has a similar format for polygons and levels. Cellar Dweller: Thank you very much, that was very helpful, I managed to implement texture/polygon coloring and now many levels are more faithful to the original. The hills surrounding the Castle are now green at last, and there are now shadows, for example, under the bridge. I'll try to post screenshots later. |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Yeah I knew this was possible with the GS
By the way I forgot to post this: http://pages.infinit.net/voxel/SuperMario64mod2006b.ips It's an IPS patch of the edited Castle Ground level featured in the video! It requires a ROM with the ABCD byte order. If you can find the string "yoshi" anywhere in your the ROM using an hex editor, that means you have the right byte order. The warp pipe on the ground leads to the warp pipe on the top of the castle, and vice-versa. But these pipes could instantly warp to any position in any level! Try that on a PSX 
A cool simple hack could be to put warp pipes all over the castle level field, each warping to a specific level and area. Ideally, a message would appear, saying "Welcome to the warp zone!"
(Edit: I changed the link to version b, since the first version I posted was for an extended ROM) (edited by VL-Tone on 02-01-06 03:25 PM) (edited by VL-Tone on 02-01-06 03:30 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Ok sorry about that, I should have thought about these details...
Yes you do need the US version. If you cannot find the .Z64 version of the ROM, use this tool: http://dextrose.com/files/n64/build_tools/bswap.zip to change byte ordering to ABCD on the US version. proffessor_gad: You need an IPS patcher program to apply the patch to the ROM, like the one mentioned by Spazzup. You can find the excellent Lunar IPS, and other IPS patcher programs at http://www.zophar.net/utilities/patchutil.html (edited by VL-Tone on 02-01-06 12:59 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Drats... I gave you the patch for the extended ROM... (with repointed MIO0 files)
This version should work (I just tested it and it works). New version that works on an 8 megs US Mario 64 ROM with ABCD byte order: http://pages.infinit.net/voxel/SuperMario64mod2006b.ips (edited by VL-Tone on 02-01-06 03:32 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by proffessor_gad I'd rather work on making the editor useable for beta testers than spending my time on doing level edits and releasing patches. So no more level edits until I release the beta. Chainlink1061: For now, the editor doesn't edit the polygon geometry, and it wont until version 2. (edit: Hmmm, I hope that didn't sound too harsh, I forgot to reply to the rest of your post, but here it is: Thank you for the compliment but I'm not a genius! Interesting bug you got with the Goomba, I guess they are never normally found in levels that contain a vanish cap box to prevent this bug from happening?)
But even if geometry editing won't be available at first, the following levels still could have major structure edits since they are built out of multiple platform objects that could be moved without editing the geometry. 
Note: these are new screenshots, before that, these levels didn't display all platforms, but thanks to Cellar Dweller's help I implemented most of the remaining object types. As for texture coloring, here is the Castle, with the green hills at last! 
The window on the tower doesn't appear, this is a bug I should try to fix (in my first images, I positioned the tower manually, but now it's positioned from level data). Trees are implemented at last, but they suffer from a texture repeat problem, and a z-ordering problem in some particular context. Here are the shadows that now appear on the castle and under the bridge.  (edited by VL-Tone on 02-01-06 10:58 PM) (edited by VL-Tone on 02-02-06 12:49 AM) (edited by VL-Tone on 02-02-06 12:49 AM) (edited by VL-Tone on 02-02-06 12:50 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by Chainlink1061 Sorry guys, I was busy these last few days. Chainlink1061, to answer your question, the first release won't enable you to add new objects. This is the kind of thing I'll work to add in version 1.5 or 2.0. I decided to rewrite some part of my editor from scratch, as it was a little patchy and got too much overhead. I'll adopt a more OOP based approach. Also, I decided to get rid of HEX values in the main interface. I'll do an inventory of all the polygon objects found in the game, and assign them numbers (in decimal). Same thing for behaviors, and MIO0 banks found in the game. That will make the editor much more easy to use. At the same time I'll keep some power user features so that you can find what hex pointer the decimal numbers refers to, and possibly these values them when it could be useful. I already partly implemented a feature where beta testers will be able to contribute by adding description to objects and behaviors, when they are not already defined. Then, by sending me back a .txt file, I'll be able to integrate those back into the editor. You'll be able to add descriptions for each polygon asset, behavior pointer, labels for the 2 parameter bytes used by specific behaviors, and descriptions of possible values for those 2 parameters (either as 2 separate bytes or a single 16-bit value). I'll try to add descriptions before releasing the beta, but for any missing ones, people will be able to contribute if they want |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Wow, thanks for all the suggestions, they are all great ideas
Even if I don't choose any of your suggestions, it's very useful to get external ideas. I must admit that TOADSTOOL is the one that caught my attention more than others. I know one word is better but how about "Toad's Tool"? Or maybe "Toad's Tool 64"? But, I have an idea myself, tell me what you think: Carpenter 64 I was about to post something about it yesterday (but again, I closed my browser window by mistake), explaining why I think Mario is more of a carpenter in his soul than a plumber. It was a long explaination and I don't feel like rewriting it. Is Mario a plumber or a carpenter? I think that he's both, but I think his plumbing jobs were "on the side", while his main profession is still carpenter. It's debatable, and that's what makes it interesting as a name, as it would generate some light debate each time the name of this new Mario 64 editor is brought up in some forum. Edit: removed that off-topic part about where my nick comes from. (edited by VL-Tone on 02-10-06 12:51 AM) (edited by VL-Tone on 02-10-06 03:18 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by dcahrakos Ok, aside from the big green pipes, what other plumbing stuff does he do? (please exclude SMS) Originally posted by Kyoufu Kawa Oh please don't take into account the scenario from that awful Super Mario movie
I clearly remember Miyamoto saying in an interview (years ago) that the plumber stuff came from the US marketing department, with the movie and the (also awful) cartoon. He contradicted himself on that more recently, but I think he just gave up on explaining it, and since the overwhelming majority thinks he's a plumber, he decided to treat him as such, starting in Super Mario Sunshine with the water stuff. For me it always made sense, but I just found that I didn't have the right definition for the word carpenter. I had the French word "charpentier" in mind when I read or heard carpenter, and it has a wider and different meaning. The thing is, "charpentier" fits the Mario series much better than plumber and carpenter. It's possible that the Japanese translator also spoke French, and did the same mistake as I did when translating Mario's job for english documentation. He's probably the same that is responsible for the "Donkey" in DK, which is also a mistranslation. The word "carpenter" has latin roots, but it likely comes from Italian or French. In French, "charpentier" has two meanings. The oldest, is close to the English definition: "Person skilled in woodworking". The most recent definition for "charpentier" is: Person that is responsible for designing and/or installing a building frame or "skeleton", which is called in french "la charpente". He also has to install stairs and other related things. Building frames were made out of wood until the last century, where metal frames and cement started to be used in the construction of high rise buildings. Metal beams used in high rise building frames are often called I-beams, and V-beams, and the letter I and V being related to their shape. If anyone wants to stick to the English definition of carpenter, which I suppose most everyone will, then tell me where is the woodwork in Donkey Kong and DK jr.? Barrels? Look at the levels in DK (and DK jr.), they are built out of metal beams, V-beams and I-beams. There are also ladders, elevators, rivets, conveyor belts and cement like the one you would expect on a 191x high rise metal frame being built. Wood barrels and metal barrels with oil also fit very well in this context. I'm sure everyone here has saw in one form or another a cartoon or old black & white movie where some character is walking on the metal frame of a high rise building in construction, avoiding obstacles and jumping over gaps along the way, and later finding himself on a moving platform (often an I-beam or metal pipe with a rope tied in the middle). It's obvious (to me at least) that Miyamoto had that mind when creating Donkey Kong. As for Mario Bros. I think it was released at a time when Nintendo of America started to handle the marketing in the US. So NOA probably wrote a little scenario for the instruction manual and decided that since there were pipes in the levels (and water at the bottom that has no gameplay purpose), that the Bros. were plumbers. Maybe NOA called Miyamoto to tell him that carpenter was not a good thing to use, explaining that the english definition of the word didn't fit well. This is speculation so I could concede that they were plumbers in that game, but only in that one. A charpentier has to be skilled when it comes to walking and jumping on narrow platforms. This is the skill that Mario predominantly uses in all games in the main series, and that can even applied to the dreamland of SMB2 US. Still, there are other clues that Mario is still a charpentier in SMB1. His duty is also to make sure everything fits well with the frame, and that includes working with bricklaying guys. A charpentier having to renovate or realign the frame of an already built brick house will have to dismantle the bricks to access the frame. The [?] boxes found in SMB1 are also a typical element of a building frame some kind of metal box or plate with 4 screws in the corners. You can also find moving platforms in SMB1 made of I-beams. The structure of levels in SMB1, SMB3 and SMW are similar to unfinished buildings. In Super Mario 64, there are tons of brick patterns, elevators, concrete, metal and wood platforms and narrow platforms where Mario has to be careful just like on a high rise construction site. Kicking a giant wooden board (in Whomp's fortress) to make a bridge is something a cartoonish charpentier would do. Another thing to note: there are very few pipes in SM64... But hey I'll probably come out as a wacko for this theory, I've never seen anything about it on the web. "Who does he think he his to assume that carpenter was a mistranslation because the translator also spoke French?". To me, it all fits too well. I guess it's hard to believe for anyone that doesn't speak French (and/or hate French), since I could have invented the definition. You could try to translate this page with google: http://fr.wikipedia.org/wiki/Charpentier_%28métier%29 though the result maybe confusing
Sorry if it was long, I got carried by my theory because I found (today) that it made much more sense with the French definition. Maybe I could write a thesis on that! Seeing all I had to write to back up my claim, I won't be using "Carpenter 64" and don't worry, I won't use "Charpentier 64" either! I don't want to have to explain that again each time I present the editor.
I hope at least a few of you found my theory interesting, though I'm sure some will find it a little wacky. I guess we're back with ToadsTool. I would like Toad's Tool 64 better. Or maybe Mario 64 Architect? I don't know... nothing is set in stone yet! (edited by VL-Tone on 02-11-06 12:24 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Oh well thanks for the correction. that throws my whole theory out of the window  Nahhh not really, Miyamoto doesn't speak English very well, and probably even less in those days so he probably had someone translate Mario's job description for him and that's where the mistranslation happened.
The core question that I would like anyone here to answer is: If Mario was a wood worker (carpenter), then why, aside from barrels, is there no wood in DK? By a weird coincidence, the levels in DK look like metal building frames, which is in French called a charpente. And the job of a charpentier happens to include walking on building frames and platforms, sometimes high in the air, climbing ladders and carrying tools like hammers, putting rivets to install metal beams, working with cement etc. So it fits perfectly with the DK setting. But yeah this is getting out of topic. Go Monkey Kong 64! 
Yeah this is a screenshot from a crappy DK port on the TRS-80 CoCo 2 that is really called Monkey Kong. Edit: Ok to really get back on topic, I compiled a list of all 3d objects refered by the game, and there are 478 of them! They are defined in 49 different geometry layout segments. I also built the list to include which MIO0 files these geometry layout segment use for the polygon and texture data. That will be useful to be able to manage segments. The editor only provide access to objects that have their segments loaded using 0x18 0x1A and 0x17 commands. Geo:1279B0 MIO0:114750 Ptrs: [0, 28, 56, 132, 156, 292, 360, 444, 560, 644, 11732] The pointers are in decimal, they are to be added to the Geo address. the MIO0 pointer indicates which segment is used by that geometry layout script, so that particular MIO0 file has to be loaded in order to use that geometry layout script. (Yet another edit: I removed 4 entries in the list that didn't make sense) (edited by VL-Tone on 02-11-06 02:28 AM) (edited by VL-Tone on 02-11-06 02:31 AM) (edited by VL-Tone on 02-11-06 02:34 AM) (edited by VL-Tone on 02-11-06 02:45 AM) (edited by VL-Tone on 02-11-06 02:46 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Some update on what I'm currently doing in the editor. (I guess I should do that more often)
I'm working on improving the speed of the level drawing routines. Levels with hundreds of objects can take a long time to draw (a minute or two for the whole level and objects). But take into account that my computer is also reeeeeaaaalllllyyyy slow and very old though, but I'm getting a new one that will be much faster, at the begining of March. It still won't be a powerhouse computer, but will be in line with what people have here on average. But anyway don't worry, there is room for improvement, because currently the level drawing routines take a very dumb approach. The editor reads the script, and then draw every 0x24, 0x39 and 0x43 objects, by reading and decoding the GBI (n64 graphic lib) commands from the ROM on the disk. It does that each time, even for objects that are duplicated... I'm currently working on a feature that detects if a 3d object was already decoded and built, and procede to clone the 3d model instead of decoding it again. Another feature I'm working on is having wireframe selection boxes that have a size that is relative to the object so that the object always appear inside the box. I'll stop using 3 colors on each box, and instead use color coding to differentiate the 3 types of objects, and which one is selected. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Just to be sure you don't think I'm that dumb, I don't reload and redecode objects each time they are moved.
Your approach is ideal, but is not as easy to use with SM64 There are 478 objects found in the game, and each of those can be made of multiple parts. I still haven't figured the geometry layout data in its entirety, and its relation to the "skeleton" data. Many of the 478 objects are themselves composed of sub-parts which are put in a hierarchy in the geometry layout data. The thing is I still don't know how parts are positionned in space. Most objects that are one or 2 parts and don't have any pivots can be displayed correctly, but the animated characters have their body parts drawn all at the same position. But let's get back to my point, creating display lists (that contains polygon data right?) for all those 478 objects and their sub-parts would take too much time, well at least in Director/Shockwave. Maybe I could pre-calculate those lists and include them in the editor but that would be ehmmm... not good? Since Mario 64 can only use specific sets of objects in a given level, I decided to load objects for specific levels only when they are needed in a level, to shorten the time it took to load the level. Also this approach was implemented at a time when I didn't have the list of all 478 objects. It's not a list of offset found somewhere in the ROM. I had to write a not so simple routine to generate it. What I think I will do (for now) is generate/draw meshes on a level basis, creating/drawing only those that can be used in a given level, then cloning them when the level is actually drawn. When the user changes the object type, the old one is deleted then the replacement is created by cloning the corresponding model. Creating a mesh from a displaylist is not as straightforward in Director and would add too much overhead, cloning is faster. I guess I shouldn't have said how much time the biggest levels took to load on my very old computer, don't worry, it will be much much less than that. (let's say 15 seconds in the worst case on a 1.2 GHz computer) One of the main culpit (beside the current redundency when loading objects) is disk access, which has to be done byte by byte because for some reason Director stops reading on byte "00". This could be solved by using an Xtra, which is a plug-in used to extend Director. One of these, the BinaryIO Xtra, is much faster than the built-in disk acces. The only thing, it's shareware, and the unregistered version displays a dialog each time you start the .exe version of the Director movie. Yeah it's a pain, but Lingo is what I know... |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Oh great, I lost a long post again.... (This time the board ate it!)
I guess I'll have to summarize what I wanted to post... 1. Something about not knowing what to say, and being shamefull about the current speed. 2. Then I explain that yeah it's a disk access speed problem, and the fact that I read/decoded object multiple times is also a major factor. Director is not that slow in itself, it can performs tens of thousands of operations per second, if not hundreds, on any computer sold in the last 3 years. 3. The BinaryIO Xtra is the solution, it could load all ROM "banks" found in M64, in a second or two, and it would only need to do this once you open a ROM. The only problem is that it will display a small nag dialog each time the editor starts. 4. Explaining that it would be much better anyway, even with the BinaryIO nag dialog, and maybe hope that someone donates the license, after the editor is released. 5. Making sure everyone understands that the editor itself is freeware, and that I need only one license to remove the dialog for everyone. 6. Trying to address the fact that some will say that my editor is crap based on the current performance of the unreleased alpha on an ancient <400Mhz computer. 7. Something about saying that BGNG is a much better programmer than me, but that the difference between speed is also exagerated by other factors. 8. Trying to explain that in the end, I do this for fun, not fame or money. And that I'm confident that I will improve the speed vastly, and that's what's important for me now (compared to worrying about the doubts I created). 9. There was nothing worthy after that |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| If I remember correctly, Stunt Race FX uses about the same polygon format as StarFox.
Here is an "old" doc I did last year that explains most of the format: http://pages.infinit.net/voxel/Arwing_Deconstruction.html Missing in the doc are some commands that deal with animation, but I since found how these work. You can also try to dig in the archive of this board to find my threads about Starfox, though images maybe missing. |
| Pages: 1 2 3 4 5 6 7 8 |
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
