Messages

16

General / Re: Game Speed Consistency

« on: April 15, 2014, 11:07:27 am »

Yeah, that's right. Even though I never saw a driver with vsync disabled globally, your remark is valid.

But I'm not sure whether we are talking about frame drawing rate limit or game loop iteration limit?
It's always the right way to make your game loop independent of time, like the article "Fix your timestep" suggests.

Reducing your drawing rate is only sensible if you have the program running on a mobile device, to prevent cpu load. For this, you could use an easy sleep(1), but don't let it sleep for more time! The more time you let it sleep, the more lag can be induced. See for example http://gamedev.stackexchange.com/questions/18898/is-it-safe-to-use-sleep-in-game-loop-on-windows or http://gamedev.stackexchange.com/questions/62273/what-are-the-benefits-of-capping-frames-per-second-if-any

17

General / Re: Game Speed Consistency

« on: April 15, 2014, 10:09:02 am »

An even better way to handle this is the vsync: http://www.sfml-dev.org/documentation/2.1/classsf_1_1Window.php#a59041c4556e0351048f8aff366034f61

Vsync is a driver option and therefore preferable over unprecise thread sleep operations.

18

General / Re: SFML QT Widget Problems

« on: April 15, 2014, 08:46:32 am »

As always, provide a minimal and complete example of your problem: http://stackoverflow.com/help/mcve
There is no point in guessing what possibly could go wrong with your code without seeing it.

19

SFML projects / Re: The 8-Bit Encounter

« on: April 14, 2014, 01:47:42 pm »

I think the title is fitting. The screens show 256 color palettes --> 8bit 

20

Window / Re: Unresolved External on changing Window Size

« on: April 14, 2014, 11:40:08 am »

added the .dll files

Those aren't the files you are looking for 

Try the .lib files.

21

General / Re: Can't compile test project

« on: April 11, 2014, 08:55:15 am »

And if it's a problem to compile SFML (which has one of the easiest compilation process; imagine other libs with dozens of dependencies), I wonder what other showstopping problems will occur...

It's better to take the time to try and learn those things. It will save you much frustration later on.

22

General / Re: How to find the Static DLL's?

« on: April 09, 2014, 01:31:04 pm »

Just why would you do that? It's possible by using LoadLibrary(), but this is a mere hack in my opinion. "Hiding away" is a very bad reason to do such things.

If you don't want any files other than your executable, you would have to choose the static libraries.

23

General / Re: Space Shooter AI Questions

« on: April 09, 2014, 08:46:25 am »

This isn't a SFML-specific question, but a short answer can do no harm 

One of the best ways for me to solve these problems is to look at other game's sources. Often, your problem is exactly one of their problems and they have a solution ready. So, just go to http://en.wikipedia.org/wiki/List_of_open-source_video_games and look for inspiration.

Apart from that, if it works for fixed sizes, why don't you increase those "logic window" size like going for 10 times or 20 times? Or is this what you already did and meant by "just go for open space"?

What's the problem / algorithm exactly, by the way?

24

General / Re: Running an SFML Game on other computers

« on: April 09, 2014, 08:39:55 am »

That's the way it works. Look at other games. Even the AAA-titles do it the same way.

The alternative is to install it to a central place like c:\windows\system32 | c:\windows\syswow64, where most of the other dlls are placed (e.g. the MSVC++ redistributable dlls like msvcp120.dll, msvcrt.dll, ...).
But that is also one of the central problems with dlls: These places should be reserved for vital system dlls and not some other files the user places there just arbitrary.
Under unixoid systems there is the nice separation of /usr/lib and /usr/local/lib that shows the difference.

So, go with it, just place them besides your files. For the MSVC++ redistributables, just include the appropriate installer with your game (and never include the *_d.dll files, as they are debug files and Microsoft doesn't allow them to be redistributed).

25

SFML projects / Re: d3d (Deferred 3D) - A 3D Engine Using SFML

« on: April 03, 2014, 11:12:40 pm »

The noise is a typical problem of path tracers, since they do random direction sampling for the GI (called Monte Carlo sampling). More samples would reduce the noise, but increase computation effort.
But in the video I think it's the codec that gets f**cked up by the noise. In realtime it is certainly less visible (my own [smaller ] pathtracer has the same problems: the output of the program looks great, videos are more difficult).

26

Graphics / Re: Issues displaying sprites after Xcode 5.1 update

« on: March 30, 2014, 12:47:41 am »

That's just the difference between declaration and initialization. A declared variable can be set to a default value like 0, but the standard doesn't enforce it. So it is best to initialize a variable explicitly instead of relying on some compiler's indivual behavior 

27

General / Re: Lag when assigning projectiles as elements in a vector

« on: March 04, 2014, 09:21:06 pm »

20 is nothing, perhaps. We can't say. You still didn't show the code for the class Projectile...

Did you do some profiling for your netbook? I doubt the bad performance depends solely on the projectile code. How does it run without projectiles?

Be aware that most netbooks are inferior to even old PCs regarding performance!

28

General / Re: Lag when assigning projectiles as elements in a vector

« on: March 04, 2014, 08:57:51 pm »

You left out one of the most interesting parts, the declaration of Projectile. Depending on the complexity of this class there can be an overhead.
Apart from that, std::vector isn't the best for fast erase, as all elements that are located after the erased element need to be shifted to the front. An alternative would be something like std::unordered_set, which has constant complexity for erasure and access.

How much of those projectiles do you have in your std::vector?

Try running the game in release mode on the PC, too! Debug mode has a really, really bad effect on runtime, especially for the containers of the STL, since there are some test made. It will be faster in release mode.

29

Graphics / Re: texture problem

« on: March 04, 2014, 11:28:56 am »

Just define a copy constructor for your Npc class where you update the texture. That would be a suitable solution.
(Just be aware of the Rule of Three/Five)

30

Graphics / Re: texture problem

« on: March 04, 2014, 11:05:27 am »

Why do you write the attribute access like

Npc::x = x;

instead of

this->x = x;

? The latter is much more readable and doesn't imply access to a static attribute. (Best would be different naming for parameters and members)
It is even incosistent, look at the setTexure() call in the Npc constructor 

Why do you repeat setting the texture rect if it stays at these magic numbers? Just do that in the constructor. And replace the for-loop with a for-range-loop.

The code is still too fragmented. Just try to reduce your code to a minimal full example.