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

Author Topic: Modernizing Retro Games?  (Read 3861 times)

MegaSkeleton

  • Newbie
  • *
  • Posts: 2
    • View Profile
Modernizing Retro Games?
« on: December 22, 2014, 11:46:58 pm »
I've had the desire to mod old games and improve them more towards our modern standards, so as to make them accessible and their appeal last for several decades more, but am unsure what is in the scope of romhacking.  I notice most tools I've found to be more specialized into doing things like modding graphics or changing settings...but how are those tools built?  I have some moderate coding experience and am wondering what it takes to look into the lines of code that the game is built on itself?

If it helps, here's an example of the type of stuff I'm thinking about:

I've recently played Shining Force for the first time and found it an enjoyable game, but held back by a variety of factors. 
1) Shopping in town and managing inventory is excruciating by modern standards.  10 menus to buy 1 item for 1 guy, and not even being able to tell if its an upgrade before purchasing?  One rushed misclick and you have to start over?  Not good.  If I were to rethink some of the menus to make them much easier to buy items in bulk for different characters, is that kind of stuff possible?  What about expanding inventory for characters or adding some kind of junk tab that is inaccessible during battles (i.e. represents all the items in your bags, rather than items you have equipped/available on hand)
2)Skip enemy turns in which they do not act.  A big slowdown of pace in gameplay occurs when you're tackling one enemy on the map yet every other enemy gets his turn.  Could I change the logic so that before moving the camera to enemies, highlighting the cursor on them, etc. etc. to run a check to see if the enemy will attack/move, and if it won't to just skip those processes entirely?
3) This kinda leads me into my next point of world map battles being terribly unbalanced by poor terrain, as well as boring ai.  This one seems a little more manageable as it would be more about tweaking spawns or move costs on specific terrains.

For reference of what I'm trying to get out of this, I don't necessarily care about the individual project so much as gaining an understanding of the inner workings of older games and how data is stored, and how to modify it.  SF is just a good example of the types of games which haven't aged so well but still have some solid gameplay and systems I feel I could improve. 

Can anyone point me into a useful direction?  I'm going through the FAQ now but it already seems a little steeped in using tools rather than cracking open lines of code within games themselves.  How do these programs read the roms?  Where can I learn about syntax or coding languages used for old games?

Thanks guys!  8)

FAST6191

  • Hero Member
  • *****
  • Posts: 3089
    • View Profile
Re: Modernizing Retro Games?
« Reply #1 on: December 23, 2014, 05:55:41 am »
The scope of ROM hacking kind of gets divided along similar lines to homebrew in terms of can work on hardware or is emulator/enhanced hardware only, however that is not the most useful distinction.

For the emulator/hardware stuff most will usually think of either SNES hacks that used quirks of emulators to make life slightly easier or the stuff a lot of people do with games rendered in 3d hardware where they replace textures, add antialiasing and various other things -- some of that is done to actually give the game textures in the first place, increased polygon counts for models or higher resolution textures, other times it is an end run around learning what I would probably call ROM hacking proper; if the text is rendered on the 3d hardware at some level it becomes a viable target for texture replacement, however most around here would consider that a horribly overcomplicated (even if the barrier to entry is more likely to be "can use gimp/photoshop/paint.net") and impractical way to set about such things. It can however go from the more subtle stuff with NES mappers (the NES carts often had extra hardware to increase their capability in various ways, not anywhere near as much as the SNES but still a lot) to things like some of the hacks with Lua enabled emulators (Lua the programming language is commonly added to emulators and can read the memory of a game, inject things in it and also put extra content on the screen, have a look around tool enhanced speedrun (TAS) forums for more there*) -- http://www.romhacking.net/forum/index.php/topic,18717.0.html .

*the two that mostly feature it as a stock would be FCEUX for the NES and Desmume for the DS, most systems will probably have a fork of an emulator with it though.

Without looking at code you can usually edit text quite easily once you know how (see pointers and encoding/tables), graphics (give or take compression), some music on some systems and levels are also often possible. Eventually though you will have to look at the actual machine code via a disassembler, bonus here is you will tend to have an emulator you can stop, restore states to, set to watch/break certain locations and much more besides. To get most places in the assembly hacking you will probably want to know the assembly for the given chip(s) and/or system in question (if that was the megadrive version you were looking at then it has a 68K chip and a z80 that mostly does sound, compared to the SNES the megadrive is not quite as commonly hacked outside of Sonic but that is OK).

Equally as ROMs of old games do not tend to get recompiled any locations you find for whatever will tend to stay that way forever more -- if you know a sprite for a given character is at this location, using this format and these colours then you can make a tool easily enough to decode said location and allow people to doodle on it with said same colours. On the other hand a lot of those tools can be quite generic and have no deep logic to them -- graphics are usually determined by hardware so you can add decode methods for various systems (they are all quite similar but with enough subtle differences that you need to play to them to see anything), add means to set the width and height of a tile, set a location you want to start decoded and bam you have a tile editor. Text might not use ASCII but it will probably still use 8 or 16 bits to encode text values, make a hex editor that can decode using a user defined table of values and you have something that can decode text. For most older systems the sound was left up to a given developer, minor exception for the Amiga which frequently saw all sorts of common tracker formats used, but newer ones like the DS have a sound format that is shared by the vast vast majority of games.

Not many people find much use in looking at assembly line by line (the closest most people will get for this is in graphics editing where you can usually open the thing in a tile editor, set the mode, press page down enough times that you have looked through the entire ROM), usually you will have a plan of attack. For instance if I wanted to hack in infinite health I would find a point in the game, do a savestate (optional but suggested), make a cheat (memory search) for the health value for that character, take said memory location and give it to a debugging emulator to pause when something touches that location, said emulator would give me the instruction that changed that location and I can either follow it up the chain or simply change instruction so it does nothing. Equally it is for that reason that a lot of people will probably learn the basics of cheat making before tackling assembly proper, though if you wanted to learn graphics tracing or something instead then that is fine.

1) UI redesign is one of the things I like to do, indeed if I review a game I will usually take the time to consider the UI in preference to a lot of other things. In this instance though it is more likely to involve assembly. There are a small handful of games that do it with their text engine but is still a small handful, and most of those are more the static UI stuff informing you of something rather than menus.

2) Doable in a general sense, how it will play out for a given game remains to be seen. I do not imagine it will be a loading/processing mask (if it was a 3d game then the chances of such things rise considerably for some reason) but it is not unheard of. If you are using one of those lua emulators you might be able to get it to fastforward if you can detect it is an enemy move time.

3) If it is initial enemy placement then that is probably quite doable (it is likely a separate table in the level layout). Move costs might be a table again; such things are usually laid out on top of graphics rather than have the game decode graphics and go backwards, it is certainly the case for 3d games, but it might also be that the graphics pull from the initial table. If it is graphics pull from the table then you will have to determine where it calculates move costs and adjust that in the game.

Syntax and coding for old games... technically the SNES did have some compiled games, however compilers did properly not start appearing and being used until the PS1 era and decompiling is not really something that ROM hacking does much of unless a game was written in some kind of interpreted language (be it something like ZZT, SCUMM or right up to the modern day with Lua -- many a commercial game on the DS has some Lua in it and a few even use it near exclusively). Most games before then and many games during and after that were coded with extensive assembly language, obviously this changes for every processor and hardware setup but if you learn more than two CPUs, especially if one of those is x86, then you tend to be able to change easy enough; you will have instructions to do maths, do boolean logic, shuffle things into and out of registers, shuffle things into and out of memory, ways to interrupt code to do something else and most of the time it will have some location in memory to do something that the CPU might not be as good at (most likely DMA to shuffle large amounts of data from the ROM into memory, or memory to another type of memory).

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: Modernizing Retro Games?
« Reply #2 on: December 23, 2014, 05:57:04 am »
You can't do most of these without changing the game code.

Do you know 68000 assembler? Megadrive hardware programming?

Wouldn't it be easier to recode the game from scratch in a more convenient language?

For Shining Force specifically, you can at least find a good commented disassembly somewhere on the net. It saves you most of the work.

MegaSkeleton

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Modernizing Retro Games?
« Reply #3 on: December 23, 2014, 12:55:55 pm »
Some very useful information here, and thanks...not sure where that leaves me though.  Is a disassembly more what I'm looking for?  Fast's posts makes me think that a lot of what I would want to do is doable with romhacking (which, let me get this straight, is mostly hex editing?).  Yes, learning old languages seems like a lot of work for some projects like this.  I definitely feel in over my head with projects that I try to take on but I know I just need to put some work in to start seeing some results.  I just feel like at this point I need to dial this back to something smaller since hex editing and any older languages used I'm sure are foreign to me.  Any recommendations?

Any ideas where I could find commented disassemblys or point me in that direction?

I'm going to keep rereading your post to make sure I digest it, but yeah.  Thanks again.

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: Modernizing Retro Games?
« Reply #4 on: December 23, 2014, 01:20:58 pm »
Changing menu system : require assembly
Changing battle proceeding : same
Changing terrain battles : likely hex editing is sufficient
Chaging AI : require assembly.

I didn't read Fast's post (like much of his post, he express himself in such a way it's difficult to understand for someone which isn't very fluent in English).

Shining Force II disassembly can be found here : https://github.com/ShiningForceCentral/SF2DISASM. I don't know for the 1st.
Various ressources can be found at Shining Force Central website.

STARWIN

  • Sr. Member
  • ****
  • Posts: 454
    • View Profile
Re: Modernizing Retro Games?
« Reply #5 on: December 23, 2014, 01:29:33 pm »
Is there a NES game that you would be motivated to improve? If so, my recommendation would be to start with FCEUX as the "hacking tool". http://www.obelisk.demon.co.uk/6502/ is a very nice basic reference to the CPU used in NES. The assembly language part is not very complex in itself, although it may take a moment to grasp at first (obviously keep a reference open). With those basics, you will understand a lot of what goes in FCEUX. I would not recommend pure disassembly as a learning experience.. you'll get a disassembly view in the debugger emulator anyway. In FCEUX debug->Debugger and debug->Hex Editor would be the two basic screens to keep on.

If you want to modify some offset in the ROM (eg NOP an instruction or change a data value that is used, for starters), a basic third party hex editor will do fine.

Even a partial understanding at this level seems sufficient for helping understanding romhacking in general.

FAST6191

  • Hero Member
  • *****
  • Posts: 3089
    • View Profile
Re: Modernizing Retro Games?
« Reply #6 on: December 23, 2014, 02:20:20 pm »
Sorry, I have been trying to get back to more simplistic language but off the cuff replies tend to see me revert.

"possible with ROM hacking" is pretty much "is it possible on hardware?" (and/or viable with the emulators that exist/small mods to them). Generally you do not turn racing games into final fantasy clones or something as such things require serious work. This is on top of general ROM hacking which can already be quite involved.

Hex editors, for some reason those new to ROM hacking tend to fixate on them. In the same way you write an entire website in windows basic notepad you can do any ROM hack in a hex editor, however you would be a fool to try that when you can flank it with any number of other tools. Equally like the web dev stuff you would have a syntax highlighting, function calling, proper search sporting.... notepad for general work there are also occasions where people say poke it and just use the basic notepad to change the thing that needs changing.

Hex editors are mainly good for
Making small changes, experimental if you want.
Making larger changes when you know what is being changed and why you are changing it.
Slicing up files into smaller chunks.
Fiddling around with widths and functions to see if something pops out at you -- if a given header for a file has entries for each file that total 18h in length then your standard 10h window might miss this out, shuffle it to 18h wide and all of a sudden you will probably have a pattern.
Scanning through to get a general feel for a section/file/ROM -- if a given section is 98% composed of 00 hex then it is probably not going to be text, may not be graphics and so forth.

For my money most of ROM hacking is a protracted game of "what does this button do?" except the buttons are several megabyte long files running on embedded systems where changing any one bit can change how something works, and changing one bit may also change how another bit is interpreted elsewhere in the game and.... However you most likely will want something specific (I want to edit the gameplay logic, the levels, the sound, the text, the graphics, the colours of the graphics.....) so you get to formulate a plan to get there. Said plan will probably involve finding something that shows through in normal gameplay and then working backwards from there. Working backwards can involve assembly, and once you know it for the given system then you will probably go with it as it is seriously potent and quick, however it is not the only way. Other ways include manually checking -- scanning through with a tile editor, corrupting part of it and seeing what has broken in the game, noticing a pattern (a stat goes up by so much each level, there may well be a section detailing exactly that*), eliminating an area/file, file names/extensions (not so much on the megadrive), file sizes (the megadrive does not have files in the classical sense so not really an option here) and more besides.
On the other hand most games will not be pure abstraction so you will need some kind of assembly at some level to do the really in depth stuff, which does include everything but terrain types and placement from your list there.
However to aid in all this you have full knowledge of the hardware if you want it, an emulator that will go one instruction at a time, an emulator that will tell you all about the state of the game, an emulator that will pause at any moment and a computer that will allow you to tweak some, test it and revert right back to how it was beforehand if you want to.

*I doubt there is a ROM hacker out there that has not had a scan through a gamefaqs style faq, wikia breakdown of stats or something similar.

Fully commented disassemblies are few and far between, though there a handful out there. Not sure precisely what goes with Shining force, it is not as popular as some of the other proto tactics games (Fire Emblem has a pretty big community, Advance wars/famicom wars/system wars does well, Daisenryaku has a few fans on the Japanese side of things) but at various points I have seen people tackle it to understand it. I have not got any good links right now though, however it looks like tryphon's link is probably what I was remembering (or at least from the same people).

A given assembly language is hard and annoying to learn but that is because most computer language development has been an effort to get away from it.

BlackDog61

  • Hero Member
  • *****
  • Posts: 784
    • View Profile
    • Super Robot Wars A Portable translation thread
Re: Modernizing Retro Games?
« Reply #7 on: December 25, 2014, 01:05:32 pm »
Wouldn't it be easier to recode the game from scratch in a more convenient language?
+1
As soon as you're trying to modernize, good graphics are a big factor for kids nowadays. That's just usually not going to be possible on the same platform. Thus the suggestion to recode from scratch as soon as the changes you plan are significant.
The thing is: you won't need assembly knowledge for new games dev from scratch, but you'll definitely need it for the kinds of upgrades you mention if you try the RH way.
Both ways can lead to interesting results. I'll be looking at you!  ;D
Good luck!

VicVergil

  • Hero Member
  • *****
  • Posts: 723
    • View Profile
Re: Modernizing Retro Games?
« Reply #8 on: December 26, 2014, 08:59:11 pm »
I'd really love to modernize Tengai Makyou 2.

As-is, it's graphically on-par with stuff like Final Fantasy 4, with really poor palette design choices everywhere (probably owing to the PC Engine limitations). Awful tile design in maps, sometimes borderline early 3-gen (ice cave looks more like a bacteria cave). Enemies shake and have no disappearing effect, not even a shitty dissolve overlay. Also, no background graphics whatsoever for fights despite the predecessor on PC Engine having those.

It received a DS port that added an UI for the second screen (though had some pretty weird choices) as well as the upgraded sound effects from the otherwise godawful PS2 budget "remake". They did away with the palette limitations obviously (I peeked in the rom and the graphical format they're using seems to allow for much more colors, since it's also used for the new DS exclusive fully colored menu graphics) but changed nothing. They added a battle background, but it's a static shitty 2000-esque explosion gradient effect in different variations that wouldn't be out of place of a Powerpoint slideshow.

What I would do:

* Take the upgraded sprites for the main cast from their cameos in Saturn Bomberman (palette around 16 colors too, yet much better)
* Import NPC sprites from Tengai Makyou Zero and Oriental Blue
* Make a map editor to make the maps more pleasant to the eye, reusing tiles from above mentioned FEoE games (possibly other 16-bit Japanese-themed RPGs like Live A Live) - will be needed anyways to translate this game as there are routinely puzzles based on stuff written on the
* Implement the animated backgrounds from Mother 3 somehow, the entire ASM routine is up courtesy of Jeff
* Change the DS version's upper screen entirely. To something like Nostalgia DS, also by Red Entertainment (their sprites could be reused, they even have the same art style)

Dwedit

  • Sr. Member
  • ****
  • Posts: 307
    • View Profile
    • Dwedit's Website
Re: Modernizing Retro Games?
« Reply #9 on: December 27, 2014, 12:28:07 pm »
Hacking a new menu system into an old game is far less work that making a new game from scratch.  In one case, you are making a new menu system.  Sure, it's complicated, and it's done in ASM and all, but you aren't writing the other 145173267 parts of a game.
"We are merely sprites that dance at the beck and call of our button-pressing overlord."

tryphon

  • Hero Member
  • *****
  • Posts: 722
    • View Profile
Re: Modernizing Retro Games?
« Reply #10 on: December 28, 2014, 06:21:08 pm »
Hacking a new menu system into an old game is far less work that making a new game from scratch.  In one case, you are making a new menu system.  Sure, it's complicated, and it's done in ASM and all, but you aren't writing the other 145173267 parts of a game.

It's less work, but not "far" less. And if you want to change other things in the game, it'll be definetely more work.

It would be far less if you had a commented source code, with crystal-clear structure. This is almost never the case.

M-Tee

  • Hero Member
  • *****
  • Posts: 596
  • One pixel at a timeā€¦
    • View Profile
    • M-Tee Retro Graphics
Re: Modernizing Retro Games?
« Reply #11 on: December 28, 2014, 06:56:23 pm »
Also, considering that you'd be ripping all of the assets, and that there are game making utilities specifically designed to make 2D RPGs, the saving of time would be significant, especially considering the difference in learning curve between learning to use RPG Maker and reverse engineering an SNES ROM.