Messages

46

General discussions / Re: Which is ideal choice among Unity and Unreal engine 4 for SFML developers ?

« on: June 22, 2017, 07:44:51 pm »

Doesn't matter then, considering both change concepts. UE4 offers visual scripting and C++, while Unity offers C# and JavaScript. Besides that, I'd pick them based on licensing terms and what they ask from you. Personally not a fan of Unity due to their fixed 100 or 150$ per seat per month requirement, while UE4 "only" asks for 5% of your revenue no matter how much you make.

47

Graphics / Re: sf::Text displaying square

« on: June 22, 2017, 12:15:44 pm »

The line break is a character you'll receive as sf::Event::TextEntered, but it's not printable (therefore resulting in the square box).

48

General discussions / Re: Free C++ Game Dev Book using SFML only Today!

« on: June 22, 2017, 11:38:51 am »

"I still don't understand why the author/editor decided to use colored images in a black and white book"

because they look great in the pdf version
probably look good in the kindle version too

"too many code snippets are either badly formatted and don't fit properly on the page"

boo freaking hoo 
so the code takes up more than one page
get over it

Well, I'd say this is something the publisher should take care of, e.g. to make sure it looks good in any common format.

"on the other he sticks with std::rand, ... no notion of gaussian or any other *actual* distribution."

who cares ?

in 99% of games it will not matter

I think it's a valid point. A whole book dedicated to generating stuff based on random numbers should at least dab a bit into the basics and explain the "why".

that criticism is like putting down an SFML book because it doesn't show fixed delta time and integration

This heavily depends on what the book wants to teach you. I'd expect it in a book about basic game design, but it would be off topic in procedural content creation.

49

General / Re: Android NDK - SFML-Example Build Error

« on: May 10, 2017, 03:46:21 pm »

Looks like you're mixing architectures. The SFML example by default builds for "armeabi-v7a", not "armeabi". As an alternative just build and install both.

50

Graphics / Re: Why does RenderTarget class not declare the display() function?

« on: May 08, 2017, 09:13:24 am »

It's just a design thing I guess. A render target doesn't have to know when it's "done"  (think unbuffered rendering).

I think the problem here is the fact that you're trying to create a "drawable", just not the way SFML wants you to do.

So rather than calling something like `yourObject.draw(renderTarget);` in your code, you're supposed to call `renderTarget.draw(yourObject)`.

The latter can be achieved by subclassing `sf::Drawable`. There's nothing wrong in making this your "super draw everything class".

As an alternative workaround – if you insist on your interface – you could just overload the method called, once for `sf::RenderTexture*` and once for `sf::RenderWindow*`. This also works for a constructor, just make sure to store which subclass of `sf::RenderTarget` you actually received.

51

General / Re: Android NDK - SFML-Example Build Error

« on: May 08, 2017, 09:02:25 am »

Still haven't found any time to look into this, but guess NDK r12 changed something that somehow breaks the build scripts in some odd way.

Have you tried using version 11?

52

General / Re: SFML License Question

« on: May 07, 2017, 09:30:05 am »

If a library you want to use is LGPL you can release your program under any other license you want as long as third parties could (in theory) replace that LGPL library with their own version. It doesn't impact your own work, unless your own work is a modification on the LGPL code.

53

General discussions / Re: Mastering SFML Game Development (n-th SFML book?)

« on: May 07, 2017, 09:15:38 am »

I know the ground looks a bit tiled, and that's simply because auto-generating normal and specular textures for tile-maps is a bit painful, and usually leads to hard edges.

While haven't tried it, create a new texture using the tiles in a 3x3 tiled pattern. Generate your normals, then just copy the central piece and use that one.

54

Feature requests / Re: Vulkan Support

« on: May 02, 2017, 04:01:45 pm »

If the option isn't there, and the program requires efficiency, SFML wouldn't be an option.
My game requires an insane amount of efficiency to run bigger levels, as there is no direct limit to entities, level size...
So that efficiency would be nice, assuming the fact that I could code it (I don't know if I could do multithreading well -but assuming I could, it would be amazing).

You missed the point of Vulkan. Vulkan is fast, because it allows you to specifically do what you need. There's less overhead.

However, if you implement it in a generic way, i.e. the way SFML does, it won't be significantly faster than OpenGL (which also implements many things in a generic way). SFML can't know what you need and what's best for your program. So even if SFML would offer a Vulkan implementation, you probably wouldn't profit from it in any significant capacity. If you want Vulkan for efficiency reasons, you'll have to access it directly.

55

SFML projects / Re: Super Mario improved

« on: May 02, 2017, 02:51:13 pm »

Well, that isn't that bad. Worst part for me are the sometimes inconsistent controls. You suddenly stop moving or jump higher than expected and similar things.

Code wise there are a few cosmetic issues, like unused variables or ambiguous empty branches, etc. which are all listed by Visual Studio.

But what's more important I'd say is you should look into finite state machines and how you can use them to implement multiple screens or game states without having to duplicate code.

Right now you've got several places in the code that draw a different screen, refresh it, handle events, etc. Using a proper state machine you'd only have to clear the screen and decide what's happening in one place, which might clean up quite a few things.

Also worth mentioning, you should try to keep file names short, consistent and meaningful. For example, rather than having a "main file.cs" use "main.cs" or "options screen file.cs" should be "optionscreen.cs".

56

General / Re: Firing is inconsistent despite using time

« on: May 02, 2017, 11:57:04 am »

You're not taking into account instances where the time passed is not just exact for one shot.

Let's assume you're allowed to shoot once every 10ms.

So VSync is enabled, your time between frames is 16.67ms. Using this approach, you're firing just once every 16.67ms. If one frame is slower, like 22ms, you're still only firing one shot, despite being able to fire two shots.

So in the end it's just another instance of fix your timestep.

While this won't fix the time between shots, it would fix the number of shots:

while (this->cooldownTime >= SHOT_COOLDOWN) {
    this->cooldownTime -= SHOT_COOLDOWN;
    // do something
}

57

Window / Re: Ignore mouse input

« on: May 02, 2017, 11:49:16 am »

You'll have to modify SFML or attach your own message queue in addition to changing the window style. More information here.

58

General / Re: Creating standalone of specific RenderWindow

« on: April 25, 2017, 09:58:22 am »

What exactly are you trying to do?

59

Audio / Re: Sound from Resource

« on: April 21, 2017, 08:54:42 am »

SFML doesn't support loading resources directly nor loading or sampling MIDI files. However, since your application seems to be Windows only anyway, you could just use Windows' Media Control Interface for playback.

60

General / Re: Thread stops the GUI/

« on: April 21, 2017, 08:43:29 am »

For threading, you'd just let the thread run (i.e. omit the sf::Thread::join() call).

But for your reload mechanic, I wouldn't use a separate thread.

Just create a `sf::Time` variable for the tank, let's call it "reloadTime".

When the player hits the reload button and "reloadTime" is not equal to "sf::Time::Zero", you do nothing.

If "reloadTime" is bigger than "sf::Time::Zero", you draw the reloading animation or icons or whatever.

Every frame you subtract the time passed from "reloadTime", if it's smaller than "sf::Time::Zero", set it to "sf::Time::Zero" and readd ammo.