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.


Messages - Sub

Pages: 1 [2] 3 4 ... 11
16
General discussions / Re: Goodbye
« on: May 13, 2019, 09:52:56 pm »
I'd like to echo the thanks for all of the work that you've put into SFML.  You've helped make this project one of the best open source projects in existence.

17
SFML projects / Re: 9001
« on: April 03, 2019, 05:09:45 pm »
Thanks Hapax. 

I'm pretty happy with how the smoke-like effect turned out, as well as with the main mechanic of trying to outmaneuver the opponent while not running out of energy (because at that point you'll be immobilized and will probably get hit yourself).

Main problem at the moment for the smoke-like effect is that it's too dark and hard to see on some monitors, but if I make it any brighter then it becomes too bright on everything else.  I think I'm going to have to implement one of those sliders where you choose the brightness at the start of the game.

The main mechanic is an evolution of something that came from a half-life 1 mod I used to play called ESF.  I made changes to make it work in 2D + make it easier to grasp/play, because that game was absurdly hard, to the point where the video I just linked to i'm sure is completely nonsensical unless you've played it.

18
SFML projects / Re: 9001
« on: April 03, 2019, 08:14:13 am »
Thanks Elias :).  Apologies for the 1 year + late reply, I have no excuse.

Latest video I recorded is a few months old, but I'm still working on this thing.

https://www.youtube.com/watch?v=cIVj0_rcbQE&list=PLdaVi1JjCyrg1m-B8Zb4EMGMaNoDN25xE&index=19

Since the video was recorded I've added some sounds + music, procedural level generation, and have played around with the terrain physics some more.  I'm not very happy at all with this iteration of the terrain, I think it definitely needs a rework.  Still have a lot more to do (energy attack system, character leveling system, I think with the right shaders it could look a lot better, etc). 

I think I'm going to take a small break from working on this and spend more time working on the other project I'm working on, It Usually Ends In Nuclear War.  Should give me some time to rethink the terrain

19
General / Re: turn-based countdown
« on: April 03, 2019, 01:46:10 am »
Each time you restart your clock, you're throwing away any time over 1 second.  This is going to accumulate more and more causing your countdown to be inaccurate. 

I modified your code to count down without any accumulation issues.  Also, you don't need the header guard in a .cpp file.

Code: [Select]
#include <iostream>
#include <string>
#include <SFML/Graphics.hpp>
#include <cmath>

int main()
{
sf::RenderWindow window;
window.create(sf::VideoMode(800, 600), "TITLE", sf::Style::Close | sf::Style::Resize);
window.setFramerateLimit(60);

sf::Font font;
if (!font.loadFromFile("Enchanted Land_0.otf"))
{

}

sf::Text text;
text.setFillColor(sf::Color::Red);
text.setFont(font);

sf::Event events;
sf::Clock clock;
while (window.isOpen())
{
sf::Time time = clock.getElapsedTime();
const int countdownNumberOfSeconds = 10;
const int timeleft = countdownNumberOfSeconds - std::floor(time.asSeconds());

text.setString(std::to_string(timeleft));

if (timeleft <= 0)
{
text.setString("GAME OVER");
text.setPosition(window.getSize().x / 2, window.getSize().y / 2);
}

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

if (events.type == sf::Event::KeyPressed)
{
if (events.key.code == sf::Keyboard::A)
{
window.close();
}
}
}

window.clear(sf::Color::Blue);

window.draw(text);

window.display();
}


}

20
General discussions / Re: What pain points do you experience using SFML?
« on: January 21, 2019, 08:22:44 am »
It's also not very useful for anything but the very simplest case. A rich text component or even just multiline component with text alignment would make a big difference here.

This is by far my biggest gripe.  I find myself often having to do a lot of tinkering with sf::Text and wondering why I have to write my own functions for things like multi-line text centering.  When I asked about it a couple years ago I was told to do it myself.  Yeah, that's fine, I'm happy to do it, but it seems like there's a bit of functionality missing from sf::Text that is not just specific to my needs, but rather features that most users would want.  I can see why these features might be low priority, but they don't even seem to be on the roadmap anywhere.

I found myself implementing common text operations like multi-line text centering as well.  I wonder how much effort has been collectively wasted here.

21
General discussions / Re: Visual Studio 2019 Preview with SFML
« on: December 11, 2018, 10:18:17 am »
Very cool.  Thanks for sharing

22
SFML projects / Re: [Release][GUI] ImGui-SFML
« on: November 21, 2018, 12:05:34 am »
I just want to register my appreciation for you making these bindings and making them open source.  Works great.

23
SFML projects / Re: I Can Transform
« on: November 10, 2018, 09:43:13 pm »
Looks good, it's clear a lot of work was put into it. 

You might want to change the name of it to something more unique.  I went to install it on Android and couldn't find it through their search.  I had to go find this thread on my phone in order to get the link. 

24
bitsPerPixel on getDesktopMode is 24.  When I call

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

The FPS cap is 144, which is good I guess.  I'm not really sure why a bitsPerPixel of 32 would result in a different cap though.

25
If anyone wants to test it, the following should do the trick

Code: [Select]
#include <SFML/Graphics.hpp>
#include <iostream>

int main()
{
// sf::RenderWindow window(sf::VideoMode(1920, 1080, 32), "SFML", sf::Style::Fullscreen);
sf::RenderWindow window(sf::VideoMode::getDesktopMode(), "SFML", sf::Style::Fullscreen);
window.setVerticalSyncEnabled(true);

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

sf::Clock clock;

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();

float currentTime = clock.getElapsedTime().asSeconds();
float fps = 1.f / (currentTime);
clock.restart();

std::cout << std::to_string(fps) << std::endl;
}

return 0;
}


26
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.

27
I'll add it to my list of things to do, but considering the fix is to alt tab and then reenter the program, it's pretty low priority for me at the moment.  I'll post back here if I find anything.

28
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?

29
I'm going to chalk this one up to a bug in Windows.  I just downloaded and installed the April 2018 update and this is now fixed. 

Thanks for the help eXpl0it3r. 

30
Quote
Ah so it's more or less just zoomed in.

Yeah.  It looks to me as if the viewport is smaller than the window size, and it's being stretched to fit.  Except it's also affecting the underlying OS.

Anyways, both monitors do indeed switch to the correct resolution.  To be clear, this is what I did
1.  Set windows to only show on monitor 1 and then ran an SFML app fullscreen.  It behaved correctly.
2.  Set windows to only show on monitor 2 and then ran an SFML app fullscreen.  It behaved correctly.
3.  I decided to try out switching the monitor ordering, so I unplugged monitor 1 and monitor 2 and switched the ports that their cables were plugged into.  I then set windows to mirror the displays again.  The issue still happens.

I should probably mention at this point that one monitor is actually a TV, and is significantly larger than the other one.  I'm sure this is a stupid question but is the code that fullscreens it at all DPI aware?  Could that somehow be screwing this up?

Pages: 1 [2] 3 4 ... 11