Messages

181

General / Simple Image Encryption

« on: March 20, 2012, 10:00:53 pm »

To be honest, encrypting images like this is relatively pointless: If people want them, they'll get them.
They'll take screen captures of the game and copy them out of that.
They'll decrypt the files by looking at the exe structure and figuring out the encryption key.
They'll just copy the graphics style and make their own.

It's pointless to stop the signal.

If you want to make it so the layman can't just copy and paste and at least has to do a couple of minutes work, compression is the better way to go.

Packing everything into one big zip file and loading them from that is a common trick that's been around since before Doom (WAD files). Plus being able to keep everything close to each other in the hard drive by packing it all into one file can help to improve performance and has some other benefits regards to making, sharing levels etc.

182

General discussions / Do you use C++11?

« on: March 11, 2012, 12:07:40 pm »

huh, interesting. I though the implementation basically did

template<typename T> struct function { };
template<typename R, typename A, typename B> struct function<R (A,B)> : real_function<R, TYPELIST(A,B)>
template<typename R, typename A, typename B,typename C> struct function<R (A,B,C)> : real_function<R, TYPELIST(A,B,C)>
template<typename R, typename A, typename B,typename C,typename D> struct function<R (A,B,C,D)> : real_function<R, TYPELIST(A,B,C,D)>
...

and so-on in that matter for a silly number of implementations. Maybe I'm thinking of Loki or something else but this is definitely a way it can be simulated...

Either way, my point that it's all made infinitely simpler and cleaner looking by variadic templates remains

183

General discussions / Do you use C++11?

« on: March 11, 2012, 11:12:16 am »

Not quite. They can be emulated with preprocessor macros (and they are, at least in Boost.Function).

I think the actual implementation uses variadic macros but I thought it wrapped them inside a huge set of template specialisations (generated by script) to hide them from the end user since they look silly ugly compared to the very clean implementation variadic templates give you. Macros are the last resort of last resorts in C++ so not having to use them is sweet

184

General discussions / Do you use C++11?

« on: March 11, 2012, 10:12:29 am »

Yes yes yes

Variadic templates are amazingly powerful and the only way to emulate them pre-C++11 is via generating code with scripts (how boost::function was written....a lot of partial specialisations generated by scripts).

static assertions are rather useful.
 Actually having access to a random number generator other than the horrible rand is silly useful.
Rvalues rule.
constexpr rules.
auto is useful for those massive names.
Lambda functions and std::function make everything more flexible.
std::sto... I use but it's hidden behind a templated function that uses a functor to specialise to the correct std::sto, to_string or if all else fails string stream. Kinda like boost::lexical_cast.
Smart pointers..I could go on for awhile actually.

185

General / Event-Handling ONLY in Console

« on: December 10, 2011, 04:34:54 pm »

You can do this with the Windows API too either by hooking up using the window handle (GetConsoleWindow and SetWindowsHookEx) which let's you treat the console window exactly like any other or using Console Input Buffer.

GetConsoleWindow: http://msdn.microsoft.com/en-us/library/ms683175(VS.85).aspx
SetWindowsHookEx: http://msdn.microsoft.com/en-us/library/ms644990(VS.85).aspx

Console Input Buffer: http://msdn.microsoft.com/en-us/library/ms682079(VS.85).aspx

I did once create an abstract window system that had implementations that worked using ncurses, the windows API or SFML to create/simulate a console window with events and such but that a few years ago and I doubt I still have the code lying around...

186

SFML projects / SFGUI

« on: November 02, 2011, 10:06:28 pm »

nullptr is in the latest versions of GCC starting with GCC 4.6, http://gcc.gnu.org/gcc-4.6/cxx0x_status.html

You can grab the build for windows at http://nuwen.net/ if possible ^^

187

Window / read input from file

« on: September 26, 2011, 10:04:23 am »

the map of course allowing constant time lookup

Searching in a map is O(ln(N))

Yeah, it's a tree search and pretty fast but it's not constant time. If you want constant time lookup then there's always a hash map (std::tr1::unordered_map or boost::unordered_map).

188

Graphics / VSync does not work properly!

« on: September 10, 2011, 01:06:42 am »

Vsync is more a graphics card prompt, not an enforced guarantee. You can have your card set to ignore it, enforce it even when the game doesn't say to and different cards are gonna handle it differently. Is it possible some of these 'problems' are just due to the graphics card not handling vsync how you'd expect or how it should?

Or the "timer" is somewhere ticking over or overflowing somewhere and that could be causing problems? Sometimes I'm tempted to give up and just label a bug as "rounding errors" xD

I guess the only way to tell would be to do tests with vsync turned on with a bunch of different libraries and compare-and-contrast :S Allegro5 is probably a good place to start for a quick-to-set-up check xD

189

SFML projects / Goal and rules of this forum

« on: September 08, 2011, 05:59:25 pm »

If things get to a state where people are posting projects with too little information, it's not unreasonable to have minimum requirements for posting a project or at least "recommended guidelines".

Like "Must/should either have a video or four screenshots if no demo, or a video or two screenshots if it comes with an executable".

190

System / Using threads to load stuff

« on: September 08, 2011, 05:42:36 pm »

Also it's probably best to declare that bool as volatile. Otherwise when you compile the Release build using the highest levels of optimisation the compiler may optimise it out and you enter an endless loop, since in a single threaded environment that would be a completely apt optimisation.

Even languages that seem pretty well geared for multithreading don't seem to have compilers thread-aware enough to avoid those kinds of optimisations without prompts from the programmer.

And don't set the bool to true in the actual loop, either do it before the thread starts or wait for it to become true before you start looking for it to become false. There's no guarantee the OS thread scheduler won't screw you over and have enough of a nanosecond delay that the while won't be checked before the bool is assigned.  It's the kind of bug that could happen 1 in 100 runs and is why multithreading, even the simple stuff, is considered so difficult: It's so easy to do something that seems like it would work, and does in 95% of cases, but will fail at seemingly random times.

191

SFML projects / Asteroids!

« on: September 06, 2011, 03:17:55 am »

I think I saw a video of a project to do similar but used procedural content generation. Basically it made worlds that looked like:
http://libnoise.sourceforge.net/examples/complexplanet/index.html

The video was of a ship in space flying down up to the planet's surface. The idea was eventually to be able to fly from world to world, go to space stations, land on the planets etc.

Dunno what became of that project or if it's still going...

192

General / New to SFML, game design questions

« on: September 06, 2011, 02:31:32 am »

SFML does not provide a scene graph. It's a 2D rendering library, any optimisation a complex scene graph can provide is going to be nothing short of overkill in 99% of cases and may even introduce unneeded overhead in that 99%.

Though don't quote me on this but I believe Laurent has been trying to find a "Sprite Batch" design that satisfies him and renders sprites in batches in a more optimal manner.

Basically instead of
Window.Draw(Sprite1);
Window.Draw(Sprite2);
Window.Draw(Sprite3);
Window.Display();

You could do something like:

Window.Begin(SpriteBatch);
SpriteBatch.Draw(Sprite1);
SpriteBatch.Draw(Sprite2);
SpriteBatch.Draw(Sprite3);
Window.End(SpriteBatch);
Window.Display();

And the SpriteBatch would sort them based on the settings passed to it and render more optimally.

Which is, incidentally, basically how XNA does 2D (though XNA doesn't provide a scene graph system for 3D either, that's the coders job).

193

General / New to SFML, game design questions

« on: September 06, 2011, 12:06:32 am »

Switching texture would most likely not cause a hit,, or at least I can't think of a reason it would.

Changing things like position and rotation maaaybe? Depends how SFML implements them.

I'd have to delve into the way sprites work but these changes would most likely require the sprite's transformation matrix to be rebuilt and using multiple sprites could limit that penalty to only when each object changes position/rotation/etc. instead of for every drawing always no matter what, assuming the matrix is only rebuilt when changes are made.

When keeping a local copy of the sprite, the "worst case" scenario (everything moving every update) wouldn't be any different but if you have a tick with something stationary, then there may be extra and unneeded work being done there. But since you're gonna be at that worst case scenario or close to it most of the time, probably not be something you notice.

Of course it could be said reusing the Sprite like that defeats the 'purpose' of the Sprite class, which I believe is for defining separate "entities" in the worldspace ^^

194

General / New to SFML, game design questions

« on: September 05, 2011, 10:08:55 pm »

You could use an id system or a flat pointer or some sort of iterator-reference, either way basically the same system and for efficiency sake the pointer or iterator to a ShipType object works better.

As for multiple sprites, well if you change one sprite you change it for all the  sprites so a local copy for each ship probably would work better. And since the sprite contains the texture, you could have the texture in the "ShipType" too or even hide it behind some "CreateSprite()" function that returns the default sprite for that ship type.

Of course that approach does spread SFML's code into multiple places around your program and whilst that's not always a bad thing, it does mean a significant change to the SFML API mid-way through development could be a bit annoying to patch so there is the argument for ease-of-management. Also it'll be more effort to replace in case suddenly SFML isn't good enough for you ^^

You could give each class it's own "Position", "Angle" etc. properties to use to figure out the sf::Sprite and draw it in the renderer.

It's a matter of what you think the ship needs to know and how you think it needs to know it. Though I'd have a constant reference to the ShipType object or hide all it's members behind "Get_X()" functions or have them all internally constant, not a flat pointer, simply so it's clear the information about different ShipTypes cannot be changed by the Ship.

At the end of the day, the best advice in coding is: do what works.

195

General / New to SFML, game design questions

« on: September 05, 2011, 07:54:47 pm »

I considered creating some kind of "enum ShipImage", but that idea seems even worse than the Ship having an sf::Sprite in the first place....

Breaking things down like this isn't an uncommon way to go about things ^^ Most programs can be broken down to databases at the end of the day, it's not an uncommon or ineffective starting point for designs by any means to treat them as such.