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

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

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #260 on: August 09, 2017, 05:48:05 pm »
Update:
I've been working on some changes for the last version I released. I'll call this new version v1.3.

v1.3 changes:
-When pressing arrow keys in dialog boxes it now changes value accordingly. (before it did the inverse, if you pressed up the value would go down and pressing down vice versa)
-Editor and Emulator Menu Items are no longer grayed out after opening a file
-mmx3 item graphics are now showing up in the editor. (heart tank, weapon tank, extra life, etc.)
-mmx3 ride armor module graphics show up correctly. also, the subtank for every game shows up properly. (before it was missing the bottom portion, re-arranged the tiles manually)
-the captions now change when you click on an object using your mouse with the event editor window open (previously they would only change via the prev event and next event buttons)

Dropbox binary/executable:
https://www.dropbox.com/s/rd06kokb7r0kyzr/megaedxv1.3.zip?dl=0
Github has been updated also

Comments:
I did look into making the undo function, and unexpectedly noticed it does save previous changes, in the bottom right box (but you have to manually re-click that and paste over your mistake). basically, the undo function would do that for you and save more than one command you could undo. Unfortunately, testing was difficult because dialog boxes are a pain to work with. I wanted to just press a key to test the undo function then change it to Ctrl-Z later, but key presses are disabled by default in dialog boxes. There's some horrible work-arounds that are ugly and I couldn't get any to work right. On a positive note, I did get the Undo() function to actually work otherwise. I just basically had it on a timer, so it would make all the changes then go back to the original after 3 seconds or so. So an Undo() function is definitely possible, it will just take some creative programming to get it to work how I want. Don't worry I also tested the game it uses the original graphics for the items, so just previewing them like this is not going to screw them up in the actual game during save. (I was worried about this for weapon tank and energy tank since it displays large versions during event editor window whether the item is actually large or small. although the caption will tell you if it's large or small).

If anyone is curious how I got the tiles to load for the graphics properly I basically just got an assemblyNum that displayed all the graphics, then arranged the tiles using xpos,x,ypos,y,and info manually. The problem was for subtanks and the ride armor module the letter was supposed to go on top of the bottom portion so   there was some initial problems because in order it would load-> top part of graphic, letter, bottom part of graphic, so the bottom portion was always on top of the letter. My work around was just load the graphic backwards. Unfortunately since it was in a for loop it went from 0 to #oftiles. Like an idiot I wrote a struct to change the for loop around so it resemebled this mess:

Code: [Select]
for (int i = start; loop.comparison(); loop.modify())
Then I wrote the struct functions to check a boolean value to see if the values should be reversed or not. I knew there was an easier way, but just couldn't think of it off the top of my head. Programmer's greatest weakness is being too impatient to brainstorm, and just immediately jumping in to code, rather than thinking things through. Later, I went back and deleted the struct and ugly for loop definition. All I needed was a separate counter variable.

Original:
Code: [Select]
auto map = baseMap + (tileCnt - i - 1) * 4;Edited:
Code: [Select]
map = baseMap + (tileCnt - counter - 1) * 4; //counter = tileCnt -1

Another bug I noticed, after spending maybe an hour or so searching for it was I accidentally had an if statement that was changing values instead of comparing them! Stupid compiler didn't even notice this error when compiling. Who uses an if statement to declare variables, DURING the conditional statement?
Code: [Select]
if (setvalue = wrongway)
if (compare2vars == correctway)
« Last Edit: August 09, 2017, 07:28:58 pm by pianohombre »
One small step for man,
one giant leap for mankind. -Neil Armstrong

justin3009

  • RHDN Patreon Supporter!
  • Hero Member
  • *****
  • Posts: 1510
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #261 on: August 09, 2017, 06:18:58 pm »
Quote
load-> top part of graphic, letter, bottom part of graphic,

This is extremely unusual. The Ride Armor Chips are a 16x16 sprite (Or Tile depending on where it's loaded.) Sprite wise though, the whole icon loads all at once then the letter gets placed. For tiles though, it's actually all pre-set as tiles WITH the letters inside them. It almost sounds like the editor doesn't take into account about a sprite possibly being just one 16x16 sprite. (Though, Ride Chips have sprite assembly like every other sprite/object in game so that may be why it's not detecting things properly).
'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.'

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #262 on: August 09, 2017, 07:26:44 pm »
Even when the graphics are decompressed they are not displayed how they are in-game, they are split up into maybe 10 or so tiles, with E for subtank being one tile and each letter for the ride armor modules(h,k,f,r) being 1 tile. The sprites are assembled using two functions in RenderED.cpp- RenderEvent() and RenderObject(). Most of these sprites are assembled automatically through a C++ function that does pretty much what an emulator would do, using 3 values- gfxNum, palNum, and assemblyNum. All the addresses are known for these pointer tables so the program just picks them up as it goes along, except it's mainly for enemies, so far none of the items (type=0) have been able to properly load graphics based off these pointer tables, and you have to manually assign the correct values.

gfxNum and palNum are easy enough to find. assemblyNum has been a struggle to try and understand, and locate. For most of the items I've just been using trial and error. Check one value, see if it loads correctly, if not increase the value by 1 and check again. One person I talked to mentioned I should do a trace-log of the VRAM, in an emulator. Although, I eventually got the trace-log of the VRAM for a known graphic I couldn't figure out how the program got the assemblyNum, or how I'd find it for other graphics. (heart tank, gfxNum=0x36,assemblyNum=0x38). This would mean I probably wouldn't have to re-arrange the tiles manually, but after doing the trial&error method for 20-50 values I just gave up and did it manually. It all seems to work fine so I'm not to worried about it. Although, most of these instructions for tile assembly were added to a for loop it may cause some slow-down. I didn't notice any slow-down on my PC however. The mega ed x editor is pretty small and still under 1mb in total after compiling.
One small step for man,
one giant leap for mankind. -Neil Armstrong

justin3009

  • RHDN Patreon Supporter!
  • Hero Member
  • *****
  • Posts: 1510
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #263 on: August 12, 2017, 03:20:12 pm »
Most of the VRAM is generally the same when it comes to enemy storage, though I know the game does use another routine where it'll shift the storage location of some enemy graphics in VRAM and even have that shift add onto the Sprite Assembly so it still assembles them properly in-game. I don't think this should ever be a problem to an extent since that routine tends to happen when you go back and forth between screen events as far as I can remember. (More-so when you're hitting a 'respawn' point and it redraws the VRAM graphics when there's a new enemy with new graphics on screen in the latter).

The base storage of everything in VRAM would be the right way to go and finding the location of the sprite assembly and animation data. Those will never have completely separate pointers as far as I know of, though some routines will shift the data accordingly when needed.

If there's ever a sprite editor implemented for X and Zero in the future, I have all the info needed for Sprite Assembly, Animation Data and VRAM setup. Only thing I don't fully understand in the animation data is some of the ending bytes as that will either tell another routine to do something or transition into another animation, though, I think that's handled OUTSIDE of the animation data itself so it's not too big of a deal.
'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.'

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #264 on: August 12, 2017, 04:04:19 pm »
justin3009,
I know what you're talking about for the most part for the shifting. I've seen some special cases where Redguyyyy used if statements to get some bosses to load correctly. I wish I could get the item graphics to load as neatly as the enemy sprites. Here's the C++ for about 80% of the enemy sprites:
Code: [Select]
unsigned gfxNum = *(nmmx.rom + nmmx.pSpriteOffset[type] + ((id - 1) * (nmmx.type == 2 ? 5 : 2)) + 1);
unsigned assemblyNum = *(nmmx.rom + nmmx.pSpriteOffset[type] + ((id - 1) * (nmmx.type == 2 ? 5 : 2)));

As far as I can tell the address offset for the item graphics (type=0) is incorrect. pSpriteOffset[0] is set to  p_objOffset in another file. Here's how it's declared in MMXCore.cpp:
Code: [Select]
const long p_objOffset[4] = { 0x86DE9B, 0x86A34D, NULL, NULL };
Just a review of what the functions do that load the tiles in MMX:
for each tile there's 4 values- xpos, ypos, tile#, and info (whether the tile needs to be flipped or mirrored).
So basically if a graphic has 4 tiles there will be 16 values in hex at a certain offset. There's a pointer variable in the C++ that goes to the first set of hex values with these 4 variables. I guess I could just set a breakpoint jot down values for a known location, and then try searching in the VRAM trace log for these same values to try and get an idea what the algorithm is to load up the item graphics, or address offset (if it's different than objOffset). I'd definitely re-write the code if I could this way. It would be a lot cleaner, and easier to debug this way. Over the next week I'll try looking into it.
One small step for man,
one giant leap for mankind. -Neil Armstrong

justin3009

  • RHDN Patreon Supporter!
  • Hero Member
  • *****
  • Posts: 1510
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #265 on: August 12, 2017, 05:20:58 pm »
Any items that enemies drop are always in VRAM at all times when in game. IE: Health capsules, weapon health capsules, explosions, lemon shot, etc.. the basics are always there

Ride chips, sub-tanks and heart tanks all have a different location in VRAM depending on the level. I'm not sure what entirely determines this but it might be like the other routines where it gets shifted depending on where it's needed. It's looking like it's the shifted graphic routine and stuff again.


From what I'm seeing in a trace thus far with Gravity Beetle
$00/B224 BD 23 86    LDA $8623,x[$08:86D7]   A:00B4 X:00B4 Y:0000 P:envmxdIzc ;I believe this loads the base location for various objects in the map to spawn.
$00/B227 AA          TAX                     A:043B X:00B4 Y:0000 P:envmxdIzc

$00/B22A BD 23 86    LDA $8623,x[$08:8A70]   A:0174 X:044D Y:0000 P:envMxdIzc ;This loads the heart-tank value of 36
$00/B22D C9 FF       CMP #$FF                A:0136 X:044D Y:0000 P:envMxdIzc

The base heart tank value is ALWAYS 36, which makes me believe it's the item to spawn in that location.

Each object, I think, maybe just item objects like this, are 6 bytes each though I'm not sure if this is all correct or not. This is what it APPEARED to be upon testing.
08:8A70 - Object graphics to use
08:8A71 - VRAM Location (2 bytes)
08:8A73 - Palette value to use (2 bytes?)
08:8A75 - Palette location in RAM to use (Doubles value so 70 here doubles into E0 which then in turn loads 7E:04E0 for the palette in RAM)


08:8A70 will load:
06:F732 (Base ROM location for compressed graphics?)  --> 06:F840 - Pointer to graphics for Heart Tank (2 bytes)
06:F732 (Base ROM location for compressed graphics?) --> 06:F842 - Bank of graphics for Heart Tank
06:F732 (Base ROM location for compressed graphics?) --> 06:F843 - How many bytes to decompress Heart Tank (2 bytes)
5 bytes for each object

Also, bit of RAM base location though I don't know all the bytes.

7E:0D18 - Base RAM location for enemies (+40 per enemy)
7E:1518 - Base RAM location for Item Objects (+30 per object)

$7E:1518 - Object active or not
$7E:1519 - What animation object is using?
$7E:151A - What event byte of object to load
$7E:151B - What sub-event object is on

$7E:1522 - What object is spawned

$7E:152B - Animation length of current animation frame
$7E:152C - Animation data pointer (2 bytes) (Not sure what determines this. Bank is $3F always)
$7E:152E - What sprite assembly to use
$7E:152F - Current animation frame
« Last Edit: August 13, 2017, 02:47:45 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.'

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #266 on: August 14, 2017, 07:51:03 pm »
Thanks justin3009, this looks like it will be helpful. Two lines of significance:
1)
Code: [Select]
$00/B22A BD 23 86    LDA $8623,x[$08:8A70]   A:0174 X:044D Y:0000 P:envMxdIzc ;This loads the heart-tank value of 36Graphics number is well-known. You can see that in the event editor window + compression/decompression programs spit out all the addresses and sizes of each graphic in a txt file. I don't get why the accumulator value doesn't reflect that though. A:0174. Why is it not A:036, or A:054 (decimal)?

2)
Code: [Select]
$7E:152E - What sprite assembly to useThat address location in RAM is what I'm looking for. Pretty sure MegaEd X is not loading up artificial RAM, for the game, like an emulator would, so I'll have to try and find the sprite assembly in some memory bank. Unfortunately, it's hard to calculate because the program uses this 6mb rom variable that seems to change each time during run-time (maybe it is loading RAM?).

Code: [Select]
unsigned mapAddr = *LPDWORD(nmmx.rom + SNESCore::snes2pc(*LPDWORD(nmmx.rom + nmmx.pSpriteAssembly + assemblyNum * 3)) + frame);
LPBYTE baseMap = nmmx.rom + SNESCore::snes2pc(mapAddr);

Even if item graphics like the heart tank, are shifted to different locations in VRAM during gameplay you don't need to compensate for these offsets in the program. It just goes to the base location and loads up that graphic for each level where the graphic is used. It's not using VRAM to display them. I'll try and make sense of this over the next few days, along with the notes I already have.

Edit:
It looks like the game stores and updates the assembly number in that ram location ($7E:152E) during gameplay so I'm able to view it during emulation in bsnes. For the subtank (gfxnum 0x8c) I already had the correct value (assemblynum 0x96) by just guessing. When I published the first update I used that value. Nonetheless, it doesn't display the graphic correctly using that number (proof below), which is why I went to all the trouble to make it look better:


For the ride armor modules the program only displays the top part of the graphic as well. For some reason it doesn't even load the tile used for bottom part. I've tried editing the frame #, size of the graphic, tileCnt variable, nothing seems to work to get the graphic to load properly. It's extremely peculiar and I've run out of ideas (except for manually loading each tile lol). Sorry for the small graphic, I think the bulletin board compresses and shrinks it, here's the full graphic for better understanding: http://i.imgur.com/joxWgD1.jpg
« Last Edit: August 15, 2017, 07:34:18 pm by pianohombre »
One small step for man,
one giant leap for mankind. -Neil Armstrong

justin3009

  • RHDN Patreon Supporter!
  • Hero Member
  • *****
  • Posts: 1510
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #267 on: August 15, 2017, 08:03:34 pm »
Thanks justin3009, this looks like it will be helpful. Two lines of significance:
1)
Code: [Select]
$00/B22A BD 23 86    LDA $8623,x[$08:8A70]   A:0174 X:044D Y:0000 P:envMxdIzc ;This loads the heart-tank value of 36Graphics number is well-known. You can see that in the event editor window + compression/decompression programs spit out all the addresses and sizes of each graphic in a txt file. I don't get why the accumulator value doesn't reflect that though. A:0174. Why is it not A:036, or A:054 (decimal)?

For the first bit, it's actually loading the byte from there and the next command AFTER would show the byte since it's loaded then.

For the other though, that is exceptionally strange. It definitely sounds like it might be a sprite assembly issue then with how the editor is handling it. It's possible it's not layering things properly.

It looks like the basis might be correct there. The first number of the ENTIRE pointer to sprite assembly is how many chunks there are, then there's FOUR bytes to dictate each piece of sprite assembly. So essentially it goes:

Pointer to sprite assembly to use:

First byte before anything else: How many pieces of graphics to use for the sprite.

After it gets that, it starts loading 4 bytes per sprite piece.

First byte: Dictates rotation value and how big the sprite piece is. 00 is normal 20 is 16x16, 40 will flip it, etc..
Second byte: X coordinate
Third byte: Y coordinate
Fourth byte: What 8x8 or 16x16 to use in VRAM.
« Last Edit: August 15, 2017, 08:35:33 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.'

slidelljohn

  • Full Member
  • ***
  • Posts: 107
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #268 on: August 15, 2017, 10:32:24 pm »
Thanks justin3009, this looks like it will be helpful. Two lines of significance:
1)
Code: [Select]
$00/B22A BD 23 86    LDA $8623,x[$08:8A70]   A:0174 X:044D Y:0000 P:envMxdIzc ;This loads the heart-tank value of 36Graphics number is well-known. You can see that in the event editor window + compression/decompression programs spit out all the addresses and sizes of each graphic in a txt file. I don't get why the accumulator value doesn't reflect that though. A:0174. Why is it not A:036, or A:054 (decimal)?

That is because the accumulator gets updated on the next line, not the line with the LDA. Look at $00/B22D and it should have the 36 in the accumulator.


The image showing the messed up graphics for the energy tank looks like it's loading the tile data correctly. It looks like the graphics that are supposed to be in vram are messed up.
If you look at where the energy tanks graphics are stored in vram they are stored at $C800-$C8DF and at $CA00-$CA7F. The graphics that are supposed to be at $CA00 don't look like they got stored there. Maybe that part of the graphics isn't getting stored in the right location or not at all.  They might be getting stored after the 1st set of graphics at $C8E0 like how they are stored when the are decompressed which would be incorrect for loading the tiles to the screen.
« Last Edit: August 15, 2017, 10:51:03 pm by slidelljohn »

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #269 on: August 16, 2017, 12:28:38 am »
Hi,
thank you both for the responses.


If you look at where the energy tanks graphics are stored in vram they are stored at $C800-$C8DF and at $CA00-$CA7F. The graphics that are supposed to be at $CA00 don't look like they got stored there. Maybe that part of the graphics isn't getting stored in the right location or not at all.  They might be getting stored after the 1st set of graphics at $C8E0 like how they are stored when the are decompressed which would be incorrect for loading the tiles to the screen.

I think this might be the case. Running the MegaEd X program through the debugger, and setting a breakpoint for the subtank assembly(fyi it's called a sub-tank in the X-series and E-tank in the classic series) I found it's only loading  5 tiles total (instead of the 7 required for the proper assembly). I tried just forcing the tileCnt to 7 instead of the 5 I know it's picking up from the pointer. That didn't work. Thinking caps please. How to fix?

Code: [Select]
GFXRLE(nmmx.rom, tram + current, SNESCore::snes2pc(addr), size, nmmx.type); //graphics decompression
nmmx.tile4bpp2raw(tram + (i << 5), nmmx.spriteCache + (i << 6)); //tile stuff
unsigned mapAddr = *LPDWORD(nmmx.rom + SNESCore::snes2pc(*LPDWORD(nmmx.rom + nmmx.pSpriteAssembly + assemblyNum * 3)) + frame); //pointer to sprite assembly
auto map = baseMap + (tileCnt - i - 1) * 4; //deeper pointer?
One small step for man,
one giant leap for mankind. -Neil Armstrong

slidelljohn

  • Full Member
  • ***
  • Posts: 107
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #270 on: August 16, 2017, 01:30:01 am »
The sub tanks do only have 5 tiles. 2 16x16 and 3 8x8.
Do you know if it's loading the data at $86:F4CD and $86:F4CF?

$86:F4CD 0E 60  //Used to store vram to $C800-$C8DF
$86:F4CF 08 E1  //Used to store vram to $CA00-CA7F
These are all v1.1 of mmx rom.
« Last Edit: August 16, 2017, 01:51:14 am by slidelljohn »

justin3009

  • RHDN Patreon Supporter!
  • Hero Member
  • *****
  • Posts: 1510
  • Welp
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #271 on: August 16, 2017, 03:38:56 am »
That's why I think it might be an issue with how the editor handles the sprite assembly. It doesn't seem to gather that it can load 16x16 tiles with the items and who knows what else.
'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.'

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #272 on: August 16, 2017, 04:03:46 am »
What I meant was that it loads 5 tiles total.

It loads the first tile twice, (mirroring the tile when req'd)
then it loads the tile for the bottom curve twice,
and finally it loads the E.

It's missing that bottom portion that is loaded similarly to how the top of the graphic is loaded (with the blue part and the legs). I'm not sure about the VRAM thing, honestly I just learned about how to do a trace log so I wouldn't know where to check for values. I know for the first set of tiles it has x-pos and y-pos that are negative, how are those values even represented in hexadecimal? I'm assuming it would just be the two's compliment value in binary then converted to hex after.

Perhaps there's an issue in one of the functions that deals with the pointers and graphics before tiles are loaded (GFXRLE() or tile4bpp2raw()). My guess is with tile4bpp2raw. It's definitely able to detect if the tiles are 8x8 or 16x16, there's even a boolean variable that checks, based on a value in info. This info variable is an 8-bit bit flag that carries a lot of info about the tiles - whether to flip, mirror, and if it's big or small. But if for some reason that first value it picks up says to only load 5 chunks of data, rather than 7, maybe the program is going to the wrong address, based on the pointer. Or for some reason this graphic is actually 2 graphics split up and it loads up the first part, and then it's supposed to load the other part.
One small step for man,
one giant leap for mankind. -Neil Armstrong

slidelljohn

  • Full Member
  • ***
  • Posts: 107
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #273 on: August 16, 2017, 04:23:20 am »
Can you post a image of the tiles that it is using to assemble
the sub tank? If it's the same image that shows up in the event editor than that's 100% the problem. The graphics do get split up and put in 2 different locations. The last 4 8x8 tiles are supposed to be under the 1st 4 8x8 tiles. Those last 4 8x8 tiles make up the bottom of the 16x16 tiles that get loaded to the screen. If they are not placed there the bottom of the 16x16 tiles will be empty.
« Last Edit: August 16, 2017, 04:54:14 am by slidelljohn »

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #274 on: August 16, 2017, 04:48:08 am »
slidelljohn,
Here's a link to some stuff with the subtank:
http://i.imgur.com/joxWgD1.jpg
One small step for man,
one giant leap for mankind. -Neil Armstrong

slidelljohn

  • Full Member
  • ***
  • Posts: 107
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #275 on: August 16, 2017, 04:58:06 am »
That image of the tiles in the event editor is not correct.
The last 4 8x8 tiles need to be moved under the 1st 4 8x8 tiles
to complete the 16x16 tiles. Load up the mega man x rom and look at its vram for the sub tank and you will see how it is supposed to look.

I don't think the editor is loading this data:

$86:F4CD 0E 60  //Used to store vram to $C800-$C8DF
$86:F4CF 08 E1  //Used to store vram to $CA00-CA7F
These are all v1.1 of mmx rom.
« Last Edit: August 16, 2017, 02:30:58 pm by slidelljohn »

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #276 on: August 19, 2017, 05:20:17 pm »
slidelljohn,
I'd like to keep the program as close to originally possible as I can. If for some reason the graphic is loaded up in 2 separate events, one that loads up the top portion, and another event for the remainder I can catch this by setting up a breakpoint and just stepping through, in bsnes. It will show a partially loaded graphic if this is the case, then a fully-loaded one.

I'll make sure to do a trace-log of the v1.1 so I get the same addresses.
One small step for man,
one giant leap for mankind. -Neil Armstrong

slidelljohn

  • Full Member
  • ***
  • Posts: 107
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #277 on: August 19, 2017, 08:05:36 pm »
Yes I definitely agree to keep it as close to the original as possible but it still needs to work correctly.

If you want to see it just load the 1st part of the graphics in game set bit 0x80 at $86:F4CE (0x60 + 0x80 = 0xE0) and
it will only load the 1st part. That 0x80 is a bit flag to tell it to load another set of graphics or not to load another set. Look at the data below. The 0xE1 will make it not load any more into vram. After it checks the bit flag it will subtract 0x80 from it.
0xE1 - 0x80 = 0x61.

$86:F4CD 0E 60  //Used to store vram to $C800-$C8DF
$86:F4CF 08 E1  //Used to store vram to $CA00-CA7F

The 1st byte $86:F4CD 0E is how many bytes to dma into vram. The formula is 0x0E x 0x10 = 0xE0. The 0xE0 is the
amount of bytes to transfer. The 2nd byte $86:F4CE 60 is for
where in vram to store the graphics. (0x60 + 0x04) x 2 = 0xC8
Which would be vram location $C800. The 0x04 comes from the data in the event that loads the sub tank.

« Last Edit: August 19, 2017, 08:19:05 pm by slidelljohn »

pianohombre

  • Full Member
  • ***
  • Posts: 194
    • View Profile
    • My personal website of short stories and comics
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #278 on: August 20, 2017, 06:47:14 am »
Alright, I checked what you said (changing value 0x60 to 0x80 in $86:f4ce). It loaded up some blinking thing, but it wasn't really the top part of the graphics like I expected. The editor decompresses the graphics before arranging the tiles, so it should reflect how it does in-game.

The size in the editor is 352 (or 160 in hex). Not sure why that is off. Should be 0109.

I'm going to have to find where the program jumps to for the tile map address variable, like for VRAM. It's based off the rom variable used in the editor so doesn't give an exact address when debugging. I think I should study a little bit more also. I'm not exactly sure how data is loaded from the rom, to VRAM, using DMA and offsets, so reading a guide will help visualize what exactly is going in hex/assembly mode.
One small step for man,
one giant leap for mankind. -Neil Armstrong

slidelljohn

  • Full Member
  • ***
  • Posts: 107
    • View Profile
Re: MegaED X, the Megaman X hacking tool (Now with MMX2 support)
« Reply #279 on: August 20, 2017, 07:10:15 am »
Alright, I checked what you said (changing value 0x60 to 0x80 in $86:f4ce).

Should be 0xE0 not 0x80. (0x60 + 0x80 = 0xE0)

The size 0x160 seems to be right for the sub tank. The 1st
part is 0xE0 in size and the 2nd part is 0x80 in size.
« Last Edit: August 20, 2017, 07:35:53 am by slidelljohn »