Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 07 Mar 2009
Online Last Active Today, 05:34 AM

Posts I've Made

In Topic: HD remakes, what does it involve?

Today, 02:14 AM

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 ;) )

In Topic: Loop Compilation - Bad Performance

15 September 2014 - 10:57 AM

it may cause a slow down but it may also run the same speed. that's very shader dependent and you need to profile it on a case by case basis. But if compile time is the big issue and the slowdown is not incredibly high, there is not much choice you have beside doing whatever is needed to speed compilation up -> [loop]

In Topic: Loop Compilation - Bad Performance

15 September 2014 - 06:43 AM

the compiler might find more optimization opportunities with more code in the generated binary. e.g. for twice the amount of code * twice the amount of possible duplicated code, even if the query to find redundant code would take just O(log n), you'd still need to execute it now for O(log 2*n).

2.7s = n*log( n)
n = ~2.7
2*n*log(2*n) -> 2*2.7*log(2*2.7) -> 9.1s
your 7.8s is not that far of I'd say smile.png

anyway, if the compilation time 'cause you trouble, try to force looping, at least for development it might save you some time:

In Topic: Odd framebuffer behavior

15 September 2014 - 06:26 AM

maybe it's somehow related to whether you're rendering fullscreen or windowed, have you given that a try?

In Topic: Voxelization goes wrong

15 September 2014 - 04:36 AM

... I've repeatedly been looking through it and failed to find the error, ...

well, looking at code is the least likely way to find bugs. you need to debug it, you need to validate parts of it, compare expected vs real results and reduce the area of error to as few bits of code as possible. programming consists of a big part of debugging and the more efficient you'll do that, the faster you'll make progress. it might sound like some work to create those validations, but it's a deterministic way to find bugs, rather than looking at code which might kill the bug in a minute or might never kill it.

also, there might be multiple errors and fixing one possible bug might not lead you to proper result and without validation, how would you really be sure it's as it should be? also, bugs will re-appear for as long as you work on your code. having a way to validate parts of it will save you tons of time in the future, you might even catch bugs that you wouldn't be aware of for a long time and later on you might have been searching in a big code base.

so, sorry, but improve your debugging skills. you have an input -> blackbox -> wrong output. slice the blackbox into smaller parts, find the error line. you will not even need us to fix that line, probably, but if you need our help, you'll be able to post the critical part and we'll give you more accurate suggest.