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 189751 times)

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #140 on: March 02, 2016, 01:53:40 pm »
I'll take a look at vsnes.

The rotating priority was the problem. I reversed the order of tiles. Now I need to add transparency and load the right palette. Then I can move on to maintaining all of VRAM so I can draw any enemy whose tiles have been loaded properly.

March 02, 2016, 11:50:26 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Ok.  Got it working for 8x8 (small) and 16x16 (large) tiles.  It has a few hacks in the code which aren't very pretty .  I'll take a look at the VRAM loading now.  I'm thinking of scanning all events up to the current one and loading up the VRAM.  Then I can display it in the event editor so you can double check what graphics are loaded and also makes it straightforward to display the enemy sprite at the current event.





March 06, 2016, 11:33:38 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I took a break from adding the VRAM tracking code and enemy display to support camera lock editing.  There are events (type=0x2, id=0x0) that trigger camera locks in 1 or more of the 4 directions.  The event editor can now be set to move between only camera lock events with a checkbox.  Events that trigger locks display a green bounding box that the engine checks when you enter it updates the bound to the direction and distance of the yellow line(s).  There are sometimes more than one direction per trigger event.  These types of events are often in pairs (or more) because you need to support the change in bounds when you are going in the reverse direction of the level (first event) and when you are going in the normal direction of the level (second event).  There's not a great way to add extra locks, but you can move the existing ones around and edit the directions and bounds.

Source updated.  Here's a binary: https://drive.google.com/file/d/0Bx9gzQZCkH8qdkR6bUZKRVhYRk0/view?usp=sharing

Here's an example from Kuwanger's stage where it changes (restricts) the bottom bounds after you climb up the ladder and opens up the right section.


« Last Edit: March 08, 2016, 04:05:53 pm by RedGuy »

Sting_Chameleon

  • Jr. Member
  • **
  • Posts: 3
  • Not the best, not the worst. Just... Normal...?
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #141 on: March 07, 2016, 01:39:16 am »
Very glad to see how far the emulator is coming along! I do however have two suggestions that seems to be an issue(both minor and not program breaking, but somewhat itchy in a way). I also have two suggestions that aren't bugs in the program, but something that would be nice to see changed.

Bugs I noticed:

1. On start-up, there is an invalid path error. I think it's the first time loading as well, as it'll close itself then re-open with the same error(only once though). Any further openings will result in the error message again, but the program stays open. It seems to be linked to the checkbox under File > Settings.
2. Under File > Settings, I'm unable to specify a path to my emulator.

Ideas I had in mind(seems like minor bugs too... ah well. shrugs):

1. When editing the tile properties, or at least viewing them on the main screen, it's difficult to read the numbers written on each tile. I mistake d for 0 and b for 8 quite often.
2. When editing scenes, the program doesn't update the map until the ROM saves or when a different level is switched to and return to the stage modified.

Aside from the two issues and the two suggestions, I've been enjoying the updated utility! I'm not sure how I can tribute/assist aside from spotting bugs I find(I'm not a strong programmer, but if there's basic hex tweak modifications needed as far as locations go, I can help there).

Also, if I may ask, what all is on the list of things to do for the utility as of now? Or is that a surprise in the future?  ;)
What would you rather have? A party cannon, or a cannon party? ...... I may not know your answer, but lets just agree that I would pick the same thing.

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #142 on: March 07, 2016, 12:59:50 pm »
I'll try to fix the settings menu if it's easy.  If not, I'll likely disable it along with the associated code to get rid of the error.  It doesn't look complete.

I can take a look at making the text more legible on the main screen.  It uses the font from the game.  There are quite a few bugs where changes are lost if you don't save.  E.g. most changes to tile graphics are lost if the level is changed.  Some of these bugs were introduced by me and some were there before my modifications.

It should be easy to have scene changes get reflected immediately in the main screen.

My goal was to help the person who originally asked for X2 and X3 support, event editing, and camera lock editing.  They are satisfied with the current version barring any bugs or new ideas they may have.  I don't have a formal list of future work, although, I'm interested in getting the enemy and object sprites to be visible for more IDs.  My gui programming skills and the editor could use a lot of help here.  That's why the new things are red, green, and yellow rectangles.  Those are easy to draw.  :)

Features will be mostly a surprise, but everyone is welcome to make suggestions and point out bugs.

March 07, 2016, 11:25:40 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Fixed edits in the scene editor to now show up in the main map view.
Fixed fonts so they use the correct base font palette.
Fixed possible read of uninitialized settings variable.

The font is a little easier to see now.  Not sure if that helps, but at least it looks nicer.  X3 was using a random piece of memory as a palette before.  The settings seem broken on my machine (ini file never gets created) but other people aren't having a problem.  Eventually they should be updated to use the registry and not a ini file.

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

March 09, 2016, 12:30:52 am - (Auto Merged - Double Posts are not allowed before 7 days.)
See if the collision font is better in this version: https://drive.google.com/file/d/0Bx9gzQZCkH8qSFdfVUVwVmdUQnc/view?usp=sharing
« Last Edit: March 09, 2016, 12:30:52 am by RedGuy »

Bahamut ZERO

  • Hero Member
  • *****
  • Posts: 903
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #143 on: March 09, 2016, 06:59:55 pm »
I know what I'll be playing around with the next time I'm burned out on the project I'm doing.  :D

Keep up the amazing work.  :)
Like Super Mario Land? Then you'll love my first completed Rom Hack: Maniac on the Run!

Sting_Chameleon

  • Jr. Member
  • **
  • Posts: 3
  • Not the best, not the worst. Just... Normal...?
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #144 on: March 10, 2016, 12:00:00 am »
I jumped on to try the latest fix a little while ago.

I'm loving the newly updated font for each tile type. This makes it perfectly eligible without using a magnifier program and comparing pixels. No more problems with the aforementioned fixes. The scene editor now updates smoothly(even if it's not immediate on the main map, it still updates before closing the scene editor. :thumbsup: ) Though more ideas flow through my head. Here's more from me.  ;D


Some more ideas and requests:

1. The ability to select a path for the SNES emulator for tests.
2. As much as I want #1 implemented, I'd much rather be able to modify the sprites and other enemies with less of a hassle.
3. Also, what I'm curious about is why/when does the tileset change with enemies and boss rooms? Is it special events? If so, that needs to be labeled when going through event editor mode[1]. I know there's some way this is modified that doesn't seem easily legible in the editor, or I must be incredibly blind when I scan through the functions.
4. The icons at the top would be needed to be changed to make things easier to register when going through them. I can spend a few hours when I get up to make a few images to fit the buttons more easily that fits the style of the editor, giving it a unique and less boring feeling while editing[2].

[1]So maybe in standard font... "GFX CHANGE" or "TILESET CHANGE" then the tileset/gfx offset which the changes are made. If you want an image for this, I'll do my best to provide.
[2]If you can give me a recommendation on the pixel dimensions(or at least a max and min size to work with), I can try to work out what I can. Also I would need to know what format to use. JPEG/PNG/BMP, ect.

This is pretty much what came to mind when I saw the editor. Also be warned, my paint skills are no better than programming a line draw in an application. But I make do with what I'm capable of. :)

Here's 100k  :cookie:  for your hard work so far! Share to your contributors(exclude me, haha)!
What would you rather have? A party cannon, or a cannon party? ...... I may not know your answer, but lets just agree that I would pick the same thing.

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #145 on: March 10, 2016, 12:55:35 pm »
The settings need an overhaul which includes specifying an emulator.  Not sure if/when I'll get to this.  I'm sure basic management of the registry for settings is not hard, but I've never done it before.

Modifying sprites is interesting, but lower priority to other things.  Before a real editor can even be considered I need to first better understand the snes code which moves things into VRAM.

My basic understanding of it is checkpoints load a base set of tiles, objects, and palettes into VRAM along with a bunch of other things.  There is a checkpoint at the start of the level.  Events (notation is type, id, subid) can advance the checkpoint.  There are also events that can advance the tiles, objects, and/or palettes (individually?).  Typically these replace a small section of VRAM.  For example, in mmx1 on the highway stage the spikey tiles are loaded into VRAM with the first checkpoint along with cars that go by.  Then there is an event ($2,$15) before the gun volt that loads the gun volt tiles into VRAM.  If I remember right, it replaces some of the car tiles.  Some of the sprite tiles are compressed with either a simple MFU byte encoding (X1) or LZSS (X2/X3).  Some are not compressed.  X character tiles are generally not compressed - I assume because there are so many of them so it's better to just go to ROM and read it than using a lot of RAM all the time or frequently decompressing it (slow).  Enemies are generally compressed, but the big X2 intro stage boss is not.  Presumably for the same reason as X character tiles.

Ideally, the editor would identify what each event does, but I haven't had to time to work through instruction traces and make a list.  Type 0=?  1=random (non-interactive?) sprites like cars, etc 2=checkpoint loads, tile/object/palette loads, camera locks, etc 3=enemies including interactive sprites like elevators.  2,0,X is camera lock changes.  2,B,X and 2,2,X looks like checkpoint changes, but not sure on this.

The code is a bit of a mess right now as everything being added is experimental and poorly commented.  Most of the main view's drawing code is in MegaEdX.cpp (see WM_PAINT:)

I appreciate the offer for making new icons, but the editor is in too much a state of flux right now to spend time making it look better.  I'd hate for you to spend time making graphics that end up not being used because major things change.  For example, we may find that the current event and checkpoint editor should be combined making one less editor (and one less button).
« Last Edit: March 10, 2016, 03:14:51 pm by RedGuy »

Bahamut ZERO

  • Hero Member
  • *****
  • Posts: 903
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #146 on: March 11, 2016, 06:28:18 pm »
For what it's worth, I'm 90% sure the compressed graphics for Megaman X can be decompressed using Lunar Compress.


Not entirely sure if Megaman X 2 and 3's compressed graphics can be decompressed with the program, but I know I saw Megaman X 1 listed as one of the games it could decompress graphics for back when I was editing graphics in Star Fox.
Like Super Mario Land? Then you'll love my first completed Rom Hack: Maniac on the Run!

DarkSamus993

  • Sr. Member
  • ****
  • Posts: 291
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #147 on: March 11, 2016, 08:46:06 pm »
Lunar Compress can indeed decompress Mega Man X1 graphics, not X2 or X3 (though X3 does have this tool).
The command format is:  "FileToDecompress FileToSaveAs OffsetToStart(h) Format Format2"

My old documentation I made while using the program shows the compressed graphics start at 0xD0200 (headered ROM) and the program itself will only decompress 10000 bytes max at a time (if you use 0 for Format2).
So something like this: "MMX.smc MMX.bin D0200 102 0" will decompress 10000 bytes starting from ROM address 0xD0200.

Side note: the Lunar Compress DLL source code itself is not provided (where the actual decompression routines are programmed). What is provided however is the source code to help build your own application that uses the Lunar DLL.

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #148 on: March 11, 2016, 09:16:42 pm »
Thanks for the info about Lunar Compress.  The mmx editor already had X1 compression/decompression support before I worked on it.  I added code for X2 and X3 compression and decompression (LZSS) support in order to load and save tile graphics in those roms.  So I think we have all three games covered when it comes to compression and decompression.

March 14, 2016, 12:48:51 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Small update.

I have most of the X1 enemies displayed when using the event editor.  The palette isn't always right, but it's still recognizable so I'm going to get the other sprites (misc objects like heart tanks and background cars) working.  Then I'll do the same for X2 and X3.

I also changed the sprite editor so it loads up the current enemy/object sprites into a window so you can see what tiles are available.  Ideally, this would be synchronized in some way with the event editor.  At one point I was using the sprite editor as a VRAM source for the event editor, but it seemed painful to have to update that view every time you move past a 2,15,x event just to see what enemy is.  It seems better to allow the user to place enemies wherever they want with some feedback on the current graphics loaded and then they can later modify what graphics get loaded so enemies show up properly.

2,x,x events are understood a little better now in how they trigger and change sprites, level tiles, and palettes.  There are also a lot of custom 2,x,x events that do things like spawn multiple enemies (e.g. jamingers, dragons) or multiple objects (moving platforms in X1 Eagle), create explosion effects, and other stuff.
« Last Edit: March 14, 2016, 12:48:51 pm by RedGuy »

Sting_Chameleon

  • Jr. Member
  • **
  • Posts: 3
  • Not the best, not the worst. Just... Normal...?
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #149 on: March 14, 2016, 09:58:33 pm »
This is a speculation on my part, but is the Dr. White capsule types hardcoded to the stage value, or is it hardcoded to asm? I know the check for MMX's equipment starts before the level loads to figure out if he has the upgrade or not, and a second time when MMX gets close to the capsule itself before it loads. I've done numerous tests and I'm not sure what the upgrade capsules look at when giving MMX the proper upgrade.

Also I did revert back to the previous editor. As a bug update, after the first few openings of the last published editor, the editor doesn't open any further than after 1 or 2 openings. My cursor still stays in the 'loading' icon state, and 3 processes are still open under task manager, and force closing them from there has no effect. But this is after the first opening.

EDIT: The above persists indefinitely or until logging off a user, not just restarting the computer.
« Last Edit: March 15, 2016, 07:30:34 pm by Sting_Chameleon »
What would you rather have? A party cannon, or a cannon party? ...... I may not know your answer, but lets just agree that I would pick the same thing.

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #150 on: March 16, 2016, 09:14:42 am »
The code uses the level number as an offset into 86:D362 to load another byte sized offset into 86:D3D5 to figure out which bits to set in 7E:1F99 which stores the upgrades X has.  Chill Penguin is level 8 which reads 86:D362+8 and gets the value 3.  Then it reads 86:D3D5+3 and gets the value 8.  8 is then set in 7E:1F99 to give X dash.

Sounds like there is some uninitialized variable problem with the settings it is trying to load when it opens.  If I have some time this weekend I'll look at it.

March 20, 2016, 12:54:06 am - (Auto Merged - Double Posts are not allowed before 7 days.)
https://drive.google.com/file/d/0Bx9gzQZCkH8qb3lnUk1VS1BoSjQ/view?usp=sharing

I changed the settings over to use the registry.  The load last rom at startup value wasn't initialized and hopefully was the cause of the loading problems.  I didn't setup an emulator to use, yet.

I hacked around on the sprite code and got most (~80%) of the enemy sprites to show up correctly.  A lot of objects have custom memory locations, hard coded LDA constants to get the graphics pointer for decompression or sprite assembly, and custom palette locations.  I didn't spend much time on those.  The sprites work in X1-X3.
- You can hit 'T' now to toggle on all enemy sprite display in the level.
- Going through the event editor will show sprites, if possible, on enemy types.
- If you go to a 2,15,x which is a sprite load (or 2,18,x) event it also displays all enemies in the level, draws a green box around ones whose graphics load in the forward direction of the event, a blue box on the reverse direction, and red box for ones that aren't loaded.
- Also on the 2,15,x there's a graphics loading dialog where you can scroll through the sprites that get loaded and modify them.  This allows you to remove or change the sprites that get loaded by these events to add enemy graphics that didn't exist before.  There's a window that attempts to display a sprite of what is loaded by one of the indices in the event.  If you change the sprite tiles that are loaded the palette won't refresh until add an enemy of that type in the level and you save/reload the level.  This code is a mess right now so I didn't spend a lot of time making it work right.

I was able to add an enemy from a different level in by adding the enemy event after a 2,15,x event and then editing the 2,15,x event to swap in the correct graphics and palette.  Make sure you use an unused palette slot if you play with this.  I think the VRAM Offset is also really a slot in VRAM to load the graphics and not the actual address, but I haven't looked at it close enough to be sure.

This all very experimental (and messy code) so don't count on it staying in this format or working properly.
« Last Edit: March 23, 2016, 11:11:29 pm by RedGuy »

Jigglysaint

  • Sr. Member
  • ****
  • Posts: 317
  • Corruptomancer
    • View Profile
    • Stuff Jigglysaint has done(like discover the Crocomire in MZM)
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #151 on: March 22, 2016, 12:00:30 pm »
This is a speculation on my part, but is the Dr. White capsule types hardcoded to the stage value, or is it hardcoded to asm? I know the check for MMX's equipment starts before the level loads to figure out if he has the upgrade or not, and a second time when MMX gets close to the capsule itself before it loads. I've done numerous tests and I'm not sure what the upgrade capsules look at when giving MMX the proper upgrade.

Also I did revert back to the previous editor. As a bug update, after the first few openings of the last published editor, the editor doesn't open any further than after 1 or 2 openings. My cursor still stays in the 'loading' icon state, and 3 processes are still open under task manager, and force closing them from there has no effect. But this is after the first opening.

EDIT: The above persists indefinitely or until logging off a user, not just restarting the computer.

From what I've seen with Mega man X3, and I assume the other two, is that the in level sprite is more of an initializing sprite.  The capsule location and the camera fix are both located elsewhere.  I have the data for X3, but it's been a long time since I've played with the data so I will have to re-learn it's format.

Edit:  I have rom locations, all are for an unheadered rom, and all for Megaman X3.

0x34CC2:  Capsule location inside level.  It requires the Capsule initialization event to be activated.  4 bytes each.  First 2 are on screen x co-ordinate followed by level position's x.  Next 2 are for the Y co-ordinate.

0x34CFA:  Capsule contents.  Values from 00 to 08 are valid.  00 to 03 are for the X armor, and 04-07 is for the chip enhancements.  08 is for the gold armor.

0x34D9F:  Capsule camera data.  Same as the capsule location except it only uses the level position bytes.  This triggers when you walk up to the capsule.  Without this value, the capsule cannot be moved or else mega man will scroll through walls and die.

0x9C5C6:  Capsule script pointers.  This is also important to moving the capsules, as it controls what Mega Man does after you obtain the upgrade.  Some are easy, such as armor, but others such as the air dashing need enough space to run the script or the game will soft lock.

That is all I've got on that.  I am assuming that X1 and X2 are similar.
« Last Edit: March 22, 2016, 05:23:38 pm by Jigglysaint »

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #152 on: March 24, 2016, 12:10:50 am »
I'm having a hard time getting all of the X3 boss sprites assembled correctly.  Namely Buffalo, Catfish, Tiger, Seahorse, and CrawFish.  I spent some time looking at Buffalo and I can see the pointer to ROM with assembly information being copied to the Cx4 chip.  It's the same address I use to get the assembly information.  Decompressing the graphics definitely shows Buffalo tiles with the right palette.  I tried inserting Buffalo at the beginning of the first stage (along with loading his graphics and palette) and it displayed properly in game so I know I have the right index to get the compressed tiles.  I also looked through the s9x source code to see what the Cx4 chip does with the data in ROM when it's copied to the OAM and I don't see anything missing in my code.  The $2101 is set to 8x8 (S) and 16x16 (L) so that's not the problem.

It's hard to tell from the pic what the problem might be.  Buffalo is a pretty large sprite, but then so are other sprites that seem to work fine.  All the right tiles (both 8x8 and 16x16) look like they are there, but they don't have the right position.  X1 bosses, X2 bosses and most enemies in all three games are fine.

My current guesses are:
- Something about the size of Buffalo is making me not calculate x and y position of tiles correctly.
- My index into the tiles is off - maybe by some constant?
- I'm missing some Cx4 transformation.

Any ideas what it might be?

Here's a picture of what I mean:



Here are the X2 bosses.  They all look fine.   Only Moth seems to be missing.  I haven't looked at that, yet.

« Last Edit: March 24, 2016, 12:17:34 am by RedGuy »

justin3009

  • Hero Member
  • *****
  • Posts: 1658
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #153 on: March 24, 2016, 04:50:24 am »
That's..really weird. It honestly looks like the Sprite Assembly is very wrong since the graphics are not setting up properly one bit. If they were, the graphics wouldn't be a mess like that which is usual a sure fire sign that the Sprite Assembly is wrong.

As far as I've seen, the cx4 does nothing with the sprites to effect them. X3 rarely ever used it for any enemy.

I didn't check much on sizes besides the usual 8x8, 16x16 tiles. It shouldn't effect him that much regardless since there's a hell of a lot of OAM free for his sprite setup.
'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 #154 on: March 24, 2016, 11:43:08 am »
I'm ignoring the 9th bit for the tile number that gets written to the OAM.  I didn't think it would matter in this case since there are less than 255 8x8 tiles in the decompressed graphics for Buffalo, but it's possible that more than one region of compressed graphics are getting decompressed for him and the sprite assembly (9b tile number) accounts for it.  Maybe something like the health bar gets loaded first from a separate compressed region and that is considered as part of the enemy.

justin3009

  • Hero Member
  • *****
  • Posts: 1658
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #155 on: March 24, 2016, 04:00:32 pm »
The healthbars are slapped into VRAM right away at the beginning of the game and when you leave the menu, most notably in X3, so that's not it.

It's very possible he has more than one decompression location.  I never actually thought of that and it wouldn't surprise me.
'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.'

Jigglysaint

  • Sr. Member
  • ****
  • Posts: 317
  • Corruptomancer
    • View Profile
    • Stuff Jigglysaint has done(like discover the Crocomire in MZM)
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #156 on: March 24, 2016, 10:45:28 pm »
I'm ignoring the 9th bit for the tile number that gets written to the OAM.  I didn't think it would matter in this case since there are less than 255 8x8 tiles in the decompressed graphics for Buffalo, but it's possible that more than one region of compressed graphics are getting decompressed for him and the sprite assembly (9b tile number) accounts for it.  Maybe something like the health bar gets loaded first from a separate compressed region and that is considered as part of the enemy.

I think the health bar is the same a X's health bar in that it should always be loaded.  In fact the boss health bar, if you were to activate it against a sub boss, will actually function against that enemy.  The only thing I can think of is that those bosses have different pieces to them that are all assembled separately.

RedGuy

  • Jr. Member
  • **
  • Posts: 89
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #157 on: March 25, 2016, 12:35:16 am »
If I subtract $20 from all the tile numbers in the sprite assembly it draws correctly except for the few tile numbers that go below 0.  I tried wrapping them back around, but that didn't fix those few.  Two of the bosses are $20 off.  The other three bosses I looked at are $40 off.  I haven't been able to figure out what's causing this or where those tiles that go out of bounds are at.  There's no obvious decompression or DMA to VRAM before that which writes $20 tiles worth of bytes.  Dumping VRAM before that shows unrelated tiles.

March 25, 2016, 12:25:55 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
For now I decided to cheat and have special cases for those sprites.  Add that to the growing list of things that need to be fixed eventually.  I'm going to take a break from the sprite displaying code and work on something else.

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

« Last Edit: March 25, 2016, 04:07:38 pm by RedGuy »

Jigglysaint

  • Sr. Member
  • ****
  • Posts: 317
  • Corruptomancer
    • View Profile
    • Stuff Jigglysaint has done(like discover the Crocomire in MZM)
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #158 on: March 25, 2016, 03:18:05 pm »
I forgot to mention that for some levels in X3, it actually uses a level copy for the changes, such as the boxes in Gravity Beetle's stage.  I think this is also used for Blizzard Buffalo and the second Doppler stage(the one with the water).  I imagine that with some hacking it could be possible to expand the shadow stages to add one for each level, then set a condition(I have located the routine for that) to make each level change.  Of course the only problem is the limited scenes, and stage order data, which I think is only one per level, though I bet even that could be changed too.

Edit:  Forgot to mention that it looks like the robot ride platforms seem to work just like Light Capsules in that the value in the level is an initialization event and the location is stored elsewhere.

slidelljohn

  • Sr. Member
  • ****
  • Posts: 343
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #159 on: March 25, 2016, 06:54:18 pm »
Not sure if you have all of mmx1 sprites loading
correctly yet but x3 looks like they are loaded the
same way. There are values stored between
7f:8000-7f:83ff that the the sprite asm algorithm
uses. The data stored there comes from the 6 bytes
that are the sprite, vram location, and palette...
I'm not 100% sure but I think the sprite data is
loaded that way to prevent people from easily adding
new enemies to the rom. They did a couple things
in mmx1 that I know of to prevent easily expanding it.