News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: MegaED X, the Megaman X hacking tool (Now with MMX2 support)  (Read 190176 times)

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #160 on: March 26, 2016, 09:35:25 am »
All except a select few of the X1 sprites load fine.  Same goes for X2.  X3 has more exceptions.

I use the 6 byte table as a reference for matching up sprite to palettes.  There's another table that indexes using enemy event id that has the sprite and assembly offsets.

I was going to take a break from sprite loading, but I looked at it one more time:
- Moth uses the Cx4 chip for rotation when swinging.  The assembly code assumes the rotated graphics are already in VRAM.  The originals are not a part of the compressed region.  There is another sprite and assembly offset after you knock him down (+1 of the values associated with his event id) which are now used in the editor.
- Buffalo loads his arms from an uncompressed place in the ROM and then decompresses the rest of the body.  The sprite assembly assumes the uncompressed code is there which is why my original assembly was off by $20.  I assume the other bosses work this way, too.

There's now a feature where you can hold the right mouse button down and use the mouse to scroll around the main screen.

EDIT: Also fixed the emulator so you configure it in settings or just hit the play button and pick the emulator then.  It records emulator path in the registry.

https://drive.google.com/file/d/0Bx9gzQZCkH8qb2toQ1ZPSWo1Tkk/view?usp=sharing
« Last Edit: March 27, 2016, 10:48:46 pm by RedGuy »

justin3009

  • Hero Member
  • *****
  • Posts: 1658
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #161 on: March 27, 2016, 08:20:05 am »
Yeah, I forgot about Morph Moth being a specific chunk in VRAM that they use for him.

They do the same thing.. sort of.. on the CX4 bosses like the Sigma Head and what not.  Except those are BG3 graphics if I remember right, but they still get messed with the same as the sprites do to an extent.
'We have to find some way to incorporate the general civilians in the plot.'

'We'll kill off children in the Juuban district with an infection where they cough up blood and are found hanging themselves from cherry blossom trees.'

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #162 on: March 29, 2016, 12:06:59 am »
Here's the latest version.
- If you hit 'T' to display events then you can click on them when the event editor is open to go to that event.  Enemies show up as their sprite, camera locks are green boxes, graphic/palette/tile changes are purple lines, and everything else is a small pink square.
- Currently selected lockNum is a thicker yellow line now for camera lock events.
- Fixed a camera lock display bug.

I'm probably going to leave event display mostly as-is for now.  The gui code needs to be rewritten and along with that some better event rendering code.

I think I'm going to spend time checking if all the graphic/tile/palette and camera lock changes are stored sequentially in memory.  If so, I can just save the whole memory block when the level is saved similar to how events work right now.  That will make it easier to setup custom stuff rather than having to use the constraints on the current subIds.

EDIT: Fixed the X3 level palette.  It's been bothering me for a while, but only now got around to looking at why it was off.

https://drive.google.com/file/d/0Bx9gzQZCkH8qLXJtUEJBS2RTa0U/view?usp=sharing
« Last Edit: April 02, 2016, 11:23:45 pm by RedGuy »

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #163 on: April 18, 2016, 01:19:12 am »
Up until this weekend I took a break from the editor and only made some minor bug fixes.  Yesterday I decided to spend some time trying to use libretro and the example lmsw code to get an emulator working inside the editor (internal emulator).  This evening I got something working.  It's buggy, but I was able to beat the intro stage of X2 inside the editor which is pretty cool.





April 20, 2016, 01:04:36 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Here's a short video showing the intro stage being played in X2 inside the editor.  You'll have to excuse my poor playing as I didn't have any megaman game when I was a kid.  :)  I fixed some display bugs and got a basic gamepad controller to work.  It attempts to load the current background tile and palette when the emulator changes it, but it isn't quite right yet.  I'd like to get save states working among other things.

https://www.youtube.com/watch?v=8QIwoahRn7M

April 22, 2016, 12:17:01 am - (Auto Merged - Double Posts are not allowed before 7 days.)
Here's the latest version with the internal emulator.  When you cross a graphics/tile/palette load it misses several frames because the update code is slow right now, but otherwise it runs pretty good.  I have to fix that problem.

The internal emulator works with X1-X3.  It requires libretro (dll included in the zip).
- F12 or file->run internal emulator to start it.  F12 also restarts it.
- Escape to terminate the emulator.
- Space to pause it.
- F1-F10 load state, shift+F1-F10 save state
- T still displays events.
- The current border lock is drawn as yellow rectangle and is updated when the emu RAM is updated.
- Graphics, tile, and palettes are updated when the emu RAM is updated.  The editor doesn't always get these right, though.  These are slow right now and either needs major rework or a separate thread with double buffering.
- Currently loaded sprites have a blue box around them.  Ones that aren't loaded have a red box.
- Locks and some other changes are drawn on top of the emu so you can see exactly when they are activated.
- No keyboard support, yet.  It only works with what I think is a standard joystick controller layout on joystick port 0 (first one).  If you use joy2key try disabling it and see if your controller/joystick works.  I need to add an internal emulator setup menu to assign custom keys/buttons.

There are all sorts of cool opportunities with this because I can read and write WRAM and update the editor as stuff happens in the emulator.  Writing to the ROM/RAM in real time may also be possible, but would be a significant amount of work.  For now I think the save states are sufficient for quick testing.

https://drive.google.com/file/d/0Bx9gzQZCkH8qTlRfZEI3amJZbzQ/view?usp=sharing
« Last Edit: April 22, 2016, 08:04:02 am by RedGuy »

CrAzY

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #164 on: April 22, 2016, 02:14:26 pm »
Excellent job. That internal emulator is so kick ass! I also like that it changes the level for you in the editor as you play. This is coming along quite nicely now, can't wait to see some level changing rom hacks for the SNES series. It has been far far too long.

justin3009

  • Hero Member
  • *****
  • Posts: 1658
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #165 on: April 22, 2016, 02:37:45 pm »
You're work on this is absolutely amazing.  I'm SOOO glad someone decided to pick this up and you're going way above and beyond what anyone would've thought would happen with this editor.  Just amazing work!
'We have to find some way to incorporate the general civilians in the plot.'

'We'll kill off children in the Juuban district with an infection where they cough up blood and are found hanging themselves from cherry blossom trees.'

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #166 on: April 22, 2016, 09:05:20 pm »
Thanks for the kind words, everyone.

I ended up reworking a bunch of the drawing code.  In the process I broke some of the editors and attempted to fix them.  If someone could give this (more experimental than usual) version a try I'd appreciate it.  The good news is that crossing over events which change graphics should be a lot faster in the emulator, although, sometimes there is a small graphics glitch.

<file>


April 24, 2016, 08:27:57 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I was allocating too much memory for the double buffered level/events (which was locking up some people's computers).  Here's a fixed version.  This also fixes some "VRAM overflow." messages in X3.

https://drive.google.com/file/d/0Bx9gzQZCkH8qMUZwc29SUF9fV2s/view?usp=sharing
« Last Edit: April 29, 2016, 09:37:11 pm by RedGuy »

DackR

  • Full Member
  • ***
  • Posts: 130
  • Mo~
    • View Profile
    • Hackaday.io Page
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #167 on: April 24, 2016, 09:53:24 pm »
Looks like you're the right "guy" for this project. Love where this is going!!

I'll try to find time to take a look at the latest editor this week. I'm really excited to play around with it!

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #168 on: April 30, 2016, 12:15:17 am »
Here's a version with some minor bug fixes.  I made an attempt at adding an internal emulator key/button setup, but it didn't turn out as expected so I disabled it for now.  I should probably take a look at what snes9x does and do something similar.

https://drive.google.com/file/d/0Bx9gzQZCkH8qWEQydWxLSFNvMzQ/view?usp=sharing
« Last Edit: April 30, 2016, 06:42:23 pm by RedGuy »

Seeeeph

  • Jr. Member
  • **
  • Posts: 92
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #169 on: April 30, 2016, 11:09:35 pm »
.
« Last Edit: June 01, 2016, 09:20:53 pm by Seeeeph »

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #170 on: May 01, 2016, 04:05:16 pm »
Here's a new version.
- Fixed a few emulator graphics problems.
- Added internal emulator key/joystick settings menu.
- Updated retro.dll to latest snes9x.

Before running the emulator make sure to go into the settings and change the button mapping.
* Set the joystick drop down to the correct number (likely 0).  Or set it to disabled.  If you use joy2key you probably should disable the joystick in the editor.
* Click on each box (turns green) and press a joystick button or key to change the mapping.  If a key is already in use the box will turn red and won't change.
* Hit Save.

All the keys the editor already uses (e.g. event toggle = 'T') are considered used already.  It would be nice if they were configurable, but I don't want to rewrite that portion of the editor, yet.

EDIT: I messed up the scene, block, and tile editor a few versions back when I added transparency support.  This version reverts that change temporarily.

https://drive.google.com/file/d/0Bx9gzQZCkH8qNUhLWWtDQnpaMHM/view?usp=sharing
« Last Edit: May 17, 2016, 11:12:55 pm by RedGuy »

Satoshi_Matrix

  • Sr. Member
  • ****
  • Posts: 267
  • Retro & Contemporary Gamer
    • View Profile
    • Retro & Contemporary Gaming Archives
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #171 on: May 02, 2016, 04:21:32 am »
This gives me hope that there will be a slew of high quality Megaman X and X2 hacks in the near future. Given how damn good both games are, I find it rather disappointing there aren't any level hacks that expand upon the original, or try different things. So many concepts of where power ups and the Light capsules could be hidden. Hopefully someone skilled will make use of this tool very soon!

Hart-Hunt

  • Jr. Member
  • **
  • Posts: 23
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #172 on: May 02, 2016, 09:17:49 am »
Well, the is one, it just isn't hosted on RHDN. It's for X1. But, since the tools the creator used were prior to this big update, the hack didn't reach its full potential.

Google Mega Man X Hard Type for more info.

Satoshi_Matrix

  • Sr. Member
  • ****
  • Posts: 267
  • Retro & Contemporary Gamer
    • View Profile
    • Retro & Contemporary Gaming Archives
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #173 on: May 04, 2016, 06:30:01 am »
Yeah, I've seen that. It's a shape that the only existing extensive level hack is one that's designed to be extremely difficult. ROM hacks are at their best when they are balanced for new comers and don't get really tough until near the end game. This is especially evident in Super Mario World hacks with so many of them not being much fun to play because they're so focused on difficulty.

But like I said, I look forward to seeing what people are able to make with this level hacking tool.

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #174 on: May 22, 2016, 10:24:47 am »
Here's a new version:

- Added layout editor (placement of scenes within a level).
- Fixed bug where it would save dynamic tiles (if current loaded tile set is > 0) as part of tile set 0.  Would result in corruption of tiles.
- Added emulator termination to reset tile and palette sets to 0 (to help avoid above problem).
- Added very experimental ROM expansion feature (File->Expand ROM).
- Fixed some X3 bugs where compressing tiles would sometimes corrupt other levels.  Buffalo doesn't compress into a space smaller than the original ROM so it's not possible to save that level right now unless you click 'No' when it warns you the tiles won't fit.

https://drive.google.com/file/d/0Bx9gzQZCkH8qZlJ6QTNtM20xTk0/view?usp=sharing

I added the layout editor hoping that it would be easy to fit changes into the existing ROM space.  Unfortunately, the layout is compressed and changes are very likely to require more space due to how simple and effective the compression is.  Sorting scenes or rewriting the compression algorithm in the ROM might help in certain cases, but wasn't a complete solution.  So I gave up and finally added a feature to expand the ROM - similar to what the Castlevania 4 editor will eventually have.

ROM expansion is very experimental right now but the idea is to move the layout, events, and anything else worth moving into space > than the original ROM size.  Currently it just moves layouts and events and provides $800 bytes per level for each.  Events required some minor hacking of the instructions in X1 and X2.  X3 was a lot more painful because it's already a 2MB LOROM and any additions get address mapped to banks whose low offsets (0-$7FFF) aren't shadows of RAM, etc.  The original event code was using indirect, offset LDs with a bank register value < 2MB and STs to WRAM using the mirrored address.  So the editor changes those to indirect, long LDs using a 3B address in memory with the updated bank along with some modifications to the bank register management.  It ended up requiring only a handful of code changes and it seems to work.

It should always be possible to expand a non-expanded ROM, but it's more difficult to update an already expanded ROM to a newer format.  It's also a little tricky to support multiple different expanded ROM types.  This could be solved with versioning, but I'd rather not add a lot of complication to support this with the editor.  Although, I did end up adding a small expanded ROM header with a version number but it's not used correctly in the editor.  So my recommendation would be to try the expanded ROM feature but don't develop anything with an expanded ROM you don't mind redoing, yet.  It's pretty cool to have $800 bytes for events...


« Last Edit: May 22, 2016, 01:40:56 pm by RedGuy »

justin3009

  • Hero Member
  • *****
  • Posts: 1658
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #175 on: May 22, 2016, 12:06:02 pm »
That's probably the best way to go honestly.  Any kind of level editing should expand the ROM, that's how I view it.

And yeah, that was a big problem I had as well with the game on the Zero Project.  Only certain bits of data could be read outside of the normal 2MB range but not all of it.  Mainly the PC's actual graphics could NOT be outside of the 2MB range due to how X2/X3 handle it using the CX4 chip, however, I have a theory that if the data from X1 that does what X2/X3 does without the CX4 chip could be ported over into X2/X3, it could actually go beyond the 2MB without any issues.  I'm unsure if this also applies to compressed level graphics as well though.  I would doubt it since there not actively loaded frequently but it wouldn't surprise me.
« Last Edit: May 22, 2016, 12:43:11 pm by justin3009 »
'We have to find some way to incorporate the general civilians in the plot.'

'We'll kill off children in the Juuban district with an infection where they cough up blood and are found hanging themselves from cherry blossom trees.'

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #176 on: May 23, 2016, 04:26:40 pm »
In X3 I got lucky and all the offset LDs (2B OFFSET in memory DBR:OFFSET) were easily converted to long LDs (3B address in memory BANK:OFFSET).  The extra byte in memory wasn't being used so I replaced the PHA/PLB with a ST to the 3rd byte for the bank and turned some other DBR PHB/PLB operations into NOPs.  There was also another section of code that did a PLB followed by an offset LD LowRAM access.  I was able to swap the two instructions so the LowRAM access used the previous bank that supported the shadow so the current level number loaded correctly.

If I remember correctly, the X2 OAM setup for the CX4 was mostly DMA operations with some basic setup and the write to initiate it.  DMA should be fine since that includes a bank.  But I can see the setup/initiation events needing a bank that supports shadowing.  Would converting LDs and STs to long addresses work in that code to avoid changing DBR to a bank that doesn't support the shadow?

The basic sprite assembly format in the ROM is the same for X1-X3.  I was considering adding the OAM setup code to X2 and X3 for a different reason: to remove the need for the CX4 chip.  I decided against it when I found out more than just the wireframe bosses used it for rotation/scaling/etc.  It may also slow down the games to not have the coprocessor do the OAM setup.  I can look into this again if you think there's value.

Tile decompression happens throughout the level based on the object and tile offsets in certain events.  For now I've decided against moving background and sprite tiles to higher addresses because they take up a lot of space and the background tile compression with sorting seems to do a good job of fitting any changes into the original compressed space.  But If I ever want to support major editing of background or sprite tiles I may have to move them, too.

justin3009

  • Hero Member
  • *****
  • Posts: 1658
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #177 on: May 23, 2016, 07:14:14 pm »
That would probably fix it in all honesty.  I didn't try to experiment with it too much but yeah there was a distinct problem with them going beyond the 2MB range when they were decompressed flat out.  Maybe it's different for compressed sprites though.

In essence there's not much value to an extent unless someone REALLY wants to graphically overhaul or add a ton of new animations to X, Zero or whichever enemy as that issue with it being outside of the normal bank would cause some problems.  I don't think it's absolutely necessary in the editor but it was a fun idea to toss out and get discussed real quick, it seems like though you experienced something similar so maybe it's all graphics in general.  Unless the editor evolves into a full blown AI, script and event editor, it's probably not worth going into such depth for a minor support that I don't think many people would take the time to understand.

I didn't realize the graphics were decompressed throughout the level.  From what I saw just by glancing at it, it threw everything up instantly for the tiles needed right away.  Though I suppose when it comes to certain objects it probably needs to change something, but I think anything that was destructible basically turned into a sprite the instant it happened.
'We have to find some way to incorporate the general civilians in the plot.'

'We'll kill off children in the Juuban district with an infection where they cough up blood and are found hanging themselves from cherry blossom trees.'

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #178 on: May 24, 2016, 01:16:47 pm »
Sprite vs background is usually a function of how the player interacts with it.  If explosions or background tile changes are triggered by events and  don't interact directly with the player then are usually kept as background tiles.  When the level starts up it decompresses the initial set of background tiles into VRAM.  As the character runs through and triggers event additional tiles are loaded into VRAM on top of the existing ones.  In 90% of the cases these "dynamic" tiles are actually not compressed so they are just copied from ROM to RAM.  I think there are some exceptions in X3 where they need to be uncompressed.   EDIT: I should clarify that the dust and fireball part of the explosion is sprites, but the changes to the tiles like holes and damage is mostly background tile changes.

If you play through the intro stage of X2 in the editor with events turned on ('T') and the tile editor loaded (I think it refreshes properly).  You can see various parts of the background purple robot tiles loading as you cross events.  When you finally reach the top of the level all the tiles are loaded.  This overwrites tiles that are no longer used and you can see earlier parts of the level start getting corrupted because those tiles are the ones being replaced.  It starts happening almost immediately in the level where the hills outside get corrupted.

If the character is going to interact with the background (falling ceiling pieces in X3 intro or boxes moving in X2 centipede) the interactive pieces are done as sprites.  Sprites almost always need to be decompressed (the major exception seems to be the character and certain boss bits) and the decompression and VRAM loading is triggered by events the character passes through.

If you play through the a level in the editor with events turned on you can see blue boxes around sprites that are currently in VRAM and red boxes around ones that aren't.  In X3 intro the falling ceiling are red until you pass a certain event before Mac captures X and they turn blue since they need to be loaded to appear properly and drop on Zero's head.

The level designer is forced to do memory management of VRAM to give the appearance of more than 64KB as the player progresses through the level.  They do this by placing background tile, sprite, and palette change events.

May 25, 2016, 11:09:54 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Here's a new version.
- Expanded ROM now supports $60 scenes per level.
- Layout editor now updates when switching between background and foreground tiles in the main window.  You'll lose unsaved changes on the switch, though.

Expanding the number of unique scenes seemed like an important part of designing larger and more detailed levels.  It ended up being $60 for a weird reason - the code runs out of space in RAM with larger values and starts overwriting other things.  I originally tried to add $FF total but it ended up wrapping around in RAM and overwriting all sorts of important things like the controller input and sound related stuff.

https://drive.google.com/file/d/0Bx9gzQZCkH8qdlNhZU42ckQ3b28/view?usp=sharing
« Last Edit: May 25, 2016, 11:09:54 pm by RedGuy »

slidelljohn

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #179 on: May 26, 2016, 12:32:10 am »
Quote
Expanding the number of unique scenes seemed like an important part of designing larger and more detailed levels.  It ended up being $60 for a weird reason - the code runs out of space in RAM with larger values and starts overwriting other things.  I originally tried to add $FF total but it ended up wrapping around in RAM and overwriting all sorts of important things like the controller input and sound related stuff.

How many more bytes of ram do you need to go from $60 scenes to $FF scenes?