Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 29 Jun 2004
Offline Last Active Today, 07:36 AM

#5236825 C++ Best Scripting Language

Posted by Rattenhirn on 25 June 2015 - 03:22 PM

The best scripting language for C++ is C++. It integrates perfectly and is very powerful. ;)

#5233326 Texture Atlas - Best practices?

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

Hi, I have very little experience with Unity, so I can't tell you what you options there are. I have, however, give some insights on your questions from a general point of view.


Firstly, there are only two cases where texture atlases can be beneficial nowadays:

1. Reduce draw calls. By combining textures into one, more things can be drawn with one draw call. This means that they draw calls also need to have the same render states, the same vertex and index buffers, the same shaders, and if instancing is not available, the same shader parameters.

Basically, when draw calls are completely identical, except for their bound textures, they could be combined, saving on some of the overhead. There are very few cases of this is actually the case, so you should go ahead and analyze your typical scenes to estimate what the possible gains are.

Also, when the platform has texture arrays or bindless textures, use these methods instead.

2. Reduce texture memory requirements. In most cases today, texture atlases actually will need more memory than individual textures. If you're targeting platforms that have limitations like only square texture, only POT ("power or two") texture dimensions or mipmapping only for POT textures, atlases can be beneficial.

None of the platforms have any of these limitations IIRC, definitely not PC.

Also, if your textures have already been manually combined by the artist, as shown in this image texture space is used very efficiently, so that can be beneficial. But there's no good way to do these automatically and it's quite difficult to get right manually as well. Those have the additional advantage of reducing draw calls as well.


Texture atlases have a lot of downside. They are a PITA to create and manage and they are prone to artifacts due to filtering and through mipmapping, so in my opinion they are rarely worth the effort.


On to your questions:

Ad 1. Modern 3D games won't use texture atlases at all, for the reasons given above. If they do, they make them as big as possible, limited only by hardware capabilities and actual needs.

Ad 2. Atlases are exactly like normal textures, so all limitations for textures apply to atlas textures as well, plus a few additional ones. I know of no recent platform that would require square textures or performance benefits for square textures. The performance hit that Unity might be talking about is, that when it encounters a platform with only square textures, it has to make all non-square textures square on the fly, increasing load times, memory usage and texture memory pressure. But a platform like that would be an ancient one anyways...

Ad 3. It's up to you how you organize your atlases. Remember, your goal is to reduce draw calls. You can put leave and trunk texture in separate atlases and use them in two draw calls, you can put them in the same atlas and use them in two draw calls, no difference in number on draw calls. The latter method _may_ save one texture switch, if the draw calls are sequential, but that would come with a render state and possible shader switch as well, so not much upside.

Or, you could put them in the same atlas and draw them in one call, using the semi-transparent settings. You save one draw call, but render the opaque part inefficiently and possibly with artifacts. Many options, none of them are easy wins. :)

Ad 4. Very few savings possible by grouping them. In addition, I guess these armor pieces might have different meshes anyways, so it's not possible to combine these draw calls in the first place.

Ad 5. Yes, things that are likely to be used by the same shader, vertex/indexbuffer and renderstates, and are rendered in sequence, so they can be combined. Not much usually fits that bill.


Here are a few things that come to mind where texture atlases might be beneficial:

- vegetation / grass

- particle systems

- crowds

- gui, menus and other 2d elements


In short, I think you'd be better off finding something else to increase performance. Did you do measurements? Are you sure that draw calls are your #1 performance killer? PCs nowadays can handle quite a lot of those with no problems...


I hope that helps!

#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.