Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Oct 2012
Offline Last Active Jul 11 2014 04:55 PM

#5041491 When to start with C++?

Posted by on 10 March 2013 - 07:01 AM

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.


And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

#5041488 Tiled games

Posted by on 10 March 2013 - 06:48 AM

While the guide is quite nice, a lot of it is theoretical, not practical.


OP - the most common solution to this is called a Quadtree. Basically, as you add objects to the screen (whether colliding map tiles or other actors), you continue to divide the screen up into continually smaller regions, each containing at most N number of objects; so that, whenever you check collisions, each object only has to check collisions with N other objects. This is exponentially faster than checking the entire grid.


http://veeableful.wordpress.com/2012/02/07/algorithm-space-partitioning-using-quadtree/ <-- This guy wrote a pretty good C++ quadtree-based space partitioning lib in C++ to support what he was working on, and put it up on github. There is a decent description of the technique, with a link to a much better description, to get the technical details. If you just want the code, skip down to the Github link for the C++ version without SFML.


Happy trails.

#4990034 ubuntu SDL not outputting stdout.txt/stderr.txt or showing terminal window

Posted by on 14 October 2012 - 08:02 AM

On posix systems, SDL does not create stdout.txt and stderr.txt; those are purely Windows conventions. On posix systems (e.g. ubuntu), if you run your program directly from the terminal, you will see output in the terminal, instead of in those files.

For example:

akesterson@localhost:~$ cat printer.c
#include <stdlib.h>
#include <stdio.h>
int main(void)
		fprintf(stdout, "This is output.\n");
		fprintf(stderr, "This is an error.\n");
		return 0;
akesterson@localhost:~$ gcc -o printer printer.c
akesterson@localhost:~$ ./printer
This is output.
This is an error.
akesterson@localhost:~$ ./printer > stdout.txt
This is an error.
akesterson@localhost:~$ ./printer > stdout.txt 2>stderr.txt
akesterson@localhost:~$ cat stdout.txt
This is output.
akesterson@localhost:~$ cat stderr.txt
This is an error.

... If you want stdout.txt and stderr.txt, you'll have to manually redirect them. POSIX default behavior is that both output streams go to the terminal running the program. If you're not seeing this behavior, it's likely a result of the IDE you're using, and how it's launching/consuming the output. If you go to the directory with the compiled binary, and run it by hand, you should see the expected output in your terminal.

#4990031 Hiding SDL from the rest of the program

Posted by on 14 October 2012 - 07:38 AM

FWIW, I had the same issue when trying to add a controller mapping class to my game engine (which backends into SDL). Upon spending numerous hours trying to wrap SDL's already well-wrapped event pump functionality, I decided that trying to wrap SDL was pretty silly and not very fruitful, so I just exposed it. I figure SDL has already encapsulated things about as well as I could hope to anyway, and putting any kind of wrapper around SDL's functionality, when not 100% necessary, would only serve to muddle my API.

Your mileage may vary.