HD remakes, what does it involve?

Started by
2 comments, last by MJP 9 years, 6 months ago
Is this purely a case of updating the textures/assets, such as high resolution/AA textures and higher poly models etc, or what else would be involved?
Advertisement

Pretty much.

You'll have a team of artists basically re-doing all the textures, and perhaps re-doing the models.

If you're unlucky, this is an equal amount of art-work to the original game (minus experimentation that didn't make it onto the disc).

If you're lucky, the original artists actually created their work at high resolution to begin with, but then shipped with reduced quality -- e.g. often you'll create 4k textures "just because", and then reduce them to 256px to get them to work on a crappy old console. In this situation, you don't have to recreate that texture, just re-export it!

However, you'll likely also need a small number of specialist programmers. The gameplay code will hopefully work as-is, but the game engine itself will need to be ported to the new platform. This probably requires re-writing the guts of the renderer, file-system, networking, platform-integration (Live/PS Network/Steam/etc), audio systems, etc...

While you're at it, you might take the time to get some gameplay programmers to fix some bugs, or to re-record/re-mix some audio, or to redo some cutscenes, etc...

If you completely redo the engine, you might've changed the way that the game is rendered - if so, you might go back through and re-do all the lighting, etc...

It really depends on the project as there's no standard practice for what's involved in these kinds of re-releases.

it's not as easy as it sounds if the game is older. From ports I've done:


-some old games are written in assembly, you could not just change assets in those, as addresses are often hardcoded and extending them isn't that simple as programmers felt like using every bit of an offset (e.g. in an 2d rts 13bits might have been offsets and 3bits specifying whether a tile was flipped and rotation). In that case it's a case by case decision how to port it. in the weirdest way I've seen that done was to run the game in an emulator and act as if the emulator had some additional ports where you could write what 'tile' you're about to draw and at which position, the emulator then has drawn in a 2nd thread the HD image. the original tiles got the first 32bit overwritten with an CRC32 and that was mapped to the new assets.


- using hardware features that aren't simple to replace (e.g. in vga you can switch the color palette at any time and some games do that on a scanline basis to emulate 200x256 colors in a 256color mode. that was sometimes used in some manager games that didn't do much more than showing pretty pictures/menues)

- some old games are written to just work with a particular compiler (e.g. I think most programmers remember how <=VC6 handled for-loop variable declarations). Those rely on bug and features and porting the code base to a new compiler e.g. to run it on consoles starts usually with hundreds of compilation bugs, followed with just a black screen after you got the binary compiled. then you debug every part of the code until it all works.

- if you retarget the game from one hardware to another, you might get totally different performance characteristics. e.g. porting a PS2 game to PS4 might still be challenging if the PS2 game does tons of alphablending. while PS4 is more powerful, you probably want 1080p and 4x MSAA, which really takes any advantage the PS4 might had have.

- sometimes libraries were used that you cannot access anymore (e.g. to play videos) and you don't have the source files of the assets e.g. videos either. re-creating assets in that case might really rise the cost (replacing a newly drawn higher res texture is relatively simple compared to re-modeling, animating, rendering the videos). You usually have just the choice of: keep it 100% orginal and sell it as intended 'retro' or redo it and make it look really good, because that's the only selling point of HD remakes.

- sometimes just nobody really knows anymore what the final game is. back then people were not using source versioning, they've just send files back and forth and to create the final game, sometimes random states of binaries were thrown together and just the 'masters' of their area knew it. you might get a drop of disks you don't even have a drive anymore to read and those might have weird archives (one code might have been using arj, another some format you cannot even google).

when I've been porting quake1 to use 32bit texture for an HD'er version, it took me 2 weeks to get through all the code and all the optimized, hand written assembly, to basically redo that. Another time I've been porting doom3 to 64bit (http://twitpic.com/7tbfjp) and their scripting system directly maps parameters from scripts to functions they call from the engine, which is ok with the 32bit calling convention they've used, but doesn't really map to 64bit calling conventions. the scripting used pointer, integer, float in a buffer and also offsets within it, but in 64bit pointers have different size than ints and floats and there was no way implemented to distinguish between those...

so, it's really a case by case basis. sometimes (Rarely!) it's a piece of cake and sometimes it's like porting to another platform. The older the game, the harder it might be but at the same time, the more worth it might be for the fans to buy the HD remake.

(oh, and please make a Star Wars Dark Forces HD ;) )

I worked on the PS3 port of the God of War PSP games. For that port we didn't use a new engine or add any additional graphical features, we just straight-ported the PSP engine to PS3. The artist improved some of the models, up-rezed a bunch of textures (a lot of them automatically through photoshop scripts), and switch out the Kratos gameplay model for the hi-quality model used in cinematics. The bulk of the work involved was just programmers porting the engine bit by bit until it ran on PS3, and then coming up with ways to get all of the graphics functionality working on the PS3 GPU. A *lot* of looking at the PSP GPU docs to figure out what the hell it did when some obscure feature was enabled (texture doubling, argh!). The rest was just bug fixing (a lot of data bugs from endianness issuess), and optimization. There was also a large amount of work put into re-rendering our old cinematics in HD, so that we weren't just playing upscaled 480x272 videos.

It really depends though on the project...some remakes take things a lot further and add lots of new graphical features. But I would say most are similar to what we did, we're it's mostly a straight port.

This topic is closed to new replies.

Advertisement