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 - Sub

Pages: [1]
1
I had previously thought the two were more or less interchangable if I provided the same width / height that would be retrieved from the getDesktopMode call, but this doesn't appear to be the case.  With VSync enabled, the following two calls result in different FPS caps for me. 

I have a 144hz monitor, and calling the following results in an FPS cap of 60 when fullscreen (144 when windowed).
Code: [Select]
sf::RenderWindow window(sf::VideoMode(1920, 1080, 32), "SFML", sf::Style::Fullscreen);

This next call results in an FPS cap of 144 when fullscreen (same cap windowed). 

Code: [Select]
sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "SFML", sf::Style::Fullscreen);

Is this expected behavior?  I've only tested this on Linux Mint Cinnamon 19.1 for whatever that is worth.

2
It seems like it never ends with the fullscreen multi-monitor issues on Linux.  2.5.1 is infinitely better than the old behavior, but there's still one weird thing going on for me.  What's frustrating is that I tested the multi-monitor patches prior to 2.5.1 being released, and I don't remember running into this.  Note that this is with Linux Mint Cinnamon 19.1, I haven't tried any other desktop environment.

When I go into fullscreen, the titlebar area clips through to show the desktop background.  If I alt tab and then reenter the program, the fullscreen covers the entire screen.  In other words, if I alt tab and then reenter the program, it then fixes the issue / behaves as it should.

https://i.imgur.com/7JHaVA7.jpg

I've also gotten the taskbar area to show through instead of the titlebar area, but I don't have a screenshot of this as I can't seem to reproduce this one reliably.  I'm not sure what the trigger is there. 

Here's my monitor setup.  It's just two 1920x1080 monitors side by side.  Note that this does not happen when the displays are mirrored.

https://i.imgur.com/PBzvAI5.png

I can reproduce the issue with the following code
Code: [Select]

#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "SFML", sf::Style::Fullscreen);

    sf::CircleShape shape(100.f);
    shape.setFillColor(sf::Color::Green);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }

        window.clear();
        window.draw(shape);
        window.display();
    }

    return 0;
}

Anyone else running into this?

3
General discussions / Apple deprecating OpenGL
« on: June 06, 2018, 04:38:00 am »
In a move that I feel justifies my dislike of Apple, they've announced that they're deprecating OpenGL.

Quote
Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, but these legacy technologies are deprecated in macOS 10.14. Games and graphics-intensive apps that use OpenGL should now adopt Metal. Similarly, apps that use OpenCL for computational tasks should now adopt Metal and Metal Performance Shaders.

Metal is designed from the ground up to provide the best access to the modern GPUs on iOS, macOS, and tvOS devices. Metal avoids the overhead inherent in legacy technologies and exposes the latest graphics processing functionality. Unified support for graphics and compute in Metal lets your apps efficiently utilize the latest rendering techniques. For information about developing apps and games using Metal, see the developer documentation for Metal, Metal Performance Shaders, and MetalKit. For information about migrating OpenGL code to Metal, see Mixing Metal and OpenGL Rendering in a View.

In regards to how this impacts SFML, I'm assuming this isn't the end of the world, because I imagine that it will be a long time before OpenGL is actually removed from MacOS.  Also from what I can gather, SFML is looking to move into Vulkan sometime in the future (?).

Still though, you gotta love Apple....

4
I looked online to see if this issue was reported anywhere and didn't find anything.  Apologies if I missed it.

I'm running into an issue where the resolution appears to be set incorrectly when using SFML in fullscreen mode with a duplicated monitor setup in Windows.

I'm on Windows 10.  The issue doesn't happen in any version of Linux that I've tried.  I don't know if it also happens in other versions of Windows, I don't have a machine to test anything other than Windows 10.

I'm using two 1920x1080 monitors.  This is the test code

Code: [Select]

#include <SFML/Graphics.hpp>

int main(int argc, char* argv[])
{
//sf::RenderWindow window(sf::VideoMode(1920, 1080), "SFML window");
sf::RenderWindow window(sf::VideoMode::getFullscreenModes()[0], "SFML window", sf::Style::Fullscreen);

sf::CircleShape shape(100.f);
shape.setFillColor(sf::Color::Green);

while (window.isOpen())
{
sf::Event event;
while (window.pollEvent(event))
{
if (event.type == sf::Event::Closed)
window.close();
}

window.clear();
window.draw(shape);
window.display();
}

return 0;
}


If I log sf::VideoMode::getFullscreenModes()[0].width and sf::VideoMode::getFullscreenModes()[0].height, they're reporting 1920 and 1080, which are the correct values.

It was hard for me to take a screenshot showing the issue off, as when I take a screenshot, my monitor goes blank for a moment and some of the issues go away momentarily until after the screenshot.  For instance, the mouse cursor is much larger than it should be ordinarily, and the circle is a lot more jaggy than the image shows.

Still though, I hope the following images show what I'm talking about.  I'm alt tabbing because it shows the issue more readily.

This is what the program / my desktop looks like when running the above code in windowed mode (so the first window line uncommented with the second one commented).

This is what the program / my desktop looks like when running the above code in fullscreen mode.  Although, again, it's worse than the image makes it out to be. 

5
SFML projects / 9001
« on: December 08, 2016, 03:08:03 am »
I've been playing around with the idea of creating a (very simple) 2D action game inspired by dbz.  I've got three small prototypes that I've built to that end
  • An energy ball effect
  • Malleable terrain (I'm thinking this would occur upon the player impacting the ground at a high speed
  • Mockup of player / energy ball flight physics

Admittedly, #1 was made with Love2D, and #3 was something that I made back in 2012.  I'm not sure how much further i'm going to go with this, but I wanted to throw it out there and get a few opinions

https://www.youtube.com/watch?v=V7AMAUB83cQ

6
SFML projects / American Gothic in the Palette of Mona Lisa…
« on: September 26, 2015, 11:26:32 pm »
Disclaimer:  I made this a while ago, and it was a one off low effort type of thing.  What I'm trying to say is that the code quality is pretty awful, even by my standards, but I've decided to go ahead and throw it out there anyway. 

I saw this post and decided that it would be a fun challenge.  The task is to create a program which takes two images and attempts to recreate the second image by rearranging the pixels of the first image.




The code:  https://github.com/DanielJPetersen/American-Gothic-in-the-Palette-of-Mona-Lisa

7
Graphics / Resizing a RenderTexture?
« on: May 17, 2015, 08:41:01 pm »
I can't figure out how to resize a RenderTexture. 

This is some test code I've tried.  The desired result is a screen which is entirely green, but instead I'm left with a screen that's 1/4th green.

The code creates a render texture at half of the windows width and height, and then clears it red and draws the RenderTexture to the screen.  It then calls create again with the full window width/height, and repeats the process but this time with the color green.  Green does indeed get drawn, but the size remains half window width/height.

What am I doing wrong?

#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow Window(sf::VideoMode(200, 200), "SFML works!");
        sf::RenderTexture RT;

        //create half screen size
        RT.create(100, 100);
        RT.clear(sf::Color::Red);
        RT.display();

        sf::Sprite Sprite;
        Sprite.setTexture(RT.getTexture());

        Window.clear();
        Window.draw(Sprite);
        Window.display();
       
        //Right now the screen is a red rectangle starting from the top left to the middle
        //lets try to resize the render texture so that the entire screen is filled by it
        RT.create(200, 200);
        RT.clear(sf::Color::Green);
        RT.display();

        Sprite.setTexture(RT.getTexture());

        //doesn't seem to have an effect though.  The RenderTexture will clear green, but the
        //rectangle will still only go from the topleft to the middle

        while (Window.isOpen())
        {
                sf::Event event;
                while (Window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                Window.close();
                }

                Window.clear();
                Window.draw(Sprite);
                Window.display();
        }

        return 0;
}

I've also tried to make it a bit more explicit by making the RenderTexture a pointer, and allocating it with new
#include <SFML/Graphics.hpp>

int main()
{
        sf::RenderWindow Window(sf::VideoMode(200, 200), "SFML works!");
        sf::RenderTexture *RT = new sf::RenderTexture();

        //create half screen size
        RT->create(100, 100);
        RT->clear(sf::Color::Red);
        RT->display();

        sf::Sprite Sprite;
        Sprite.setTexture(RT->getTexture());

        Window.clear();
        Window.draw(Sprite);
        Window.display();
       
        //Right now the screen is a red rectangle starting from the top left to the middle
        //lets try to resize the render texture so that the entire screen is filled by it
        delete RT;
        RT = new sf::RenderTexture();
        RT->create(200, 200);
        RT->clear(sf::Color::Green);
        RT->display();

        Sprite.setTexture(RT->getTexture());

        //doesn't seem to have an effect though.  The RenderTexture will clear green, but the
        //rectangle will still only go from the topleft to the middle

        while (Window.isOpen())
        {
                sf::Event event;
                while (Window.pollEvent(event))
                {
                        if (event.type == sf::Event::Closed)
                                Window.close();
                }

                Window.clear();
                Window.draw(Sprite);
                Window.display();
        }

        return 0;
}

8
Feature requests / Maximize window on startup
« on: November 30, 2014, 07:09:30 pm »
It'd be convenient to have an api call to create a window which was maximized on creation.  I've searched for this and the answer was that SFML is not a dedicated windowing library. . .  However, maximizing a window is one of the options that might be added to SFML 2.

It's honestly not a huge deal, but I'm wondering if there's any room for reconsidering this now that SFML 2.0 has been out for a while and the SFML team has expanded quite a bit.

Thanks for your time.

9
SFML projects / It Usually Ends In Nuclear War
« on: December 07, 2013, 02:17:11 am »
It Usually Ends In Nuclear War
  • 4x civilization building game in development for Windows and Linux
  • Heavily influenced by Civilization II, Alpha Centauri, Call To Power, and Rome Total War.  To a lesser extent Endless Space and the Europa Universalis series
  • Currently prealpha
  • Design goals.
    • Keep microamanagement to a minimum yet allow for larger empires than recent civ games.
    • Not turn based, but rather semi-real time.  When the game is unpaused, turns will occur at a set-interval of roughly one turn every 500 milliseconds
    • Revolutions / collapsable civilizations
    • Interesting end game
  • Huge gallery (1000+) of screenshots I've been maintaining throughout the project.
Screenshot from October 15, 2017


Something more recent

10
Graphics / Anti-aliasing causing small graphical glitch?
« on: October 27, 2013, 01:38:33 am »
I'm either confused on how to properly enable anti-aliasing, or it's causing a small graphical bug in my program in the form of small squares that appear randomly around the screen.  This is a zoomed in screenshot that I took to show what I mean.

http://i.imgur.com/cXX5Inw.png

And here's a small test program I made to make sure the problem wasn't elsewhere in my code
Code: [Select]
#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow MainWindow;
   
    sf::ContextSettings ContextSetter;
    ContextSetter.antialiasingLevel = 16;

    const int DEFAULT_SCREEN_WIDTH = 800;
    const int DEFAULT_SCREEN_HEIGHT = 600;
    MainWindow.create( sf::VideoMode
( std::min(sf::VideoMode::getDesktopMode().width, (unsigned)DEFAULT_SCREEN_WIDTH)
, std::min(sf::VideoMode::getDesktopMode().height, (unsigned)DEFAULT_SCREEN_HEIGHT)
, 32), "Antialiasing Test", sf::Style::Default, ContextSetter);

    sf::Event Event;
    bool Quit = false;
    while (Quit != true)
    {
        while (MainWindow.pollEvent(Event))
        {     
            if (Event.type == sf::Event::Closed)
            {
                Quit = true;
            }         
        }

        MainWindow.clear(sf::Color(60, 90, 150));

        MainWindow.display();
    }
}

Anyone have an idea on what I'm doing wrong or what's causing this?  I'm using a nightly build that I last updated on 9.27.13.  I took a look at some of my old screenshots and this artifact doesn't appear to be on them, so I'm thinking it might be a recent change which causes this.

edit:  I just did a test with SFML 2.0 and it still happens, so that's not it.
edit2: This is what it looks like when not zoomed in: http://i.imgur.com/SY39cGI.png

11
SFML projects / Sins of a Hex Empire
« on: October 19, 2013, 01:59:30 am »
Sins of a Hex Empire
Disclaimer:  Due to VS2012 apparently not liking Windows XP under its default settings, this won't work on Windows XP.  It's also a poor clone of Hex Empire(http://www.freewebarcade.com/game/hex-empire/).

Download link -- http://goo.gl/wLStq7


  • Turn based strategy game
  • Your goal is to defeat three opposing AI and conquer the entire map
  • The black dots scattered across the map are cities. If you own a city, it generates one army every turn.
  • Capitals (the stars) generate two armies per turn. If you capture a capital, that enemy will be eliminated
  • Your units have two values -- armies and experience. Armies are the thin black crosses, experience is the black outline around those crosses.
  • A unit gains experience whenever it expands your nations borders
  • You only get 5 moves per turn
  • Pressing enter moves to the next turn
  • Pressing spacebar at any time spawns a new map.

I think that's about it. It was originally written with SDL, but I ported it over to SFML. That old version never had AI and never worked quite right.  I ended up drastically changing the code structure, updated a lot of old functions since a lot of my old code was terrible, fixed a bug with the pathfinding which took forever to figure out, and added in an AI. The AI is terrible, but it only has a few hours of work on it, and I don't care enough to improve it. It's managed to beat me a few times so I figure that it's good enough for a base line level. It's still mostly retarded though. If you want a harder challenge you can artificially handicap yourself by picking a terrible starting position.

I didn't really test it too much, so there are probably some bugs.

12
Graphics / I have a question regarding the best way to draw shapes
« on: August 17, 2013, 11:00:26 pm »
I made a simple clone of Conway's Game of Life, but I'm not sure if I went about drawing the screen correctly.  When nothing is being displayed, I get 3,500 frames per second. If I were to pause the game and fill up every cell, the framerate drops to around 230.

It's basically just drawing a series of untextured rects which can be one of any arbitrary number of sf::colors. I'm thinking there has to be a way to draw the screen without such a drastic framerate drop. http://i.imgur.com/NxRJiYP.png

Right now what happens is this -- Every frame I create a sf::VertexArray, set the primitive type to sf::Quads, and then loop through every cell. If it encounters a cell that is alive, I create an sf::Vertex with the 4 points of that cell, and then append it to the vertex array.  When it's done checking every cell, the vertex array gets drawn.

That seems to be the way it's done in the tutorial, but I guess I just expected better fps than what I'm getting.

13
SFML projects / Tetris + AI
« on: February 24, 2013, 11:26:27 pm »
I made this back in October, but I think posting about it now can't hurt. 

There was a 48 hour game jam that I participated in, but I couldn't think of anything that I wanted to make with the theme, so I just decided to make and submit Tetris for a laugh.

After I had a working game of Tetris, I thought it might be fun to expand on it with an AI.

Video of the AI  -- https://www.youtube.com/watch?v=vkUx0RRj4Yc

Brief explanation of the AI -- It analyzes every possible location you can put the current shape and assigns each possible location a score based on aspects like height, how many lines you clear, etc. The highest score is the location chosen. There's also a bit of AI learning in that the value of each aspect of score is determined by a process similar to natural selection. Run a few games with different values, pick the best performing values and change them slightly and repeat the process and it should improve. For example, if the game started off with assigning height a positive score, then after a few generations it should see a downward trend since placing blocks high up is generally not a good strategy to get a good score.

This article explains the whole thing -- http://www.danieljosephpetersen.com/posts/how-my-tetris-ai-works.html

In this version, the AI learning is turned off.  It's always going to be using the same values, which actually weren't the best that I found (it's not as good as the video), but I unfortunately have a bunch of values saved and am not sure which ones were the best, I'd probably be better off just rerunning the thing again overnight.  There's a ton of room for improvement, but I did it over the course of a week and I'm happy enough with it.

Controls:
Enter turns AI on/off
Period (.) key increases time between ai moves
Comma (,) key decreases time between ai moves

14
Graphics / Getting an invalid pointer error while using sf::Text
« on: October 17, 2012, 03:06:47 am »
This is slightly odd.

I just switched from Visual Studio 2010 to 2012 Express. 

In 2012 I'm getting runtime errors whenever I assign an sf::Text both a font and a string.  If I assign one without the other, it will work fine.  I can assign character size, color, and position without any problem, but those two functions together are giving me a debug assertion failed error.  It says Expression: invalid null pointer.

I'm declaring the texts in a class and assigning the font and string in the constructor.  The same exact code in 2010 produces no errors, and I've double checked -- I'm using the same library files, they're the debug libraries for SFML 2.

I imagine that I'm doing something wrong to cause the problem, but I have no idea what that would be.  Any help would be appreciated.

15
Graphics / Drawing lines is incredibly slow?
« on: September 25, 2012, 02:54:08 am »
I'm currently trying to replicate this tutorial [http://gamedev.tutsplus.com/tutorials/implementation/simulate-fabric-and-ragdolls-with-simple-verlet-integration/] and I'm getting low FPS when I try to draw a grid. 

I have 2500 points on screen, each spaced 6 pixels apart from each other, and I want to draw a line between each point and its neighbor.  When I do so, my FPS goes from 4200 to 20-100.  Is this normal, or am I doing something wrong?

Here's the code I'm using to draw the lines.
void SFML_Program::drawLine(sf::Vector2f a, sf::Vector2f b)
{
        sf::Vertex line[2] = {a, b};
        MainWindow.draw(line, 2, sf::Lines);
}

I've also tried:
        void SFML_Program::drawLine(sf::Vector2f a, sf::Vector2f b)
{
        sf::VertexArray lines(sf::Lines, 2);
        lines[0].position = a;
        lines[1].position = b;
       
        MainWindow.draw(lines);
}

I'm calling that 4900 times to produce this. 

http://i.imgur.com/tI1tz.png

The code that calls it simply retrieves the two points it needs and then calls the drawline.  Am I doing something wrong?

Pages: [1]