 |
| 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 |
| ||
| Well the first GUI based Notepad program released in a commercial manner was included in the original Macintosh in 1984. Actually it was a "Desk Accessory" which is kind of like the Widgets are in Konfabulator or OS X's Dashboard.
It was included in Mac OS 1-9, but was retired starting with OS X. But anyway there always been a bare-bones Text-editor included with the Mac OS, called TeachText, then SimpleText, then in OS X it was replaced by "TextEdit" which is also basic but also includes powerful features. It can open Word .doc files, do spell checking, render html and many other things. But enough Mac blabbering. The dialog for BinaryIO is small, includes text some text about registering it and an OK button. It is the only annoyance, and it doesn't prevent you from using the editor. Again I have to state that the editor is and will always be Freeware! I won't personally nag people to donate for the license, but obviously I wont refuse if someone donates the license. Here are the good news. After some preliminary tests, I found that I can load all 131 possible data segments in memory in 8 ticks! That's more than 8 megs of data, in 8/60th of a second, and on my dinosaur Mac. By comparison, with the old built-in byte by byte method, it would have taken 5 minutes 
There will still be some little overhead since Director cannot store raw byte data in variables. In this case the BinaryIO copies the bytes as text in a variable list, so to read them I have to use the chartonum() function. BinaryIO can also read bytes in a more "numerical" fashion, as signed integers, long integers, float etc. but it can only read one of these at a time. The command I used in my experiment can load multiple bytes in one chunk, but only as text. But anyway its the best way to store and access bytes in a variable in Director, without using an I think I'll do a major rewrite of the editor, it's getting too patchy, as I added special cases to deal with objects formats I just found about. Yesterday I imported the main decoding routines in a new project. I'll work on making them read the data from the segments stored in variables using the Xtra, instead of using the old method. After that I'll have to decide if I recopy the new routines to my old project, or if I try to build a new one after it. It could end up being faster to do that instead of trying to work with the patchy version I have now. The current editor evolved from nothing, and grew as I discovered new thing in M64, and incidentally parts of this program was used to reverse-engineer the game. I should have separated the two before, but it's not a bad situation. Now that I have a clearer overview of the format in my head, I know I can write new version with simpler and optimized code, and I already experimented with different interfaces. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| I was hesitant to do a rewrite, but now that I think about it, it will be more easy and pleasant to start from scratch. I won't completely start over, as I will use some parts of the "old" code too, and reuse parts of the graphic interface.
The only important thing missing is that I don't know how articulated objects are built. As I said, I'm still puzzled about how to find the position of the body part joints on objects like Mario. I know how they are stored as hierarchies, but this data doesn't include position of these parts. For now, I'm stopping there, finding how this works is looking to be very complicated. Cellar Dweller was on this particular case the last time he posted, he may be the one that brings the answer to this problem. Still I will consider the possibility that he may not find the answer, so I will build my editor around this limitation. It's very propbable that objects with animated articulations won't display properly in version 1.0b. Static or rotating objects are fine though. There will be boxes around every objects (that you can hide if you want), so you'll be able to select and position invisible objects. Menus will have descriptions so you can chose these object types even if they don't display. I don't mind having this limitation in version 1.0b, it's more of a cosmetic thing than a functional one, even if visual cues are useful too. The tool will still be very powerful for what it will do, and will lead to interesting discoveries... By the way I've found the beta yellow fish found at the bottom of this beta Mario 64 picture: 
More about it soon... Edit: And soon enough, here is more about it: 
I don't know which behavior pointer it should use, so I used some static object behavior, though I could try to use one from another fish. (edited by VL-Tone on 02-14-06 04:25 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by BGNG Oh crap, it was late, I was tired and the only place I remembered seeing this fish is in that beta picture... And the description of the picture said that this fish wasn't in the game. It's the description's fault  Also, I found that it was "loaded" in Wet-Dry World using a 0x22 command, but is not used. I didn't search much more though, as I would have found it in Dire Dire Dock... Currently, DDD doesn't load anymore in my editor, since I recently implemented the decoding of special objects positions in the solidity data. There must be a command that I didn't define a length for, it's only a matter of finding its length (trivial).
Anyway, next time I find what I think is a beta object, I'll make sure it's not used in the game! As far as I know, no Mario 64 beta were ever leaked. Here is a very small video from the beta version, dating from 1996 that only few of you may have seen: ftp://www.gamezero.com/video_files/mario64.avi I had found this video a while ago trough archive.org, but I traced back the website that was credited at the end of the video (gamezero), and it still exists!. The site has archived content dating from 1996 until now! The site owner seems to have some fixation with cartoons of muscular women, anyway I just wanted to warn you if you visit the rest of its site |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Raccoon Sam: These old .avi files would play on Quicktime in OS 7-9 with a plug-in called "intel indeo video". But this plug-in wasn't rebuilt for OS X.
Fortunately you can use a program called VLC to play the video, it can play just about everything QT cannot play (including DIVX and others). For WMV files, you may be interested in the free Flip4Mac WMV QT plug-in, which enables you to play WMV videos in Quicktime. To download the Mario64.avi instead of having it opened by the QT plug-in, option-click the video link or do a right-click and select "Download file" (edited by VL-Tone on 02-15-06 02:00 AM) (edited by VL-Tone on 02-15-06 02:01 AM) (edited by VL-Tone on 02-15-06 02:11 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Well thanks for taking care of the video mirroring, transcoding and everything
By the way BGNG, ogg video does play using VLC on my machine. (But I still needs a new computer for other reasons) So what do you guys think about the video? I remember seeing part of it on TV in 1995-96, I wish I had a full resolution version... Anyone got any idea on how we could find this? Maybe contact some old video-game magazine that were there at the time? Or the guy that runs that game-zero site? I'm sure someone somewhere has this on VHS... (edited by VL-Tone on 02-15-06 11:30 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by BGNG Cool
Edit: I deleted the rest of the post, since it ended up being useless, and this is getting off-topic. So ehm... I guess I'll post some filler like new screenshots... later  (edited by VL-Tone on 02-17-06 03:09 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| TS_Death_Angel: these are nice videos you found there! Many of these I've never seen before
and they are much better quality than the little Mario.avi I had. To get back on topic, here's is an update of my progress. I started rewriting the core of the command loading process. Here is a code snippet so that you can see how Lingo (Director's scripting) can look like. Warning! Geek Alert! Most of you may not understand a thing to this code, because they are either not programmers, or are confused and unfamiliar with the Lingo synthax.
The Loadcmd function will read bytes from a memory segment and place them in a list template. The actual data of each segments is stored in text chunks inside the variable metaram. This metaram variable is itself a property list, where the property labels for each item is the position in ROM of the segment. The ram=metaram.getprop (bankoffset) sets the variable named ram to the right segment. So bankoffset is an input variable that will hold the start offset of the requested segment. The variable basepos is the offset inside the segment where the command is found. bankoffset+ basepos= the address in ROM of this command (in uncompressed data). The variable strucs contains a property list that is fed as a template. An example of a simple strucs template that could be used, for command 0x22. strucs=[#objectid:[[4,1],#int,0],#banknum:[[5,1],#int,0],#offst:[[6,3],#int3bytes,0]] What the Loadcmd function does is to replace the zeros (third item of each sub list) with actual data read from the segment. The format of each item in the strucs list is something like that: #propname:[position_in_command,length], #paramformat, actualdata] #objectid:[[4,1],#int,0] will read byte 4 of the command and store the result in item 3 of the list (where the 0 is). I've included other possible data formats such as 3 bytes integers, signed integers, words, long integers. You know the kind of thing that is easy to deal with in C++ ;) I guess it gives me more flexibility, as I could add other formats. I won't use this function to load every commands, but only those that will be editable (or eventually editable). For example, here's the strucs input for a 0x24 command: [#actvalue:[[3,1],#bin,0],#objtype:[[4,1],#int,0],#xpos:[[5,2],#sigint,0],#ypos:[[7,2],#sigint ,0],#zpos:[[9,2],#sigint,0],#xrot:[[11,2],#sigint,0],#yrot:[[13,2],#sigint,0],#zrot:[[15,2],# sigint,0],#param1:[[19,1],#int,0],#param2:[[20,1],#int,0],#behav:[[22,3],#int3bytes,0]] The level parser will use the loadcmd function to build the list of 0x24 objects and store it in a variable called obj24data. The output of the loadcmd function is [#bankoffset:bankoffset,#cmdpos:cmdpos,#strucs:strucs]. Which is a property list with labels having the same name as the variables used in loadcmd. That means once the level script is decoded, I can refer to any parameter of any 0x24 objects. For example obj24data[10].strucs.xpos[3] will return position x of 0x24 object number 10. When the data is modified and needs to be converted back to raw bytes for subsequent saving, all the needed information will be available in each obj24data item. obj24data[10].bankoffset will retrieve the segment, and obj24data[10].cmdpos the offset inside the segment for this command. obj24data[10].strucs.xpos[1] will return the position and byte length of the xpos parameter, and obj24data[10].strucs.xpos[2] will return #sigint, meaning that it needs to be converted back as a 16-bit signed integer. Lists built with the loadcmd function will contain enough info to be used by the editor to display, modify and save changes to objects. The complexity will come from build the user-interface, and I'm not talking about button layouts. To be useable by mere mortals, the editor will have to provide menus containing only valid values, and a description of each item. Behaviors will have to be described too, and custom labels for behavior parameter will be possible, as their meaning is often specific to the behavior. But I've already planned all this, it's just a matter of re-implementing it. The polygon decoding routine is also on the list of things I have to rewrite soon, but only when I finish the level decoding rewrite. (Edit: Somehow, the pre tag messed up the layout of the whole page) (edited by VL-Tone on 02-19-06 12:42 AM) (edited by VL-Tone on 02-19-06 12:43 AM) |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by TS_Death_AngelOriginally posted by VL-Tone |
|||
|
VL-Tone Paratroopa  Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| I don't know why I posted it either... I guess I needed to see if I wasn't taking a completely dumb approach... Should I delete this post?
Lingo is originally based on HyperTalk, the scripting language of HyperCard, an older development program from Apple built by Bill Atkinson, MacPaint's creator. HyperCard was one of the main inspiration for the World Wide Web. But bragging-rights aside, HyperTalk was a very high-level language. Lines of codes could almost be read aloud as a correct english phrase ie: "put 10 into x" or "put z after character 10 of line 2 of field hello". The term "for" was not self-explaining so it was not used, repeat made more sense. At first, Lingo was very close to HyperTalk, but it evolved in subsequent versions (I started on Director 2.0 in 1991, and the current version is 10) to include dot notation and eventually an alternate java-script syntax. The "repeat" is still used instead of "for" because of backward compatibility, not for the sake of being different. But while both FOR and REPEAT can be used to make loops, they don't work the same anyway, so what's so crazy about replacing the word FOR by something that actually makes sense? This is the kind of thing that you only have to learn once. "IF THEN" structures use "else" not "otherwise", just like about every other language: If x=1 then It's "case" structures that uses the "otherwise" keyword to avoid confusion with IF structures. case X of Anyway I guess I sound again like ranting, but I find that these particular observations of yours are nitpicking. Director/Lingo has weaknesses I won't argue about it, but using REPEAT instead of FOR is a non-issue IMHO. BGNG, I'm not angry at you, I guess that it's the only things that could be said about this boring routine post
As for the skybox, do you have a screenshot of this? What kind of texture mapping does it use? |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| I was about to ask if you were sure if they were spheres, because I figured out that you assumed that from seeing multiple triangles in the sky, and I knew it simply could be the 32x32 pixels tiles.
So the screenshot and your theory matches what I thought it was. The 32x32 tiles are stored in a linear way, but from what you found it seems that some tiles are reused to extend the background. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| There you go...
http://pages.infinit.net/voxel/METROID_ALL_BLOCKS.IPS It's a pretty crude ASM hack that has some side effects, and I don't remember exactly how I did it, tough I could go back and dig trough the Metroid disassembly. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by HyperMackerel From what I've found it's possible to add "courses" to levels, as there is the possibility to use 8 course stars in a single level. You can assign a course number to a star, or make it level independent. So we could have levels with 8 courses, including the all-coin star. By the way, anyone has the text table file for SM64? Not that I couldn't find it myself, but if anyone has done it already, I'll take it! Spazzup™: I never said that, actually, the ROM will need to be expanded to at least 16 megs to use the editor, and I'll provide a small program that will do this for you (and repoint MIO0 files to the upper 8 megs). It will be impossible to make an .ips patch for the original ROM, but I don't think there's any way around it even though version 1.0 won't let you add things, as the re-compressed MIO0 can take more space than the original, and everything fits tightly in the original 8 megs ROM. I have a weird schedule at work these days, but the editor is still progressing. I'm currently rewriting the texture loading routine. It's still too slow for my tastes in some situations, it seems that the .char() function slows down when it accesses a very big variable, like the one containing the Mario MIO0 file (which is a shame...), and I may have to chop the loaded ROM segments in 32k or 64k blocks to avoid that. |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
stag910 + Welcome back! Thanks for the table I'll include a text editing feature in the first release thanks to you! Though I guess I could have found it myself by looking at the font textures 
I've look into Mario Kart 64 and yes it uses the same texture and polygon format. MK64 track editor anyone? Nahhh Too bad I can't clone myself!. A thing in the "more feasible" range would be to import MK64 models into Mario 64! It all depends on how similar the format is. That would probably be more easy to pull off than an import/export to a 3d program. Those other n64 games with a green elf with a sword... I forgot the name... well these also use much the same polygon format I wish I could work on that too, but I suspect someone else will do it.
Not all games use this format though, GoldenEye uses a different one for example, like most of the Rare games. ------------------------------------------------------------------------------------------ BGNG wrote this:ASCII was an old standard that was used in DOS, but was replaced with the ANSI character set once Windows came about. The first 128 characters are the same in both standards, which is probably what confuses many people. I guess you got confused too... ASCII is 7-bits, 128 characters. A is decimal 65. But DOS didn't use Standard 7-bit ASCII. DOS uses a proprietary variation of ASCII called OEM that descends from the original IBM PC, and uses 8-bits. The lower 128 are almost the same as ASCII, and the upper characters are used for a few accented characters, some graphics etc. At best it could be called Extended ASCII http://en.wikipedia.org/wiki/Extended_ASCII Since the term seems to encompass every 8-bit extension of ASCII used on various platforms. But Unicode since Windows 95? hmmm... this is from a page on microsoft.com: The problem was the difficulty in supporting a Unicode application on Windows 95/98/ME; developers had to support those customers as well. Because those platforms do not have the native Unicode support provided by the NT family of operating systems, it was just easier to write non-Unicode applications. However, times have changed.... Starting with the Windows XP RC1 version of the Platform SDK, the Microsoft Layer for Unicode on Windows 95/98/ME Systems (MSLU for short) can help you solve this important challenge. This component provides a layer over the Win32 API on Windows 95/98/ME so that you can write a single Unicode version of your application and have it run properly on all platforms. Cool, Windows 95/98/ME got a "real" unicode layer when Windows XP RC1 was released... From all I've read on Windows related sites, the support for unicode before Windows 2000/XP was mediocre at best. Microsoft now admits it... The vast majority of developers stuck to ANSI until XP for these reasons, and many still do. ANSI is not a character set by itself, its more of a switchable dynamic character set, a Windows re-implementation of a hack they used in DOS to "switch code pages", which is a way to have multiple and extended character sets. On a Windows 95/98/ME English system ANSI uses code page 1252 by default, and this is probably what you always used yourself on these OSes. http://en.wikipedia.org/wiki/Code_page_1252 Page 1252 contains an 8-bit character set that was "inspired" by ISO-8859-1 aka Latin-1 found on the Web. http://en.wikipedia.org/wiki/ISO-8859-1 It's also an extension of ASCII, with the first 128 chars being about the same, A is still 65. There are differences between Latin-1 and Windows Page 1252 but they cannot be seen in the credits and level select. It could be standard ASCII for all we know since it uses only the lower 128 characters. ANSI Page 1252 is a Windows thing, as far as I know, other platforms don't use it natively except for translation purposes. Nintendo is not known to integrate MS "standards", and they were working on SGI platforms that likely used ISO-8859-1. Please find me text in any in-house Nintendo game that is without a doubt Windows ANSI... So to summarize, the Credits and Level select text in Mario 64 is ASCII for all that matters since this text doesn't even use any of the upper 128 characters. There is no way to prove in one way or the other that its based on any particular ANSI code page. (edited by VL-Tone on 02-26-06 03:26 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| The DOS code page 437 is not more (or less) a variant of ASCII than ANSI code page 1252, ISO-8859 or the old Mac Roman for that matter. All four use much the same first 128 characters with a few differences in control characters. Incidentally, Unicode too...
As for what you call "ANSI": This is from a Microsoft pdf at http://download.microsoft.com/download/5/6/8/56803da0-e4a0-4796-a62c-ca920b73bb17/21-Unicode_WinXP.pdf The term "ANSI" as used to signify Windows code pages is a historical reference, but is nowadays a misnomer that continues to persist in the Windows community. The source of this comes from the fact that the Windows code page 1252 was originally based on an ANSI draft, which became ISO Standard 8859-1. However, in adding code points to the range reserved for control codes in the ISO standard, the Windows code page 1252 and subsequent Windows code pages originally based on the ISO 8859-x series deviated from ISO. To this day, it is not uncommon to have the development community, both within and outside of Microsoft, confuse the 8859-1 code page with Windows 1252, as well as see "ANSI" or "A" used to signify Windows code page support. Talk about confusion... I guess I got it wrong too about ANSI, its neither a character set nor code page support. You wrote, in bold: "as all 32-bit Windows platforms provide functionality for wide characters." My point was that Windows 4 didn't natively support Unicode, as in "the whole enchilada". How do you explain my other quote from the MS site admitting that real Unicode developer support was almost non-existent in Win 4 and was hard to develop for? As far as I know Unicode =! Wide characters. Sure you could view web pages and unicode text, but making an application that used it effectively to create and edit documents was a seemingly complicated process. Anyway if we are only talking about files that most people in this community encounter, then your reference to Unicode only added more confusion, as these people don't use it. DOS used an extension of ASCII, and so does the English version Windows even today with the "standard" code page 1252. So your whole point falls flat (sorry, I don't like to say that). Everything you could say to explain your use of the term "ASCII" to describe the standard DOS character set can be used to say that all English versions of Windows used ASCII as a standard. In other words, if you say DOS used ASCII, then by inference what you called "ANSI" is ASCII too. ---------------------------------------------------------------------------- Ok I'm wasting too much time debating about this... Proffessor Gad, nice pictures but I don't think they deserve to be here. There are tons of things that can be done with a gameshark, but this is not the point of this thread (I guess that discussing text encoding is neither but text takes less space). But hey don't stop having fun because of this
---------------------------------------------------------------------------- HyperMackerel This is great news! I thought it was Zelda OOT: Master's Quest for some reason... (OOT has 1400 YaZ0 files, so I figured out that maybe OOT MQ had around 2000)
I'll continue this reply tomorrow since I work early this Monday. (edited by VL-Tone on 02-27-06 01:00 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| Proffessor Gad:
I don't know how behavior code works, it's customized for each objects, while what you are asking would be technically possible, I don't know how to do it, and for now I don't intend to look for the answer any time soon. Update on my progress: Almost all the dialog text is contained in MIO0 file 00108A40. There are two (or three?) lists of pointers for the text. One is at FFC8 inside the same MIO0 file, and each of the item in the list is 16 bytes. Here is the first item, which points to the first message you get in Level 1. [00 00 00 01] [06 00 00 1E] [00 C8 00 00] [02 00 7D 34] The last 4 bytes are the segment number and offset of the text in the segment (in this case the segment number is always 0x02, which is the one containing the data from this MIO0 file decompressed from 00108A40 in the ROM). The first 12 bytes are parameters that presumably set the kind of dialog box that appears, and which sound it plays. The first 4 bytes are almost always [00 00 00 01] and [00 C8 00 00] seems to be used 95% of the time. There are 170 in this list, and if I'm not mistaken, you can choose anyone of those using one parameter byte used with the behavior for signs, pink bob-ombs and other talking fellows. At 10A68 (in the MIO0 file) there is another list of 170 items, this time each item is only a 4 byte segment-offset pointer, there are no parameters attached so maybe they are more generic dialogs. Then at 10F68 a smaller 4 bytes pointer list can be found, this time 26 of them. --------------------------------------------------------------------------- So I started to make an editor for text dialog when I remembered that I couldn't edit this particular MIO0 in my extended ROM. Currently, I edit an extended 16 MB ROM that has all MIO0 files decompressed and appended at the end of the original ROM. All 0x18 commands are changed to 0x17 so the game loads raw uncompressed data instead of decompressing a MIO0. Then, the start and end pointers are changed to point at the decompressed data in the extended portion of the ROM. There are two problems with this approach: 1. The MIO0 file 108A40 is a special case, it's decompressed and loaded with a custom command that cannot be easily changed to a 0x17 command. (I know how to re-point it though, thanks to Cellar Dweller) 2. The command 0x1A which is used about once per level loads a compressed texture segment like the 0x18 could do, but when I try to re-point it to decompressed data and changing the command from 0x1A to 0x17, the game crashes. So some texture would not be editable. I could bring the MIO0 decoder to a good speed thanks to faster disk access, but the re-compression is still a problem... I cannot find a way to build a fast enough compressor in Director. Scanning the 4096 last read bytes for matches for each bytes read is taking too much time. I tried to use the offset command (which finds a string position) to get a good speed, but it's case-insensitive so it's useless to deal with byte data. There are commands to find position of properties or items in lists, but not multiple items (bytes) at the same time. Maybe there is something I don't know about searching lists in Lingo that could give acceptable speed. Yes I know It's pretty bad because after all MIO0 compression is simple... Whatever... I don't think that keeping the data decompressed is a bad thing in itself. So what can I do to get around the two problems mentioned earlier? I found the answer yesterday, and I wonder why I didn't think of it at the beginning of all this. It's simple, MIO0 files don't have to contain compressed data! You can make a perfectly valid MIO0 file that doesn't contain anything compressed. Just make a valid header, building a data map table that has all bits set to 1, the raw uncompressed data follows the header, unmodified. This way I'll be able to save all MIO0 files in 1 second instead of much more. This way the game will work as intended, loading valid MIO0 headers, but the data inside the MIO0 files will be easily editable without having to compress-decompress. If for you BGNG and Hyper, MIO0 compression and decompression is quick and trivial, then go for it, re-compress everything after editing, but this is not the approach I'll take, I don't have much choice. As a bonus, I'll avoid having to deal with MIO0 files that change size after re-compression. (edited by VL-Tone on 02-28-06 08:19 PM) (edited by VL-Tone on 03-22-06 04:41 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| I'm fully aware that working with byte arrays is faster, but the last time I checked that BinaryIO Xtra was the best option, but it was limited.
So I checked again, and it seems that I missed out a better solution. It's called BuddyFile Xtra. The license is cheaper and from what I read I don't need it since the editor won't be a commercial product. It doesn't have a nag dialog, and best of all it can directly read data and return an integer list... That will solve most of the problems I had. Director doesn't support byte arrays as is. Variable lists used in Director are much like 1D arrays, but they can contain a variety of data types. listvar=[0,1,2,3,"abc",#symbolA,65537,-10,[1,2,3]] As you can see, a list can contain other lists so you can build multi-dimensional arrays too. The Buddyfile Xtra will return a linear list that could look like [0,0,2,255,255,128,10,12] with each value being equivalent to a byte having been read. Then I can read back the data much more directly instead of having to use chartonum(). I can just do byteread=bytelist[x] to get the decimal value at position x. It won't help that much for the compression problem though, since the problem is that I would not be able to search for example for a match of [255,128,10] in that list, I can only find the occurrence of individual bytes, so the matching routine will be as slow. But anyhow, seeing that it's not really important to anyone that I re-compress the data or not, I won't try to do it. I'm currently building a small program that will reposition all MIO0 files, build new header and copy the uncompressed data after each header, and repoint the 0x18 commands offsets. I had made a similar program that didn't include the MIO0 header aspect, but it was slow anyway, so I'm starting a new one. I'll probably release it as a small stand-alone program in the next few days, so that you guys can have a concrete example of what the editable ROM will be like, and maybe manually edit some things in the MIO0 if anyone feels like it. (edited by VL-Tone on 03-01-06 12:45 AM) (edited by VL-Tone on 03-01-06 12:47 AM) (edited by VL-Tone on 03-01-06 12:48 AM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| I leave the forum a few days and what happens?
Like BGNG said, I don't think that working on Super Mario 64 DS is a good idea, for many reasons. If anyone wants to, they can... in another thread. The game is different anyway, they may have use some polygon data and textures from the original, but the engine is completely different. So we won't learn much from diging into the DS version. Ok so BGNG about the code snippet you posted, it looks like the first thing I tried. It worked but it was too slow, that's why I was trying other methods. Hyper: Actually, the "Xtras" plug-ins for Director are .DLLs on Windows. They have to be built following some specifications though. Maybe I could try to look how easy it could be to build an Xtra. The thing is, I would have to build versions for both platforms. But anyway, I just got a brand new (overpriced) Mac mini! It may not be the fastest thing on the market, but it's definitely much much faster than my old iMac which was incredibly ancient and slow. I'll have to make some tests to see how fast my projects run on it. I'm still in the process of transferring stuff and reinstalling programs, and I will install Director MX tonight. From the speed I get from the Shockwave Peach Castle thing, it's really encouraging. Though the Shockwave thing doesn't do File I/O, the slowness I experienced in my editor was probably mainly due to the simple fact that my other computer was simply too slow. With a "decent" computer at last, I'll have much more motivations to work on the editor. (edited by VL-Tone-neko on 03-07-06 05:59 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| 1-Can you predict when the editor will be finished? I thought I heard someone
say 2006,Feb. or March. And it's March right now. Let's say the public beta will be released before the Revolution. 2-Will the editor be able to place water where one wants to place it? For example, the person could move around "cubes of water" Maybe this will be part of the editor, but as for now, I don't know what defines water areas. 3-If the editor is still a long time away, can you at least release a very small princess slide editor?[wait...I don't think I'm alowed to ask for editors...] No, and what you should understand is that my editor won't be able to modify the actual geometry of things (at least not until version 2.0), so in the Princess slide, the only things you would be able to move and change are coins and other objects found on the slide. I'll post other pictures eventually don't worry
Good news my first tests reveal that my editor is much much faster on my new comp. Levels load in 3-15 seconds depending on the size, but that's with the old method which has a lot of redundancy, decoding the same objects multiple times. (It use to take more than a minute to decode some levels + all objects) Also, I made a routine that pre-loads all textures when you open a ROM. The bad news are that it takes up to 25 seconds to load 850 textures found in the game. I'm working on improving that before continuing the rewrite. I may release a texture editor as a first testbed, to get an idea how the process of extending the ROM and loading texture works on other systems. On the current working editor I've implemented key controls to move and rotate objects, and new camera controls to make it orbit around the selected object, zoom in and out. (edited by VL-Tone on 03-09-06 10:10 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
Originally posted by proffessor_gad Thanks for wanting to help, but I never said that editing the terrain was impossible. I already know how it can be done. I don't want to explain yet another time why I won't put polygon editing in version 1.0, just re-read the thread. You can always try, but I don't think you can help much now, I know what I need to know to build the kind of editor I want. I'm still missing the bone/animation data format for characters and objects with moving parts, but I doubt that you can find how it works. I hope it doesn't sound too rude, don't stop trying to find things and have fun hacking Mario 64
Originally posted by creaothceannOriginally posted by VL-Tone I thought about saving the textures to disk beforehand, and this is how I used my editor before, but here is the problem: what if you open a ROM with textures already edited? The textures would have to be loaded anyway. Maybe I could put a checkbox option that reads "Load custom textures" in the editor. Another thing I could do is write a small table in the ROM that keeps tracks of which textures have been edited so it only loads them. A completely edited ROM would still take as much time though. I'll work on releasing a bare-bones texture editor and a ROM expander/repointer so that you guys can test it on your systems. It wouldn't surprise me that it's faster on most of your PC's since Director has faster disk access on Windows. So until then, here is a "sprite sheet" of all the 850 textures. I think it covers every texture in the game, except the fonts and interface icons. 
The full resolution version is too big for Photobucket (it's a 900k PNG), and I don't know where to host it, I don't feel like putting it on my own web server. Wasn't there a thing called "commons" or something like that on this board? I can't find it anymore... was it removed? Can anyone here host this file? (edited by VL-Tone on 03-10-06 06:18 PM) |
|||
|
VL-Tone Paratroopa Since: 11-18-05 Last post: 6505 days Last view: 6505 days |
| ||
| This is nothing that wasn't possible before, decoding the textures from Mario 64 has been possible since a long time. I'm sure people working on the High-Res pack have seen these before. But if you only used a bitmap viewer and peeking in the MIO0 files, you would have to spend time finding those textures, aligning their bytes and the pixel width (16, 32 or 64), since many are found in between polygon data at various offsets and with different sizes. Some are grayscale and some are RGBA.
I built a list of all texture offsets, their size and bitmap mode, by decoding all the objects found in the game, and adding these properties to a list, each time a texture command is encountered. This list is already calculated and stored, and it was used to load all of the textures sequentially. |
| Pages: 1 2 3 4 5 6 7 8 |
| Acmlm's Board - I3 Archive - - Posts by VL-Tone |
Just thought that it would be helpful if I told you...