Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 16 Nov 2010
Offline Last Active Apr 21 2016 06:49 PM

#5287628 Optimizing Generation

Posted by MarlboroKing 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 MarlboroKing 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 MarlboroKing 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 MarlboroKing 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 MarlboroKing 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 MarlboroKing 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 MarlboroKing 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.