Recent Posts

1

SFML development / Re: Removing dependency binaries

« Last post by FRex on February 23, 2019, 11:16:10 pm »

If user wants to link to system's dynamic binaries then doesn't it mean the bundled deps aren't built at all/CMake doesn't generate their projects/makefiles?

Is that related to SFML_USE_SYSTEM_DEPS? What does that one even do? If I check it in CMake with VS 2017 the Audio still references ogg, flac and others and Graphics references FT.

Right now the deps are static libs, get linked into dlls but not static libs (they were a long time ago but it was changed and now user must link them when linking SFML statically).

2

SFML development / Re: Removing dependency binaries

« Last post by Elias Daler on February 23, 2019, 10:37:35 pm »

Okay, fair enough, these are some strong arguments! I'll try to include FreeType's code into SFML's repo and see how to build it conveniently.

One more thing - do we want to have an option to build dependencies statically vs dynamically? Only OpenAL requires us to build dynamically, but maybe we can give users ability to choose if they want to build SFML linked to system's dynamic binaries?

3

SFML projects / Life Game

« Last post by Akzafield on February 23, 2019, 09:05:27 pm »

Hello there !

Here is the first true attempt I had to make something with SFML (well started off by testing how many thing I could put on the screen it ended up like this after a few week xD.)

So this "game" is about.. well looking and changing a small ecosystem by adding you own creature into it (by changing the game file or use the simple In game UI) and... thats it. This small game/project is not realy worket anymore as I dont have the time for it and I am working on something else on the SFML.

Here are a few screenshot of it->







(In case of [img] not working ) ->
https://imgur.com/D7YYoib
https://imgur.com/a/foKA6zm
https://i.imgur.com/4XScksx.png

Feature ->

-Creature will move around , eat their designated food , reproduce and die of old age or being eated by something
-Tree will grow near alrealy existing tree
-Ability to create/modify your own creature via the game file (.txt)
-Ability to modify the landscape (deleting,adding tree,water,rock..)
-Ability to set stuff on fire (Muhahahaha...)
-Support between 2000 to 5000 creature on the map
-Different "Biome" are generated on the map
-All world are being randomly-generate at each "new game"
-256*256 size world

Thing to know before starting :

- A freez may occur a few second after a map load , this will last for a few second and then the game will resume itself without freezing anymore.
- Will not work on older/very weak graphical card (due to how the world is displayed)
-You can move the camera by using the Arrow key and zoom in/out by using your mouse wheel


Download it on itchio :

https://akzafield.itch.io/life-game

Thank you !

4

Window / Re: Window resizing problem

« Last post by dips on February 23, 2019, 06:50:24 pm »

That is not 'explicit event polling', that is implicit, because you have additional layer as your own event queue processing. And it is not callbacks it is direct calls from swith/case noodles of processEvent method. And you uses yet another swith/case noodles in 'main' function.
Two performance pitfalls with sf::Events design: First - additional queue,  Second - additional switch/case in 'main'.

My variant is  'S'imple 'F'ast    and more C++ idiomatic.
I'm not expect somthing from you, a have my fork. It's enough for me. But I advise to recall my words when you wil write SFML-3.

5

SFML projects / Re: Nero Game Engine

« Last post by Sk Landry on February 23, 2019, 03:49:54 pm »

Hi everyone, hope you are doing great !

Engine Update

Bug fix : Physic Objects Center of Mass

In the current version of the Engine, Physic Objects (Box2D bodies) don't have their center of mass at the right place. The bug exists since the early versions of the Engine. I did not bother to solve it until now. It's a good thing to have this bug solved because now it's more easy to play with Box2D Joints.

Physic Objects new methods

With the center of mass bug fixed, it's now possible to retrieve the size and the bounds (AABB) of a Physic Object.

vector2f size = physic_object->getSize();
sf::FloatRect bound = physic_object->getGlobalBounds();

Physic Objects Joints

Here is a feature I did not plan to add in the first version, but after I solved the center of mass bug, I said why not ? 

11 Joint Types have been integrated in the Engine API

01- Distance Joint
02- Friction Joint
03- Gear Joint
04- Motor Joint
05- Mouse Joint
06- Prismatic Joint
07- Pulley Joint
08- Revolute Joint
09- Rope Joint
10- Weld Joint
11- Wheel Joint

Create Joints is pretty easy. For each Joint you have a JointProperty object that describes the Joint parameters. The code below shows how to create a Distance Joint between two Objects.

//Retrieve Objects (Physic_Object, Solid_Object or Aniamtion_Solid_Object)
auto object_A = getObjectManager()->findObject("object_a");
auto object_B = getObjectManager()->findObject("object_b");

//Create a Distance Joint
nero::DistanceJointProperty property;
getObjectManager()->createJoint(object_A, object_B, property);

Most of the parameters in a JointProperty depends on of the Joint Type. But all JointProperty has a parameter for the Joint Name.

nero::DistanceJointProperty property;
property.name = "distance_joint_01";

Find Joints

A Joint can be found using its name. The find method return a generic nero::PhysicJoint object. For each Joint Type you have a static Cast() method.

nero::PhysicJoint::Ptr my_joint = getObjectManager()->findJoint("distance_joint_01");

nero::DistanceJoint::Ptr distance_joint = nero::DistanceJoint::Cast(my_joint);

Remove Joints

A Joint can be removed using its name. If the deletion succeed the ObjectManager will return true.

bool removed = getObjectManager()->removeJoint("distance_joint_01");

Release of Version 1.0.0

Seems the time to wrap up the Project and deliver a first version has come. The version 1.0.0 will be released on April the first. Until that I will fix all bugs I can found. Most important I'll need to resit to the desire of adding new features  .

Website and Tutorials

I don't have much time to work on the Engine and the Website now. So I'll focus on the Engine and begin to work on the website after the first version is released.



That's all, have a good day !

6

SFML development / Re: Removing dependency binaries

« Last post by FRex on February 23, 2019, 02:04:50 pm »

STB updates (2 years ago) produced huge diffs. No one ever mentioned that being a problem in any way and they are neatly stashed in a 'STB updated to x.yy' commit by themselves. Ideally no commits other than 'updated some lib or other to some version' will ever touch a given lib's dir. If a lib needs to be patched urgently because it derails SFML I'd rather it be done inline in the main repo too.

Most people using git might not even know submodules exist and if they do they will often not know the command off the top of their head (I fit into latter category). It's 1 extra command and more CMake checks for no real benefit to anyone.

The size of FreeType doesn't matter. Bigger (and less compressible) binary files are in the repo already. Amount of files doesn't matter either, git handles it, it's not some prohibitive amount (like thousands of files) and they will be stashed away in own dir and only touched by some 'FT updated to X.YY' commits. To build SFML you'd need to fetch it all anyway most of the time.

What do we care for git histories of deps? These libraries are ostensibly stable API solid C libs that will be updated rarely to some given x.y.z stable release version (so just how binaries were now except not in 5 copies of each anymore and without needing to build it all), not kept up to master or their repo where we need to debug them ourselves.

Even Qt repo linked in the first post doesn't use submodules for the third party libs. They dump all third party code into one repo and add a file saying what version it is in the root of their dirs. They discard all the history and produce huge diffs. I've seen them use submodules in some other repo (with chromium submodule for web engine and with their 'super repo' that is all submodules, maybe more) but that makes more sense for them than for SFML.

It's one more parameter or command (that most people don't know off the top of their head and even ones who know it might forget it exactly since it's such a rare operation to clone and build SFML) and extra checks in CMake, all for no real benefit/solving no real problem. These source dirs should be treated exactly like the binaries are now (except for there being like 5 version of the binaries) - totally opaquely, just changed once in a while in their own commit and used in builds (to build lib that then gets linked/installed) if the user doesn't check that 'use system deps' flag.

The reason why binaries are gonna be removed is not to ever work on these libs code but to make it more convenient to build SFML everywhere so adding submodules throws that small gain out the window instantly. Binaries were never a "I don't know what this binary's git history is" problem so just dumping C into the main repo is no worse from that standpoint either.

7

General / Re: opengl what to use instead of glbindbuffer

« Last post by fallahn on February 23, 2019, 12:05:41 pm »

<SFML/OpenGL.hpp> will only give you the most basic OpenGL functions (version 1.0 I think). If you want to use any kind of modern OpenGL you'll need to load the correct functions via something like Glad, which you can find here: https://github.com/Dav1dde/glad or glLoadGen: https://bitbucket.org/alfonse/glloadgen/wiki/Home

8

Feature requests / Re: Add Vector2i overload to transformable.setPosition()

« Last post by SoggyBiscuit on February 23, 2019, 11:49:38 am »

Ah, I have found it in transformable after you said and didn't even say which one it was in, tucked away and written in a manner that wouldn't seem out of place on the tutorial pages as a footnote given its unique oddity that certainly is of use to new coders.

A note on coordinates and undistorted rendering:
By default, SFML (or more exactly, OpenGL) may interpolate drawable objects such as sprites or texts when rendering. While this allows transitions like slow movements or rotations to appear smoothly, it can lead to unwanted results in some cases, for example blurred or distorted objects. In order to render a sf::Drawable object pixel-perfectly, make sure the involved coordinates allow a 1:1 mapping of pixels in the window to texels (pixels in the texture). More specifically, this means:

• The object's position, origin and scale have no fractional part
• The object's and the view's rotation are a multiple of 90 degrees
• The view's center and size have no fractional part

Well that shouldn't be a bother, since if I have elements with pixel art I shan't be moving, rotating or viewporting them in fractions of pixels.

Though it doesn't document how to solve this conundrum for when you intend for smooth movement, full rotation or really anything about how to understand the problem nor everything that has an impact on it.

However given that the documentation is blaming OpenGL for the fault, including that in my searches has yielded better answers. Unfortunately it seems the only solution applicable to SFML is creating wraparound, disused border pixels. A shame that.

9

Window / Re: Window resizing problem

« Last post by Laurent on February 23, 2019, 10:36:42 am »

Ok, I think we all understood that you prefer callbacks than explicit event polling There's no "best" solution however, both designs have their pros and cons.

So what do you expect from us? Do you want this design to replace the current event system in SFML? Do you have any problem that you still need to solve?

10

Feature requests / Re: Add Vector2i overload to transformable.setPosition()

« Last post by Laurent on February 23, 2019, 10:26:18 am »

It is mentionned in the API documentation. And if you read that piece of doc, you'll see that it's not just about entity's coordinates. The final pixel positions also depends on the current view, viewport, etc. So providing an overload for integer coordinates would only solve the problem in some specific cases. In any case, you have to understand the problem, and know everything that can have an impact on it.

I imagine you need coordinates/size to be defined as a float for some reason

For moving / rotating entities. If you disallow decimal coordinates, they will look jerky.