Jump to content

Zane Avernathy

Member
  • Posts

    174
  • Joined

  • Last visited

Previous Fields

  • Favorite Fire Emblem Game
    Sacred Stones

Member Badge

  • Members
    Duck

Recent Profile Visitors

4,023 profile views

Zane Avernathy's Achievements

  1. So, why not post those here? Additionally, what're the responsibilities and requirements for "Developers, bug testers, Translators, and team leads"? Finally, what do you bring to the team? Why should anyone join you rather than doing it themselves?
  2. Including the anti-huffman patch, which is basically a requirement for any custom/edited text? I'm also curious as to why you'd disallow the essential fixes which consists of QoL features and bug fixes. There's also the question of whether this applies to ASM changes applied automatically by tools, such as FEditor's autopatches.
  3. Booky's been hard at work. There isn't a release date set in stone, but he says that script stuff is nearly done and he's aiming for a release soon.
  4. Thanks for the suggestions! Tilesets are mildly annoying to edit, but custom/edited ones are entirely possible. In fact, Another Journey has a few tileset edits (walkwable double pillars on the map, some other alternate pillars that've yet to be used).
  5. A few of the portraits in the "Others" sheet are used to represent the artists when reading off the credits at the end of the patch. I figured that it'd be best to let the artists represent themselves with a portrait of their choice. The Lyon portrait actually replaces Anna when the suspend option is chosen, stemming from a joke suggestion in my dev chat. It also serves as a kind of throwback to the original project I wanted to do in FE5, which was an FE8 sidestory that never took off.
  6. Hacking is a hobby. Like all hobbies, there are a few basic principles to it: A large part of my work with ECVII has been tackling the tedious. I've redone nearly everything in the hack at least twice now, creating and updating tools and methods. Unlike modern GBAFE hackers (not to bash them, however), I simply don't have multiple text insertion methods, fancy editors, or a documented event standard library unless I write them myself. So I did. A lot of the tools I've written are currently unpublished due to their rather amateurish state. I do plan on releasing them, too, but there's still a lot of iterations to come. I think that the best hackers are the ones who actively release documentation and tools for the betterment of other hackers, which is why I strive to post as much information I can. Here are some examples: So, surely all of this information helps me work on ECVII, right? Let's talk about some progress I've made. A huge amount of effort has went into a portrait formatting tool that automatically converts portraits from a human-readable hackbox state into a compressed 4bpp SNES image, palette(s), and table entries. Here are the portraits we currently have now: Huge amounts of cleaning files and transferring individual tables and routines into their own files, along with some organizational tools and macros to keep things fairly drag-and-drop. I've started transitioning menu elements to a prerendered variable-width font. It's not without its issues, however (possibly more on that later). Events have been partially redone with changes to my fe5stdlib. The library currently has most of the vanilla codes documented. Events also are utilizing much more sensible encoding definitions. I've figured out quite a bit of FE5's text control codes, too. Up next is maps. I've written a map converter based on circleseverywhere's tmx2ea and have maps for chapters 11-17, 19-20, missing Port of Badon because of a current lack of a proper ship tileset. (Did you know that water tile animations take up $10000 bytes in the ROM?) I mentioned before about using images for menu text. There are some huge issues with that, including but not limited to: There's so much more I could talk about, from the multiple things I've found in the game that nearly nobody knows about to the dozens upon dozens of routines I've written to get anything at all done, but I feel like I'm rambling on at this point. Here's your tl;dr: If you knew just a smidgen of the amount of work that goes into any hack, especially one for a game without an active community, established tools, or doc, you wouldn't make low-effort comments toward people who spend their time creating hacks. Be patient and understand that this is something I do for fun.
  7. SoA is older, your names are entirely generic, and your claims are baseless. You might as well be dogpiled for using any of the names in that thread that're based on existing things. You do realize that 'Shon' is the name of a protagonist in one of the most well-known GBAFE fangames, right? This is a good way to get the FE hacking community to dislike you.
  8. I know this is really hard to understand, but different types of "coders" aren't useful in the same ways when making a project. Someone who knows THUMB assembly Someone who knows Python Someone who knows 65816 Someone who knows C, C+, etc Someone with experience using GBAFE's engine(s) Someone who does RPGMaker scripts etc. all do very, very different things. Are you looking for some type of programmer? Someone who can write events? Do you need some kind of external tool made? Don't get defensive, get specific. It sounds like you don't know anything at all about what you need.
  9. Making something in FEXNA will probably take just as much learning, reading, and effort.
  10. As far as permissions go: I doubt Blazer'd let you do it. As far as logic goes: This is a dumb idea. If you're having trouble repointing and expanding something, editing an existing hack is going to make things harder for you. Things won't be where or how you'd expect them to be. Many resources and tutorials simply won't work. You wouldn't buy a new car to replace a flat tire.
  11. Setting a goal is a good idea! Be sure to read all of the documentation that you can. Give this entire section of the forum a read, especially the resources and questions subforums. Be sure to check out FEUniverse.us, too, which houses a lot of technical info. I don't know exactly what you guys might have read, so I'm going to dump some common resources here as a starting point. Blazer's Ultimate Tutorial This is one of the most common starting points for GBAFE hackers. It's pretty old and uses outdated tech/methods, but is certainly a good starting point for figuring out how to work with GBAFE. Please note that the ideas, not the techniques are important. Tools and programs have changed. Arch's advice for hackers Big names talk big ideas here. Read this. Unified FE Hacking DB This is the wizards' playground. Although most of this isn't particularly useful for newcomers, there's a Toolbox folder containing a lot of common tools. This DB also has plenty of ASM, doc, and musings from talented people. I'm not about to go link the entire Resources subforum, but you should probably check it out.
  12. For an explanation of how I went about extracting the map sprites, see here. I don't know anything about the battle animations. I don't see why this matters. Besides, it shouldn't take you long to check yourself, if you wanted to.
  13. Here's a writeup of how you'd go about extracting these yourself: Map sprites in FE5 are comprised of four pieces: An unknown moving sprite, a set of 3 idle sprites, a set of 16 moving sprites, and a variable number of combat sprites. I'll be going into detail for each of these. Each class within the game's class data has a byte for that class's default map sprite. The uppermost bit of this byte is a flag for whether the class uses mounted sprites. The unknown, moving, and combat sprites are selected by using this byte as an index for another table, but the idle sprites use this byte more directly. The formula to get this index from the default map sprite byte is: if default < 0x80: index = byte at 0x363AD+default else: index = byte at 0x363AD+((default&0x7F)+0x4B) If this index happens to be above 0x69, it is set to 1. To get the unknown sprite, the formula is: offset = 0x190000+(0x200*(index-1)) Each is a 32x32-pixel uncompressed 4bpp SNES image cut into four rows of four tiles each. Here's an example of how they're formatted within the ROM, scaled x4. In the ROM, the order of these rows is 1, 3, 2, 4, where row 1 is the top row. Each unknown sprite takes up 0x200 bytes. To get the idle sprites, the formula is: if default < 0x80: offset = 0x388000+(default*0x180) sprite is 16x16 pixels else: offset = 0x398000+((default&0x7F)*0x240) sprite is 16x24 pixels Both are 4bpp uncompressed SNES images. Here's an example of how the smaller sprites are formatted: And the larger ones: As you can see, these larger sprites are in the order 2, 3, 1. Moving sprites are where things start to get complicated. First, we get a short pointer to an animation data table: pointer_offset = 0x51D23+(2*index) The routines that read these short pointers expect the animation data table to be in the same bank, 0x8A (mapped). Each entry in this table consists of two long pointers followed by a byte. The first pointer is to the graphics, the second is for the animation's script. The byte determines the direction that the unit faces when initially selected. Possible values are: 00 - Left 01 - Right 02 - Down 03 - Up Graphics are compressed 4bpp SNES images. Format is the same as the unknown sprite, but repeated for each of the 16 moving sprites. Finally, there are the combat sprites. I don't actually know the specifics of these. The sprite index is used to select an entry in a short pointer table: pointer_offset = 0x26A89+(index*2) Like the moving sprites, the routines involved expect the animation data table in the same bank, 0x84 (mapped). Each entry is a set of 8 long pointers, one for each cardinal and diagonal direction. The graphics are compressed 4bpp SNES images. Their format varies, and I haven't gone looking for whatever determines how they're displayed.
  14. I have not extracted or edited battle sprites yet, but they are compressed graphics cut into pieces with some kind of frame data that determines their placement.
  15. To be as blunt as possible, these topics are the ones that experienced hackers laugh at. If you want help, post your experience, skills, examples of things you've done, etc. If you have a team, list your team and do the same for them. If you have an idea, pitch it to us like you're actually asking someone to publish your story. If you can't do any of these, you'll never finish your project. I see new faces talk about "coders" a lot. Do you mean people who know Thumb Assembly? Maybe someone who knows GBAFE eventing? I think there are less talented music-oriented hackers than there are assembly hackers, so good luck with composers. What kind of artists? Portraits, battle spites, weapon icons, etc. are all pretty commonly changed in hacks thanks to easy-to-use tools, but could you work on more complicated things? Some tasks require knowledge outside of graphics themselves. "Designer" is such a general term that it's meaningless. What do you need designed? You need to be very clear with what you can and cannot do. How much do you know about hacking? What tools are you comfortable with? Are you confident that you can solve problems that will arise? Truthfully, the most important thing for a hacker isn't experience with a tool or knowledge of some task. You must be able to solve problems, debug your work, and hunt for information. This is exactly where it'd go. If you can't be straightforward to the people you ask for help from, none will ever help.
×
×
  • Create New...