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

Pages: [1] 2 3 4 5 6 ... 37
changing the frame rate on Ghosts 'n Goblins for the NES?

Not easy. I'm not sure about what frame rate the game actually runs at, but improving it would be a hell of a task. It's not like 3D games, games on the NES were just designed to be like that, so changing that design would be more trouble than it's worth. Just play the arcade version. :D

add Super NES Mouse support to Nintendo's SimCity?

Now THIS is more doable. One could analyse how mouse input works on Mario Paint and the few other games designed to use the mouse, then try to replicate that in Sim City. If there's a game out there that supports both controller or mouse, even better. The tricky part is telling the game that that's what you want to do, but I really don't think it's outside the bounds of possibility.

Given how much people like this version over all others, I'm surprised nobody has tried to do it. I would, but alas, no time.

A hack or a Game Genie code to allow a level select in Castlevania (Akumajou Dracula) on Nes, or a way to skip levels, would be awesome !

Always worth checking that site to see if they have something you want. :)

EDIT: Actually that doesn't help an awful lot: that code will start you on the three parts of Level 1, but if you try to start on Level 2, the game loads the wrong ROM bank and everything is screwed up. I could try to figure out where the game decides which bank to use, but that will take a bit more hacking. I might give it a shot, though. Hell, at this point it'd probably be better to just include an actual level select in-game. :)

Are you referring to this document, Sir? I will look into it. Thank you for the reference! :)

Yes Sir, I am referring to that document. ;) It took me some time to understand how it all worked, but I was really pleased when I used it to put DTE in my own hack, and some of the principles detailed there have helped me out since.

Great job! But you both seem to have much more patience for random battles than me. :P

Thanks, though I wouldn't say I have patience - in all honesty I'm not likely to play the game myself. :D I just saw someone with a feasible request and decided to try and fulfill it. See guys, sometimes when you write a FEASIBLE and LOGICAL request in this thread, someone comes along to help - especially when you show you can do a little bit of the work yourself. ;)

Something really quick I noticed in the RAM viewer: there's this byte at $06b5 (aka $c6b5) that goes up every step or so... It seems if you keep it really low (like 1), random encounters appear much more rarely. Maybe the game uses this number as a % of probability (ie, if there's a 20 there, a battle can come up 20 out 100 times). Also, if set to 0, it seems there are no random battles at all.

Well, you're right that it's a step counter, good job. It increments every step, unless it reaches $10, in which case it stays at that. After it checks this step counter it calls a routine which I assume is an RNG routine, but I'm not familiar enough with such things to know. Suffice to say that freezing it at $01 means that encounters are very rare, and freezing it at $10 means encounters occur very quickly.

So, what is obviously happening is the game sees how many steps you've taken and makes a 'dice roll' to see if you have an encounter or not. To use a board game analogy, it's a bit like rolling 2D6 and having to get 13, but adding 1 to your roll for every step you've taken. Thus, zero steps means no encounter, and the more steps you make, the more likely it becomes. At least, that's how it seems to me.

I'll make a routine to only increment every other step, and see what happens. :)

EDIT: and I'm done. :) Just patch the ROM with this and it adds a little routine, which I shall now explain.
Quite simply, the patch breaks out of the regular program to check a (hopefully) unused RAM address, $C6FF, to see if it's zero. If it is, it increments it and loads the step counter as normal. If it's not zero, it decrements it (bringing it back to zero) and decrements the step counter. Then when the step counter is incremented as normal, it basically means it doesn't change. Therefore, your step count only increases on each alternate step. As far as I can see there are no problems with this, and I assume the encounter rate appears much less - but you'll have to test that yourself. :)

Hat tip to KingMike for suggesting the 'spare RAM address' idea in his DTE tutorial that taught me a lot about assembly. :D

I know you've probably moved on from this already, but I downloaded the patch, patched the ROM with Beat and it played fine. Of course I'm not using an SNES Mini, but I see no reason why it shouldn't work if the original ROM does. Clearly you did something wrong: either you didn't use Beat to make a new ROM file, or you're using a weird ROM, or something.

I used the one in GoodSNES named "Super F1 Circus 2 (J) [!]", CRC32 0AB53000, as the page for the hack suggested. You needn't worry about headers and such, they're pointless unless the patch is super old and using a weird old ROM dump. So if you want to try again, I'd recommend doing so, just remember to get Beat:

In address 0690 when you are in an area with no random battles the value is 0 and once you go outside, it is set to 1
In address 0695 when you're in a battle area the value quickly goes from 01 to 18, then resets back to 01 and continues the same behavior (It is set to 0 when you are in houses). Do I understand correctly that this is what influences the random battles?

Good find there. I took a look at the game in BGB's debugger and if you just want to have random battles disabled permanently, change $2339 in the ROM from 7E to 79. This instruction is used when you move from one screen to another and changes $690 in RAM to whatever that screen requires. With this change, instead of loading $690 with the correct value, it loads it with what's in the C register - that is, zero. Different areas have different numbers, so this presumably affects what kind of enemies you encounter.

As for reducing the rate instead of turning off battles completely, I'm not so sure that $695 is connected: it rolls around every frame or so and you still get random battles regardless of what number it lands on. That will take a little more investigation.

Would it be possible to reduce the encounter rate for this game to make it more enjoyable? :)

If you learn Z80 assembly then sure. That's the only way you'll be able to alter the encounter rate. First you'll need to figure out how the game decides when random battles occur. Like, Final Fantasy 1 takes a random number and counts down with every step, so you could just double the number and get a much lower encounter rate. But this ain't FF1, so who knows.

ROM Hacking Discussion / Re: Hack patches that impove original snes roms
« on: November 02, 2018, 05:28:56 am »
RHDN has an "Improvements" category in the hacks section

I was gonna say the same thing. I'm pretty sure they're categorised already, unless the person submitting them has mislabelled them. Seems a little subjective, though: where precisely the line is drawn between mere improvements and game-changing mods.

Gaming Discussion / Re: Does anyone know what game this is?
« on: October 23, 2018, 06:44:38 pm »
platformer.  Had some guy with a sword and fire in the background I THINK...and I think one of the first levels was outside, the next was in a castle with some tough jumps.  Gosh, I barely remember the game, one of the LESSER KNOWN snes platformers I would think

Speeding through a YouTube video of every SNES game (assuming it was the SNES), a few candidates come up as "platformer with man with sword": Actraiser 1 and 2, First Samurai, Skuljagger... not much else. There are a couple of others that might fit the bill, but not entirely.

Newcomer's Board / Re: Sega mega-play/megadrive/genesis
« on: October 23, 2018, 06:05:21 pm »
I don't know about an Insert Coin function.

Perhaps (just a guess) the modified Mega Play version of SOR2 has a routine that won't let you start the game without a certain address in RAM having credits, and another routine to check a register that checks for coin input, or something. If SOR2 works like that, you could possibly add the same routine to the other games and bingo. I'm not saying it would be a walk in the park, of course, and frankly I don't see why you wouldn't just have the game as-is in your cabinet and forget about coins. I mean, who really wants to have to put more quarters in every time... :D

There are no diagonals in this test cart.
There -are- diagonals in this test cart... but it only registers buttons presses from an emulator while in the 4 player multi tap test screen...

I'm on my phone and can't see the videos right now, but my point was that the NES collects input by polling the registers at $4016 and $4017, then storing the result in RAM. The result is 8 bits (up, down, left, right, A, B, Start, Select), hence there is no distinct diagonal.

However, I assume what you're referring to is that the diagnostic test doesn't ask you to push two directions at once to see if it can be done, which would be testing the physical attributes of the pad rather than the circuit connection. I suppose you can allow for that in the software (the test) but maybe I just misunderstood what you meant.

I agree that diagonals on some pads can be tricky (such as trying to do them in Dead Or Alive 5 on a 360 D-pad) so being able to test it would be useful.

register diagonals

Eh? You mean "up and left simultaneously"? Surely if it sees all four directions, that's enough. Maybe I'm missing something here, but diagonals aren't independent, they're just two directions.

Newcomer's Board / Re: How to delete account?
« on: October 16, 2018, 06:22:23 am »
Reading through all your previous posts, I don't want to presume what's going on in your life to make you feel like this, but my advice is to chill out and take it one step at a time. Hacking and translation are two different things, and as someone who does both, I would say that you don't have to be competent with the hacking in order to translate.

If you still don't understand table files, perhaps you've been trying 16-bit games with compression etc, which is always tough if you don't know assembly. I recommend something simple to get the hang of this. Example:

Take a look at the first game I translated, Detective Conan Mechanical Temple whatever on the Game Boy Color. Open the ROM in Tile Molester, scroll through it and you'll find the kana effectually. Next, use Relativeful Search and search for the first word Conan says in the game (don't remember what it is), by using numbers instead of kana in the order it's in the graphics - a is 1, i is 2 etc. Make sure to avoid dakuten characters like da and ji, cause different games do them differently.

You will probably find an address where that word is (you may find a few if it's a common word). Now open the ROM in WH32EX and you can see what hex values the kana have, so use Tabular to make a table file (it's a good program cause it can do autofill for different character sets, just use Romaji for now).

So you put the kana in your table file, including anything else you saw in Tile Molester, and open the ROM in WH32EX with your table file, and go to the location where Conan's line is. Voila, there's your text. :)

If you didn't follow, gimme a shout.

Here's the thing: you couldn't just make it 16:9 by extending the screen because, as you said, you'd have to crop the top and bottom. Which, to be honest, is pretty dumb. On the other hand, emulators for later consoles like the Dreamcast can play in 1920x1080 and expand the viewing window, which introduces artefacts like objects popping up, but you don't miss anything and it looks cool.

Going back to the NES and SNES, it wouldn't be difficult per se to remove stuff from the top and bottom, but why would you? Extending the playfield is great, but shrinking it is pointless. The only way to fix it is to do like Outrun Cannonball, which is a port of the original game with a new engine.

In a 3D game like Shenmue, you can extend the viewing area and see things that aren't normally in your immediate view, but you can't automatically do that on NES because... they don't exist. They'd need to be put into VRAM first. Actually, come to think of it, you COULD kind of extend the viewing area because the nametable has enough for two full screens. But more than likely the sprites will pop in on the edges, unless you modify the code to make them appear off screen.

What I'm saying is, theoretically, yes, you could make an emulator that could extend the NES screen, but the results would be very variable. But forget about doing it on real hardware.

some does not have any sense of scope - suggesting projects that would take considerable time and effort.

The difference between saying "I want to be able to access this menu with a single button instead of having to go through a separate sub-menu", and saying "can someone take this SNES game and make it for the Genesis for me? kthxbai"

I agree, you may have "all the ideas" but unless you understand that sense of scope, those ideas are just shouting into the void. Incidentally I did a hack for someone who posted here, because it was just "restore graphics from Japanese game to US game" which took about an hour. Oh, and I spent a similar amount of time combining two Metroid hacks, so simple things do get done.

I know I should probably finish Zoids first, but the amount of text in this game seems pretty small, so I'll have a look. If I want to go ahead with it, I'll let you know, but anyone else is welcome to try, too.

"If I knew how to do X, I would do all this stuff myself." Well, the first step of doing X is learning how to do X, so put your money where your mouth is.

Preach, brother. 8) If you've got time to post the 100 different hacks you want other people to make, you've got time to learn how to do it yourself.

Porting of Famicom Detective Club 1 and 2 from FDS to NES.
Afterwards the rom can be extended to translate the game.
Same with Shin Onigashima.

FDS games have roughly 64KB of storage on each side - although in practice it's less, according to Famicom Detective Club 1 has two double-sided disks for a total potential size of 256KB. By using the formula from and looking at the amount of space used on each side, I estimate around 34,833 bytes free across the four sides, which when combined with a simple DTE routine, should arguably be enough free space for a translation.

Converting FDS games to ROMs is no mean feat, and when you consider that practically every emulator and Everdrives all emulate the FDS perfectly well, it seems reasonable to leave the games as FDS games. Switching the game over to a cart mapper rather than just adding more stuff to the files on the disk seems like more trouble than is worth.

All this is just a long-winded way of saying that if someone really wants to translate FDC then go right ahead, but I'd personally much rather do it on FDS than a ROM. :)

Same situation for Shin Onigashima (it actually has even more free space on the disk) but you have the bigger problem of the text format going vertically rather than horizontally. Good luck fixing that! :D

Personal Projects / Re: Commander Keen translation(s)
« on: October 08, 2018, 06:04:24 pm »
I didn't specialise in Hungarian translations at all.

You have submitted 36 translations to the site and 34 are in Hungarian. :huh:

Anyway, I'm sure any translation is welcome here, but given Commander Keen is in English, we'd have to hear from someone who doesn't understand English.

Pages: [1] 2 3 4 5 6 ... 37