Jump to content

  • Log In with Google      Sign In   
  • Create Account

Making a game on a PC with defective RAM

  • You cannot reply to this topic
6 replies to this topic

#1 Sik_the_hedgehog   Crossbones+   -  Reputation: 1833

Like
0Likes
Like

Posted 24 September 2013 - 10:32 PM

Looking at the source code of some old game I found this gem in the readme:

 

 

This game should be called "how to make a game in 6 days with a broken computer that crashes all the time", because that's pretty much the description of this game. I had a deadline of 6 days to make this game, not kidding! And the computer would crash all the time, so if we only count the time where it WORKED, it's more like a 1 day job. And in case you wonder, the computer turned out to have damaged hardware, which is why it kept crashing like crazy. So yeah, it shouldn't have worked at all in the first place...

 

In case you wonder, it was actually this computer when I had just bought it. The RAM stick was defective, making it hang all the time. How I managed to make a game with a system like that is beyond me. Oh, and the deadline was a birthday, so yeah, no way to push it back.

 

The replacement RAM stick was double as large by the way, so besides fixing the computer it also doubled as an upgrade =P It's the one currently in use, at that. Fun stuff.


Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

Sponsor:

#2 wintertime   Members   -  Reputation: 1876

Like
1Likes
Like

Posted 25 September 2013 - 05:31 AM

I dont remember where I read it, but there was someone having an old computer where a single bit in RAM didnt work. After testing he just always allocated it on startup and it worked perfectly from then on.biggrin.png



#3 Hodgman   Moderators   -  Reputation: 31800

Like
5Likes
Like

Posted 25 September 2013 - 08:24 AM

Sounds like that game caused the programmer a few grey hairs! That's hellish!

 

 

I've had a similar experience, which was also hell. At the end of a project, we discovered a rare memory corruption bug, where some memory was just changing it's value randomly. Usually this appeared as players suddenly becoming a soup of triangles. This occurred on all our dev-kits, so we quickly ruled out hardware faults.

 

Because this happened randomly, you couldn't be sure if you'd fixed it or not either, because sometimes it wouldn't occur until the game had been running for hours...

 

It took weeks to even just diagnose the problem. Normally you'd find out which parts of memory are being corrupted, then set a Memory-Access-Trap so that when the CPU writes to that memory you get a breakpoint and you can discover the buggy code. Easy! However, the MAT was never triggered, which means that the CPU never did write to the memory... So, by divide an conquer, I'd register regions of RAM to be memcpy'ed and memcmp'ed at certian points, to manually check if they'd been modified, and eventually found patterns in which areas were being modified. Then I could just go over the code responsible for those areas with a fine-toothed comb for bugs (which took more weeks).

 

The real kick in the pants here was that there were two bugs.

  • One was a bug in the GPU-side memory allocator, where render-targets were being told they had x memory to use, but it actually only allocated x-n memory, which caused the GPU to overflow this buffer by n bytes, randomly corrupting whatever happened to be allocated after that render-target.
    This was the real bug I had to fix. The reason it didn't trigger the MAT was because the GPU accessed RAM through a different memory controller than the CPU... and even if it did trigger a CPU breakpoint, it would've been meaningless.
     
  • The other was faulty RAM only in my own dev-kit that I was using for the diagnosis!!! Many of the systems where I'd diagnosed memory corruption were actually caused by a hardware fault on my machine, which meant I'd wasted weeks trying to find a cause in the code for corruption that didn't actually occur on normal hardware. sad.png 
    The reason this didn't trigger the MAT was because it was due to problems inside the RAM chip itself, nothing external ever did actually write corrupt values to RAM.


#4 Moe091   Members   -  Reputation: 576

Like
0Likes
Like

Posted 02 October 2013 - 03:32 PM

 

 

Sounds like that game caused the programmer a few grey hairs! That's hellish!

 

 

I've had a similar experience, which was also hell. At the end of a project, we discovered a rare memory corruption bug, where some memory was just changing it's value randomly. Usually this appeared as players suddenly becoming a soup of triangles. This occurred on all our dev-kits, so we quickly ruled out hardware faults.

 

Because this happened randomly, you couldn't be sure if you'd fixed it or not either, because sometimes it wouldn't occur until the game had been running for hours...

 

It took weeks to even just diagnose the problem. Normally you'd find out which parts of memory are being corrupted, then set a Memory-Access-Trap so that when the CPU writes to that memory you get a breakpoint and you can discover the buggy code. Easy! However, the MAT was never triggered, which means that the CPU never did write to the memory... So, by divide an conquer, I'd register regions of RAM to be memcpy'ed and memcmp'ed at certian points, to manually check if they'd been modified, and eventually found patterns in which areas were being modified. Then I could just go over the code responsible for those areas with a fine-toothed comb for bugs (which took more weeks).

 

The real kick in the pants here was that there were two bugs.

  • One was a bug in the GPU-side memory allocator, where render-targets were being told they had x memory to use, but it actually only allocated x-n memory, which caused the GPU to overflow this buffer by n bytes, randomly corrupting whatever happened to be allocated after that render-target.
    This was the real bug I had to fix. The reason it didn't trigger the MAT was because the GPU accessed RAM through a different memory controller than the CPU... and even if it did trigger a CPU breakpoint, it would've been meaningless.
     
  • The other was faulty RAM only in my own dev-kit that I was using for the diagnosis!!! Many of the systems where I'd diagnosed memory corruption were actually caused by a hardware fault on my machine, which meant I'd wasted weeks trying to find a cause in the code for corruption that didn't actually occur on normal hardware. sad.png 
    The reason this didn't trigger the MAT was because it was due to problems inside the RAM chip itself, nothing external ever did actually write corrupt values to RAM.

They could make an awesome episode of House M.D with your game as their patient :P

 

  •  

 



#5 wodinoneeye   Members   -  Reputation: 876

Like
0Likes
Like

Posted 12 October 2013 - 11:19 PM

Fails after playing for long time  (aborts)

 

I recall many years ago having to add a special state saving feature to save the game at any point I hit a key command and then could reload at that one point to continue.    That was for a recreatable bugs (or near enough) that you could  do the saves manually  up til you saw the problem happen and then start doing debuging from that point  (avoiding having to watch debug thru some humongus amout of runtime).

 

Usually the bug wouldnt go away after using the good ole print statement logging method of trying to trace where the bug happened (when even when you got close what was left was still sufficient runtime/execution to take up hours in one debug run)

 

So that also included a logging mechanism to a file (with EVERY  log invocation going to a file which was immediately buffer  flushed)

You would get the last execution log msg before the bug killed the program and then you would add additional  print logging  around that sequence of code til you narrowed it down to a point you could actually run via the debigger (single step)  efficiently.


--------------------------------------------Ratings are Opinion, not Fact

#6 Shane C   Crossbones+   -  Reputation: 1283

Like
0Likes
Like

Posted 13 October 2013 - 04:54 AM

This reminds me of the time I used a monitor which hurt my eyes. It was actually a small LCD TV, and for some reason the brightness was way too high no matter what I did. So I had to use this for making my game.

I've had malfunctioning hardware before too, but for some reason, it reminded me of that.

#7 samoth   Crossbones+   -  Reputation: 5032

Like
0Likes
Like

Posted 13 October 2013 - 07:06 AM

I dont remember where I read it, but there was someone having an old computer where a single bit in RAM didnt work. After testing he just always allocated it on startup and it worked perfectly from then on.biggrin.png

That must have been a really oooooooooooold computer then, one where the OS wasn't doing any such thing as virtual memory :)

 

I've had faulty RAM a single time in my life, and it was "working normal" all the time except it bluescreened the machine roughly once every 45 mins. That's not the annoying part of faulty RAM, though. When it crashes, that's actually good. What's really bad is when it "works normally", because you can never know for sure whether it really works or whether it just incidentially doesn't cause a crash (but silently saves your documents/sources as total garbage or such).







PARTNERS