 |
| 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: 6100 days Last view: 6100 days |
| ||
| Well in SMS, everything is neatly organized into files with a filesystem. There are files for vertices locations, files for polygon (triangles) connection data. Others for textures, collision data etc.
In Mario 64, there's no directory for things like that. To find where all the textures are for example, you have to decode all level scripts to get the pointers for geometry data. Then decode all the geometry data to find all polygon pointers and then decode the polygon data to find all unique textures. Same goes for vertices data and many other things. Also, in Mario 64, the triangle data is part of an ASM-like script that controls the graphic chip directly. The 0x4 command loads a limited number of vertices found somewhere else, then the 0xBF command draws triangles using those vertices. So it's impossible to build, for a particular model, a complete list of all vertices and their locations in the ROM without parsing the graphic commands first. In SMS, just load the corresponding vertices file, triangles file and texture file(s) and you're good to go. But I'm not into GameCube hacking, as I find the console to be to much recent for hacking, and there's no really functional GC emulator yet, so no real possibility of an editor. If you really want to know more about it, check out the threads on emutalk.net. Ok you're lucky I'll answer another question for you  since I wanted to reply to this one before and apparently didn't...
To do this move in Mario 64: Run, press A to Jump, press B to dive, then while diving press B again (or A) making Mario spin so he doesn't land on his belly. I do this all the time to go faster. (edited by VL-Tone on 07-03-06 03:14 AM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Originally posted by Doritokiller It varies. I do have a real job as I said, and have to work there 6-7 hours a day, 5 evenings a week. When I do work at my job, I spend less time on TT64 (ToadsTool 64). It can be from about 3 hours to maybe 5 on those days. Friday and Saturday I may work on it even more, sometimes up to 8 hours. Unfortunately I was busy much of my last days off, so I didn't work on it as much. When I get back from work, I'm not always in the mood for programming. As much as I like working on the editor, sometimes I need to relax and do other things. So that's about it... I'm gonna publish something later that may help you wait, which is a list of offsets of all textures I found in the game, with their size and type. It will then be much easier for people to find and edit textures using TileMolester. It will only work for an extended SM64 ROM. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Oops! I went to bed earlier yesterday, forgetting to post the texture location list.
Here it is, attached to this message. There are 849 textures in this list, and it doesn't include fonts and other menu graphics. Textures with type 0x10 should be decoded as 16-bit RGBA 5551 color. The ones with type 0x70 are also 16-bits but 8 bit grayscale with an 8 bit alpha mask. It's possible that some are missing, since like I explained, the whole level and polygon data must be decoded to find texture locations. (edited by VL-Tone on 07-05-06 01:00 AM) (edited by VL-Tone on 07-05-06 01:01 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Ok first, please don't fight each other over anything!
Update about the editor progress: I decided to implement a way to copy/paste one or multiple parameters between objects. This wasn't planned for the first release, but it will make it really useful, especially since the first release won't allow you to insert new objects. I'm thinking about including the texture editor/swapper in the first release. I also implemented a revert button so you can revert to the saved command/object. I will make the Text Wrangler load the font from the ROM when the next version is released along with the editor. I feel I may have exagerated the number of hours I work on the project. When I say 8 hours on my days off, it includes some breaks... I don't program 8 hours non-stop And before June, I didn't work on it much, and that's why I didn't meet the deadline.
Since then I work on it almost every day, but I do sometimes take days off programming, which I don't tell you about, since I feel bad about not releasing the editor soon enough. I never said I didn't work on the editor fridays and on week-ends. Actually I work on it more since they are my days off for my "real" job, the one that pays the rent etc. Actually, I'm tired of discussing this aspect. Do I really have to explain my daily schedule in detail to justify the time it takes? Ok... About newbies or "n00bs", whatever you called them. Don't you notice a pattern here? You could say it's their fault for not reading the whole thread, but explaining that to newbies doesn't fix the problem, they just keep on coming, and by definition, they are new, so they can't know what you said to other newbies. Actually, It's my freaking fault... I should have at least a web page in my sig explaining when the editor will be released (and the answer is "soon") and other frequently asked questions. Maybe a simple text only FAQ could do the trick. I can do it myself, but I wouldn't mind if someone was kind enough to prepare one for me... I'll proof read it and correct it if necessary. About the splash-screen. I will keep that tower crane idea for sure, whatever what some people think. As for the title text, I'm open for suggestions. Personally I liked the idea of some bubble-wrap effect over the pixelized M64 font, but it seems it's too weird for some... I wanted to name the editor Toad's Tool 64 more than ToadsTool 64, but people seemed to like ToadsTool better. Maybe I'll call it Toad's Tool 64 anyway, nothing is set in stone for now. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
A picture is worth a thousand words doesn't it?
I will include the "Basic Advanced Expert" modes after all, but there will be separate settings for the command list, and for the parameter bar. I use "Basic" instead of "Beginner" because the basic modes can be useful even for experts. In the Basic mode, the command list will show only the five commands seen on the screenshot. 0x24, 0x40, 0x43, 0x36 and 0x26. The Advanced mode will show more, and the Expert mode will show just about all the level script commands. The Basic mode for the Param bar will show only the Sprite Combo and XYZ pos and rotation. The Expert mode all the possible params for this command. The Advanced mode something in between. The color palette is to adjust the background color of the 3d view. I changed the color scheme for the parameter bar so it's now meaningful. The red parameters are "Combos". They are values that don't exist in the ROM. They are sets of other multiple other parameters. Note that the Sprite Combo param is not currently totally functional (hence the lack of value there) The blue and green parameters are both used for normal, in ROM parameters. The alternance of blue and green is there to separate groups. (I should make the Act param blue) Just about every platform in Rainbow Ride is moveable. The red boxes are only for the 0x24 commands, and the yellow box is for the selection. In case you didn't notice, there's no Save command in the screenshot... I have to admit that this is one of the main thing missing. The whole structure that will enable saving is there, but there's a few things left to implement. You have to remember that I have an older version that did save, so it's not like I never tried. There are a few interface elements left to be added. I'll add some buttons in the empty blue bar below the 3d view. The new scroll-bars and the window title bar are specific to my own computer, as they will show the OS native look. (I used an OS-wide ShapeShifter theme) As for closing the thread momentarily, I'm not against. With all the respect due to people here participating in this thread, just about everything discussed here will make more sense once the editor is released. And as you can see, I'm not that far from a release. While the thread is closed, I won't have to worry about answering questions or giving updates. Don't worry guys, the editor is near completion. At the same time, I feel sad about closing this thread, slamming the door in the face of those who got involved in it. donrayiv, I'm sure you're well intended, but the hype surrounding this thread will bring newbies after newbies that won't read your advice. If this thread does get closed for a moment, you and others shouldn't take this personally. I'm really getting stressed about this thread, and I was about to announce that I wanted to get away from the thread for a week. But I realize that if I did that, the thread would have gotten worse, with more newbies asking "where is VL-Tone?", and regulars here having to deal with them. I don't want to have the last word on this, but to me, it's either being able to think by myself for a week or two VS. giving freedom to those that want to talk about TT64 here. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Oh well keep the thread open then
I didn't even saw the name change for the thread when I posted the post about closing the thread... Anyway I simply didn't know what to decide about this, it sounded like this thread didn't make any sense for the moment. But with the new title, I guess it's alrighty
The only problem is that a great affluence of newbies create opportunities for trolls, who can try to pass as newbies. Some of them are becoming very obvious, and I won't name names... So what do you think about my latest screenshot? Too glossy? Sorry but I in that mood, and that effect is trivial to add in Director. (But yeah I know, Director has its limitations too) Oh and I just realized that I should have written "Flying Carpet" instead of "Flying Rug". Incidentally, there's a retro-computer related story linked to that particular mistake. The first time I read and learned the meaning of the word "rug", was while playing a text adventure+graphics game called "Calixto Island" on my Tandy CoCo 2 (64K). One of the first puzzle was to type "PULL RUG" to reveal a trap door underneath the rug. Of course you needed to collect some stuff like a flashlight before going into the trap. So since then, whenever I'm using a computer and I have to think about a word for "carpet", I think of the word "rug" first 
Ehm, to get back on topic, while Zelda OOT has an engine based on M64, there are some key differences that wouldn't make it that easy. But I've rewritten my editor in a modular way so it could adapt to new commands and parameter formats, making it easier to adapt it for another game. But please Zelda fans, let me finish and polish TT64. Don't count on it from me either, I may chose to concentrate on other projects after TT64 2.x is released and debugged. Chainlink1061: Just saw your post after posting. That's a good mini FAQ. I'm currently implementing the texture export/import, and copy/paste texture functions. It may not be included if I run into a major problem (this is the type of thing that could go wrong since I never tried it and the export relies on an Xtra I never used before.) Maybe some line about the camera controls could be included. (edited by VL-Tone on 07-11-06 03:54 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| What made you think that I wouldn't use the official names? Is there an official name for the Flying Carpet?
No I don't know all of the enemy names by heart like some of you Mario 64 ultra-fans, but there are lists on the web I can use to complete and verify my list. |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Hi, just a quick post...
I did take a week break. I said I wanted to take a week break earlier, but I admit I kind of "disappeared". Oh well, I'm back
Edit: I stumbled across a few problems with the editor, to really explain them, I'll need a very complicated explanation
There are 3 types of 3d sprites objects: Type 0x24 is found in the level script data, which is uncompressed in the original ROM. This type of object command offers the most flexibility, enabling you to change the sprite type and behavior type independently as well as the behavior parameters. You can change the X, Y and Z position value and the rotation angle for all 3 axis. The 0x42 type (mislabeled as 0x40 in the screenshots and in the editor, its type is not in front of each sub command so I did a little mistake when deciding which label it should have ) comes from commands found at the offset found in the 0x39 command in the main level script. These 3d sprite commands are found inside the MIO0 data for a particular level, they don't actually feature the 0x42 type, they are simply a sequence of the same type of object commands. Each one of these is 10 bytes long. With these you can change the X, Y Z position, but only the horizontal rotation. The sprite type and behavior pointer are fusioned in a single byte+ 1 bit from the horizontal rotation byte. This gives 512 possibilities. The table referred by this value is found at 0xEC7E0 in the ROM. Each entry in the table is 8 bytes long and contains a sprite type value (same kind as the 0x24 sprite type) and a behavior pointer (in bank 13) as well as 2 one byte parameters for the behavior. So with the 0x42 command 3d sprites you are restricted to a specific set of sprite type/behavior combo. It does include 2 bytes that can override the behav params from the table. The list of 0x42 sprites ends with a 0x1E or 00 object type. Now as for the 0x43 3d sprite type. It's found after the solidity data. The solidity data can be found at the offset pointed by the 0x2E level script command. The solidity data is complicated in itself, as there are different types of solidity triangle data. The editor currently doesn't directly deal with the solidity data, but it has to be decoded anyway since its the only way to find the offset of the 0x43 command. Since it's not part of my hacking document, I'll explain it. The first command in the solidity data is 0x0040. It's 4 bytes long in total, including the 0040. The two last bytes are the number of vertex point in the following list. So after the command is the solidity vertex list, with each entry being 6 bytes (signed 16-bits values for X Y Z). So to find where the next solidity command is just skip the number of vertex in the 0040 command multiplied by 6. After the 0040 vertex list, various solidity commands can be found, each of them creating different types of solidity triangles. These are the solidity triangles commands used in the game: "001E", "000E","002C", "0024", "0025", "0027", "002D" 001E works much like 0040 but is instead followed by a list of triangles instead of vertices. The command itself is 4 bytes long including the 001E and the two last bytes define how many triangles there are in the list. Each triangle entry in the following list is 6 bytes. The rest of the solidity triangle commands "001E", "000E","002C", "0024", "0025", "0027", "002D" mainly work like 001E, but their triangle entries are 8 bytes each, so each triangle has additional parameters which meaning varies depending on the command. You may find the 0x0041 command which is only 2 bytes and doesn't load a list. Once all the solidity triangle commands and their list have been decoded, you will encounter the 0x0043 command. The 0x0043 command is what I wanted to talk about. This command makes the game load the following 3d sprites commands, that are in yet another format different than the 0x42 and 0x24 command. The sprite commands following work much like the 0x42 commands but with a twist. The sprite type value is only 8 bits (not 9), and refers to a table at 0x0ed358 in the ROM. The difference in this table is that while the 0x42 sprite type value refers directly to the n'th data chunk in the 0xEC7E0 table, this table at 0x0ed358 uses the first byte of each entry to define which byte will be used by 0x43 sprite type values. What I just found is that if a 0x43 uses a value that is not referenced in the 0xEC7E0 table, it falls back to the 0x0ed358 table... So essentially, the 0xEC7E0 table is patching the first 256 entries of the 0x0ed358 table. By the way if you edit either of these tables, you'll have to recalculate the checksum, unlike the rest of the editable data. The game will also use these table entries in not-easily-predictable ways, as the sprite type they contain, is like the one from the 0x24 command and refers to the 0x22 commands that point to the geometry layout data. These values change depending on the level. So sprite type 0x03 means the castle Tower in some level, and a platform in another level. But for some reason (prevent duplicate table entries), they both use the same sprite type/behavior combo in a 0x43 command. That complicates things because if you edit one of the table entry thinking about one level, you may find weird things happening in another level. So I don't recommend serious hacking of these tables. Because of that and other reasons, editing this table falls into the realm of version 2.0 and beyond. The checksum is not a problem, as I had to do it in the ROM extender. Also... The 0x43 sprite commands have a variable size depending on the sprite type. "7A","7B","79","1D","21","7D": 8 bytes, contains x,y,z pos, sprite type (using 0xEC7E0 or 0x0ed358 table) "83","CD": Unkown use, 6 bytes. "88","85": 12 bytes, like the 8 bytes commands plus 2 behavior params override params plus 2 unknown bytes. "A0": Unknown use, 4 bytes "C0": Unknown use, 12 bytes "00": Unknown use, 10 bytes "CE": Unknown use, 6 bytes "44","42","1E": End of solidity and 0x43 commands list. For any other values before the end of the list, the byte length is 10, and it works like "88" and "85" sprite types without the 2 extra bytes. Bowser for example is a 0x43 command, its type is 0x21. This type happens to be the only 8 bytes type in the Bowser battle levels. So while my editor could switch other object into duplicate Bowsers, I just recently realized/remembered that this would corrupt the game. In the 3 Bowser hack I did, the editing was done manually in hex to get around this problem. So that's the problem I now have to solve. Even if I accommodated the varying length of 0x43 sprite commands it could likely overflow in the following data found in the MIO0 bank. To get around this I would have to copy the solidity data at the end of the MIO0 banks, and change all 0x2E pointers to reflect the new position of the solidity data. Same for the 0x17 commands (0x18 in the un-extended ROM) that point to the MIO0 data. I could make the ROM extender set the end MIO0 pointers to include the 32k of empty space that exists between the decompressed MIO0 data segments. Ok now... Why is it so complicated ... Mr. Miyamoto?  Or maybe Mr. Tekuza could answer?
Hehehe don't worry I'm not delusional. But Mario 64 is very "patchy" in its nature, and it's understandable. Mario 64 was developed at the same time as the n64 itself and the UltraLib API's. That's why I'm sure Zelda OOT will be simpler to deal with, as they learned from their mistakes in Mario 64. It looks like they started by using an 8 bits value for the sprite type, thinking that they wouldn't need more than 256 different object presets. But they they ran out of possibilities, so they decided to use one bit in the horizontal rotation to double the number to 512. But then, they still ran out of numbers, and couldn't easily move things, at a time when they were trying to fit everything into 8 megs. So they decided to add other sprite objects commands at the end of the solidity data, but in a format where space is maximized, using variable length commands based on the sprite type referering to a table patched to make use of new objects while keeping the access to some original sprite types used by 0x42. Between the sprite types used in the 0x43 objects, and the actual polygon data, there are like 5 layers of different data formats. It's not that easy to visualize all these layers and how they interact. Maybe I should make a diagram with boxes and arrows... that would help
Hey that's an idea... even with my lengthy explanations, I'm sure many of you would like to understand the structure of the game in a visual way. I have very good visualization skills, but something tangible like a graphic would probably also help me in this project. That's it for now, these are my days off work so I'll work on the editor as much as I can. Edit: Here we go, the diagram of the Mario 64 level formats structure, or whatever it should be called. I finished it before going to bed last night. 
For a bigger version click this url: http://i26.photobucket.com/albums/c105/Starxxon/M64Diagram.gif (edited by VL-Tone on 07-21-06 12:36 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Originally posted by bloodzero Well this post was not intended for everyone as a whole. Many of these things are findings I did in the last days of the older editor prototype, and weren't explained or documented anywhere. My problem is that I forgot about these unfinished commands from the first version, and I'm only now at the point where latest rewritten editor brings up those problems. This post was also a good reminder that the Super Mario 64 level format is complicated. My editor aims at making the editing simple, but it still requires the whole complicated structure to decode and store things and chose which valid values are available to the user. The graphic I added represents data elements in the game and their relationships. Many commands depend on which memory bank is loaded. (I know I should call them segments... but bank is shorter and conveys a better meaning) Other elements depends on tables that are defined by other data elements that are level specific. Object numbers for 0x24 3d sprite commands are defined by the 0x22 command for example. But let's not get too technical again
I'll try to make a movie of the editor in action, that should be more interesting to some... |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Hello, friends and foes Happy 64th page
First I'd like to mention, the editor cannot be delayed, since there's no release date set. The issues I described in that long post are not that hard to fix, just hard to explain 
I'm still working on making a movie of the editor, I did a few experiments but I'm not sure yet what I'll put in the movie. Any suggestions? Screen recording is a little slow when recording the whole window, so I may only show the 3d viewport. One of the reason the movie is still not done is that while trying to make it, I got the incentive of fixing bugs and implementing missing features like copy/paste and revert, so I guess it's not a bad thing, as the editor is progressing. Next week I'll have a week of from work so I'll have much more free time to try to finish version 1.0. I may release a pre-release beta with saving disabled (which is a good way to prevent this version from spreading all over the web). I still wont commit to even an approximation of the release date, for reasons I mentioned before. It doesn't mean it will be released in a long time either. Aside from that, any suggestions on what should I show in the movie? Any levels you'd like to see featured? As for me narrating the movie, it's actually not such a bad idea. I could describe features and things happening in the movie. But... I'll probably put the M64 credits music instead (edited by VL-Tone on 07-26-06 11:58 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Goomba Fondue, you're weird, not necessarily in a bad way, and you don't have to be sorry about it
I'm taking some of your suggestions into account... Here's a little "teaser" video in mpeg-4 format. It's around 3.6 megs so it's even suitable for dial-up. http://65.111.164.51/Toad'sTool64demo1.mp4 Edit: Raccoon Sam I just saw your post after posting mine. I planned to do something clearer, this is just a little demo movie. It's not easy to coordinate a demonstration session and do it without messing up, it's like movie acting with the mouse pointer
Shiryu I'll try to answer your questions: Is the wing cap switch level the same as the wing cap level where you see mario falling? Same level. if so, then is there an object or level propertipes that makes what's mario current state when the level starts? I didn't find it yet. (edited by VL-Tone on 07-27-06 05:41 AM) (edited by VL-Tone on 07-27-06 05:42 AM) (edited by VL-Tone on 07-27-06 05:43 AM) (edited by VL-Tone on 07-27-06 05:45 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Originally posted by Raccoon Sam Raccoon Sam, since when are you a Mac user? Because the Mac OS had button-bar-button scroll bars since 1984... They were the default until Mac OS X. Other optional variations were added in Mac OS 8-9, like up-down-bar, and a hidden feature enabled up-down-bar-up-down scroll bars like Kyoufu Kawa had. In Mac OS X, by default you get the up-down-bar setup you seem to use. These are nicknamed "NeXT style arrows" since this is how they were in NeXTStep Open System Preferences/Appearance and you'll see that the first option is what I used: "Place Scroll Arrows: At top and bottom". Like I said, this one is just like the classic Mac OS scroll bar. (Please don't call this "the Windows order") Double double arrows are possible in OS X (up-down-bar-up-down). Open the terminal and type: defaults write -g AppleScrollBarVariant -string DoubleBoth And hit return. Relaunch your apps and voila! Double double arrows! Other keywords can be used instead of DoubleBoth: DoubleMax: Default in Mac OS X (what you use) Doublemin: Single arrow pair like DoubleMax, but at the opposite side of the bar. Hidden feature. Single: Like Classic Mac OS/Windows: up-bar-down (available in System Prefs / Appearance) ANYHOO... Like I stated before, my editor will use standard native scroll-bars from your own OS, and they will act just like you set them to in your OS preferences. I don't have anything to do about how the scroll bar behaves in the editor, it's your OS that decides. By the way there's a little mistake in the video demo: the four towers at the end should have yellow boxes as they are selected. There's currently a bug with the paste command, that deselects (visually) a selection after pasting. (edited by VL-Tone on 07-27-06 03:17 PM) (edited by VL-Tone on 07-27-06 03:18 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Well... sorry about the scroll-bar rant. I realize it was a stupid rant and if you add 1+1 you can understand why I didn't feel like posting on this thread in the last few days.
From what I've learned, Beta is a stage where all features are implemented and only bug-fixing is left. I'm currently in the Alpha stage for this editor, which means that some features are still missing. tahu363 please learn to be patient in life. You should know that the video was created with the older version that was since rewritten almost from scratch into the current development version. This older version was hard coded for the older ROM extender format and won't ever be released. The new one is much more flexible regarding the ROM format, and many other things. The current version couldn't be released. It would generate errors too often and you'd have to restart it each time. To me it's useable because in the development environment, errors like this just stop the playback, and I can quickly restart where I was without having to reload everything. I'm having a week vacation from my job starting today, and intend to stay here. I'll have much more time and motivation to work on the editor. It's possible that by the end of the week, I'll be close to release at least a demo with no save function. But it's also possible that it will be later. I'm not teasing anyone, I just don't know and don't want to be tied to a release date for now. Goomba Fondue: Bravo! you basically nailed it. (tahu363 brought a good point but then went on a crazy rant... ) The behavior code contains pointers to an animation index in a format I don't know much about yet. The meshes pointers for each body parts are stored it what I call the "geometry layout data" for a particular 3d sprite. But what defines the mesh numbers used by the animation data is not so obvious. The meshes are arranged in a hierarchy which I think is a BSP tree. For now, 3d sprites with bone animation will be a weak point in this editor, as they wont display correctly. Fortunately, the level and platform meshes are not animated. I must also warn that the editor might have some z-sorting issues in some situations. I'm trying to get around that bug, but it's a Shockwave 3d issue. I'm thinking about renaming the editor "DoesntEditPolygons 64 1.0b" (edited by VL-Tone on 07-31-06 02:28 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| First, great work on MK64 HyperMackerel
I'm not sure if this will answer your question but here's how to know the width and height size of a particular texture, from the F3 command. It's not obvious and wasn't totally explained in the two M64 threads and in my doc. Do the following operations to get the actual pixel width and height of a particular texture.
I hope it makes sense to you and that you don't already know all this |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
| Dang I'm so glad that I don't have the weight of the other thread on my shoulders anymore, seriously...
Maybe others are better to deal with this kind of pressure, but it was too much for me and I felt the other thread was so full of... filler content and redundancy. So here's the deal. I'll give you some updates and post here when I feel like it, but don't ask me any questions in this thread until I release the editor. Feel free to ask "legitimate" questions here, but don't direct them at me, I won't answer them (sorry!). Also, don't redirect questions to me.It's not that I don't want to share info or anything of the sort, I just don't want this new thread to become the "ask VL-Tone" thread like the other was. Now about Toad's Tool 64: Don't worry I won't suddenly cancel or abandon the editor. I still won't give you a release date, but the editor will be released before the tenth anniversary of the US n64+ Mario 64 release, which will be this September 29th. I don't want to have to justify the time between my post and updates here. I may go another week without posting here, we'll see... I'll take the time I want to complete the editor, but I want it to be out before Sept 29th. One major milestone in the editor progress: the feature set and interface layout is pretty much frozen now, which means I'll stop wasting time deciding which features should be included and how they'll work. The last main feature I added before freezing the feature set is the ability to save up to 8 camera sets for each level. Each camera set will contains positions and rotation for the top/bottom/left/right/front/back/fly/orbit camera. I felt it was important to add this feature as 3d editing requires you to often move the camera. By saving/loading camera positions, you can easily get back to a particular view of a level that you were editing. I'm glad to see you guys starting to do some manual hex hacking of M64. Just keep in mind that while the 0x24 object commands are relatively straightforward, the 0x42 and 0x43 objects found in the MIO0 data are not that simple. Jenscomposer said that I did not share info about these commands, well it's not true, though it took me some time before publishing all the details about it. Remember that big post that many people said that they didn't understand half of it? The one with a graphical representation of the game structure? The info about these object commands is all in there... And the complexity of it shows why the editor is not as simple as only editing the 0x24 commands. Warning, the rest is pretty much off-topic. Guy Perfect, If you read this: I removed any mention of a "sprite" in my editor to avoid confusion. I'll call the 0x24, 0x42 and 0x43 commands "3d objects" instead of "3d sprites", and the "sprite ID" has been changed to "model ID". I think though that your definition of sprite is skewed. I come from a parallel world where a sprite is more of a container with parameters that can display an image, not image itself. To me, sprites are discrete image elements that have a x,y position and optionally some display parameters. Maybe I'll post something about sprites in another forum on this board, because I feel I have many things to say/debate about it, and I don't want to get this thread out of topic. But one last out-of-topic thing: Voxels... Guy Perfect this is not aimed at you since you seem to understand the meaning of voxels. It's more about the following posts about voxels I found in the other thread. As the author of Metroid Cubed (and other voxel based demos/games), I cringe every-time I see someone mentioning Novalogic games like Red Alert as using voxels. Sorry but height map terrain generation using vertical lines is not what I call a voxel-based engine. Novalogic call this "Voxelscape" but that doesn't mean they're voxels. At best (to me it'd be at worst) you can heavily skew the definition of voxels until it fits the Voxelscape concept, but at least, when you mention NovaLogic, please mention it's a very limited and non-standard sub-set of voxel technology. Again, I don't want to start a debate about this in this thread, if anyone wants to debate with me about the definition of sprites and voxels, start a thread in another forum on this board (and tell me about it). (edited by VL-Tone on 08-10-06 02:40 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6100 days Last view: 6100 days |
| ||
Originally posted by jensthecomposer Bahh I should be the one that's sorry not to have put that in the hack info doc.
About Tile Molester, I guess that an endian issue when its ran on a PPC actually "fixes" the byte order problem for me an Raccoon Sam :/ It's a little too late for me to make the editor deal with a byte-swapped ROM. Maybe you could byte-swap it, do the texture changes and de-swap the bytes after. But that would be a pain... I guess I'll have to include a texture import/export feature in the first release. |
| Pages: 1 2 3 4 5 6 7 8 |
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
