Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Hapax

Pages: [1] 2
1
SFML wiki / Rectangular Boundary Collision
« on: July 11, 2017, 08:08:46 pm »
Rectangular Boundary Collision

SFML's sprites and shapes can provide you with their axis-aligned boundary boxes (getGlobalBounds) and you can easily use these rectangles to test if they intersect. Unfortunately, this only allows axis-aligned collision detection.

Rectangular Boundary Collision allows testing collision based on their original rectangular boundary box (getLocalBounds). It tests to see if an object's rectangular boundary collides with another object's rectangular boundary. This method, however, allows transformations to be taken into account - most notably, rotation.

Rectangular Boundary Collision is a single, templated free-function contained within the "collision" namespace:
const bool spritesAreColliding = collision::areColliding(sprite1, sprite2);

You only need the header, which is approximately 100 lines of code...

The collision is performed in three stages:
  • Level 0 - AABB (axis-aligned boundaries boxes):
    tests the axis-aligned boundaries boxes (equivalent to getGlobalBounds) of the objects to see if they intersect.
  • Level 1 - Corner inside opposite object:
    tests to see if any of either object's corner is inside the other object.
  • Level 2 - SAT (Separating Axis Theorem):
    tests using a simplified version (for rectangles) of SAT to catch other cases.
If, at any time, the result is certain, the following stages are not calculated. This allows easier detections to be done without resorting to the more involved calculations.

The collision level represents after which stage to leave the function, regardless of if a result is certain.


(red = collision, green = no collision)

Wiki page:
https://github.com/SFML/SFML/wiki/Source%3A-Rectangular-Boundary-Collision

GitHub repository (it's a part of SfmlSnippets):
https://github.com/Hapaxia/SfmlSnippets/tree/master/RectangularBoundaryCollision

Example used to create the above screenshots is included in the repository and also on the wiki page.

2
If a text is drawn to a window in a separate thread, an OpenGL error is reported when the font is destroyed.
The OpenGL error is caused by SFML's Texture.cpp (when sf::Font is destroyed).

Note that, even if the thread is completely finished and destroyed, the font destruction still causes the error.

The error:


The line to which is referred in Texture.cpp:
glCheck(glDeleteTextures(1, &texture));
https://github.com/SFML/SFML/blob/2.4.1/src/SFML/Graphics/Texture.cpp#L104

A complete and minimal example that causes the error:
#include <SFML/Graphics.hpp>
#include <thread>

void threadFunction(const sf::Text& text)
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "");
    window.draw(text);
}

int main()
{
    {
        sf::Font font;
        font.loadFromFile("resources/fonts/arial.ttf");
        sf::Text text("Text", font);
        //text.getLocalBounds(); // uncomment to stop error
        {
            std::thread thread(threadFunction, text);
            thread.join();
        } // thread completed and destroyed here
    } // font destroyed here - OpenGL error
    sf::sleep(sf::seconds(1.f));
    return EXIT_SUCCESS;
}

Any ideas as to why this happens? Any solutions?
Should the font be so seemingly linked to the window?

The strange thing - as you may have noticed in the code - is that if you call getLocalBounds() on the text object (and subsequently ensureGeometryUpdate), this error no longer occurs. This, could be considered a workaround (or "solution") but I'm still curious as to what causes the problem in the first place.

Note that this exact example was written and tested (and screenshot) using v2.4.1. However, the problems also occur with v2.4.0 and v2.4.2.

3
SFML projects / Splashentation
« on: June 10, 2017, 12:43:31 am »
This is Splashentation!

Splashentation is a slideshow presentation that is shown in its own window and runs in its own thread.

Useful for opening animations, loading screens and other situations, Splashentation shows multiple SFML drawables per slide and transitions between each slide while allowing real-time control of those drawables.

Controls to progress are also available, allowing specific keys and/or mouse buttons to jump to the next slide, skip entire presentation or quit the presentation. Controls can be stored both globally and per slide.

As you can see in the code for the following example, it is also possible to progress to next slide, skip or quit the presentation programmatically from the main thread.

Each slide can have its own controls (as mentioned in the previous paragraph), duration (including infinity), transition duration, background colour and drawables. The order that drawables are drawn can also be controlled (using a "z depth" value).

Splashentation is released under the zlib licence (the same as SFML) and is available from here:
https://github.com/Hapaxia/Splashentation/wiki

Simple Example - Loading Splash
https://www.youtube.com/watch?v=p6w0QxvPq6M
Simple Loading Splash example source code

4
SFML website / Documentation Version Linking
« on: January 16, 2016, 12:57:34 am »
At the moment, the website has the documentation for each different version that are contained within their own folder. As new versions become released, any linking to the documentation automatically becomes linked to what is then and old version.

Would it be possible to include a way to link to specific articles in the documentation while being able to specify a more generic version?

For example,
http://www.sfml-dev.org/documentation/2.3.2/classsf_1_1RenderWindow.php
links to the (currently) latest version of the documentation for sf::RenderWindow.
As soon as 2.3.3 - or, indeed, 2.4 - is released, this link would be out of date.

Since patch updates - and also minor updates - shouldn't be changing the documentation in a "breaking" way, it would be convenient to be able to link to these articles using a form of "wild-card" version.
A suggestion would be able to specify wild card at minor or patch level like so:
http://www.sfml-dev.org/documentation/2.3.x/classsf_1_1RenderWindow.php
which would link to sf::RenderWindow in the latest version of 2.3
http://www.sfml-dev.org/documentation/2.x/classsf_1_1RenderWindow.php
which would link to sf::RenderWindow in the latest version of SFML 2.

The website already has the feature to some extent for its documentation's "main page" where, if you leave off the version, it'll choose the latest. Adding the suggested ability above to the articles directly would help increase permanence of documentation links.

I found that, as I was linking to the documentation a lot, I have started to drop using the patch level version from the links thus:
http://www.sfml-dev.org/documentation/2.3/classsf_1_1RenderWindow.php
as replacing all links every time a new patch version is released just to make sure you're on the latest version feels like overkill and these are "pretty much" the same. Pretty much, as much as linking to the wrong patch version would be, anyway.

Suggestion summary:
documentation/2.3.2/article
2.3.2 article
documentation/2.3.x/article
latest 2.3 article (currently 2.3.2)
documentation/2.x/article
latest 2 article (currently 2.3.2)

5
SFML projects / Selba Ward
« on: December 13, 2015, 11:21:08 pm »
Welcome to Selba Ward!
.................."check in to check it out"




Introduction
Selba Ward is a collection of generic, reusable and flexible drawable objects for SFML.

Objects
Currently available objects:
Usage
Selba Ward can be built as a single library and then the objects can be included as required (as I use it myself) or the individual objects can be copied into your project and built along with it. The drawable objects are completely independant of each other. However, they will also require the very light Common.hpp header, along with any dependants (e.g. Bitmap Text requires Bitmap Font) or extras (e.g. Palette Enums can be useful with Console Screen)

Future Objects
Small and quick objects can usually be added quite quickly when they are added to the to-do list.
Suggestions will be taken into serious consideration, even larger objects.

SFML
All objects in Selba Ward require SFML version 2+. The latest version is recommended, although some objects may not have been tested with that version.

Feedback
As always, feedback (on the currently available objects, their interface, or the underlying code) is highly appreciated.
Suggestions for objects will also be taking into consideration.
Please report any problems with specific versions of SFML to me. This thread can be a good place for that.

Demo Animation
Best viewed in 1080 quality and 60 FPS.
http://www.youtube.com/watch?v=Yjs-oRhn2fE

Examples
(click to show/hide)



Thank you for reading and I hope you find Selba Ward useful!
Selba Ward is available here on GitHub and is under the zLib licence (same as SFML).

EDIT: Added screenshots of new simple examples for Spline that shows rounded corners and caps.

6
SFML website / Fake or fine?
« on: August 28, 2015, 10:28:28 pm »
Anybody know what this is
http://icwww.epfl.ch/~sam/infosv/doc-sfml/html/index.htm
and why it's describing itself as "the official SFML documentation"?

7
SFML projects / My Practice Beginner Games
« on: August 23, 2015, 08:47:23 pm »
Foreword
I realised that I have avoided programming those beginner games that everyone does to learn stuff and for general practice so I decided that I'm going to finally attempt them.

This project (of multiple games) doubles as practice for using GitHub too so it will all be available on GitHub. The repositories are the actual files that I am working on so you so you will be able to see my workings, mistakes, and re-factoring (I tend to do that a lot, I think). This also means that you can feel free to raise issues on the repository and the like.

Of course, SFML will be the base library for all games. Who actually wants to write console-only games?  :P
I also will be using a few small libraries of my own - all of which are completely available on GitHub.

I'll be up for discussions on any part of the project - including suggestions - but not really questions about C++ that should be, at the very least, first googled.

Games
Complete:
Current Work In Progress:

Early video of MTD (v0.0.2):
http://youtu.be/K5IZUl_7BaY

Video of Puzza (v1.0.0):
http://youtu.be/Hp1IyuBLyRE

(click to show/hide)

The Code
Click here to visit the GitHub repository.

Disclaimer
These "games" are work(s) in progress and no guarantees to their working success are given.
I may or may not decide to work on more than one game at a time.
None of this can be considered tutoring. It is not intended to teach. I am learning and this is what I am doing. That is all.

8
SFML wiki / Sprite3d
« on: July 30, 2015, 05:03:11 pm »
NOTE: Sprite 3D is now included (and maintained) as a part of Selba Ward.

Sprite3d

Sprite3d could be considered a follow-up to the sprite animation temporary class, SpinningCard, which allows you to rotate a sprite around either the x axis or the y axis. It does this by animated the corners in an ellipse.
However, where SpinningCard was only intended to used during the spinning animation and then discarded, Sprite3d is intended to be used on its own.

Sprite3d does not animate corners using an ellipse; it uses a "proper" transformation matrix (albeit a rather compact one) to rotate around the x and y axes. This combined with the usual rotation around the z axis (this class inherits from sf::Transformable) and you can rotate around all three axes.

Sprite3d injects itself into the same namespace as SFML to allow for an easy and seamless transition from sf::Sprite to sf::Sprite3d.
Sprite3d is intended to be able to used in place of a standard SFML sprite with no changes to the code.

The source is, of course, available on my GitHub and is also available on its Wiki page.

Here's an early test screenshot (it really does not do it justice!):


The screenshot doesn't properly show what it does so here is a video of an early test example:
http://youtu.be/EAPDIlVEMKA

One thing to note is that this class doesn't solve the texture mapping problem evident in SpinningCard (and is evident in that screenshot - look at the lines). It does attempt to reduce the effects by a user-controlled number of triangles. The quality of this effect is therefore dependant on both mesh size and apparent depth.

If you want to see the mesh fixing the texture distortion, run the current example and start the rotation (press Space). Increase the Mesh Density to 4 (use the square brackets [ ] to adjust) and turn on dynamic subdivision (Return). Then increase the depth to 50 (use - and = to adjust). The example displays how many triangles are being used at any point in time.
For more controls, see the comments at the head of the example code.

To combat the texture distortion evident when a non-affine transformation (three dimensional rotation is a non-affine transformation as the edges stop being parallel) is applied to a quad, there are three features in Sprite3d that alter the mesh (size and number of triangles).
  • Mesh Density
    This is how many points are used per dimension, not including the edges. For example, if the mesh is created from 5x5 points, that's 5 points per dimension - 3 points per dimension, not including the edges. So, a mesh density of 3 would give you a mesh created from 5x5 points (a single quad is 2x2 points; 5x5 points creates 4x4 quads)
  • Subdivision level
    This is very similar to Mesh Density. It changes how many points are used for the mesh. Each subdivision divides each quad in the mesh into four quads. e.g.: 1 quad that is subdivided once becomes 4 quads, 1 quad that is subdivided twice becomes 16 quads, etc.
  • Dynamic Subdivision
    When enabled, Dynamic Subdivision changes the subdivision level automatically based on the most extreme angle. That is, the greatest rotation angle of pitch and yaw (around the x and y axes respectively). The range of subdivision can be specified; the default range is 1 to 4.
    Example: Using the default range, if pitch and yaw are both 0 (object is flat), the subdivision level would be 1, whereas if pitch or yaw is close to 90°, the subdivision level would be 3. Subdivision level 2 would be used if the most extreme angle was not almost 90° but was not almost flat.
    The range is interpolated linearly so (in the case of the default range) from 0° up to 30° the subdivision level would be 1, from 30° up to 60° degrees it would be 2, from 60° up to 90° it would be 3, and at 90° it would be 4.

I invite people to try Sprite3d in place of any standard sprite you already have to see if the replacement is seemless or needs some work. I would appreciate any feedback on this (or any) matter.

GitHub repository for Sprite3d.

EDIT: updated to reflect complete version (1.0.0)

If anyone knows if it's possible to use a shader to fix the texture distortion, please let me know how.

9
SFML wiki / RadialGradient Shader
« on: July 28, 2015, 06:18:05 pm »
Just posted a shader on the Wiki to add radial gradients to untextured SFML graphics objects e.g. rectangles, circles, vertex arrays.

There is also a complete example that - using an sf::CircleShape and an sf::Rectangle - ends up displaying this:


Here's the Wiki page:
RadialGradient Shader

EDIT: changed image width to fit into the forum.

10
Window / Error Message On Incorrect ContextSettings
« on: June 28, 2015, 08:30:16 pm »
Setting one of the context settings' attributes to one that will fail causes an error message to be displayed. I don't think it's always been like this; to quote the documentation for sf::ContextSettings:
Quote
No failure will be reported if one or more of these values are not supported by the system; instead, SFML will try to find the closest valid match.
which obviously isn't true anymore.

Is there, at least, a way to suppress this error message? Preferably, at least for release mode.

Here's some short code that now causes the error message to be shown:
#include <SFML/Graphics.hpp>
int main()
{
        sf::ContextSettings contextSettings;
        contextSettings.antialiasingLevel = 128; // changing just one unsuccessful setting can make SFML display an error message

        sf::RenderWindow window(sf::VideoMode(800, 600), "Context Settings", sf::Style::Default, contextSettings);
        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                window.close();
                }
                window.clear();
                window.display();
        }
        return EXIT_SUCCESS;
}
Error message (on my computer):
Warning: The created OpenGL context does not fully meet the settings that were requested
Requested: version = 1.1 ; depth bits = 0 ; stencil bits = 0 ; AA level = 128 ; core = false ; debug = false
Created: version = 4.2 ; depth bits = 24 ; stencil bits = 8 ; AA level = 4 ; core = false ; debug = false

I intentionally overshot the anti-alias maximum value by using an impossibly high value but it works the same if you overshoot it by anything (e.g. on my computer, trying 8). Overshooting seemed to be the solution previously due to not knowing the maximum (anti-alias level) it could achieve.

Commenting out the anti-aliasing assignment stops the error message as ContextSettings having default values for all of its attributes will cause it to find a match with no error message.

This also brings up another question: is it possible to disable the stencil buffer - or depth buffer - (as mentioned in this tutorial) as it requires the stencil bits to be set to zero but this is ContextSettings' default value and finds a match (see error message above).

EDIT: Turns out that for depthBits and stencilBits, anything lower will be 'promoted' while anything higher will cause the same error message.

11
Audio / AL_INVALID_OPERATION from SFML 2.3 Audio
« on: June 25, 2015, 01:44:14 am »
The closest thing that I could find that already mentioned this error is this post but since the error I'm getting is in SFML 2.3 but not 2.2, I don't think that topic is relevant - barring the fact that it didn't seem that the problem in the thread had a solution.

The actual error I'm receiving is:
An internal OpenAL call failed in AudioDevice.cpp (157) : AL_INVALID_OPERATION, the specified operation is not allowed in the current state

#include <SFML/Audio.hpp>
int main()
{
        sf::Listener::setGlobalVolume(100.f);
        return EXIT_SUCCESS;
}
That code is enough for me to get the error. It doesn't get an error by instancing an sf::Sound object (like in this SFML Github issue that I visited to see if it was related) instead of using the Listener. In fact, after some extra tests while writing this, I found that of the setters in Listener, setGlobalVolume() and setPosition() causes the error but setDirection() and setUpVector() do not.

I've fully linked to 2.3 and it causes this error. I then fully linked to 2.2 and there is no error.
I then tried 2.3 with 2.2's Audio dll and the error disappears. 2.2 with 2.3's Audio dll brings it back.
Both versions of the SFML DLLs are the release versions.

Indeed, the reason I noticed this was because I linked my Faux Car project to 2.3 and it caused this error at the very beginning (when setting global volume) and then I had some weird destruction crash when main() closed. I've found the source of the crashing so they're not related as I originally considered. I addressed this first (the audio error) as it's the first error and I found it easy to reproduce with minimal code.


EDIT: This error is only appearing in debug mode, not release.
Windows 7 64-bit, VS Studio 2013, SFML 32-bit - dynamic and static both same result.
EDIT 2:
64-bit gives same result as 32-bit (debug, not release; both dynamic and static same result).

12
Window / First GainedFocus Event Fails After Recreation Of Window
« on: June 11, 2015, 10:57:17 pm »
The window doesn't seem to receive a GainedFocus event if the window is recreated after losing focus.

Here's an example:
#include <SFML/Graphics.hpp>

void createWindow(sf::RenderWindow& window)
{
        window.create(sf::VideoMode(800, 600), "Gained Focus Event Failing", sf::Style::Default);
}
int main()
{
        sf::RenderWindow window;
        createWindow(window);

        sf::Color color{ sf::Color::Green };

        while (window.isOpen())
        {
                sf::Event event;
                while (window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed || event.type == sf::Event::KeyPressed && event.key.code == sf::Keyboard::Escape)
                                window.close();
                        else if (event.type == sf::Event::LostFocus)
                        {
                                createWindow(window); // this stops GainedFocus from working
                                color = sf::Color::Red;
                        }
                        else if (event.type == sf::Event::GainedFocus)
                        {
                                //createWindow(window); // this is fine if commented out or not
                                color = sf::Color::Green;
                        }
                }

                window.clear(color);
                window.display();
        }

        return EXIT_SUCCESS;
}

The code changes the window to red when it's not in focus and green when it is in focus.

When the window is recreated after losing focus, when returning focus to the window, it doesn't receive the GainedFocus event and therefore no longer turns green.

In the code, if you comment out the createWindow line (before turning color to red), the event works fine. In addition, if you uncomment the createWindow line (before turning color to green), it makes no difference (lost focus still works immediately). In fact, even after regaining focus but not receiving the GainedFocus event, the window will still receive LostFocus events.

It's obvious that event is still for the correct window as you can still close the window that can't regain focus.


EDIT: Win7, VS2013, SFML2.3 debug and release (32-bit).



EDIT 2: modified thread subject title.

13
SFML wiki / Zooming a view at a specified pixel
« on: January 27, 2015, 11:13:02 pm »
Hi.

A thread appeared on the forum that asked about zooming a view at the mouse's position when the mouse wheel was scrolled so I created a simple free function that zooms a view at any specified pixel (in relation to the window).

Here's the wiki page:
https://github.com/SFML/SFML/wiki/Source:-Zoom-View-At-%28specified-pixel%29

It includes an example that scrolls on mouse wheel usage as stated above.

I hope you find some use of it.

Hapax

p.s. It's also my first SFML wiki page so I hope it follows all of the rules.

14
SFML projects / Faux Car
« on: December 02, 2014, 09:45:16 pm »



Intro

It may be obvious to some that I've become interested in faux/fake/pseudo 3D. I think it shows in the Spinning Card class that I created. I began to investigate more pseudo 3D usage and stumbled upon the old car games that used it.

I felt the need to attempt to see if I could also make this pseudo 3D track effect - using SFML, obviously!

Faux Car is what I came up with.

I'm not sure if I'm going to turn it into a complete game yet, but I do intend to evolve it.

The altitudes and positions are calculated using perspective algorithms but all turns are fake. There are no technically no rotations. Bends are simply accumulations of offsets.

I'm willing to discuss the code and show parts of it too. It's a little impractical to show it all; it's in many files and is reliant on my own library (full version of Hx).

Version Info

(click to show/hide)

(click to show/hide)

(click to show/hide)

(click to show/hide)

(click to show/hide)

15
SFML projects / Spinning Card
« on: September 24, 2014, 02:16:06 am »
NOTE: you may be interested in the much more flexible follow-up to this class, called Sprite3D.
Sprite 3D is now included (and maintained) as a part of Selba Ward.



I remember someone once mentioning animating a card so that it spins around without using OpenGL. I think the answer was simply "scale the width". I had said it could be faked by animating the corners but I think they thought that might be too complicated.

It inspired me to create something that spins a card easily without using OpenGL but still looks 3D (enough).

I bring you...
Spinning Card

Here's a video of a really basic example of it in action (source code for example is on github):
http://www.youtube.com/watch?v=u428K0xyorI
The example code uses two SpinningCards - one for the front and one for the back - and switches which one to draw depending on the current angle. It animates the angle linearly from 0 to 360 degrees and animates the scale depending on the angle (to make it float forwards).
In this example, the card starts the spinning animation whenever the Space Bar is pressed. The "stuttering" is because of the key pressed quickly.

The class takes a sprite and mimics it by creating a vertex array and taking the sprite's position, origin, scale, rotation, colour, and its texture, which it takes a pointer to.

The card, by the way, can also be spun vertically.

If you can think of something that this class is missing, let me know. It's a simple class with a specific task in mind, though, so it probably shouldn't start including an ability to bend the card or anything  :P

As always, feel free to let me know if my code could be improved and how.  ;)

Pages: [1] 2