MP2E
-
Posts
89 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by MP2E
-
-
Hey guys, thought you might be interested in this:
http://gbatemp.net/threads/release-3ds_ctr_decryptor-void.370684/
Apparently, they have figured out how to decrypt 3DS roms. The ROMs can even be modified and played on a Gateway 3DS, from the information I have been reading.
Looks like the 3DS world is blown wide open for ROM hacks, though you'll need a gateway and an old 3DS to do it, for now.
-
Actually, it isn't. FE7 is when the series switched to the two-RNG system as opposed to the one-RNG system of the older games (where hit-rates higher than 50% are more likely to hit and vice-versa). While the older games are great, the one-RNG system makes for some ridiculous moments, especially in FE6. I distinctly remember how on my first playrthough, my Saul got attacked by a hand-axe fighter. The fighter had a 23% chance to hit and 1% chance to crit. He crit, instantly killing Saul and causing me to reset and curse aloud. It was even at the end of the chapter too.
I still quite enjoy FE6, but the RNG is especially wonky in that game. I never understood why aside from the the one-RNG system.
No, FE6 is when the series switched to the current 2 PRNG system. The algorithm is exactly the same as FE7.
Please don't assert conjecture over someone who has "done their homework".
-
VWF is totally going to happen :) The goals aren't going to be compromised, it just might take a long time :Pi've actually got a near-complete batch of item descriptions, but unsurprisingly they were written with a vwf in mind because i'm arrogant as hell, so i guess i should go do some significant paring down in case that doesn't happen. turns out brevity in writing is something i suck at :P
I'm still around, I'm moving again in a day and personal life is kinda hectic which is why progress has been slow. My computer works again but my old source for resire was lost so it was fully rewritten. Here are the remaining issues before public release:
- Verify all the dialogue bytes in my script documentation to make sure they are what I think they are
- Clean up the text handling a bit so that the dumped and reinjected text is all UTF-8 and strip away the EUC and Shift-JIS libraries
- Verify that the dumper and reinjector form an isomorphism over the ROM and write a formal proof to make sure this holds with new versions
- Write tests, write tests, write tests.
- Write some usage documentation
- Make sure all FE4 text is being dumped(no missed parts, and no garbage data)
I think I'll release a first version with just FE4 in mind and then adapt it to support FE5 later. Then script injection work can start and I can work on VWF if joesteve hasn't figured it out :)
-
I'm sorry to hear that :( There's nothing more demotivating than losing all of your hard work. Thanks for posting the latest patch you could find :)If anyone still cares about my patch I think this was the final version - I lost the sources when I had a computer die on me (it was in a VM, pretty hard to back up). The patch is on Dropbox. Enjoy.
Thanks for the support! I'm hoping for a preliminary beta sometime before the end of the year. It's taking a while because I decided to rewrite all of the text dumping tools. The text dumper and reinjector actually *mostly* works, but I'm pretty unhappy with the way it finds the regions of text right now. It's a total hack(adopted from the Reparation source) to get FE4 to work and I don't think it will work in FE5 without adding hacks for that game too..I'm interested to see the code of naga, looks cool!
And then at some point I thought supporting the GBA games was a good idea( because FEditor makes fe6 explode :( ), so now I'm studying the dialogue structure and trying to find some 'formal' way of finding all of the text across these games without resorting to brute force searching with rom maps.
So yeah, Project Naga, coming this lifetime™. I'll make a thread about it when I think it's far along enough to show off something :) In the meantime, this is the patch to use
-
OK, I'll change Priest to Cleric.
I thought earlier about doing the double letters thing. The problem is, the individual sprites are now only 16 pixels wide by 32 high (instead of 32x32). So there's only enough space for one letter per sprites. The GBA support multiple resolution sprites so I could theoretically keep the 52 letter sprites at 16x32 and add a couple of 32x32 double letters sprites. But now, the center function and the spacing between letters would all go to hell whenever those double letter sprites would be on screen.
I'll see what I can do though. It may be easier to change the centering+spacing functions so that they're aware of the different sprites width than find the bug in the first place. I found another possibility for the bug which involves the number of color palette. Each letters has its own color palette so that they fade in/out individually. The GBA has a miximum of 16 palettes. When there's >11 characters on screen, that's at least 12 palette used for the characters but there's the name separator, the weapons used and the label "weapons" that all uses palettes of their own. Palettes are also changed in WRAM before dumping them to the Video chip so there's a possibility that too much characters make palette data leaks into whatever's after that in WRAM.
Anyway, like I said, I'll see what I can do!
Oh dear o.O Is there any point where a letter will use a different pallete? If the palettes are the same, perhaps the ASM could be reworked to only use one palette for all of the letters? I could be missing something obvious here.
Thank you for your assistance in this project, consider sticking around! :) We could always use more ROM hackers in the community.
-
As others have said, GBA ROM hacks are very *very* different than FEXP or FEXNA and there isn't any way to convert between the two without a massive amount of manual work. It's an exercise in masochism.
Also the more you have to show, the more likely others are to help you
-
Just in case you hadn't found it yet: http://darktwilkitri.thegreatbeyond.net/dtntd_fireemblem4.php
I respect the people involved in the old translation and the amount of work necessary to create that project, but the script is terribly lacking. Bookofholsety has a fantastic script that will one day replace it, with any luck :)I won't complain and say there were improvements needed in other places outside something as irrelevant as names... but yeah, that's basically what the new patch is.
-
Somehow I keep passing over this game, despite the translation looking fantastic and all of the great reviews from members here and reddit. I think it's because I want to complete Shadow Dragon first, and I just end up losing interest in that game around Chapter 7. Should I finish Shadow Dragon or just jump to FE12?
And on a semi-related note, does Shadow Dragon get better as you go on? :P Maybe I just need to give that game another chance..
-
Neat find, I'm not sure where that came from. Perhaps Thracia 776 Deluxe Edition? I looked it up and saw no mention of a keyring, though.
-
Great to see there's a new version!
As soon as I have a computer and I'm programming again I'll take a look at some of those issues. I haven't forgotten about fixing the level up screen and I wouldn't mind trying to fix some of the other things too.All the other remaining minor issues are basically beyond my current knowledge of hacking, and I don't even know where to begin with solving them. I'll accept any offers of help, but until such offers come, except for bugfixes, the patch won't be worked on actively anymore. There's just nothing left for me to do (that I know of).
Thanks for all of the effort put into this!
-
ARGH Intel *just now* sorted everything out so that I can get a new processor for my computer, but I have to ship the old processor to a warehouse where it will be inspected for a few days then the new processor gets shipped back(so probably 2-2 1/2 weeks more).
I'm incredibly annoyed. The only way around this is for me to somehow get 345$! :/ Honestly, I have no idea when I'll be able to continue work on the translations, because life keeps throwing out some pretty bad situations. Ideally within the month I can start up again..
-
Any chance of a mac version being released? I tried using Wine, but it wouldn't open.
I recommend CT075's randomizer, but for what it's worth, you can run this program in Mono on Mac OS X and Linux with Mono and the mono-basic package.
-
3 days! They will be sleepless nights :P Trailer looks awesome
-
There is probably a 2 glyph limit like FE6. I'm actually going to be looking at that issue in FE6 as soon as my computer is back in commission(which should be tomorrow). It might require a bit of ASM hackery, but I'm confident it can be done.
It would drive me nuts if we had to stick to 2 letters, same with the 8 letter limit. I've even thought about replacing some of the menu boxes if they aren't big enough :P Ultimately, it won't be the priority until text can easily be removed and added.
...
I've drafted out Resire's entire base in a notebook. It's rather frustrating because I can't be sure it works until it compiles and runs. I have some clever ideas to stress test the program to ensure it is correct, however.
I noticed that Lambda Calculus Category theory laws can be applied to Resire:
- The first law is Identity. The result of dumping the whole script and reinjecting it from the text files right after should equate to an unmodified ROM.
- The second law refers to composition of smaller actions into larger ones. For instance, if you dump the script and make a modification to a file, reinject, and make another edit and reinject again, the resulting ROM should be equivalent to making both edits at once and reinjecting the "sum".
Let's talk about the second law. A clever reader may notice that if I inject text that is longer than the destination text, some bytes will be stored in a known empty position in the ROM. This means that if I make 2 edits and they both happen to be longer than the source text, the ROM will actually differ depending on the order of injecting these edits! I did a bit of head-scratching until I realized that as long as the resulting dialogue is the same and the total length of the dialogue structures are the same, the ROM can be guaranteed to be the same, from the perspective of a user.
These laws may seem silly and superfluous, but if you think about it, if these laws hold than the entire program must at least be consistent. They also eliminate many classes of bugs. For instance: the composition law guarantees that making many edits won't bloat the ROM *cough* FEeditor *cough*. The first law guarantees that only dialogue structure is changed, that it is predictable, and that dumping and reinjecting text are symmetrical. Introducing a bug in one system will introduce errors in testing identity unless a symmetrical bug is made in the opposite system! It literally makes writing buggy code more difficult.
I will use a test suite to ensure these laws hold through totality testing.
If any aspiring programmers or simply curious people have any questions about Resire, feel free to ask.
[sarcasm]Hopefully it'll be out this lifetime! [/sarcasm]
-
So, let me get this straight. You want someone to implement a full hack essentially, with only ideas to contribute?
Yeah, sorry, pass. Most people with the knowledge and skills to do these things are already busy with their own hacks. Hacking is hard, where's the motivation to help with a hack if literally no ground work is done?
Learn to do something, make whatever you can and be explicit as to what you need to do and why. Even then, help is something that often comes when least expected. In my experience, you can't expect something to get done unless you do it yourself.
Also, your link is broken.
-
Bad news, my computer is overheating so I've been unable to use it for the past week. I'm unsure as to what the issue is, but I think I should be able to fix it.. Not sure when, though. I need more thermal interface compound and I've been tight on money lately.
It's coming along, though. Just slowly :X
-
MP2E, just wondering, how will the injector insert text into the rom that uses the English alphabet? I know that there's no English font in the original rom, so will your it just add them into the font?
Precisely, it will inject the font over the Japanese font and then the new English characters will be referred to when injected.
I haven't yet figured out where it's all going to go. I am probably going to look at FE4's current font and see where that gets injected.
-
The only thing I can think of right now is maybe they have a different encoding then the rest of the font? Although that wouldn't really make sense to do that, but I can't think of anything else.
That would be consistent with your result above, and in FE4 menu text is stored as a fixed-width variant of the japanese Shift-JIS encoding. Most other things are direct references to the images.
-
Prohibition doesn't work. Throughout history, people have tried to make mind-altering substances illegal and all it does is create a strong demand for said substance. The black market can then rise and the funds can easily promote organized crime.
Illegalizing any substance just destroys innocent lives. I've seen it happen all around me, and any of you who can seriously vote "yes" to this poll are immature. Why does it matter to you what I do in my free time?
I believe in a right that, unfortunately, was never written in the constitution. That is the Right to Freedom of Cognition. Freedom of Cognition is the ability to think however one wishes, whether under the influence of drugs or otherwise.
If your argument is "waah everyone will do drugs" then you are both a cynic and incorrect. Look at Portugal, they legalized all drugs a decade ago and they have only seen decreases in use since.
Please stop the misinformation, instead of demonizing people and substances you should instead learn about it from a scientific perspective and create a view based on that.
Now as for where you are allowed to smoke.. I am not 100% about that one. I think anywhere outdoors should be fine but indoors should be restricted.
I look forward to debating these points.
-
I don't think so because when I overwrote the font with English letters, this happened-
.. snip ..
(It's the 'K' on the SPD bar)
Wouldn't compression cause the glyphs themselves to display corrupted? A Japanese glyph is just replaced by an english one here, which is what I would expect when replacing a Japanese font.
Whether it's correct or not depends on how you reference the glyphs.
I feel like I'm missing something here, though.
-
I've looked into it, and yes implementing a VWF will be very difficult. So for now I'm going to hold off on that until summer time when I have more free time.
At the moment I'm looking for a font to use in the menu for my patch. You'll notice in the screenshot I posted a few days ago that it uses the same font as the Shaya patch. I really dislike that one so that's just a placeholder. Does anyone have any suggestions for fonts? I'm no expert in typography so I could use help here.Edit- You know, I decided I'll wait for the FE4 patch and use that font, just to keep it consistent. I know you probably haven't decided yet, but do you know if you're going to keep the old font or use a new one, MP2E?
The font and mock-up screen shot were both provided by bookofholsety. He used the Mother 3 font as a base, I believe, but there are changes to fit FE's style a little better.
The mock-up isn't *exactly* what it will look like in the final product, but it's a good reference. I think it looks really good.
Note this is for dialogue, not sure what is going to be done with the character/weapons/other stuff font(if anything)
EDIT: Slightly funny story. If you notice I've updated the table file to decode text ~7 times. I managed to find the actual font table inside of the ROM and map it to the corresponding glyphs so that I could fix all of the messed up parts, yet every time the table would break again. It turns out git was automatically changing the line endings, which in turn changed the position of all of the glyphs in the file...
In other words, every time I would push a fixed table file to the internet, it would break again. Kind of maddening. It's fixed now, though :V
-
I'd like to have weapon names along with the type. That looks pretty good! If we decided to statically render all of the 2 glyph combinations we would still have enough room to translate the games, but I'd rather not do that.
If you want to go with static glyphs, it would be better to glyph each word itself. It would use less space and you could reuse words like Iron. Finally, it would allow for proper kerning.
Of course, why bother when variable width fonts can be implemented? It might be needed for a few edge cases where the game insists that we use 8 glyphs, but the general cases will be handled, like dialogue.
Variable width font encoding is something I understand the concept of but I haven't looked deeply into 65816 assembly yet nor as to what subroutine needs to be replaced. It doesn't seem too complicated, more tedious with a lot of consulting a table.
I'd be very greatful if you got a variable width font engine working, joesteve. It'd be one less roadblock to deal with :P I would recommend using bass, written by byuu to compile the assembly. The current dictionary coding routine is found in the j2e source under asm/, it's not in the correct syntax for bass but may help a bit.
For debugging/disassembly I can only recommend Loki. Loki is bsnes' debugger and it isn't on byuu's webpage but if you check his forums you can find it. Or maybe no$snes, that debugger probably costs money, though.EDIT: I checked it out, no$sns is actually what it is called and better yet, the debugger is free. It looks fully featured, and loki is only in beta... So maybe no$sns would be better?
-
EDIT: Found another EUC table file from a different source that already does what I want it to do
-
Small-ish progress update. Still working steadily, I've hit a few roadblocks with the auto detection of dialogue so I've broken out a hex editor to try and figure out if there's an obvious difference between pointer tables and ... everything else. The issue is that SNES opcode length is defined by a register, so in other words, unless you're emulating the SNES AND you've already executed the instruction, you have no idea if it's an instruction or not.
It doesn't *seem* like there's an easy way, but I feel like I'm missing something. I've been reading documentation like crazy to make sure.
Dumping with PPT memory files will still be the default. I'm realizing how much time I've wasted trying to auto-detect text when more important things could be done, so I'm going to focus on getting the actual dumper and injectors finished so we can start putting the actual dialogue in.
Oh yeah, Resire is going to include the re-injector now. Looking at all of the generic code that can be shared between the dumper and reinjector, it seems silly NOT to put it in the same utility.
No plans for a GUI yet, that's far in the future.. I definitely forsee Resire needing to dump font data, character portraits and various other image formats and reinject them, but I don't know if I'm up to programming a full image editor + text editor suite. I'll revisit that idea when I'm a lot farther along.
One huge thing I forgot to mention : This tool is going to be released on Windows, Mac OS X, and Linux. It's command line only at first, but I'll include some simple double-clickable scripts for each platform in the interest of making it incredibly easy to use. Performance is pretty ridiculously fast(like it matters, since it's dumping text) and memory usage is low :)
Oh and, here's a bit of a 'teaser' to prove I'm actually coding and not just a fuckwit: Bit of Resire's code
That code just handles command-line options, I'd like to keep the juicy bits secret for now, but all will be released when it's ready and as close to bug-free as I can possibly guarantee :P
In the interest of not posting a bunch with no progress, I'll probably wait on posting another status update until real progress is made. I'll still be checking this thread a bunch, though.
EDIT: Aha! Found how Team J2e detected pointer tables and it's pretty simple. Whew. Maybe it will be in the first public release then.
EDIT2: The syntax of script files as they will be dumped is now fully documented, check it out here
Hacking the FE13 ROM...
in Fan Projects
Posted · Edited by MP2E
It took until about 2008 til the simpler games were playable (Pokemon, etc) at full speed but 'good' game compatibility didn't come about until 2010-2011. Currently the best emulators are Drastic(for Android), no$gba, and iDeaS. The best one, Drastic, didn't come about until 2013. It's pretty funny to me that an Android emulator is both more accurate and faster than the PC equivalents, but Exophase(the author) is a veteran in the field of emulation.
3DS emulation is currently in its infancy, but it is progressing rapidly. Citra still only plays homebrew demos, but apparently the author is in contact with smealum. The further the 3DS SDK and hacking come along, the further Citra will follow.
If you want my estimate, I'd guess that we'll see the first simple games playable in late 2015-early 2016 and we'll start seeing better game compatibility rates in 2018. 2020 is when you can expect 85-90% emulation.
But who can say? These are pretty conservative estimates, and emulators wildly vary. Maybe the 3DS won't need to be emulated on such a granular level as previous consoles because of the Operating System, and they'll be able to get away with HLE for most of the games? Maybe the 3D hardware is similar to the DSes(which is what took DS emulators so long, a DS GPU is *nothing* like a PC GPU) so the architecture will be easy to import vs creating anew like last time?
Trying to estimate what PC it will require is even more of a guess! I'd say, a faster (2.5ghz+) Sandy Bridge Intel i5 should be able to do it.
Oh my :( my condolences to you and your brother. It's great to see that emulators can do good beyond mere convenience.
100% possible with ssspwn, arbitary execution of userland code will allow for cheat code programs ala Gecko OS, Ocarina and other programs for Wii. I wouldn't be surprised if most 3DS ROM hacks end up modifying the game with a similar loader.Smealum may even have something at release, he did have those hacked Pokemon, after all, so he's definitely poked around with the idea of modifying games with his loader