Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jun 2004
Offline Last Active Today, 03:37 AM

#5233162 Malloc/Calloc question

Posted by Rattenhirn on 06 June 2015 - 10:32 AM

Your friend is right. Free will not work correctly on anything but the addresses provided by malloc/calloc, with the exception of NULL.

#5227971 "simple" equation confusion (a - b = c)

Posted by Rattenhirn on 08 May 2015 - 09:53 AM

I think you made an error substituting the variables with your values:

The first case:

A - B = C -> 15 - 5 = 10


A = 15

B = 5

C = 10


The second case:

B = A - C -> 10 = 15 - 5)


A = 15

B = 10

C = 5


Can't make any sense! ;)

#5210789 Modern C++ Book?

Posted by Rattenhirn on 15 February 2015 - 02:26 AM

Effective Modern C++ by Scott Meyers

#5167376 What's the next step after LZ77?

Posted by Rattenhirn on 17 July 2014 - 05:54 AM

If you're looking for speed, I recommend LZ4 (http://en.wikipedia.org/wiki/LZ4_(compression_algorithm)), if you're looking for high compression LZMA is pretty much the best freely available algorithm (as stated above). If you want a good trade off between those, zlib is still pretty competitive.


If WinRAR is faster than your LZ77 implementation, then your LZ77 implementation is very very slow.

#5138060 Pointer confusion

Posted by Rattenhirn on 11 March 2014 - 03:54 AM

One more note, making by value parameters (like the pointer pD3dscene and pLightingEffectId in your example) const does not really give you any benefits, because the values are copied anyways.


But it's a matter of personal preference really...

#5137937 Pointer confusion

Posted by Rattenhirn on 10 March 2014 - 04:02 PM

In your case, all the pointers point to a const object, meaning you can't change the object through that pointer. You can, however, have the pointer point somewhere else, as is evident from the assignment of mD3dscene.

If you want the pointer itself const, you have to put a const after the *.

int * ptr; // non const pointer to non const object
const int * ptr; // non const pointer to const object
int const * ptr; // non const pointer to const object (same as above)
int * const ptr = something; // const pointer to non const object
const int * const ptr = something; // const pointer to const object
int const * const ptr = something; // const pointer to const object (same as above)

I think these are all cases and I hope that helps!

#5133831 data compression

Posted by Rattenhirn on 23 February 2014 - 05:55 AM

data compression means to move data from the space dimension to the time dimension...

From Wikipedia:
"Lossless compression reduces bits by identifying and eliminating statistical redundancy."

So nothing is moved between dimensions, whatever that might even mean in this case.

Maybe you try to space/time trade offs that are often the case with CS algorithms, including compression. For instance, a better compression rate will typically take a longer time. So by spending more time working on the data one can save space or, vice versa, by using more space, one can cut down the processing time.

Is this what you mean by any chance?

#5133793 data compression

Posted by Rattenhirn on 23 February 2014 - 03:44 AM

I recommend you watch this video, it gives a good and easy to understand introduction:

After that you can find more detailed videos on the same channel.

#5129807 sizeof() behaviour with inner classes (MSVC12)

Posted by Rattenhirn on 08 February 2014 - 05:58 AM

Just to clarify, this doesn't have anything to do with the inner class.

Next time you make a comparison, only change one thing at a time and the result will be less confusing! ;)

#5107953 DXT Compressor Type performance

Posted by Rattenhirn on 08 November 2013 - 04:03 PM

I had some time to dig up the info on the compressors as well, read this for lots of info:

#5107942 DXT Compressor Type performance

Posted by Rattenhirn on 08 November 2013 - 03:31 PM

It will have no impact on the performance of your game whatsoever!

#5090835 8 bit textures in DX9

Posted by Rattenhirn on 01 September 2013 - 12:51 PM

P8 is for 8 Bit texture with palette, which is unlikely to be supported on modern GPUs. As the previous poster said, you want L8. L stands for luminance.

#5068414 Why does a gameplay programmer need to know C++?

Posted by Rattenhirn on 09 June 2013 - 08:21 AM

A couple of comments:


Firstly, many companies or teams do not distinguish sharply between gameplay programmers and other programmers. The skillsets overlap too much to make that a useful distinction anyways. It's rather an affinity towards certain kinds of problems.


Secondly, scripting languages are usually only available for very specifc domains. Like the GUI, AI scripting or cutscenes. And they are supposed to be used by non-programmers. The reason you can script everything in engines like UDK and Unity is that they do not like giving out the source code or native APIs, making scripting pretty much the only option.


Thirdly, there's nothing wrong with knowing C++. I'd say, it's probably one of the most useful programming languages to know, even if you don't use it, as it gives a lot of insight into how programming languages do things and what the costs of certain features are.

#5064724 Is it alive? No. But wait... Yes!

Posted by Rattenhirn on 25 May 2013 - 03:11 AM

Nice, I wonder how "isDead" is implemented though...

#5053139 c++ delegates, evil method?

Posted by Rattenhirn on 14 April 2013 - 07:26 AM

Hello all, been a while, I'm working on this project for a university assignment and I would really like
delegates in C++ haha, so I came up with something in a side test project and I'm pretty sure its
evil, could someone explain to me what could happen if it is in fact evil (ignoring the usual errors that could happen)


Delegates per se are not evil. There are plenty of implementations out there, with various pros and cons.


Your particular implementation has a pretty nasty fault, that's also very easy to spot: The c-style cast to "handler_t". Pretty much anything can happen at that point. From compiler errors to obvious runtime errors to subtle runtime errors.


As a general rule, when programming C++, stick to static_cast and dynamic_cast. When interfacing with legacy code or low level, use reinterpret_cast and const_cast. Never ever use c-style cast, especially if you only put it in there to shut the compiler up.