 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by VL-Tone |
| Pages: 1 2 3 4 5 6 7 8 9 10 |
| User | Post | ||
VL-Tone Red Cheep-cheep Level: 23  Posts: 181/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Cellar Dweller, That's great info, and it will be useful for sure, since it seems the only easy mean of repointing this MIO0 data. Ideally though, I was looking to do the equivalent of changing a 0x18 command (load MIO0 data into a RAM segment) to a 0x17 command (copy uncompressed ROM data into a RAM segment), and repointing the uncompressed data to the end of the ROM, extending the ROM file. It works great and enables direct editing of decompressed MIO0 data right in the ROM. The main interface MIO0 file (Fonts , icons etc.) at 108A40 is one of the only MIO0 file not decompressed with a 0x18 command. Do you think it would be easy to achieve the equivalent of 0x18 to 0x17 switching for the 108A40 file? Originally posted by OmegaPirate The Mario object is inserted into a level using a 0x25 command. I tried to modify the parameters but the best I could do is render Mario invisible  Now Mario seems to be a special object, made of smaller objects, which are his body parts. At 0x2ABCA0 in the ROM, is one of the shared level loading script. It loads, amongst other things, the Mario MIO0 file, then uses 0x22 commands pointing to body parts in the file. Each part is assigned an ID number that is used by the game engine.2ABCA0: By modifying this area of the ROM, it may be possible to change Mario into something else. Maybe it's possible to load another MIO0 file instead, and re-associate the body parts, but other creatures don't use 0x22 commands as far as I know. Their body part arrangement comes from their geometry layout data, which uses another set of commands. Anyway I'll try to transform Mario into Yoshi later tonight, as I didn't experimented yet modifying the values at the start of 0x2ABCA0. The Princess hack was done at the geometry layout level. In the mean time, you can try swapping the ID numbers for body parts and see what it does!  |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 182/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker Yes that's what I figured out, but I'm wondering if changing this custom call from a "decompress and copy" to a "copy only" command would be as easy at the ASM level. I thought about making a program that transform a Mario 64 ROM to a more editable form. It would automatically change all 0x18 commands in the game to 0x17, relocate all the decompressed MIO0 data after the end of the ROM and repoint the 0x17 commands accordingly, with plenty of padding between each segment so that we could expand them individually without having to move huge chunks of data. The resulting ROM would be then much more easy to edit by an editor. All the MIO0 files decompressed are less than 8 megs, so the ROM may be 16 to 32 megs depending on the padding we want to put between segments. Maybe 24 megs could be a good compromise. But at the price of HD's these days, why stop at 24 megs? It shouldn't be that hard to make such a program, it could be done by generating the padding files, then merging it all in order with decompressed MIO0 files and the original 8 megs ROM. The 0x18 commands locations could be pre-scanned and the new offsets pre-calculated. Anyway to make this one, I'll have to dip my toe a little deeper into C++. In other news, I didn't try to transform Mario into Yoshi yet, but it seems like a lot of manual work, matching body parts. By the way Zelda: OOT looks much more easy to work on, and it seems you can easily put any characters into any levels, as each polygon object is stored in a single YaZ0 file. Not so in Super Mario 64, as specific sets of objects are bunched together into MIO0 files, and different sets are loaded in each levels (though some are shared, like trees, doors, coins, stars etc.) "In the future" a Mario 64 editor may provide more flexibility by letting the user choose which object sets are loaded in each level. I'll try to gather data from the original level scripts to build list of possible 0x22 commands pointer values, and which MIO0 file they are targeting. That could give us a picture of how objects are distributed among levels and MIO0 files, and how much flexibility is possible. 0x22 commands are actually pointing to "geometry layout" data loaded by a 0x17 command. The 8 bytes 0x15 command inside the geometry layout data then points to different geometry data inside a decompressed MIO0 file. I'll try to put up a much improved Mario 64 hacking document that will list all commands I know about, and some info about the structure of the game and the way courses are loaded at the script level. (edited by VL-Tone on 10-13-05 03:39 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 183/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker Almost all graphics are part of the compressed MIO0 files. I'm pretty sure that only the Mario face demo uses uncompressed graphics at other places. Music files are very small (compressed midi files), though samples may take some more space. But yeah it's a good idea to keep some free space for other things, I didn't know about the 32 megs limitation. So maybe 24 MB could be a good target size. 8 MB for the original ROM data, 8 MB for the uncompressed MIO0 files, and 8 MB distributed between each decompressed MIO0 to allow flexibility in expanding them. Also remember that space currently occupied by MIO0 files would then become available for other things. tachyon I would help you if I could, but I can't... |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 184/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by Cellar Dweller So is there a 32MB limit on ROM size? As for compressed data, it's not that I'm to lazy to code a MIO0 compressor, but is there really any use at keeping the compression? Anyway I'm not totally against it, but I would like to know of any reason why we should keep compressed files. Ok I must admit that the reason I'm inclined to get rid of the compression is that it's too slow in Director/Shockwave (which is, unfortunately, what I'm more experienced in). The rest is fast enough, it has a relatively fast OpenGL or DirectX driven 3d engine. As I said before if anyone with good C++ and OpenGL experience wants to build a Mario 64 level editor before me I won't mind at all, but if I want to make my editor progress, I need to get rid of the compression. I'm thinking of learning C++ to make a simple program that transforms the ROM into a directly editable uncompressed version that doesn't require to write too much data on saving. By keeping space between the segments in ROM, it avoids having to move big chunks of data when a segment expands. One way or another, the ROM needs to be expanded and MIO0 segments need to be relocated after 0x800000. So I will try to offset this process in C++ to get the needed speed. Once the ROM is transformed, it can be edited and used as is. An inventory of the assets is a very good idea, but I don't see how compression can help that. By the way from my brief encounters when digging Zelda: OOT, I realized it's organized in a much better way, and that there is probably a directory of all assets somewhere. Mario 64 doesn't have that, as you said you have to walk the script to find offsets for the different parts. Most offsets refer to RAM segments and we have to keep track of which data is loaded in which segment. My current editor does that, and it has too, since there is some skipping between segments happening in level loading scripts. That 0x24 command used as a no-op should be very useful along the way of improving the editor. I wish I found a similar command to use in StarFox. Ok, I'm on my way to make an improved Mario 64 hacking document... |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 185/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker RAR, ZIP or GZIP could do the same job to compress a patch as MIO0. And also, blank space can be compressed by a large amount, to only a few bytes. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 186/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker Why? Because I have no choice, Director/Shockwave is too slow in itself to decode and encode MIO0 files at a reasonable speed. My solution for my particular problem was to have an external C++ program preparing the ROM for more direct editing of the file. I guess I could make my editor call another external C++ program to re-compress MIO0 files and reinsert them. Anyhow what I was proposing was a much easier solution for me and I didn't thought that "wasting" 8-16 megs on a multi-gig HD was that bad (for the environment I guess?). I never proposed that it was the best way to do things, or that other people working on an editor should do the same. I'll stop dragging this thread into my own development platform problems, and I'll deal with those myself and with the help of people on another site, since I guess everyone here that could help me solve my "particular" problems will tell me to change dev platform and learn C++ and OpenGL. I'll still post everything I find in Mario 64 on this thread, and any future public release of my editor, but I guess that I'll be less pro-active. I'm not mad or anything, but I'll stop wasting your time with my choice of development environment. Bah ok I have to admit, I'm somewhat mad... not against any of you... but against myself and the situation itself. Oh well I'll calm down, it's just a thread on a forum on the internet after all... |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 187/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by HyperHacker Ok then everything is fine, everyone is happy Forget about my rant, I had a stressful day at work...Edit: I made a major update to my Mario 64 ROM hacking doc found at http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt Since some are too lazy to click URLs I'll paste what's new (it's very long). ------------------------------------ (edited by VL-Tone on 10-17-05 10:38 PM) (edited by VL-Tone on 10-18-05 03:10 AM) (edited by VL-Tone on 10-18-05 03:15 AM) (edited by VL-Tone on 10-18-05 10:48 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 188/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by Spekkio My Mario64 prototype editor is not online anymore, it was very limited, only could change a few objects in one level and had a some flaws that made it not so useful. I could put it again online, but only when I moved to my new host. The version I'm working on is improving and is able to open just about every level, but it will take some time before I can release a new version. Let's say that before the holidays I'll publish a new version (edited by VL-Tone on 10-18-05 03:07 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 189/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by Santa Claus Yeah that's the joy of copy and pasting There were 2 other similar mistakes that I fixed. I also changed 2 things because I figured out how they work.First is the 0x1F command:
I found out that this command not only loads the geometry data for an area, but also marks the start of an area inside a level (ie. bonus slide), and command 0x20 seems to indicate the end of area specific data. Byte 3 in the 0x1F commands seems to determine/assign the area number, that can be used by the 0x26 warp command for example. By the way, I successfully merged my newer decoding engine with my old editor, and it can now show and edit %90 of all levels, and thanks to my discovery yesterday, you can select which area to edit inside a level. For now it still edits the 0x24 objects only, but it displays the objects loaded from the 0x39 command too (which are inside a MIO0 file, these are the object that you guys made a list for). You'll have to accept the following limitations if I release the new editor anytime soon: it requires that you uncompress all MIO0 files from Mario 64 and that you put them in the same folder than the editor. Each file must have its name representing the address where the MIO0 file is found in the ROM. This is the way the MIO0 de-compressor N64UNC found on Dextrose automatically names its output files, I'm not sure if the other MIO0 de-compressors work the same way... I'll probably make the 0x39 objects editable, but it will require people to deal themselves with inserting the data back into the game. (The 0x24 objects are uncompressed in ROM so it won't require that.) I'll probably add something to edit the music bytes, and I'll work on an interface that would enable to change other things like the 0x22 commands and warps. For now, it will still be cubes representing objects, but I may add the option to make it draw them as is (which currently doesn't always work for all objects, and they don't appear in the right scale) So Santa I'll probably release something much sooner than expected, before the holidays even start (Edit: proof reading? what does it mean?) (edited by VL-Tone on 10-18-05 11:15 PM) (edited by VL-Tone on 10-18-05 11:20 PM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 190/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| I've seen very good graphic and level hacks lately that probably required hours of work, and congratulation to the authors, but I can't help it, I just love that kind of graphic hack concept that is Super Mario Bros. Transparent! I actually like it better if applied to the original levels. I still love to play the original levels once in a while, and it's surrealist twist to to the original graphics. Shane you got a very good idea there, I look forward to the completed version. Did you think about doing a SMB 2 and 3 version? The only thing is that I would like to see bricks that look more like bricks, but maybe it would lessen the "transparent" aspect... I don't know really, just some little nit-picking Aside from that it's really neat visually, even more on a black background where it looks like a transparent "neon" effect. The ASCII hack is also very interesting, though less visually pleasing |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 191/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by Santa Claus Yeah I'm starting to learn D++, I just can't get enough of D++ Seriously, I have years of experience in programming, and I know I could learn other programming languages quickly, but learning C++ and OpenGL at the same time to do this would require me too much time to be able to build a Mario 64 editor. Even if I did learn those two, I would probably still use Director to prototype stuff, simply because it's much more easy on the brain, if just for the coding legibility, I find the use of { and } to be a bad typography choice, as those two looks the same when your eyes do a quick scan of a listing. For that and many other reasons I find It's much easier to test code parts with that kind of development environment, and then port the code to C++. You know it's like using C++ to prototype code that will latter be implemented in ASM, which I don't think is that rare even for experienced programmers. That being said, I will look into some dev solutions that are not Windows specific, trying to gauge how hard it could be for me to port my editor. For now though, expect any future release of my editor to still not include built-in MIO0 decompressing or compressing. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 192/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by Santa Claus I gave the example I had on the top of my head. I don't think that indentation totally solve the issue, as it doesn't remove the requirement to use { }. Those have more meaning than indentation, so you still have to take them into account when reading code. I guess it's nit-picking, if you take just this example, but as you said "There are plenty of reasons to complain about C's readability", and this is what I was implying in my post. Anyhow, I said that I'm looking to start learning C++ more and probably OpenGL, so I don't want to "debate" about why one should choose C, I was stating the reason why I think some higher-level language can be good for prototyping code and interfaces, even when you know C++. I'm reverse-engineering Super Mario 64 because I love doing it, I'll take the time I need to choose what solutions I have to get past the compression problem. In the mean time, I'll continue to evolve the Director/Shockwave version, and probably release a version "not intended for the general public". But could we please move on? I guess I'm the one doing all the blabbering about that, but I don't think anything good can come out of having this discussion about C++ in this thread. I feel like I annoy many people when I talk about this, and I always look like the one who "over reacts" in situation like these. The last thing I want in this context is stalling the evolution of Super Mario 64 hacking because of issues like that. I may or not ever release a fully featured editor supporting compression, like I said before, don't count on me, I'm providing a hacking tool. There is now enough info in this thread for someone to build a very useful Mario 64 level editor, so what are you waiting for people? -Now back to our regular program- In the ROM 21CCDC replace: 0C 00 00 00 80 2C B1 C0 0C 00 00 00 80 29 CA 58 0C 00 00 00 80 2C B2 64 with: 0C 00 00 00 80 29 CA 0C 00 00 00 80 29 CA 58 0C 00 00 00 80 29 CA 58 And you get super turbo charged Mario! He runs faster than Sonic! Some little glitches here and there but it's really fun! Mario runs faster, swims faster, and flies faster with this hack. But he also gains some mass, as he cannot jump as high Oh and yes I'm aware that some gameshark code can make Mario faster. This one can be made permanent on a ROM though, also there are other interesting Mario related things around there since it's the location of the Mario "behavior code" pointed by command 0x25 (see hacking doc).I posted the other day something about replacing Mario with some characters and that some 0x22 commands where exceptionally used for individual Mario body parts. Well I was wrong, the 0x22 commands found at 02ABCE0 do point to the Mario data, but as whole animated objects, not body parts. Mario is only one of these objects, the first one at 02ABCE0: 22 08 00 [01] [17] [00 2D D4] 01 is the number assigned to Mario. The rest is the segment and offset where to find the Mario geometry layout. Segment 16 is containing many geometry layouts for shared objects like coins, doors trees etc. You can copy paste the last 4 bytes of the other 0x22 commands to replace the 17 00 2D D4 with something else and transform Mario into many other objects. Only copy from 0x22 commands that point to segment 16 or 17. Flat objects like coins and trees are only visible when Mario faces the camera. In theory, it will be possible to load some other MIO0 file and then simply re-point the Mario 0x22 command. Here are possible values for segment 16: 16000388 160003A8 1600043C 160004D0 160005F8 1600068C 16000720 160007B4 16000868 1600091C 160009D0 16000FE8 16001000 16001018 16001048 So at 2ABCE4, replace the 17002DD4 with any of these values to transform Mario into a pipe, a tree or a door amongst other weird things! (how impressive  )I'm trying to find ways to load other MIO0 files to use Yoshi or Mips for example. I don't promise anything, but it should be easier to change Mario into something else than expected. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 193/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by BGNG Ok, I guess I should have been clearer on what I meant by "not Windows specific". Yes I meant multi-platform, but I was under impression that it was a well known fact here that I'm not working on Windows or DOS, nor Linux, because of my rant in the Hardware/Software forum. But I guess that you didn't know. My native platform is ehm *cough* Mac OS X *cough*, I have friends who use Windows so I can test stuff there, and I can run DOS in an emulator (I could run Windows too ,albeit a little slowly, but I lost my Win 98 boot disk image). Macromedia Director/Shockwave can produce programs for both platforms, so it didn't really matter until I realized that the disk I/O routines were too slow to move large chunks of data, and that my Shockwave MIO0 decompressor is too slow to be useable (though I guess it could be optimized). That's one of the reason I was not too keen to mention it before that point, because it didn't really matter and I didn't want to be labeled with pre-concieved ideas. OS X is a FreeBSD UNIX variant, and most Linux/UNIX programs can be recompiled without much change. I recently ported the YaZ0 decompressor with only one small change. By looking at it, I could probably port the MIO0 compressor and decompressor too. But anyway it doesn't matter much to you I guess. All that to say that FreeBASIC looks like a good solution, and the fact the source is written in FreeBASIC is really neat, but it's not natively supported on my platform even though it would be probably easy for them to port it. I'll try to find another solution, and many exists, to support all three platforms. Don't bother looking for me if you don't feel like it, and I suspect you won't. I assume that a somewhat large percentage of people on this board have negative views of Mac OS X. I can understand that, for anyone interested in video game ROM hacking, because while OS X has zero viruses, it also has just about zero ROM hacking programs, aside from a few emulators, IPS patchers, hex editors, UNIX ports, a GBA devkit and my own level editors. The Windows hacking tools and editors can be run in emulation (Virtual PC), and next year when I buy an intel equipped Mac, it will emulate them at 80%-90% of the native speed using the Mac port of WINE. But anyway for people doing ROM hacking on Windows (probably all of you ) the Mac is simply not a viable platform for them and I don't see how I could argue otherwise. Still, this is the platform I chose and like, and I happen to like to hack ROMs and reverse engineer them with tools I build myself, I don't mind the limitations and lack of tools, I learned to appreciate the challenge of it. But what should I do? Should I stop contributing to this thread because I don't use the best and latest tools to reverse-engineer Super Mario 64? Should I put a warning in my sig? If so, I guess it's another sign that the ROM hacking community is in a sad state...So, now you know. Sorry for the off-topicness, though it's relevant in a way. Don't worry I don't have anything to add. Ok, I'll add just a little useless "fun" fact. Try to guess what the president of Nintendo Satoru Iwata uses as a personal computer, see the answer in the link: http://pages.infinit.net/voxel/IwataTGS2005.jpg |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 194/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by BGNG Yeah actually Tile Molester is one of the few ROM hacking tool that can run "natively" on the Mac OS, thanks Snowbro! (Yeah I like to thank him, he started it all!  )I had Java in mind before, but got under the impression that it was not very good at 3d graphics. You seem to say that it's not the case, and I believe you, but I'm pretty sure that Java cannot drive OpenGL inside a web browser without downloading something extra. Anyway I don't mind, it's not a requirement for me that it works online, even if I did publish online demos of editors in the past, like the StarFox editor, which was not exactly "good" since it had to contain part of the ROM data. There was one version of Director in the past that supported "exporting" to Java directly, but it only made sense for small programs, and many things wouldn't be translatable. Some helper would tell you which lines to change, but for anything big it became too complicated. The feature was latter dropped. The current version of Director does supports Java syntax for scripting, which will probably help me make the transition, even if I currently mostly use the Director/Lingo syntax which is not so far from Java anyway. So Java it will be I keep getting recommendations for AJAX, so I guess I'll give it a try. I don't know why I got so inclined to go to C++, maybe because I needed raw power. But Java is also on the list of languages I want to learn, and I kinda forgot how fast it was for disk I/O.Santa Claus: I have a picture of Miyamoto San himself having a Mac at his desk, but it's an old photo so it doesn't mean he still use them (though I would personally assume so). Nintendo does use Windows for part of their development. Intelligent Systems http://intsys.co.jp which is a spin-off of Nintendo's R&D1 (or are they R&D1?), is responsible for such games as Metroid Fusion, the (Advanced) Wars series, Fire Emblem, Panel de Pon (Tetris attack) and others, is also producing some of the Nintendo development tools for the n64, GB(A), DS and Gamecube. If you look on their page you can find that many of these tools also exists for the Mac OS, which implies that at least Intelligent Systems uses some Macs to make Nintendo games. I know it's a drop in the ocean of Windows using developers, but I just wanted to dispel the myth that only dumb people buy and use Macs. Many people that you admire use them, and not necessarily just because they look "cool". But let's move on, I'm starting to learn Java, which is by definition cross-platform, and I expect to learn it pretty quickly considering my years of experience at programming in a not so different language. So I guess I'll try to port my Super Mario 64 editor to Java piece by piece (first the level decoding routine, then the 3d part). |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 195/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| The Metroid transparent really looks (to me) like a "slice" of my voxel based Metroid. You guys never seen a slice of a Metroid Cubed scene, but I did, and it looks something like that (since most object are hollowed). Anyhow Shane -26-, don't worry about the de-sticking, it doesn't mean your project is not cool, it got very positive reactions overall so I hope you are still working on it! Edit: Ehmmm... I didn't read the "other" thread about SMB transparent before posting this...Oh well, I thought it was a neat idea, I don't read much of the other threads these days and that one seamed to stand out, so that's why I got interested in it. I never thought it deserved a sticky though. (edited by VL-Tone on 10-22-05 01:32 AM) |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 196/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
| Oh wow that's just fine...I add my second "innocently" positive post on the Super Mario Transparent thread, but just AFTER posting I find this thread... Yeah, just fine... /end sarcasm The M64 thread is taking enough time of my life as it is, I usually don't take the time to read the other threads here these days, unless something stands out or deals with my favorite games (which are few). In the first positive comment I posted in the SMB transparent thread, I took the time to explain that while I saw many very neat level and graphic hacks, I liked this one too even if it need much less work. I don't have time to congratulate everyone for all the great hacks that get published these days. I'm very impressed by what many do here but I just don't have the time even look at them, even less post a comment on each of them. I'm an older gamer, I have different tastes and a different nostalgia about very specific games, so while a complete level and graphic hack for Final Fantasy 1 deserves praise, if it's only for the effort involved, I simply doesn't see myself posting a comment on a FF1 thread simply because the game doesn't mean anything to me, as I'm not an RPG fan and played the game for at most 30 minutes in my whole life. I can understand that not everyone can see a value in the result of SMB transparent, but it seems that people "on the other side" cannot understand why others could have other tastes. Some of you in this thread, including Disch seem to attack (maybe indirectly) anyone that posted positive comments on the other thread by saying it's the worst hack ever and things like that. The problem is that your frustration comes from the number of people that posted positive things on this particular thread, compared to threads on much more evolved hacks. Well nobody here in particular decided the number of people that would post positive things there. Blaming each of the individuals is the wrong thing to do. If only one person posted a positive comment about this one, we wouldn't have this thread... What do you expect with your rant Disch? That everyone will be afraid to post positive things on hacks that require less than 50 hours to do and that automagically only "good" extensive hacks will be posted here? Unless something in the rules forbids a hack like SMB transparent to be posted, it shouldn't work like that: angry mobs of users trying to impose what type of hacks should receive positive comments. How about making a sticky: "Don't post positive things about an easy concept hack, or some user will get angry and start a thread that all the other angry users users will join to blast your post" I guess that the fact that the "other thread" was posted as a sticky for some period of time didn't help things, I never thought it was a good idea to make it a sticky, but I thought "the mods are always right". I would have posted in the thread if hasn't been a sticky anyway, because I'm dumb it seems So muchos gracias, have a good night. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 197/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by tachyon Don't be sorry, it's hard to find There you go, here is the address: http://www.dextrose.com/index.php?s=3&m=8&f=270#f270 |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 198/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by tachyon I used .Z64 when I used the program (in DOS), or maybe it was .n64? Anyway it's the ROM you have to open, the program will search for MIO0 files inside the ROM for you and extract all of them in one sweep. BGNG: That Java 3d API looks really neat, I'll look more into that... I did some work on my editor lately, I'm currenting experimenting a new interface layout. Please don't mind the gaps in the interface, they'll be filled by future features, and I'm currently shifting things around. Just to be sure it's clear enough, this is not a release, it's a peek into what I'm experimenting with the editor.  (Dang this time I used photobucket!) If you click "Load Level" you will be presented with a list of every level in the game and its sub areas that you can click to load a particular level area. For now there are a few areas that won't load. The white text list in the upper left corner is to select what kind of objects you want to edit in the game. If you select Objects (0x24), the editor will behave much like the old version, but with some new things like the list of object you find just below the edit mode list (small green text). By clicking on lines on this list you can select an object to be edited with the interface at the bottom. The same applies to the other edit modes. The 0x39 objects, which I call "Macro Objects" because they can spawn multiple objects, like 3 Goombas at the same time for example, or coin formations, are called by a single 0x39 object found in an area, which reads a list found in the main level MIO0 file. They are represented for now in the 3d view as blue diamonds, and the 0x24 objects are still tri-color cubes. When in Macro Object editing mode, a different kind of list is presented with a description based on the list of objects made earlier in this thread. I'm also implementing an editor for the music values for each area (easy), and warp values (not so easy). Many other types of object editors could be added to the list, for 0x22 commands or 0x18 commands for example. Maybe I could put an "expert mode" where those would appear. I have other kind of features in mind, like camera position bookmarking, where you can save camera positions to go back later. I added a feature where the camera will automatically position itself to have a good view near an object that you select. Ok that's it for now, I gotta sleep sometimes , and I work more early tomorrow. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 199/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by tachyon Hmmm, first, are you sure you get a MIO0 file that is the same size? You can't just insert a differently sized MIO0 file back and thus making the ROM a different size, because even if your emu didn't warn you of a wrong size, the game will more than likely crash when run. So first, verify if you get a MIO0 file of the same size when you recompress. If it's the same size, paste it over the original. If it's smaller, paste it over too, but keep the rest of the data so it doesn't change the ROM size. If it's bigger you'll have to extend the ROM and paste it somewhere else in the extended part. For both a bigger and smaller MIO0 file, you'll have to find the 0x18 command that loads the file (sometimes there are a few of them) and change the start AND the end pointers so that they match the new MIO0 file. To find these commands, you can usually search for the MIO0 file start address, and almost all the occurrences you should find are part of 0x18 commands. You can also change the 0x18 in the command to 0x17, and paste the UN-compressed version of the MIO0 file into an extended ROM. Don't forget to change the start and end pointers too. That way you can edit bytes directly into the ROM without having to re-compress and insert the data each time. In other news, I started fixing my pictures in the first 7 pages of this thread, which were 404. I'll continue the rest in the next few days. |
|||
|
VL-Tone Red Cheep-cheep Level: 23 Posts: 200/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by tachyon Look at the format of the 0x18 command earlier in the thread, it always begins with 18 0C. So you should find 18 0C a few bytes before the pointers. As for the compression, it's not even a matter of a good or bad implementation. You should understand that even a single byte change can change the size of the compressed file, and you can't really predict what the compressed size will be until you compress it. Actually, if you change something and the re-compressed file is the same size, then you were lucky... (Edit: 200 posts! Wow did I really post 200 times?) (edited by VL-Tone on 10-28-05 12:15 AM) |
| Pages: 1 2 3 4 5 6 7 8 9 10 |
| Acmlm's Board - I2 Archive - - Posts by VL-Tone |
