Messages

1

Window / Re: Splash screen

« on: July 30, 2020, 01:08:42 am »

Could you clarify what does actually happen here. I presume both styles work the same but do they centre on the display or the desktop?

On Windows, both styles appear centered on my main display (the 3440x1440 one).

2

Window / Re: Splash screen

« on: July 24, 2020, 10:39:53 am »

Did you try my example here:

Yeah as I said I tried your example and it fixed my problem. No more an issue, thanks!

This is strange. So, if the style is default, it centres on the main display but if style is none, it centres on the entire desktop?

I would say that this is unintended.

It does. Well... it centers horizontally but vertically it sticks to the bottom of the screen.
I'm trying this on 2 setups :

1. An Ubuntu 19.04 with 2 monitors (both 1920x1080)
In Style::None mode, the window always appears so that a) it's 50% on the left screen, 50% on the right one and b) its bottom edge is touching the bottom of the screen, whatever the window size is
(edit: Could it be because of Gnome's workspaces, somehow "extending" the desktop below?)

2. A WIndows 10 with 2 monitors (3440x1440 and 2560x1440)
And no issue so far with either sf::Style

3

Window / Re: Splash screen

« on: July 23, 2020, 05:32:01 pm »

Hey, your example works way better than mine! My issue wasn't about a lag between the cursor movement and the window, but really a "bias" in the window movement going half as far as my cursor... Anyway, thanks.

Ok about the first point...
What's strange is that if I replace sf::Style::None by sf::Style::Default and run your example, the program opens a window in the current display (the one I launched the program from) at a (20,20) top-left coordinate or so. BUT if I run it as-is, that's when the borderless window appears astride both screens...

But yes, overall it would be nice to have some extra info about sf::VideoMode::getDesktopMode(), something like a std::vector<sf::IntRect> matching each screen # to an area in the desktop VideoMode... I bet there's a lot of portability issues I don't see though.

4

Window / Splash screen

« on: July 22, 2020, 02:46:07 pm »

Hi,
I'm having a few issues with windows using sf::Style::None to implement something like a splash screen.

#include <SFML/Graphics.hpp>

int main()
{
   sf::RenderWindow window(sf::VideoMode(200, 200), "SFML works!", sf::Style::None);

   // center the window
   sf::Vector2i splashOrig = {
      int(sf::VideoMode::getDesktopMode().width)  / 2 - int(window.getSize().x) / 2,
      int(sf::VideoMode::getDesktopMode().height) / 2 - int(window.getSize().y) / 2
   };

   window.setPosition(splashOrig);

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

   bool dragging { false };
   sf::Vector2i dragAnchor;

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

         if (event.type ==  sf::Event::MouseButtonPressed)
         {
            if (event.mouseButton.button == sf::Mouse::Left)
            {
               dragging = true;
               dragAnchor = sf::Mouse::getPosition();
            }
         }

         if (event.type == sf::Event::MouseButtonReleased)
         {
            if (event.mouseButton.button == sf::Mouse::Left)
            {
               dragging = false;
               dragAnchor = {};
            }
         }

         if (dragging)
         {
            auto currentPos = sf::Mouse::getPosition();
            auto deltaPos = dragAnchor - currentPos;

            window.setPosition(window.getPosition() - deltaPos);

            dragAnchor = sf::Mouse::getPosition();
         }
      }

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

   return 0;
}

 

1. I want my window to be positioned at the center of my main monitor on startup, but since I have 2 monitors the getDesktopMode() gives an area which is the sum of those 2 and the window ends up astride both. It kind of makes sense, but how can I set up "splashOrig" so that my window appears at the center of my main, or current, or any screen?

2. I'm trying to make the window movable by drag-n-dropping as you can see. It kind of works, but the anchor point I set when left-clicking isn't stuck to the cursor... the faster I move, the more it "drags behind".
I've already implemented an Image viewer before in SFML and I know you need mapPixelToCoords/mapCoordsToPixel transformations in some cases... so what am I missing?

PS: I'm aware using sf::Style::None and tweaking it so it behaves like an sf::Style::Default is a bit odd... I'm just testing the limits of the thing. If it's more convenient I'll go with sf::Style::Titlebar in order to move my splash screen around.

5

General / Re: How should the code be organized?

« on: December 24, 2014, 01:53:06 pm »

There's more than one valid way to structure these programs.  Yours is valid, but you haven't given any real reason why it's wrong for him to put the RenderWindow outside the Engine class, or not use the Engine::run() approach.

That's why I asked him first.
Variables should be declared as locally as possible, so if there's not a second Engine instance in his main that needs a reference to the renderer window, there's no point scattering his code across Engine.cpp and main.cpp.

imo a three-line main() like that simply makes main() a piece of meaningless boilerplate

That's the point : main.cpp becomes just a bootstrap and all your program logic is contained inside classes like Engine.
That's the Qt approach.

Those tutorials seem interesting, but I'm already seeing questionable stuff in them like manual new/delete

That's just a tutorial.
No need to add complexity by adding smart pointers everywhere.

lots of this->member instead of just member

I personally prefer the this->myAttribute notation over the m_myAttribute one.
Just a matter of taste.

We also don't know enough about ILostMyAccount's program to tell if he needs a top-level GameState stack, so we shouldn't be asserting that either.

He probably doesn't know either.
Trying to find the perfect-fitting code structure is pointless.
He just started SFML, he may be a bit lost, so he probably needs a quick HOW-TO with some basic game structure more than an exhaustive analysis on the subject.

Update: His second tutorial shows multiple draw functions with a clear(), a draw() and no display().  I think that's a severe enough mistake to warrant saying do not use these tutorials.

What are you talking about?
Link? Quote?

6

General / Re: How should the code be organized?

« on: December 24, 2014, 11:01:27 am »

Why did you keep the sf::RenderWindow outside of your Engine?
You should make it a private attribute, initialized in the default constructor.
You basically need an extra method:

void Engine::run()
{
  sf::Clock clock;
  while (this->window->isOpen())
  {
    sf::Time elapsedTime = clock.restart();
    this->Update(elapsedTime);
  }
}
 

So you main can look like this :

int main()
{
  Engine engine;
  engine.run();
  return 0;
}
 

EDIT
I came across this (quite recent) tutorial:
https://www.binpress.com/tutorial/creating-a-city-building-game-with-sfml/137

It's pretty good IMO.
His Game class and the way he manages his states with a GameState stack is most certainly what you're looking for.

7

Feature requests / Re: sf::Texture::Texture(std::string file)

« on: December 23, 2014, 02:28:37 pm »

 

8

Feature requests / Re: sf::Texture::Texture(std::string file)

« on: December 23, 2014, 02:23:30 pm »

How would you know whether the loading failed?

9

General / Re: How should the code be organized?

« on: December 22, 2014, 04:37:13 pm »

My usual game classes:

GameEngine:
* created and run inside the main()
* handles my scenes under a state pattern so I know which one to run, and whether I should switch to an other one
* handles the sf::RenderWindow and all the global SFML stuff
* the run() method contains the classic SFML pollEvent() loop

Scene:
* created/updated/displayed/destroyed by the GameEngine
* implements sf::Drawable according to a composite pattern (i.e. contains sub-sprites and other drawable elements)
* contains an OnUpdate(sf::Time elapsedTime) method to update the physics engine (if any) or any entity of the scene (charac animation, menu cursor blink, etc).
* Concrete implementations could be: TitleScene, SettingsMenuScene, WorldmapScene, Level1Scene, etc

GameEvent:
* Similar to sf::Event but with my own events
* Used along an observer pattern
* Example: TitleScene uses a GameEvent to notify its subscribers that the "New game" button has been pressed. GameEngine is notified and updates its state diagram accordingly.

10

Feature requests / Re: Set an object's color without creating a color object

« on: November 24, 2014, 12:12:21 pm »

Do you think a variadic template overload of setColor would be an overkill?

template<typename... Args>
void Sprite::setColor(Args... args) {
  this->setColor(Color(args));
}

11

General / Re: SFML for VS2013?

« on: November 21, 2014, 03:12:09 pm »

I'm using it right now (VS12 aka VS2013) so I can confirm it works if you build SFML from its sources.

12

Feature requests / Re: std::size_t instead of unsigned int

« on: November 17, 2014, 02:08:35 pm »

There were problems with:

• stb_image.h that uses int types as a difference result between 2 pointers (should be ptrdiff_t, but the whole thing is inside an extern "C", so I don't know...)
• IpAddress.cpp that uses inet_addr() that seems to be deprecated for MSVC12 (warning C4996: 'inet_addr': Use inet_pton() or InetPton() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings)
• RenderTarget.cpp(L280): vertexCount is a size_t but glDrawArrays needs a GLsizei (i.e. an int).

13

Feature requests / Re: std::size_t instead of unsigned int

« on: November 17, 2014, 12:30:14 am »

There's an oversight in one file:

void ConvexShape::setPoint(std::size_t index, const Vector2f& point)
// instead of
void ConvexShape::setPoint(unsigned int index, const Vector2f& point)
 

After fixing it, the SFML project compiles/installs himself correctly with MSVC12 x64, but produces some warnings.

Yet, the sf::VertexArray used in my project do not produce any warnings now.

14

Feature requests / std::size_t instead of unsigned int

« on: November 10, 2014, 10:57:38 pm »

Hi
Just a quick suggestion about the types used for indexing.

I'm compiling a VC++ projects in 64bits right now and I've noticed some sf::VertexArray methods use the 32bits unsigned int (i.e. unsigned long) index types, even though their underneath std::vector<Vertex> uses the 64bits unsigned long long types.

This leads to unnecessary casts and warnings.

So I think you should use std::size_t for unsigned indexes and std::ptrdiff_t for the signed ones.

NB: I didn't check, but sf::VertexArray probably isn't the only concerned class.

15

Graphics / Re: Parallax Scrolling: Views or no views

« on: January 27, 2014, 09:33:17 pm »

So sf::View objects can be used to define different layers within one renderer, and from independant Drawable objects...

Interesting! I'll check your thread link, thanks.