 |
| 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 Zeld |
| Pages: 1 2 3 |
| User | Post | ||
Zeld Red Paragoomba                 Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| I use VBA-H, as recommended by labmaster. I saw a thread in which he explained a short assembly hack to some fellows from another forum who came here seeking help, and with his example I was able to make sense of assembly and get started myself. I'm fairly new at it...(it's been 3 or 4 months, but who's counting?) Ironically, I'm dealing with a bit of fanboyism from that forum now, since I went a did a whole bunch of short (but awesome >.>) assembly hacks that I was able to do after reading the same tutorial they did.
Yes, that whole "a single number is the label for an entire name" thing is definitely an opportunity to use a debugger with fairly no complications. Sometimes assembly hacking isn't all that straight forward, but what you've given me sounds like a simple task of tracing a read of the number you have mentioned. 50 missions sounds a little intense. Are missions really short or something? I haven't played many, so I don't know yet. I'll play the game a bit more soon. I'm a fairly decent spriter, as well (look at my avatar), so perhaps I could mess around making a few monsters using combinations of existing ones and inspire you? Another program you will definitely need is unLZ GBA. It's a decompresser for much of a GBA game's data, since, of the many methods of compression available, it is the most commonly used. "Why 'unLZ'?" Because, the compression method was devised by a couple of dudes whose last names began with L and Z, so the compression method is called LZ77 (for the year 1977), and unLZ literally un-does the LZ. I felt like explaining that, since I thought "unLZ" was just a random 4 letter word that the program writer came up with out of nowhere when I first downloaded it. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
Originally posted by Alice I've never heard of variable width font, but I imagine it would explain why the A ad the W overlapped. I mean, for all I know, they were only drawn overlapping as a result of...varying width...and don't actually overlap in the font table in the ROM. Either way, I'm gonna trace the sucker, so I don't need to worry about bad theories. Originally posted by Alice I kinda mentioned that (in much less detail) at the beginning of one of my other posts (I never would have thought of using radio signals as a way of generating random numbers; I always wondered how that worked). Originally posted by Alice What was wrong with my example? 
Also, for my avatar: It isn't a character from Fire Emblem, but it is composed of pieces of several Fire Emblem characters. The character I used to make the face didn't have a right eye, because his hair originally covered it. The face had all kinds of holes where the hair had been. Most of the face is done by hand, while the rest is mixed parts from existing characters. And, of course, I changed the palette. I plan on making him the Lord of my FE 7 patch. I'm working on expanding everything first, though. Edit: I must apologize for my stupidity. I completely neglected the idea that perhaps other tile data would be loaded into the place where the text ended up in the process of loading text graphics. I wound up altering...the text bubble's background. Realizing that I ignored the idea of the same addresses being reused for other things at the rapid computer processing speed that still blows my mind, I started messing with registers during my breakpoints to make sure I knew which write was right. That was a terrible rhyme; I apologize for that too. I remembered seeing an "e" in the WRAM the other day (graphically, of course; noticing an ASCII e would be pointless). I had scanned the WRAM with my tile editor upon noticing a WRAM address in the registers of my breakpoints that looked suspicious and recognized the e as being the same font as the ones displayed in the text bubble, but I foolishly ignored it. I decided not to ignore it this time, and found the capital G of the beginning of the text I had been looking for. Turns out, each letter is separately loaded into the WRAM, copied to the VRAM, then replaced by the next letter that is loaded. I know you wanted to change the intro text, and at first I thought that meant the text during the snowball fight. I'm sure you'd like to edit in game text, either way, but the text during the opening movie that I completely forgot about until recently is a different matter altogether. I suppose you meant that text, and not the rest of the text, so I should probably look into that so I don't end up helping with the wrong things (which I seem to be good at). (edited by Zeld on 01-17-07 06:33 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| As long as you know I'm not nearly as devoted to this project as you are...
I usually patrol Fire Emblem forums looking for a simple yet effective hack that someone wants done that only I can do. I'm just not good at doing whole projects. I'm not even sure I'll finish my own... I like your plot idea, actually. Since you said you made it up in ten minutes, I would imagine that spending more time on it would be a good idea, because there's no such thing as a plot that's too good (I wonder sometimes if game developers even realize this v_v). Just remember that everything you plan has to actually be done, and won't happen automatically. I don't think I've ever seen (and hopefully never will see) graphics that are compressed using a method other than LZ77, so changing the graphics should be fairly easy. Adding graphics should be easy as well. Animating them, however, will be difficult. I've hacked animations before (as in, I not only hacked the graphics of a sprite, but I was able to hack how the sprite was displayed). The animation I hacked was the Fire Emblem battle animations (I dunno about you guys, but I think it's a pretty big deal >.>). Unfortunately, Fire Emblem's animation data is really easy to understand. FFTA's animation data could be difficult and painstaking. Now, for things like mission titles...from my experience, titles aren't handled the same way text is. If titles for things like missions appear on a plaque in a big fancy font, that generally means that the text isn't text, but is actually just graphics. So, simple graphical hacking would suffice. Item descriptions will most likely have a pointer to a bundle of descriptions that are for all items (which is analogous to the way names are handled that you mentioned earlier). So, you can change item descriptions by changing a single number, but if you do that you will only be able to choose between existing descriptions. That would be ridiculous. This will require text hacking of the sort that I've looked into. I'm still not sure of the compression method. Rewards and other object data will be easy to change (add? I don't know; change? Easy enough); all you have to do is target the number that tells the game what item to use and change it. Making a weapon triangle, as in FE, will require assembly hacking. Having pondered increasing entry length of data tables recently, I've noticed issues with making the loading process. I will have to create a stand alone table to take care of a potential loading issue. I've made plenty of those in other assembly hacks, so no worries. Each weapon will get a byte, supplying you with 8 bits per weapon to determine what sort of weapon it is. You could use this awkwardly to have 256 types of weapons, or do the smart thing and have 8 or less. Really, a wooden sword and a metal sword should be "swords", not "wooden sword type" and "metal sword type". I mentioned character movement before. Because of how easy it is to locate RAM addresses to set breakpoints on when what I'm trying to change can be altered in real time, movement shouldn't be too difficult either. It seems like text will be the biggest problem, really. Map data could be too, since that's such a big thing to change. Because of the awkward angle of viewing the game, I theorize that the maps are actually just big graphics, and that the actual data that determines where you can stand and move to is separate. Sometimes the graphical data for a map and the ability you have to traverse the map are linked, which makes things easier, but sadly, I don't think this is the case this time. |
|||
|
Zeld Red Paragoomba  Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| What you're doing is called "corruption", and should probably be done with a specialized program called a corrupter (lololol says it's spelled "corrupter", but my familiarity with the English language leads me to believe it should be "corruptor". I guess not). Though, of the ones I've tried, none worked properly. That method of hacking is rather inefficient anyway, so it shouldn't be your first method of changing things.
The way I hack things that aren't as obvious as weapon and item stats is to dump RAM states, make changes by playing the game, and load half of the RAM state to see if I achieve a desired effect. If I don't, I toss the hex, and if I do, I chop the hex in half again and test the halves as I had previously. This is how you find invisible RAM addresses with ease. Then, if you find a pile of say, map data, in the RAM, you can copy the first few bytes of it and search for it in the ROM with a hex editor. You should find a match, but if you don't, the data is probably compressed. Of course, if you do find a match, then you're ready to actually hack something in the ROM. Naturally, this method is limited, as are all methods, but it's especially helpful to me, because I can trace RAM addresses to ROM addresses if data is compressed or just altogether nonsensical in my eyes. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| BIOS - Stored at 0x0
Boot up script. It is the program that tells the Gameboy how to start and contains information for universal programming routines such as decompression, copying data, etc. WRAM - Stored at 0x2000000 Work Ram. Size is 0x40000. This is where most of the stuff that code makers (gameshark, action replay) like to hack is. IRAM - Stored at 0x3000000 In Chip RAM. Size is 0x8000. This RAM is located on your game cartridge, whereas everything else is either on the Gameboy itself, or copied to it (e.g. ROM). Also a great place for making gameshark codes, but lots of this area is used for actual programming instructions, and contains a block of data called the "stack" that stores variables for active math operations. Changing stuff in the IRAM can often crash the emulator. This can happen with the WRAM, too, though not nearly as often. I/O - Stored at 0x4000000 Input/Output. Pretty self explanatory. At 0x4000130 is a set of bits that change depending on keypad input. Great for making button activated gameshark codes, but most gamesharks are programmed to check that address by use of a dummy address (at least, that's what I theorize a joker code does). So, you don't have to know this address... Palette RAM - Stored at 0x5000000 Palette data. Can contain 16 lines of 16 color palettes or a single block of 256 colors. VRAM - Stored at 0x6000000 Video RAM. One section of this RAM creates "tiles" by using a chosen codec (4bpp for 16 color mode, 8bpp for 256 color mode) to call colors from the palette data and use them as a single pixel. The pixels form colorful squares called "tiles". The other section of VRAM, which I believe comes first, contains "map" data, which is a bunch of data using numbers that are assigned to the "tiles" in the latter part of the data to generate a map. The maps are layered, given transparency, translated, etc. to show you what you see on screen. The VBA has a cute little sine function in the BIOS used for rotation effects (I may be easily intrigued, but I think the sine function is a wondrous piece of work). ROM - Copied from the cartridge and loaded into 0x8000000 Read Only Memory. Everything you want to hack spawns from here. SRAM - Stored at 0xE000000 Save RAM. You know those files that are called ".sav"s? This is where they come from. They are exact dumps of the data at 0xE000000. That's pretty much the entire memory map of a Gameboy Advance. You could always just google GBATEK and click the link called "specifications" and read more about the GBA (and the Nintendo DS!) in your free time. That site helped me a lot when I was writing programs by hand due to my lack of common sense, which forced me to use something other than an assembler. I don't think I type the opcodes syntactically correct. I seem to add or leave out symbols... As for features: I don't know what the logging or I/O features do. I estimated that the logging function would debug specific instructions and that the I/O window would allow you to alter I/O bytes, but changing stuff around in either of those windows didn't affect anything for me. The disassembler, however, is a very useful tool. You punch in an address and it actually reads off the programming code of that address. Thing is, if you don't know assembly, you won't know what the hell to type in. I do use VBA. I was able to get into ROM hacking and hacking in general because I was enthralled with all of the features that VBA comes with. It's by far my favorite emulator. (edited by Zeld on 01-19-07 03:08 PM) (edited by Zeld on 01-19-07 03:09 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| Ouch. This is another reason I fail at using an assembler. I continue scripting stuff by hand...it actually doesn't slow me down much at all, considering how well I've memorized most of the map of opcode/operand bits for thumb opcodes. Every now and then I'll forget a little and type in a 2 to use register 2 as an operand and end up using register 4, but you only have to type 4 numbers to type a whole opcode (assuming you're working in thumb, which you probably are most, if not all of the time). Can't be that much worse than getting the assembler to work, can it?
I haven't even gotten along with goldroad long enough for it to show me that it knows what "add r0, r0, r1" means.
Also, that thing about devkit pro making the assembly completely different...what was different about it? Was it like, "devkit tried to optimize my assembly for me" different or "what the hell is this?" different? |
|||
|
Zeld Red Paragoomba  Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| This is bugging the crap out of me. I can think of ways to do multiplication in assembly, but I have no clue how to program division. I haven't seen a division function for the Gameboy advance ARM7 processor, and I'm worried that when I get around to making assembly hacks that require division I won't be able to obtain enough accuracy.
So far I can get .875 from dividing 9 by 10. That's sort of accurate, but I imagine it's terrible accuracy in comparison to a more standard method of division. How do processor creators implement their division functions? Keep in mind this only has to handle integer division. Surely there's some semi-universal method for programming integer division on a processor using loops and shifts, etc... I can't find anything with Google, but then again I'm probably not typing the right thing into the search engine. Edit: I sort of thought of a way to do a small floating point implementation and acquired "0.884765625" for dividing 9 by 10. Perhaps if I extended the length after the "decimal" point from 2 digits to 4 I could obtain something more accurate...I still can't help but think that I am doing this the hard way, though not necessarily the wrong way. I haven't actually translated any of the stuff I'm jotting down into an assembly script. I'm writing math operations on paper that can be executed easily in assembly, but I haven't actually written any assembly. So, I can't give a source to show what I'm doing, which means I can't really get any constructive criticism. :\ Edit: I saw a problem with my pseudo decimal point and multiplied by 256/100 to convert it properly. Except 256/100 contains a grotesque division in itself, so I just decided to use a lsl 1 + lsr 1, which is the same as multiplying by 2.5. Was that bad of me? I get 0.8994140625 now. That should be close enough, right?
Edit: I decided to write out my idea in assembly for reviewing. I would include a text file attachment, but for some reason there's no apparent way to add attachments to posts in the editing window. R00=00000009 R04=00000000 R01=0000000a R05=00000000 R02=00000001 R06=00000000 R03=00000000 R07=00000000 R00 is nominator R01 is original denominator R02 is new denominator R03 is "float" for R00 * lsl r2, r2, #0x1 add r4, r4, #0x1 cmp r2, r1 blt $* lsl r0, r4 add r5, r0, #0x0 ** cmp r1, r5 bgt $*** sub r5, r5, r1 add r6, r6, #0x1 b $** *** mov r7, #0x64 mul r5, r7 **** sub r5, r5, r1 add r3, r3, #0x1 cmp r1, r5 ble $**** asr r7, r3, #0x1 lsl r3, r3, #0x1 add r3, r3, r7 lsl r2, r2, #0x8 add r4, r4, #0x8 lsl r6, r6, #0x8 add r6, r3, r6 R00=00000090 R04=0000000c R01=0000000a R05=00000000 R02=00001000 R06=00000e64 R03=00000064 R07=00000014 At this point, asr r6, r4 equals approximately 9/10, but it will be truncated to 0. As you can see by the last bit of code (for those of you who understand assembly and can make enough sense of ARM7 even if it's not one of the assembly languages you're familiar with) this script is incomplete. It's my attempt at stepping in the right direction. I'm sure there's much more efficient methods of division, but this is the one I came up with. If I wanted to use the number 9/10 to get 90% of something, I could use this program. Unfortunately, mul r3, r6; asr r3, r4 would get me 89. It should give me 90, because 9/10 of 100 is 90. But no. I would get 89. Damned shame... Edit: I tested the results of trying 7 divided by 9 with this program and it seems I have approximately a 1% error (it was .99%). That may be terrible by today's standards, but I like it. (edited by Zeld on 01-20-07 11:44 AM) (edited by Zeld on 01-20-07 12:10 PM) (edited by Zeld on 01-20-07 01:03 PM) (edited by Zeld on 01-20-07 01:18 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| I don't understand what to do with the 21 times 0x55555556, nor do I see where your mention of multiplying two 32 bit numbers together takes place...
Also, 21/3 isn't as big a deal as 9/10...9/10 is less than 1. I had a look at the IEEE floating point system and I understood most of it. However, I didn't understand how 1.01 in binary is equal to 1.25 in decimal. This could be owed to the fact that the concept of having a decimal number like 1.01 in binary escapes me. If there's a way of writing 1.01 in binary already, why even make a floating point system? It looks like a circular reference to me...using a float to create a system for creating floats. Yeah, and 1=2. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| Oh, right. Yes, that does make perfect sense. I just plain didn't see it as powers of 2 when there was a scary decimal point distracting me.
Except that first 1 be multiplied by 2^0. Anyhow, thanks for clearing that up. Edit: oops, I missed Dwedit's other post. The fixed point system is actually what I was going for. 9/10 may be truncated to 0, but the rounding method would give the number meaning. Not to mention I could still use it for multiplying by an integer, which is what I planned to do, after which shifting off the bits representing fractions wouldn't leave the result as a meaningless 0. Multiplying by 100 and then shifting would actually yield a percentage. Also, I understand the 64 bit stuff now. I didn't at first because when I was calculating the result in microsoft calculator, I forgot to change the product's size to 64 bits before pressing equal (I wanted to see it myself and was following through your instructions). After realizing that mistake I now see how the high register contains the result, but I'm a bit miffed that the opcode you speak of requires a branch change to ARM. I haven't done anything in ARM yet (never needed to) so it will take longer for me to program in it. Of course, I can just use less bits for the fraction in order to do the same thing for thumb, yes? Like, mul r0, r1 where r0 is a number like 3c and r1 is 10/9 (which is 11C71C7 in a 24 bit system, right?) I get 0x42(6 digits of crap), shift it 24 bits to the right, and wind up with 111% of 60: 66. I'm going to need this for a skill some folks at FESS want me to put into a GBA Fire Emblem game (the original skill is in the Gamecube Fire Emblem). (edited by Zeld on 01-20-07 07:39 PM) (edited by Zeld on 01-20-07 07:48 PM) |
|||
|
Zeld Red Paragoomba  Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| What do I do if I want to divide by a variable? I was thinking I could make a table of the fractions 1/X where X has a domain of 1 through 256, and then the variable would be used to call the fraction. This seems a tad impractical, and doesn't solve the issue of having a floating point that is being divided by a varying floating point. "It's a gameboy. Why do you need floating point math?" I don't, but I want to know this stuff. I'd like to get into N64 hacking soon, too. Seems like there aren't enough people into N64 hacking that spend more time doing than they do dreaming. | |||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| Wouldn't it be completely different, due to differing compression and programming methods? Not to mention extra data in the (more kick ass) DS version. | |||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| Interdpth told me about SWI 6 and 7 last night. I felt kind of ridiculous, having read through GBATEK so much and not even seeing those SWI's.
Interdpth suggested I read through the BIOS to understand how the BIOS itself handles division, but I don't know where to look in the BIOS. How does "SWI $6" translate to a BIOS execution address? Edit: Never mind. I took a random ROM and screwed it up to get stuck in an infinite loop of mov r8, r8 and branch back to the mov r8, r8 (in thumb mode). Then I changed it a bit to include the SWI and just spammed the Next button in the disassembler until it took me to the function. Good stuff. Well, it's good...if you ignore how inefficient it is. I can only imagine how many cycles would be wasted when dividing by large numbers... Edit: I rewrote my crummy assembly script. I imagine this is far more optimized than what the BIOS uses: Here, r0 is the dividend and r1 is the divisor. ** cmp r0, r1 blt $* sub r0, r0, r1 add r2, #0x1 b $*** * add r4, r0, #0x0 ; The rest is optional and generates a float by use of the remainder mov r0, #0x0 sub r0, #0x1*** cmp r0, r1 blt $**** sub r0, r0, r1 add r3, #0x1 b $*** **** add r3, #0x1 ; There, now it rounds up mul r3, r4 r2r3=Quotient.Fraction Edit: I did some crappy math, and it looks to me like this function would take 90 seconds to calculate a division by 3. I'm worried about this...my only thought of a solution was to convert 3 to 2.999999999 to speed up the subtraction loop process. Edit: No, that's a lame solution to. I thought of a better way (dividing a number, such as 3, into each digit separately, then shifting the remainder to emulate an actual carriage like they teach in grade school v_v). Edit: Did I say digit? I should say "bit", as it will be much more efficient that way. (edited by Zeld on 01-21-07 01:52 PM) (edited by Zeld on 01-21-07 03:14 PM) (edited by Zeld on 01-21-07 04:20 PM) (edited by Zeld on 01-21-07 09:28 PM) (edited by Zeld on 01-22-07 12:25 PM) (edited by Zeld on 01-22-07 12:39 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| Easy? That sounds like an assembly hack, buddy. If I were able to debug an NDS, it might still be easy, but that's because I'm familiar with ARM. Even then it wouldn't just be "easy". I don't expect it to be, at least. I mean, even if there's just a simple modifier byte between the different types of jumps and a bit flag for who can wall jump, you wouldn't be able to find the addresses without reading a little assembly.
I think I may have downloaded this ROM. I don't recall it being in separate files. Maybe I didn't download it, but even if I haven't, the NDS ROMs I have downloaded all came in one piece. Does that mean the site I'm getting my ROMs from fails or something?  |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| That's for if you find the data in the ROM in VBA (an address that looks like 0x8XXXXXX). You simply found it in the RAM.
The next step is to take that table you've found and search through the ROM for strings of familiar text that match up with your table. You might not find a match though, in which case, I'll see if I can use your findings to speed up the debugging process (although the reason I'm debugging so slowly is because I haven't worked on it lately; see my thread in the programming forum for my excuse). |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
Originally posted by Alice Yes, I thought that my be the case. If I quit being lazy and locate the text/compression method (assuming there is one), then we won't have to ponder in the dark anymore. I like how you were able to make that font table, but when I did a relative search of the RAM, I didn't find anything. Perhaps this can be owed to the fact that I looked for conversational text and not names. One, both, either, or neither could be loaded into and then overwritten in the RAM too quickly for a RAM snapshot to get a hold of them. There's still many possibilities... |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| Making level editors and that sort of thing would probably be best kept with focus on the N64 version. However, from what I can understand about the N64 and NDS processors, reprogramming SM64DS with innovative assembly hacks would be much easier than on the N64.
Not sure if that matters much, since assembly hacking usually comes after editor making...or like, during editor making. Ah, whatever. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| I apologize for double posting, but if I simply edit my post, no one will think I've appended my progress as of late.
I completely ditched the whole "8 bits for the integer, 24 bits for the float" crap. It was too limited. I decided to rewrite my entire division algorithm from scratch to make it calculate the reciprocal of any IEEE 32 bit float. After much testing, I have finally gotten it to produce consistently accurate results when compared to an online float calculator on an IEEE website. So far I have tested the following numbers: 2 3 4 5 329402312 That last one was completely random. I wanted to make sure my calculation was precise regardless of the complexity of the input, and according to my program, it works perfectly. All 5 of these inputs provided outputs that match the reciprocals of these numbers in 32 bit IEEE float format, as provided by the IEEE calculator I was using for reference. It can handle negative numbers easily, but I haven't tested my program's ability to reciprocate fractions. I imagine it can handle those with equal success. The best part is, I had no source to view from an actual floating point processor, so I pretty much had to figure most of it out myself. Things like adding 0x800000 to the mantissa before dividing it into 1*2^46, to account for the implied 1. Unfortunately, I just realized my program can only compute normalized numbers. I don't think I want to add denormalized support, because I can just feel how ridiculously painful that would be in relation to such little pay off. Then again, I see a relationship between the denormalized number I tested, the incorrect output I received, and the correct output I should have received. Perhaps I CAN fix it...except, I'm tired and cranky right now. Edit: I decided to treat denormalized numbers as "0", as a form of rounding and simplification. My program seems to only have one issue left (I need to figure out how to make it return "0" when a denormalized number is generated). I may not have to implement this if I remind myself not to use the program for reciprocating overly large numbers, although I'm curious as to how I could even input such numbers... Edit: I thought this would be fun to share: Input: 0x83759847 - What I typed into my Gameboy Advance Output: 0xfb856c48 - What my Gameboy Advance typed into my eyes Expected output: 0xfb856c49 - What it should have typed instead Difference: Decimal 158456325000000000000000000000 - Big number? % error: Decimal 0.000011436401767426803224837107833072 - And yet, a tiny percent error XD (edited by Zeld on 01-25-07 12:46 PM) (edited by Zeld on 01-25-07 01:08 PM) |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
Originally posted by Bones_the_Great There's these things called "IEEE" floats, which are standard for representing fractions in hexadecimal. Considering the GBA doesn't have a floating point processor, it probably does some other nifty trick to emulate the "1/2" thing. Originally posted by Bones_the_Great You should probably avoid that. If you open the ROM in a hex editor that supports table files, then upload a table that matches the one you posted, you'll get the same thing. I'm thinking Thingy for tables and Translhextion for hex editing/table file support. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
| I normally don't post in hack progress threads, because I usually don't have anything to contribute
I had to post here, though, because the concept of this hack amazed me. The graphics look wonderful. My friend and I are exchanging comments on your screen shots over AIM right now, and I must say, we're impressed. We especially had fun laughing at your comment: "I hope you like the idea. :3 ". We found it amusing that you implied that anyone could not like it. As if that were even possible. 
Mario appears to be keeping the abilities of the character he is replacing, as well. The crossover game play will be a wonderful touch... Something else I don't normally do is to actually download peoples' releases and play through their games. I'm a selfish bastard, so I usually just focus on making my own hacks without trying others', but I think I'll end up playing this one. With gusto. |
|||
|
Zeld Red Paragoomba Since: 11-05-06 Last post: 5911 days Last view: 5909 days |
| ||
Originally posted by Bones_the_Great I don't recall how I got thingy to work...I was trying to use it for a game that has compressed text (yes, I was a terrible little noob way back whe- I mean, half a year ago), so it didn't matter how well I learned how to work it. Crud, I deleted my "tablers" folder from my ROM Hacking folder. Curses. Hell, I just realized...I didn't use thingy, I used TaBuLar. I think TBL generates...tbl...files, which I think is the same format as thingy tables. I dunno...I do recall getting a table I made to work with translhextion, so get TaBuLar if you're on a Windows OS. Originally posted by Bones_the_Great Makes sense to me. |
| Pages: 1 2 3 |
| Acmlm's Board - I3 Archive - - Posts by Zeld |
