Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Nov 2010
Offline Last Active Sep 11 2016 11:35 AM

#5310186 C++ Going Beyond Basics

Posted by on 09 September 2016 - 08:04 PM

If you don't know programming, C++ is a terrible language to learn. I would start by learning a friendlier language first. Python is often suggested for this purpose, but I don't think there is anything wrong with learning C, for instance.

I think you have the right idea in trying to find projects that motivate the learning of different concepts.

Beyond input and output, try to learn:
* Loops (make a multiplication table)
* Fancier loops (test if a number is prime by trying to divide it by trial division)
* Functions (learn to organize your code in understandable chunks with a good name and a clean interface, provided by the parameters and the return value of the function)
* Data structures (things like arrays, lists and trees; but the details depend on the exact language you are working with)
* File I/O (process a text file and count how many characters, words and lines it contains)

C++ is a GREAT way to start coding. You learn about how a program behaves, instead of being stuck by rules. Once you understand how a program works, the rest is syntax.

Sure, memory manipulation, stricter syntax, no safety nets, etc. But, it's best to learn WHY you need to do /that/ instead of being told "its bad".

I always recommend starting with C or C++, then understanding the basics of x86/x64 Assembly. Seeing how a program works, is far better than being told "it works".

Edit: To the OP. Have you done classes and inheritance? The cpp standard? STL? Win32/x11? There's far and far more to learn. Master what you know now, then move on. I highly recommend learning the cpp standard first. Then move on to the area you like (sound, opengl/directx, vulkan, etc), api programming, so forth). Learn to structure code throughout files. Can you write a number guess game via std::cout? Try that. Then move on.

#5287628 Optimizing Generation

Posted by on 19 April 2016 - 10:57 AM

Constant allocation and deallocation is a big no, for something this big.

It appears for every single block, you're new'ing and delete'ing. If you're aiming for world modification, shifting, etc. - create your initial data structure at once, then assign the block types.

Yes, new'ing each block works, but if in one scene you have 8,000,000 blocks, that's a lot of allocation and deallocation. But 8,000,000 new operations, and, let's just say, 400,000 delete operations, it's just flat overkill. Eg;

if( someCondition ) {
blocks[myIndex].nType = BlockTypes.AIR;

Also, I'd say use a 1D array instead of a 3D array.

#5236487 what really get and set do?

Posted by on 23 June 2015 - 09:52 PM

Here's another approach:
public String CharName { get; private set; }

Which allows public return, but prohibits assigning outside the class.
Get/Set is just a quick 'macro'. It basically points to a data type in a class/struct.

#5139755 Exactly what's the point of 'int32_t', etc.

Posted by on 17 March 2014 - 12:07 PM

I see very little point of using the 'int32_t' compared to 'signed int'. The project irrLicht actually shows one valid example for it in .\irrTypes.h:

#if defined(_MSC_VER) || ((__BORLANDC__ >= 0x530) && !defined(__STRICT_ANSI__))
typedef unsigned __int64            u64;
#elif __GNUC__
#if __WORDSIZE == 64
typedef unsigned long int           u64;
__extension__ typedef unsigned long long    u64;
typedef unsigned long long          u64;

MSDN writes little about the 'fixed size' data types it supports, such as __int32:
"The types __int8__int16, and __int32 are synonyms for the ANSI types that have the same size, and are useful for writing portable code that behaves identically across multiple platforms" -- Great, it's "ANSI principle", I suppose.


I guess my point is; why does MSVC declare the data types prefixed with "__" a fixed size, yet \most\ other compilers determine the globally used "int"(etc.) as a fixed size? Is there any scenario that I should dread about a non-fixed size integer?


Edit: I am aware that 'int' on a x86 build is 32 bits, yet should be 64 bits on a x64 build.

#5019519 Is it such possible to create fast games without using C/C++ ?

Posted by on 09 January 2013 - 10:57 AM

All that can be said is you can write an equivalant game in a different language, with the same speed.

That being said, it all comes down to how it was coded. You can write a fast game in C# or Java if coded correctly, and a bloated slow game in C++.


There are reasons why others like the language they chose. So in the end, it's what you're most comfortable with. Unless you are going for industry, learn what you can on everything!

#4922081 Whats wrong with java?

Posted by on 14 March 2012 - 04:53 PM

Laziness has little to do with it. People have a fairly universal limit on the number of things they can juggle at any given time. The less cycles you're wasting tracking bullshit the computer could do for you the more you can spend on the problem at hand.

Why should a language "protect you from yourself"? That's the advantage of C++ that Java and C# will never see. Also, no matter what language, clock cycles are still being used to free the memory allocated which takes away from your game. But if you want to talk about bullshit tracking, Java's easiest solution for memory leak detection is a seperate program, 7 steps, 2 runs, dumping the stack each run, loading dumps and comparing. C++ is 1 header, 1 define, 1 function and usually 1 run and it'll tell you what function and even what line. That's not including the time spent debugging and testing the fix because that'll usually be same same on either language.

No matter what language you choose, there are positives and there are negatives. Don't assume C++ is better than Java and don't assume Java is better than C++, they both have their pro's and con's that smash eachother into a practically equal state. Choose what you are comfortable with and/or would be the best solution for you.

#4921731 Outputting data to a log file

Posted by on 13 March 2012 - 01:45 PM

void CLog( const char* szMsg, ... ) //Own, custom function


    if( g_CLog_bInitialized )


        char szBuffer[512] = { 0 };

        va_list vaArgs;

        FILE* pFile;

        va_start( vaArgs, szMsg );

        _vsnprintf_s( szBuffer, sizeof(szBuffer), szMsg, vaArgs );

        va_end( vaArgs );

        fopen_s( &pFile, "MyLog.txt", "a+" );

        if( pFile )


            fprintf( pFile, "%s", szBuffer );

            fclose( pFile );




#4894050 Writing a game engine

Posted by on 14 December 2011 - 07:56 PM


You only missed the part where 'game engine' has a very exact definition.

If you asked 50 people how the earth was created, you'd get many different theories, but not always a specific answer - it's the same with what defines a game engine. Yes, it needs to be able to be reused, yes it needs to do some, or most, of the work for you. That's the base to every engine. But, my primary point was to help guide him off the tracks that some have seemed to try to rail him onto on a engine needs <this>, a engine needs <that>.

I've seen, and used, engines that are just graphics/animations, which are engines. But to some, are not. Which brings me back to my first sentence: you may get a completely different theory yet you'll always hear that the world is round and people live on it. Saying "Oh, God created the earth and anyone who says he didn't is obviously a moron" is driving onto a one-way street. (Not saying you are saying that, just an example. :] And no, I'm not saying God did or did not create the earth, let's just leave it like that.)

I'm sorry if my sentence seemed like I said "Yeah, you can just make a function that calls CreateWindow(..) or Direct3DCreate9( D3D_SDK_VERSION ); and bam, you got a engine", that was defiantly not my intention.