runs at home but not on some work pcs!

Started by
3 comments, last by ade-the-heat 19 years, 8 months ago
My game is simple, it runs well at home. So I zipped it all up and took it to work. It ran fine on my pc at work (after downloading glut32.dll and openal32.dll and installing the latest graphics card drivers). It didn't run though on anyone else's pc at work. They downloaded the latest driver, glut32.dll and openal32.dll. However, on starting it crashed every single time with error reading 0xcdcdcdcd - which we all know is baaaad !! The only thing I can think of is maybe I've used an extension that isn't supported on their card (although I'm sure I put all this stuff behind flags). So without me taking my entire code to work and taking over someone else's machine - how can I know what the problem is ?
Advertisement
It's really hard to answer these types of questions without knowing anything about the code or the computers you are testing.
So, a general answer would be to make sure all of the files that your app references are actually there. Do you check all the files that you try to open in your code? There might be a place where you start reading a file that isn't there.
Maybe those machines have less memory and they run out. Do a little debugging (which I know is annoying because it's on someone else's machine) and see if you can narrow down the problem a little.
ok, what I did was clean the area of my pc at work, I took the precise zip file my colleagues had and put it in my pc and unzipped. The game worked first time !
This is really annoying !
So it isn't the files...
Take a debug-build to work and make it spew everything to a log file. When it breaks on your colleages machine you can see where the last succeeded code was called and make assumptions from there.

Aside from that, just make your code more robust: check to see if calls to functions succeed and do something that will be more tolerant. Do checks for NULL parameters and NULL pointers before dereferencing them. If you use shielding (#ifdef BLAH) you might be bypassing code sections by accident that need to be called (eg. initialization of a structure).

The 0xcdcdcdcd sounds like you're using a pointer member of a structure without initializing it after mallocing it. When you call malloc it fills the memory with 0xcdcdcdcd (c=created I think) in debug builds and when you free something it fills the memory with 0xdddddddd (d = destroyed I think). If you're using constructors with classes and passing them not as pointers it's possible that your copy constructor isn't setting correct data.

Other than that, don't trust any functions to succeed. When they do fail, do something that isn't going to break the rest of your program.

Helped? :)
do unto others... and then run like hell.
cheers
I'll have a look tonight...

This topic is closed to new replies.

Advertisement