Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Jan 2013
Offline Last Active Private

#5171148 Need Help with amortization formula

Posted by wintertime on 02 August 2014 - 12:01 PM

Why dont you ask your teacher (thats his job) how function parameters work, how return values are used, how to find descriptive variable names and how to translate a formula into a C++ function?

#5170281 Setting up GLFW in Code::Blocks

Posted by wintertime on 30 July 2014 - 05:27 AM

Why didn't you read http://www.glfw.org/docs/latest/build.html ? You need to correctly link all dependencies and you should not link both the static and the dll version of the GLFW library at same time.

And you better use the -l option for adding a library: https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Link-Options.html#Link-Options

#5168040 In need of some architecture help

Posted by wintertime on 20 July 2014 - 05:44 PM

You can let windows remember some data for you that you can retrieve inside the window procedure and cast back to the type of your window class.


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

Posted by wintertime on 20 March 2014 - 06:13 AM

 No really, they specified they are in twos complement, but the problem is the few types that applies to are optional: Exact-width integer types
1 The typedef name intN_t designates a signed integer type with width N, no padding
bits, and a two’s complement representation. Thus, int8_t denotes a signed integer
type with a width of exactly 8 bits.
2 The typedef name uintN_t designates an unsigned integer type with width N. Thus,
uint24_t denotes an unsigned integer type with a width of exactly 24 bits.
3 These types are optional. However, if an implementation provides integer types with
widths of 8, 16, 32, or 64 bits, it shall define the corresponding typedef names.

It would be nice if they just specified everything had to be twos complement and maybe even little endian, but they are supporting ones complement, sign-magnitude and big endian and keep a huge number of things undefined. Hopefully someday computers running ones complement, sign-magnitude or big endian need not be considered anymore.

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

Posted by wintertime on 18 March 2014 - 04:53 PM

I think the standards committee finally realized it was foolish to not make all types fixed size in the first place, because most libraries included Rube Goldberg Contraptions using the preprocessor to derive from a million compiler and platform specific defines its own incompatible version of fixed size types that end up being not the same size sometimes. Though in its extreme pursuit for compatibility they couldn't get themselves to just say short/int/long/long long are now always 16/32/64/128 bits, but had to add a few dozen new types. And the most useful fixed size versions are not guaranteed to be there, only the fast and least versions that are near useless, so people will still not use them and can enjoy using 100 types per program for a few decades longer. rolleyes.gif

#5139311 Need help: a vector of different extended classes

Posted by wintertime on 15 March 2014 - 03:45 PM

Contrary to what the other people said, the simplest solution is to not throw all entities into one vector only to later having to check their type through virtual calls.

The point of templates is that they know the exact type:

vector<EntityArrow> arrows;

Btw., if you create a large hierarchy of classes derived from Entity you'll probably discover later that it leads to problems. You'll be tempted to duplicate some aspects or move unrelated things up in the hierarchy where they not belong, because not all objects can be categorized into a regular tree. Better to avoid that from beginning and use composition instead of inheritance.

#5139306 How to efficiently divide files up?

Posted by wintertime on 15 March 2014 - 02:42 PM

You can download LibreOffice Calc for free and use that, no need to use Excel. I think the easiest format to read in a simple table is csv, no need for xml in that case.

#5138179 Function Pointers in Structs

Posted by wintertime on 11 March 2014 - 01:23 PM

As I see it, if you decide to use C you should do it only if you want to avoid being tempted as easily to create overcomplicated OOP-isms. If you want OOP you can spare yourself from emulating it and just switch the compiler to C++ and be able to use all those goodies like function overloading, namespaces, destructors, std library, exceptions and so on.

The example looks like its doing no useful work (I guess its cause of being a quick example only); theres no need for useless getters with function pointers for such a simple struct.

In C I think a functional style without structs would make more sense:

float calculate_whatever(int a, float b);

Or with the struct:

typedef struct {
  int a;
  float b;
} MyData;

int main() {
  MyData data={.a=1, .b=3.141f};

  float f=mydata_calculate(&data);
  // ...

Though if you plan on allocating many of those structs think about using SoA style and providing functions for looping over whole separate arrays.

#5124378 the public syndrome

Posted by wintertime on 17 January 2014 - 07:04 AM

If too many places in your code want access to some things, you should not make it public, but think about changing the design to decrease that number to the minimum. You should not intermingle input and processing of data in such a way that you "have to read the mouse click while checking if i have a menu/tooltip/mouseover open", as you can easily read input and then distribute the data where its needed.

Btw., getters and setters are not much better that making everything public. Its better to try following the "tell, dont ask" principle and only get/set if there is no other way around it. That means instead of inspecting the private parts of an object, then deciding outside the object, then changing it, you just call a method on it to let the object do what you want from it.

#5118172 PUTT People's Choice Award and Comments

Posted by wintertime on 19 December 2013 - 11:45 AM

I'm sure its just people have much to do and did not remember, but the given extended timeframe is now overdue since more than a month. One reason I joined this was receiving some feedback and I'm honestly a bit sad.

I'd think all participants would like getting to know some result. Could we expect this for christmas by any chance?

#5117806 When to Implement Game Loop

Posted by wintertime on 18 December 2013 - 05:13 AM

How are you implementing you game without a loop? In pretty much every game there are things that need to be repeated (even in text games), so how are you doing that now? goto? I don't even understand how you could make a game without a loop of some kind. Even an event driven game has a loop (it may be hidden from you but it's there).

There are always loops. IMHO, a typical beginner game is often just structured around the game logic with many different loops and many different ways to get input, like this simplified pseudocode:

int main() {
  wait_for_keypress(); // first loop hidden there
  string answer;
  while(1) { // next loop that repeats each time a new game is started
    while(first_scene) { // next loop that repeats in same game state
      do { // next loop that waits for acceptable input
        answer=input_text(); // loop hidden here to collect chars
      } while(!text_validated(answer));
      int number;
      do { // next loop that waits for acceptable input in a different way
        number=input_number(); // loop hidden here to collect chars and only let numerals through to convert them
      } while(!number_validated(number,lower_bound,higher_bound));

      // many more loops here
    // many more loops here
  wait_for_keypress(); // another loop hidden here

Then sometime later they hear about the game loop and hopefully do the mental leap to realize its just a simplification, by turning this mess inside out, cutting out all those hidden repetitions of slightly modified output, input, validations, loops and replacing it with just one loop and some conditionals inside.

#5114640 Something I've noticed

Posted by wintertime on 05 December 2013 - 11:02 AM

Yeah, OpenGL1 may sometimes be convenient for prototyping something, but for serious programming its way too old. At least step up to OpenGL 2.1 and ignore all superfluous ancient cruft that got cut out for that reason in OpenGL ES 2.0 or OpenGL 3.x, since that avoids wasting time learning about the indexed color mode, glBegin+associated things, display lists, the fixed function stuff with uncounted different function calls, contrived texture combiners and so on.

#5114573 Im being haunted by my dreams!

Posted by wintertime on 05 December 2013 - 07:23 AM

gcc 4.7.2 has almost complete C++11. Why dont you just add -std=c++11 option to activate it?

#5114572 Multiple selections under one button

Posted by wintertime on 05 December 2013 - 07:14 AM

Why dont you just draw the fleet markers at different places inside the larger circles around the stars to enable the player to see there is more than one and click a single one?

Or just show a fleet list when there is more than one and then require another click to choose one fleet from the list, if there is more than one?

#5114294 Should I make my game engine cross platform?

Posted by wintertime on 04 December 2013 - 06:06 AM

If you pay some attention to stay crossplatform from the start its probably not more difficult. Just restrict yourself to only use libraries that are crossplatform already (may even save on time when selecting a library by cutting down on choices) and in the rare case there is none wrap the platform dependent calls yourself (possibly write those wrapper only for one platform at first) and only use the wrapper (I doubt you would loose much performance from this). Then with some luck porting may be as easy as providing another implementation of your thin wrappers and adapting the build system to use some other compiler (you should not have used compiler dependent things).

If you instead build your game on OS-dependent calls and put those everywhere in your code, you will be out of luck later and have to tell everyone porting is not feasible/too expensive/too much effort.