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.

Topics - nesrocks

Pages: [1]
Has anyone here ever done rom hacking for the odyssey 2 system? The most popular (and only?) O2 emulator seems to change the game's speed to ultra slow if it doesn't recognize the ROM file as a known O2 game. I suspect it does this through a CRC check. I was wondering if anyone knows what's going on.

edit: it turns out the emulator o2em uses a lot of internal hacks for compatibility and it detects the ROM by a crc32 check. So my only option is make it so the rom keeps the crc32 after modification...

Personal Projects / NES Goonies II Revised Design
« on: February 03, 2019, 02:46:08 pm »
So, I've finished a Goonies II hack aimed at improving the overall experience. There are several changes:

- Text is a lot faster.
- Camera has been fixed, now more centered.
- Pressing the select button toggles between Hyper and Jump shoes if you have any of those.
- Start button goes to the map screen. Pausing has been removed.
- Better password screen with more information on controls and also way more intuitive controls (see screenshot).
- New map screen showing the location of some important items. The player is still left wondering what those are and how exactly to get there anyway, so it actually works like a loose guide. It could seem like it makes it too easy, but in the end that is definitely not the case.
- The "start/continue" screen has been redone with quick guide and plot setting.
- Cannot move the hand or the hammer when hitting in rooms. Just use the item and if there's something to appear, it will. I figured this made a better game design. Because if you don't know where to hit you'd just have to hit everywhere until you're lucky. There are no hints as to where to hit. So it was just boring. Even if you know where to hit it is just boring. I've made it quicker by doing this so the player can focus on the gameplay.
- Rearranged the health on the HUD.
- Only need to hit the lady once instead of five times.
- Better controls inside rooms. Should be a lot more natural:
 A confirms
 B cancels
 Select changes the item list
 D-pad moves the cursor as expected (all directions work)

Download Version 1.0 here

I wonder: should I change the game's text messages to actual useful clues?

Programming / Emulator for SNES hacking?
« on: December 06, 2018, 08:44:56 am »
I've tried two:
- snes9x 1.51 Geiger build: the first thing I tried to do when testing it was to use the rom hex editor. It simply closed on me.
- bsnes plus v04: it has many great features! It's an amazing emulator, but I can't see how to save the changes made to the ROM on the hex editor. This is a major pain. I ended up having to rewrite every little change that I did on an external hex editor, and that's very confusing to keep track of what was changed and what wasn't. When hacking I need to experiment a lot to reverse engineer the rom, and when it works I'd like to save the current state. I may not remember everything that I changed. I also would like to clear the activity highlighting on the hex editor, it won't clear unless I close the rom and reopen it.

How do you guys do snes hacking?

Programming / How does the rope collision work in Umihara Kawase?
« on: October 25, 2017, 11:14:43 am »
I'm looking into implementing rope physics in my game, like in the DOS game Worms, or like Umihara Kawase (SNES), sans the elasticity. So the rope is always straight, and bends around corners. But I'm baffled at how hard this is. Does anyone know how they did it in Umihara? Since my game is tile based it should be a good example. I'm not looking for a detailed technical analisys, I'm looking to know the concept behind it.

I've tried this approach that didn't work very well:
- Each frame I check several points of the rope for collision with tiles.
- Whenever a point is inside a tile I do a series of checks to find out which direction it was coming from so I can determine where to place the bend relative to the tile it is in.
- I check if the rope's pivot's X coordinate is smaller, the same or greater than the tile that had a collision. Then I check the angular velocity to see if it was clockwise or counter-clockwise, and based on that info I place the pivot on one of the four corners of the tile.
This caused several problems, first one is that sometimes it would collide with a wall of more than 1 tile and it would place the bend in the middle of the wall.
Another problem is that sometimes the angular velocity couldn't be trusted.

So, I thought of another approach:
- Check for collision on several points of the rope on every frame, but store their positions on a list. If it doesn't collide, this was the last good position for the rope.
- If the rope collides with a tile, I check the same point (based on array index) for its previous position to find out where it was coming from and expell it from the tile and create the bend on the closest tile corner to that point.

Just thinking about it this approach it seems better but it may also be problematic. Any ideas?

edit: forgot to mention, I'm making the game in game maker (full code mode). I'm not using physics. Not that it should matter, I'm just looking for how it was done in Umihara Kawase, in concept.

Personal Projects / The Real Ghostbusters Remastered (GB1, NES)
« on: June 08, 2017, 10:44:33 pm »
I should now reveal what I've been working on. It is a hack that gives a serious facial uplift to the original game. Without further ado, here are some images (nothing final):

click to enlarge (title screen credits go to Macbee)

It is mostly original graphics, but slimer and the heroes are adapted from the "new ghostbusters 2" game from HAL lab.

The title screen says "os ca├ža-fantasmas" but that will be on the brazilian portuguese version only. As with the super pitfall hack, I will release this in both US-EN and PT-BR.

As usual Macbee has been looking closely at the progress and making nice suggestions (his idea to use the new gb 2 graphics). Also, he did the graphics for the new title screen and made it pre-stretched to compensate for the nes aspect ratio on the tv (things I never even noticed, but cannot be unseen!).

I didn't pick this game because of this, but it is another badly ported/adapted david crane game.

I don't think the game design can be saved on this one, so I just want to work on graphics mostly. I was thinking a few tweeks here and there, but nothing complicated. Oh, and I've fixed the stairs controls. Now you just press LEFT or RIGHT to move LEFT or RIGHT. Like a videogame!

Also, on the boss scene I've made it so you can move freely and the screen won't switch (that was super annoying on the original game). Now you press B if you want to go to the staypuft marshmellow man screen (press B again to return). Also! I've made it so you always shoot up.

I also noticed these errors with the original game:

This one is weird, they made the graphics but inserted the wrong numbers for the sprites. Original game on the left, restored graphics on the right:

This is all I have so far. To do are the other 3 variations of the background on the ghost hunting scene, the staircase scene, the final scene (both screens), the shop and a few details, like the gas station, the GBHQ, running out of fuel, etc.

TLDR: this is a gameplay-only hack of the japanese version aimed at making the game a lot faster.

I wondered why I should like the castlevania series on the NES but never have really. I came to the conclusion it was because of the pace. The character moves slowly, his attack is slow, climbing staircases is slooooow, opening doors is like watching a metal gear solid cutscene, etc etc. So I started modifying everything that felt sluggish to me. I didn't hold back, but I did try to keep a certain balance. For example, a faster attack meant the bosses became too easy, so I modified some values so it wouldn't be so. All in all, the game can be completed much faster now, and I think it isn't TOO easy (certainly it isn't harder).

In the end, it has a lot of personal preference on it, but it is all very consistent with the "make stuff faster" setting. I think castlevania fans with an open mind will enjoy it for the new action feel, but it is mostly aimed at people who feel the game is slow the same way that I did and are missing out on this classic.

What I explicitly chose not do to:
- change the graphics.
- change the music.
- change the levels, with the exception on spots where the new jump distance made it impossible to pass, so very minor modifications were done to prevent that from happening, like adding one or two blocks to stop the player from falling on pits. This was done on 5 places total, I think.

The only thing I changed that wasn't compatible with the fast mode setting is the sfx played when counting down the timer and hearts at the end of each level. I changed to more subtle sounds.

Full list of changes:
- doubled horizontal speed for trevor, sypha and alucard. 50% more for grant
- consequently, jumps now travel more distance proportionally
- very minor level modifications to prevent the player from dying with the new jump
- grant's move speed on walls doubled
- alucard's bat form moves faster now
- double speed on staircases
- the knife and cross weapons now move faster
- way faster morphing between characters. I kept the same sound, and you can really tell how much time is wasted because you've morphed fast and the sound is still playing for a long time.
- characters don't go all the way to the end of the screen on the cutscene, so it cuts earlier
- flooding fills up 2x faster during action and 4x faster during the cutscene
- the dialogue is super fast
- the blocks fall faster on the collapsing bridge sections
- the big pendullums swing faster
- the boss spirit moves 2x faster horizontally when choosing a new coffin
- faster and more responsive weapon attacks
- sypha, alucard and grant had their skills slightly buffed
- weapon damage adjusted for balance
- mummy boss shoots a faster projectile
- some bosses won't stop briefly when getting hit
- small hearts and big hearts give 2x more hearts (less farming)
- always restart on the same room after dying and when continuing (I fixed one checkpoint for this, haven't found another bad one)
- crushing spikes take 25% of max health only
- no death by timer (this may be removed, what do you think? makes no difference anyway)
- no low timer sound warning
- auto verticall scrolling stages now scroll a bit faster
- 3x faster door opening animations between sections
- more subtle sfx on timer and heart count at the end of the level

This hack is compatible with the awesome localization patch

How to name it?
So, I'm not sure what to call it. I can't call it abridged like the Adventure Island hack, because although the game is now faster, all the content is intact. Here are some naming ideas:

- Akumajou There is No Time To Explain Densetsu
- Akumajou Densetsu On Steroids
- Akumajou Densetsu Turbo
- Akumajou Densetsu for People Who Don't Really Like It

Gameplay video:
Here is a brief gameplay video, because screenshots are basically identical to the original game.

So, the reason I posted here was to see opinions before I release it. I have played through a dozen times on different paths and with different characters and it all seems to be working fine.

Personal Projects / Adventure Island Abridged (NES)
« on: March 20, 2017, 10:24:32 pm »
I'm recreating the topic that was lost and I decided to change the hack's name to better represent what it is the most: a shortened version of the game!

So, to those who didn't see it, I've made a hack of Hudson's Adventure Island for the NES. What I wanted to do was to cut down on repeated / similar content to keep the game fresh and short but still challenging. In the mean time I added several features that should make it a more enjoyable experience, such as a revised game mode and a clock for speedrunning. I know I'm never playing the original game again, this is my go to version now.

Also, I wrote an article about the experience on my blog with some findings:

Is it possible in some way to have tekken 1 running exactly the same but with high poly count models and high res textures? In an emulator or something? I know the models have bones (which involves skinning) but in this game the vertices seem to always have 1:1 bone skinning, so that wouldn't be too difficult, if it is possible. Maybe via a epsxe plugin?
Am I dreaming too much?

I imagine it would involve some sort of hacked ISO along with an overclocked ps1 emulator of sorts. I think it really is more work than it is worth, but I could be missing something.

Personal Projects / metroid mOTHER health refill and warning addendum
« on: October 27, 2016, 10:27:11 am »

So, I recently discovered this hack, and I noticed there were 2 wanted missing features*:
- Starting with 99 in energy
- Not warn until energy drops below 10 instead of 16

I got those features to work with 2 surprisingly simple changes on the patched rom:
For low energy warning only on 9 health or less:
Address 0x03CE82: change to 00 (or change to $10 for 10 health or less, if that is better)

For health refill
Address 0x03FFE5: change to AD776820C5C209098D0701A9998D060160

So, I have little knowledge about the game or hacking the game, so maybe some input from the experts would be good, but I think this code is fail proof? Of course it could be done better though, I set it to loop an excess number of times because I know the maximum number of energy tanks, so I just set it to refill like 9 times and that works, since the player can never get that many extra energy tanks.

So, I have added sram saving to my super pitfall hack and it is working on fceux, nestopia and nintendulator. But it it isn't working on punes. I've sent the rom to protomank and he tested on an everdrive v8 and it isn't saving there either. So I figured my saving implementation is incomplete.

What is the correct process to succesfully add saving feature to a game? I've eddited the header using NESHEAD, clicked the sram checkbox and saved the rom with the new header. Then I simply added code that reads / writes to $6000-$7FFF memory range whenever I needed. On the three mentioned emulators it saves perfectly, I can close them and it keeps all of the save.

But on punes it doesn't keep the save even when I do a soft reset, so I think my writes and reads to $6000-$7FFF are doing nothing at all, ever. I have tested wario's woods, a mmc3 game with save, and it is saving correctly on punes.

I save at any time during the game. Here's how I'm writting (it's as simple as it gets):
STA $60B2
... many other addresses

And I load everytime I load the main menu:
LDA $60B2
STA $00B2
... many other addresses

My header settings, according to NESHEAD:
Mapper: 4
PRG 16K Count: 8
CHR 8K Count: 0
8K RAM-banks: 0
Mirroring: Vertical
SRAM: yes
Trainer: no
PAL: no
4-screen: no
VS Unisystem: no
Clean out possible garbage: yes

In other words:
   .db  $4E
   .db  $45
   .db  $53
   .db  $1A
   .db  $08
   .db  $00
   .db  $43
   .db  $00
   .db  $00
   .db  $00
   .db  $00
   .db  $00
   .db  $00
   .db  $00
   .db  $00
   .db  $00

If this is all there is to it then is it possible that it is a problem with my mmc3 conversion? The game is originally UNROM.


The only breakpoints that are working are to banks #00, #06 and #07 (super pitfall ROM).

When I create a breakpoint for read + write and executes to 0000-FFFF with condition K==#05 it never breaks.

For testing, I have tried setting 3 forbids for 0000-FFFF RWE to banks #00, #06 and #07 and then setting a breakpoint to any bank with all addresses also for RWE but it never breaks. It will only break on banks 0, 6 and 7... What am I missing here?

Personal Projects / Super Pitfall NES (improvements)
« on: April 24, 2016, 01:53:23 pm »
Minor edit (disclaimer):
This project has escalated into something way bigger than I initially wanted to do. It has moved from an improvements hack to a complete overhaul of the graphics, game design, songs and bug fixes. I won't update this first post with a lot of content, but instead will give a few images to give an idea of what this hack does (check the whole thread to see all of the changes done, or go straight to and get the hack!).

Please note that a lot has changed since I started on this project, so many of the ideas posted here were not how the project turned out to be. It is cool to keep it though to see how it really progressed. Original post following (/edit end):


Hey guys! I've been using my interest to hack super pitfall to improve my hacking skills. I've been studying all the tools and trying to understand 6502 asm for the past month. It's been a blast. Special thansk to dougeff, Disch, snarfblam and macbee  :crazy:

I've managed to make a lot of progress and even come up with new stuff. Here's what I've got:

- change the amount of starting lives (independent for each quest)
- change the amount of bullets a gun gives
- change the amount of gold required for perfect ending (default 100)
- always invincible (makes testing easier)
- invincible mode without blinking sprite (makes testing easier)
- change in-game hud position
- flip the gun in Harry's hand. For some reason it points towards him
- full map editting for static tiles and partially for the other objects, including warps
- change where each warp leads to from the default list of 8 possible destinations
- make these items always visible: guns, extra lives, lion key, invincibility star, medicine, ring 1, ring 2 and cross (everything except the suit keys)
- change the title screen
- a hack that gets rid of 2 player mode and lets you choose which quest to start on! It's working but I haven't finished the game on either option yet so I can't tell that it's 100% finished

I have also found one unused test room, that is to my knowledge, unknown so far.

And I've also found, weirdly enough, that the ROM contains older versions of almost all the rooms of the main map (except for 3 of the bottom ones). It's a lot of unused data. There are lots of minor differences in these rooms compared to the main map. There's isn't though a "map" that assembles these rooms as a full map like every other used map in the game, but they are similar enough to the main map that the main map's reference is probably the right one for these. I've then tried to compile a full image of this "beta" map but I lack the skills to automate it. I've tried contacting kingkuros of vgmaps because he mapped the used ones but he's hard to reach.

I've mapped quite a few addresses. And I have listed the hex ID for every object. It includes some possibly unused items and enemies that lack graphics but have a simple behavior I haven't seen or don't remember being in the game.

So I plan to release my work in the following ways:

- a hack for quest select mode (done)
- a hack for making items always visible (might need help with the suit keys, it's driving me nuts, otherwise it's done)
- a graphics hack, including new title screen and new font
- a map hack containing a completely new adventure (might need help with fully understanding how dynamic object data is stored). This hack will possibly require the graphics hack as I plan to make much better use of background tiles

So, is anyone interested in taking a look at the suits and dynamic objects problems? I have the addresses figured out, so it only probably takes a better understanding of asm.

Also, I have a question. What does the unrom to mmc3 patch does? Is it useful to me?

ROM Hacking Discussion / Can fceux have breakpoints on read from ROM?
« on: April 17, 2016, 03:19:55 pm »
Is there a way to use breakpoints when reading from specific ROM addresses? How does that even work? On the debugger I only see references to things loaded in RAM, cpu memory and such. How does an assembly opcode read from ROM? Can anyone shed some light on this?

ROM Hacking Discussion / Is there such a Hex editor?
« on: April 05, 2016, 03:41:33 am »
I just had the idea that it would be cool to have a hex editor that would allow loading a list of single (or maybe double?) byte addresses from a file. Preferably, each address would have a field to add a comment (explaining what they are). The hex would have an interface that would display the loaded list with comments and that would allow easy change of value for each address and then saving the loaded file (ROM). Is there already such a tool? I have found a series of addresses for a game that refer to weapon damage, character health, etc, and it'd be neat to have a handy editor for when beta testing the hack. I feel like this would speed up the testing process.

edit: I imagine this would be almost like a patcher... You load a list of preset modifications, modify their values and then you can use it to patch a ROM file. Or you can load the list of addresses and a ROM file and it will show the default values for those addresses before you change them.

edit2: I think "cheat patcher" is very close to what I was looking for. I'll be testing that.

Pages: [1]