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 10
They might be tile based systems, but you can setup the tiles in such an arrangement - that you make a pseudo bitmap. Depending on how many unique tiles/cells the systems can show, is how large your bitmap/pixelmap can be.

 The usual method (because most older systems don't have full access to vram during active display), is have a buffer of the bitmap in local ram. Once you draw what you need to that buffer, you then upload it to vram. If the bitmap size/window is large, it might need to be updated across a few frames. If this is the case, then you usually want to have two spots in vram to 'double buffer' the image. I.e. So you don't get tearing or partial screen update artifacts.

 That aside, you still need to deal with the logic of the bitmap itself. Most older systems are planar format (with the exception of the Genesis, which are linear pixels), which can make it a pain to do certain things (types of drawing/plotting/compositing). The 16bit era systems have 4bit pixel graphics, so the tendency is to leave the whole bitmap in 4bit pixel format (else you get attribute clashing). SNES has two 8bit pixel modes available, but really limits the size of the bitmap window due to using double the vram space (and the option to do double buffering). Then there's the issue of bitmap in local ram has to be in 'tile' format. That slows things down. Some Genesis games optimize the bitmap in local ram as 'columns' of 8 pixels wide. That works well rendering stuff on a vertical level (like a raycaster engine).

 That's the basic idea of it.

I can use the 'megaman' part. That works out:

 I managed to find a clean source of what I was working with, so I'll just go with that:

 So I'm good. Now to work on the animated intro...

ROM Hacking Discussion / Need a menu and title/boot screen for Megaman
« on: January 14, 2014, 04:30:31 pm »
For this:

 I need to make a menu for when the game first boots. It allows setting the channel's (for PSG sound FX) stereo separation and as well as global PSG volume level. And difficulty mode setting.

 Anyone interested? The title/boot screen is shown before the game begins and doesn't replace the original title screen.

 I can put something generic there, but I figured why not add something custom/nice for a change. Looking to do this fairly soon.

 I'll give a few details: Title/boot screen image is 256x224. Tiles are 8x8. Each tile is 15 colors.  The color format is RGB, 9bit. To do it in something like Photoshop, use RGB steps of 36 (0,36,72,etc). For example R of RGB has 8 steps: 0, 36,72,108, 144, 180, 216, 252. Same for G and B. There are 16 subpalettes. Each subpalette holds 15 colors. A tile can be assigned to any of those 16 subpalettes; but only 1 subpalette per tile (doesn't matter where that tile is, in the pic). For photoshop, I usually just have a transparent overlay that's in a 8x8 grid - so that I can keep track of which tile uses which subpalette. Sound complicated? It's not. I can give a PSD example file of how it works.

 So, that's that. If you're interested, post some mock-ups here.

Edit: I was actually gonna use this:

But the I need a 'megaman' title, not a rockman one. And I need that 'megaman' title bar on a separate layer, so I can scroll it in. And since there's no detail underneath it, I can't (I'm not a good enough pixel artist to replace the BG detail).

ROM Hacking Discussion / Re: PC Engine/Turbo Grafx assistance needed
« on: January 14, 2014, 03:56:35 pm »
There's a document I made, a number of years back, here:

 Describes the tile compression and tilemap format. But yeah, get familiar with mednafen's debugger. Bizhawk also has a trace logger.

 The compression is pretty simple. What are you trying to do with the game?

 Tilemolester will view pce tiles and sprites. But for sprites, you need to set TM to 2D mode and the width to 16 pixels - since PCE sprite cells are 16x16. PCE sprites and tile cells are also in two different planar format. It's a pain. I just use TMOD2, with the PCE decode pack, and run it in DOSBOX emulator. It's fast/simple and has a few nice features. The only downside to tmod2, is that the PCE pack doesn't support 2bpp and 3bpp sprite viewing for PCE. Not too big of a deal, though. One of these days, I'll need to write a new tmod2 clone app for windows. And add a few missing features.

 If there was enough demand for it, I could give Bonk the 'nes mapper' treatment. I.e. Decompress the graphics and expand the rom, so hacking/editing would be easier.

 Edit: Also, the PCE 'tile' format is the same as the SNES. It's composite of 2bpp tiles.  It's the sprite format that's different/unique.

ROM Hacking Discussion / Re: Mega Man: Upgrade Patch RELEASED
« on: January 12, 2014, 10:06:29 am »
Well, if I have some support for the above stuff I will bust my ass to get it made because it's one of my dream projects.
If you want I'll pm you about what I want to do, tomaitheous.

 Definitely :)

ROM Hacking Discussion / Re: Mega Man: Upgrade Patch RELEASED
« on: January 11, 2014, 07:38:10 pm »
I may need help from a more experienced ASM programmer for the more complicated stuff and I'll definitely need help from someone proficient with the MM1 sound code for changes and additions to the music.

That said I also can't wait to see what others can do with this.

 I can probably help out with the music engine. I've done my share of taking them apart, putting them in other projects, etc. And having worked on NES APU emulation, I understand the hardware side pretty decently.

 If you do a MM1 hack of powered down (with this mmc3 upgrade), I'd love to do a nes2pce conversion of that hack.

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.

General Discussion / Re: So are you guys conservatives or liberals?
« on: December 29, 2013, 02:36:03 am »
I'm none of those. I'm not even 'other'. 

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.

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