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

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 - tomaitheous

Pages: 1 2 3 [4] 5 6 7 8 9
Ahh, ok. Shouldn't be too hard to add, but the devil's in the details  :laugh:

Did you ever get the slide mechanics working on MM1? I was going to try this out, if no one had accomplished it.

ROM Hacking Discussion / Re: Mega Man: Upgrade Patch RELEASED
« on: January 08, 2014, 10:29:43 pm »
It would be awesome if someone could take a part of the extra space to make something like this:

Not sure if possible, though.
Where did that screen shot come from? I can use it in my tg16 version of MM1, if the author doesn't mind.

Wow. I see. Yeah, quite the dilemma. Thanks for answering my questions. :)

dont worry guys, nevermind. I aint going to dare even think about touching the level format. I knew it would entirly break all megaman/sprites because gravity/wall/hit detection/ground all read the level data. it's way to complex to screw around with anyway.

it's one of the few things i've never touched in all the years i've spent with megaman 3.
And lenophis and others were correct about the concept making level data be 4x bigger. And i cant ever just do something insane like that.

I got other methods im able to do in order to use more than 256 "32x32" structure blocks. (the limit in megaman 3 - 6 was 256, not 64 like megaman 1.

just kinda suck-ish that there could be trillions of "32x32" block patterns. but the 16's table that it's built on, doesnt really have any such problem

For my own curiosity, because I haven't decided which Megaman game to do next for nes2pce (3-6), is the level (collision, sprites, objects, etc) on the upper level structute (32x32) or on the lower level (16x16) after the game engine fetches the data from the decoding table? Sounds like it's inside the 32x32 decode table itself (from the description of "hitboxes, gravity effects and a lot more").

 Just curious about "And i cant ever just do something insane like that." <- As in, you're opposed to expanding PRG space?

 Though even if you solved all these problems, what editor would you use to handle this new format? Old fashion hex editor? Or just a new one?

MM1 had something like a 64 32x32 table setup. It MM3 limited to 64 entries as well? Assuming the map data itself is byte wide entries, are all 8bits used? If not, then you could expand the table with a little bit of code (possible putting the expanded table . If so, then you could have reserve 1 entry as an 'extended' form, that looks for an alt map data corresponding to the current map location; and then access a full byte with an alt table elsewhere in rom (possible expanded rom area). I.e. You only increase the map size by two (with split locations), but you break nothing of the original game map code.

 Is the editor you're using gonna support anything other than what the game already supports? I.e. Make changes to the games format, how is the editor gonna handle that?

As you certainly will have no interrest into Megaman Odyssey as well. Anyway..
Huh? Did I say something to offend?

The map data would be 4 times as large, as you need four times the needed data two represent 32x32 area, with 16x16 tiles. You'll have to do some rom expansion and probably relocation of the new map data (won't all fit in the original area). That said, it is doable - with the right amount of time thrown at it (asm re/work).

 I was planning on doing something similar to Megaman 1 (either 16x16 or 8x8 cells for level maps). I have no interest in MM3 at the moment.

Personal Projects / Re: Megaman and other NES hacks for PCE
« on: January 05, 2014, 11:06:43 pm »
Yoshiatom: definitely. There's always work to be done ;)

 So I got Jackal up and running on the PCE. It's a chr-ram, with compressed graphics. Since I want to do some graphic upgrades, I need to remove this system. I figured, while I'm at it - I'll make a MM1 chr-rom version for NES, if anyone wants/needs it. Easier to edit that way :)

January 10, 2014, 12:11:29 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Megaman 1 with Redbook support is up on the blog. It's in cue/iso/wave format, so you can change the tracks to whatever you want (track/wave length/duration doesn't matter). I also put in an 'easy' mode hack for the game (damage is now (damage/2)+1 ), but this is mostly for people to test the game on the real hardware (that aren't... good at MM1). I'll upload a replacement ISO track with normal mode, when I get some time (or upon request). 

 So basically, all music is redbook/CDDA and all sound FX are PSG. I didn't use ADPCM for anything, yet. Should work fine in PCE/TGCD emulators.

Personal Projects / Street Figher 2 CE for PC-Engine
« on: December 29, 2013, 09:26:49 pm »
Current researching/hacking the game. I'll post info here, as I get it (making everything public).

 Also, if you're bored/curious/interested - help out. The 6280 is pretty much 65x code, so if you've done 6502 or 65816 stuffs before, then this should be second nature. Mednafen is the debugger of choice - currently. Post any info here. I'll do the same. :)

 Some info to start:

 Backgrounds are compressed. It's a simple mask+constant compression, for 8 byte chunks. Sprites are uncompressed. Palettes are bitpacked compressed;first two bytes contain the upper bit (Green) for the 9bit entry - for a block of 16 values. 16 bytes follow.

 As I get further along, I'll start putting info from here into docs and submit them to RHDN docs section.


ROM Hacking Discussion / Re: YouTube/Google Video thread
« on: December 29, 2013, 09:20:38 pm »
For now, it's just the tilemap,tile,palette data that I can hack. But I plan to do a lot more with it.

What game are you trying to work on?

 Here's the rundown:
- Most main dialogue and stuff that uses 12x12 or 16x16 font, is almost always SJIS. The reason for this, is the huge majority of the system card bios (rom) is actually just a sjis table of 12x12 and 16x16 characters. The bios has a get char function that takes a sjis value and size, as the argument.
 - most CD 2.0 games use no compression. You can see the sjis plain as day in the data tracks (usually only 1 data track is the script and code, the last being a redundant data track, and any in between are either adpcm tracks or graphics for cinemas. The reason they break them up and interleave them, is to cut down on track seeking for segmented cinema loads).
 - most CD 3.0 games and later gen games DO employ compression. All of the compression schemes that I've seen, are LZSS based. Usually nothing fancy. But you can't see a lot of the sjis text because of this compression.
 - sjis is a two byte encoding. Very few games have single byte ascii support, at least for main text routines. Japanese sjis two byte still takes up less than English 1byte encoding. So assuming the game only supports 2byte encoding, and you don't know how to do ASM hacking (which for CD games is a pain in the ass, unless you find a way to get more ram - like upgrading the 'CD' to a higher level card), you won't be able to fit the english translation back in without cutting it down dramatically. The font spacing will also look like the infamous 't e r r a  a n i g m a' translation.
 - ASM hacking for CD games (especially 3.0 games) is pretty advanced. It's not uncommon for CD games to treat different parts/load of the game as completely different game engines. I.e You have to make multiple asm hacks. And it's possible free resources that you exploited to put in the hooks and new asm code, are in different areas and/or different in size for different areas of the game (Ys IV translation had this problem. So does Spriggan Mark 2).
- There isn't always room for a replacement font, let alone for new code (we ran out of space for the Super Raiden hack and that didn't even have replacement font routines).

 What would be nice, is if there was a new system card with a few more ram space (even just 8k of ram) - for making translations. You could cheat and use the SuperGrafx for extra ram (24k extra ram), but how many people have SGX let alone SGX+CD. Myself and a handful of other people in the world.

 Not sure what you goal is, but CD hacking on the PCE is not a beginners task. There are exceptions, but you'll have to look for those exceptions.

Personal Projects / Re: Megaman and other NES hacks for PCE
« on: December 27, 2013, 12:49:46 am »
How is the color palette handled since I know the NES handles color palettes a lot differently than the PCE. The NES has no standard color palette and relies on the TV itself, whereas the PCE has a much more standard setup.

 For the color/palette upgrades? That's handled via an extension that passes the palette data directly to the PCE hardware, instead of the NES video emulation. And that format is 9bit RGB (3bit Red, 3bits Green, 3bits Blue).

 Megaman2 is about 95% complete, public,  and beatable. Again, there's no patch file - so all links are in my blog site.

ROM Hacking Discussion / Re: Necromancer text compression scheme
« on: September 06, 2013, 08:47:50 pm »
If I understand it correctly, it sounds like a table-based Huffman tree.  The ones I've seen before were hard coded, so it's hard to tell.  :-\

 There appears to be a 4 byte header that sets all of this up, but the intro to the game puts hard/immediate values into place of reading from a header table. But in game, appears to be all called from a header table. Hopefully not too many areas/events are hardcoded.

 Edit: Ok, what was throwing me for a loop, was the offsets inside the huffman tree. I figured only variable/values would be there. But that's not the case. Weird. Guess I've never seen it implemented like this (or rather, I never wrote a huffman tree like this). If bit is 1, add the value from the tree to the pointer. If clear, skip two bytes in the table. Actual 'character' is encoded in 3 bytes in the table (pointer accumulators are 2 bytes) and this 'character' also preceded by #$01 - so that the pointer is incremented to align with the char (and not a terminator value of #$ff).

 They kind of missed an optimization. They could have added 'words' to the table entries as well, but appears only single characters are in the entry (once a valid character is read, the position into the tree is reset). Maybe 2 and 3 char groups don't lend well to Japanese/hiragana?

ROM Hacking Discussion / Necromancer text compression scheme
« on: September 05, 2013, 09:59:00 pm »
I've done quite a bit of work with compression schemes in the past, but this one is pretty unfamiliar to me. It appears to be some sort of binary tree compression scheme.

 There's two varaibles; a down counter (always re/load with a value of $07, check looks for $ff value) and an byte bit mask.

 There's also a table/block. Each entry is either 2 or 3 bytes long (though there might be an entry that is 4 bytes long, IIRC). The ending byte is always $FF. So something like $97,$ff,$07,$ff,$85,$ff. #$ff is the terminator of each entry (which means skip to the next). The mask corresponding bit determines whether to skip 1 byte or two bytes. If two bytes, then the value from the 'block' or tree is added to the tree/block pointer, helping incrementing it. When a non termination value is read, it's passed to the string build routine, and then the tree pointer is reset back to the beginning of the block.

 There's also another block and pointer. When the down counter expires, this pointer is incremented and the mask is reloaded. Neither the base nor the index of the tree access system is reset at this point.

 There's another layer of mechanism in place as well. At the very start of the call, there's a variable that stops the string routine from accumulating. When this variable expires (decremented; 00 = expired), then it will copy valid string data to the string build routine. Else, it just accumulates the second pointer position.

 Soo... does this description sound familiar? Sound like a binary tree compression scheme? I'm on the verge of figuring it out; just need to trace back to the top layer function calls and hopefully begin test (and text) extract trials. Any advice or comments?


Script Help and Language Discussion / Re: [PCE] Nazo no Masquerade
« on: September 01, 2013, 08:41:33 pm »
Hey MooZ! Nice work ;)

Personal Projects / Re: Mega Man 9 NES
« on: September 01, 2013, 08:38:03 pm »
If this gets completed, I'd definitely do a nes2pce conversion :)

Nice work :D Do you have the actual music format figured out as well?

ROM Hacking Discussion / Re: Rondo of Blood Audio tracks editing
« on: May 07, 2013, 01:50:31 pm »
Yeah, some PCECD games LBA for audio tracks and some use track #'s (the bios call excepts both arguments).

Personal Projects / Re: Megaman 1 and 2 for PC-Engine upgrade/hack
« on: October 25, 2012, 01:48:35 pm »
That is amazing, Mega Man 2 is by far the greatest entry in the series, can't wait to eventually play it on my Duo. Wily Wars was so shit with that delay between control input and action. Also excited about the PCE version of the soundtrack, I love the PCE's sound chip and can't wait to hear Wily's Theme pumped out through it!

 You mean remade PCMPSG tracks using the PCE upgrades? I'd have to find someone willing (and capable) of remaking the tracks for PCE's PCMPSG, but CDDA/redbook hack would be cake to do. Otherwise, it sounds the same (for the most part; I still need to complete the audio emulation):

Pages: 1 2 3 [4] 5 6 7 8 9