Humus - Comments

More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 57 58 59 60 61 62 63 64 65 66 67 ... 71 ... 81 ... 91 ... 101 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 365

Query FailedKayru
Thursday, June 24, 2010

The console way definitely seems like the way forward. GPU is just another processor in the system. Ideally, with shared memory and very low level API, like libgcm. But thats probably too much to ask...

Bryan McNett
Wednesday, June 23, 2010

My suspicion is that, as flops/watt continues to improve for many tiny slow cores, there will eventually come a mobile computer generation in which the sequential CPU no longer earns its keep and is left out. Amdahl's law always applies, but the common belief that popular apps require serialism is a myth, IMO.

The driving force behind this is flops/watt. So it should happen to mobile computers first, then videogame consoles or servers, and finally to desktops. But the process may take decades, and a majority of developers will resist it.

diegopark
Sunday, June 20, 2010

Although a paid application, I suggest Visual Lint / PC-Lint

Richard S
Saturday, June 19, 2010

If you use custom memory pools (i.e. allocate all memory at startup, partition into your own system-specific pools, and allocate from there with custom allocators), the best way I've seen is to initialize all memory to known values at startup. That way you don't have to care about per-allocation overhead of the memory fill. Depending on your needs, you can re-fill on free also.

If you go with a different fill value per user, you can often catch some of the more nasty bugs quite easily - it's really simple to base the fill value off of the username (first byte, first 4 bytes, whatever); add USERNAME=$(USERNAME) to the Additional Defines settings for the project.
This helps as a bug may be 100% reproducible on only one member of the teams build, and if looking at the memory you see their username, it makes it really clear what the problem is.

dooz
Saturday, June 19, 2010

We had a very related problem in a game I worked on; vectors weren't been properly initialized before being used (and we had a design decision to not have the default ctor init x, y, z to 0), and this could lead to both obvious and very subtle bugs.

We solved this by turning on floating point exceptions, and having a debug build ctor initialize the values to NaN, so if you tried to perform math on an uninitialized value, an exception was thrown. Kinda cool, and it helped alot.

Arseny Kapoulkine
Friday, June 18, 2010

Sorry for the accidental double-post, I hate F5 form resending

Yep, if you have virtual functions, initializing the whole class is a bad thing. However, the same can be said about members with virtual functions - i.e. you have to be careful when deciding what variables are ok to garbage-init. If you're going through this, you might as well, uh, initialize them in the ctor.

Anyway, I'm glad it works for you.

Arseny Kapoulkine
Friday, June 18, 2010

There is one thing about class layouts that drives me crazy. And this is changing your memory layout between builds. This leads to all sorts of weird "unreproducible" bugs.

Some compilers (gcc) allow you to declare a zero-size array member, though that's not portable.

Anyway, why do you need those markers? If that's a debugging feature, just work on the whole class.

Sascha
Friday, June 18, 2010

A very good freeware tool is Cppcheck. According to the documentation, it should also check for uninitialized variables.

http://sourceforge.net/projects/cppcheck


General
	News 3D Pictures Textures Articles Cool stuff
Other
	FAQ About Humus
Other 3D sites
	OpenGL.org GameDev.net Beyond3D Rage3D
Programming info
	OpenGL extension registry NeHe