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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - pianohombre

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 ... 14
it seems you're missing some run-time libraries. Please make sure you're running the latest version of Visual Studio. If you're trying to compile it yourself, it seems to work in v2015. I'm not sure why Avast is giving you that error. I virus-scanned it myself with my anti-virus and it's fine. If you're worried about malware the open-source is available on github. You can always download and compile it yourself. Maybe just copying and pasting the executable from the debug directory is the wrong thing to do? You may need to install .NET. When I downloaded the version from Redguyyyy I just needed that retro.dll and it worked fine.

thanks to everyone who is supporting this site with donations.

News Submissions / Re: ROM Hacks: Chrono Trigger 1.01
« on: August 30, 2017, 09:52:03 pm »
Any chance this will be ported over to the PS Vita?

Gaming Discussion / Zelda Maker
« on: August 30, 2017, 08:14:14 pm »

For anyone that doesn't know there's a project in the works, that is basically a GoFundMe/Kickstarter/Patreon to get classic 8-16 bit Zelda worlds made, submitted online, like the popular mascots for Nintendo, Sega, Sony, and Capcom have been doing lately.

The only difference is that Nintendo Japan has taken legal action against the lead programmer for this project, and the programmer has had to change the graphics from typical enemies and characters to clones to avoid copyright infringement and intellectual property lawsuits. It looks like it's near to be released soon. Probably within the next 3-6 months there will be a demo available for supporters.

Gaming Discussion / Re: Kaze's Super Mario 64 Online Multiplayer
« on: August 24, 2017, 09:01:49 am »
Unofficial Mario Party 64? They need a rom hack to compensate for multi-player mode. All 120 stars have been designed with only 1 player in mind.

I read that Ninja Gaiden for Genesis was leaked, but there was no official release. The leak itself is pretty buggy. If someone would fix those bugs that would be awesome. There's also some unused graphics like a buff red demon, that could potentially be used for a boss fight.

I think you understand the graphics for the most part, except you wouldn't want to change anything at line 268 (that's palettes/color junk). If anything there should be another shift or offset to load the second set of graphics for the subtank (probably needs to be loaded separately, not sure if it's possible to load them both at the same time). Maybe there's a way to add the second set of graphics before tile4bpp2raw is executed.

here's the definition of gfxrle:
Code: [Select]
int GFXRLE(BYTE* rom, BYTE *dest, int pointer, int size, int type, bool obj)
so if gfxrle is ran twice with rom + 0x400, tram + size of first set of graphics, new size, etc. as parameters maybe it will load into "tram" the entire graphic so that tile4bpp2raw is able to pick up those last 2 tiles. Or maybe adding an offset to the pointer variable will get to the location for the second set of graphics.

However, if you scroll down the program, for example, many shifts and offsets are done after tile4bb2raw and mapAddr is initialized.

Code: [Select]
if (nmmx.type == 2) {
                // temporary fix for the boss sprites that have assembly information that is off by 0x20 or 0x40.
                tile -= (assemblyNum == 0x61 || assemblyNum == 0x92) ? 0x20 :
                    (assemblyNum == 0x68 || assemblyNum == 0x79 || assemblyNum == 0xae) ? 0x40 :
                tile &= 0xFF;

This may not work for work for the subtank though, since "tile" is an unsigned variable and the tiles range from 0-6.

As you can see with the photo, even the Maverick Hunter Bit/Byte in the sub-boss room below doesn't load 100% correctly. Probably about 80-95% of the sprites load correctly in the editor. Mainly sub-bosses and bosses have trouble loading correctly. I've been meaning to make a list of all the broken sprites. It's not a huge bug though, as long as people understand just because the sprite isn't assembled in the editor correctly, doesn't mean it won't run fine in an emulator/flash cart.


Scroll down to where it says //subtank @line 147. That inserts the values 0x96, later used as an address offset to load the graphic in RenderObject.
@line 206, it loads the correct palette, and other stuff that I've commented out to manually load the tiles.
There's more stuff below a giant nested for loop, where it's loaded onto the screen. That's also commented out. If you have any questions let me know.

I'll try and post a photo of the armor module graphic later.

Gaming Discussion / Re: Mega Maker (Mega Man Maker) released!
« on: August 21, 2017, 07:44:44 pm »
It looks like there is a way to browse by rating, or by most played. Just click the title bar while browsing and you can select different options.

I'm not sure if it has always been included or they added after version 1.0. Cool feature. I downloaded a few top rated, most played levels, and tried the worst rated stage also.

I just released a new stage called "Move It". You can also search by my username on the site: Divinecomics. If you check it out let me know what you think. Thanks.

@protorock, are you the main hacker for protoman 21xx? I saw a demo looks pretty cool. They actually changed the stages also, not just the palettes and sprites.

Can I ask what happens when you change the bosses around? I've only swapped around a few enemies, and I had to change the VRAM to do it. I think you would have to hack the assembly also, because each boss has a weapon weakness, and gives you a weapon after defeated. Not sure if that's copied when you change bosses. Plus, for Vile in Sigma stage there's a giant event revolving around that fight, that influences a small cutscene with Zero and enables large blocks of text.

Hey that's great! By changing it to 0xE0 it looks exactly how it does in the editor. That's a good clue as to how to fix it. Only problem is I see it's directly copied from the rom in bank 86, and 0x60 is hard-coded there, so it should recognize to fully load the entire graphic.

Also, were these instructions directly before the subtank is loaded in the ram @ 7E152E? I need to find the something similar for the ride armor module graphics, that are having a similar problem loading.

Thanks for the help!

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.

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.

If someone redesigned part of the map of Super Metroid, or Megaman to resemble LOZ:LttP I'd check that out.

Programming / Self-deprecating binary joke
« on: August 17, 2017, 05:40:38 am »
Me: Please rate my looks on a scale of 1-10
Her: You're a 1
Me: ha ha. I get you recognized I'm a computer programmer and are probably suggesting that we should use a scale of 0-1, like binary!
Her: No
Me: So technically I'm a 1/1 or the same value as 10/10. You could also have said 1010, which would have been like saying I'm two 10's!!
Her: That's not what I meant

Here's a link to some stuff with the subtank:

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.

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?

Thanks justin3009, this looks like it will be helpful. Two lines of significance:
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)?

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.

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:

Programming / Re: Changing a password system into a save system
« on: August 12, 2017, 04:16:20 pm »
Someone should just extract the images from Megaman X collection and use those for an SRAM save. Good luck spending the next month hacking in ASM hahahaahaha you will understand insanity. I've been playing MMX3 a lot over the last week trying to get 100% of the items in the game including gold armor and Z-saber. I think it's funny they screwed up the translation when loading the save file it says-
Do you load?
(it should say "Load file?" or something along those lines. above sentence is grammatically incorrect, since the game was a near 100% port of the playstation version they probably just had a Japanese programmer translate the 1 or 2 extra sentences they added, instead of having to pay someone else...........hahaahah)

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.

Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 ... 14