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

Pages: [1] 2 3 4
1
SFML game jam / Re: 4th SFML Game Jam Announced
« on: May 27, 2015, 09:55:07 pm »
And a Mac build of Raven Catch. Just like with the others, I made a few changes, namely adding CMake files, an Icon, resourcePath(), and making the window resizable. Also, I think the game is relatively complete for a Jam game, and it's actually kinda fun to play too! I'm not entirely sure how it relates to the theme though...

Also, zsbzsb, wasn't there going to be comments/judging on the website? It still says that it'll be "coming soon".

2
SFML game jam / Re: 4th SFML Game Jam Announced
« on: May 25, 2015, 03:32:32 am »
Did you try the game? What did you think? Any suggestions for on what to do/avoid during future stuff? I'm still noob so appreciate any hints  ;D

Of course I played it! I think that it's well done overall, especially considering it's a Game Jam and also your first game. The only thing that really bothered me was that you don't slide on walls, which makes it kinda difficult to get through the doorways. I'm still very noobish too, so I don't know how much advice I'm entitled to give, and I also didn't go through the source code too much (just looked at the few places where I made changes), so a can't really comment on that either. I will say, however, that the best way to learn to make games is by actually make games, especially small, but complete, games like this.

If someone does build your game for Windows, I'd love to try it so let us know if you hear of someone doing so!

I would really appreciate if someone could do this, since I have barely touched a Windows computer, let alone do programming on one. Also, my Cmake files will require a few (hopefully small) changes to get working on other systems. If someone actually does get a good build of it though, they'll probably it here, so keep your eyes out.

3
SFML game jam / Re: 4th SFML Game Jam Announced
« on: May 24, 2015, 03:50:54 am »
So I had some free time today, and so I managed to get a Mac app for both Struct and Bring It Back. I'd really appreciate if someone else could test them on their computer, just to make sure I actually made them fully independent.

I also started working on getting the other projects to compile on a Mac. Would you guys be interested in Mac app bundles for them?
This would be awesome! Such appreciation would go for such a gesture. I'd like to be able to return the favour but building is not a strength of mine (I even still don't build SFML for myself).

Naw, the pleasure is mine! I just figured out how to create application bundles, and so applying to several projects in a row is definitely some good practice. I also really like the SFML Game Jams, and providing easy-to-run binaries rather than just-try-and-build-it-yourself code will hopefully generate more interest, and ultimately, higher participation.

Also, I would highly recommend you get into build systems. Cmake does wonders in terms of ease of building and cross-platform development (I used to use plain Makefiles/shell scripts, and those were a nightmare). You'll also find a lot of freedom in it too, being able to compile SFML directly from source, so you can make your own modifications too.  ;)

4
SFML game jam / Re: 4th SFML Game Jam Announced
« on: May 23, 2015, 04:07:18 pm »
I am also unable to update my submission (which is a shame, as I just figured out how to make it drag-n-drop installable). I also started working on getting the other projects to compile on a Mac. Would you guys be interested in Mac app bundles for them?

5
SFML game jam / Re: 4th SFML Game Jam Announced
« on: May 20, 2015, 12:01:09 am »
I gotta say that I really like this Jams as they push me to actually get a final product, and also force me to be creative with a theme I otherwise wouldn't have considered. I mean, I would have never considered making a reverse Tetris style game, and even if I had, I would have spent weeks working on a complete tile insertion algorithm, rather than a so-so one in one evening. In the end, the code looks like a train wreck (for my coding style, at least), but that doesn't matter because you created a game, or at the very least a game prototype. So I would definitely encourage anyone who can to participate in the Jams as it definitely teaches you a lot.

Also, Hapax and Ricky, do either of you plan on releasing your code? I only have access to a Mac, so I can't run the Windows builds, and so I'd like to try compiling them myself and see if I can get a Mac build going.

Finally, since it seems very difficult for many potential participants to make such a short deadline, maybe we should look into extending the Jam length? Personally I like the idea of having two deadlines, one after 3 days (like now), and then another one a week following that. This way, there's a good reason to make something playable quickly (so you have something to be submitted by the "Initial Release" deadline), but you still have time to add features and polish the game (or just finish it, if you were busy that weekend or otherwise couldn't participate) before the final deadline.

6
SFML game jam / Re: 4th SFML Game Jam Announced
« on: May 17, 2015, 08:14:35 pm »
It seems the website is currently down. I keep on getting timed out errors.  :-\

EDIT: It's working again.  :)

7
Graphics / Re: Blending Mode "Intersection"?
« on: February 21, 2015, 11:32:30 pm »
I don't think it is possible to do that using just a sf::BlendMode, even if you create a custom one. It might just be easier to draw the light/visible areas, as those would overlap correctly with the default blend mode. Using a shader when drawing the final buffer could also work, although a little advanced.

8
SFML game jam / Re: 4th SFML Game Jam
« on: February 19, 2015, 04:01:21 pm »
Maybe setup a poll? I personally would love to do it this weekend as I'm not going to be very busy this weekend. I would say that even using the forum itself to post the games, as I believe it was done in the first game jam, wouldn't be that bad of an idea.

9
General / Re: OS X: crash when resize window to minimal size
« on: January 30, 2015, 06:36:47 pm »
Yeah, this definitely seems to be a problem with Apple's library: it got stuck in an infinite loop that overflows the stack. I wonder if it could be possible to prevent it on our end though. Can you try to get a full backtrace so we can determine where and if SFML code is triggering it? Also, I was not able to reproduce this on 10.9 with the latest SFML, what version of OSX and SFML are you using?

10
Feature requests / Re: System cursors
« on: January 19, 2015, 10:20:07 pm »
Here is a quote from the tutorial you linked to:

Quote
Since SFML is not a framework nor a GUI system providing a native function for changing the mouse cursor doesn't fit its purpose.

So while it would be a useful feature, it just doesn't fit under the scope of SFML. Besides, the tutorial provides you a way to do it easily without needing SFML to do anything to support it.

11
General discussions / Re: Multi Monitor Setup
« on: January 06, 2015, 11:59:45 pm »
I don't really see the point of calculating a (0,0) for every monitor rather than using the actual screen positions, so that the top left corner of the primary monitor is (0,0) and all coordinates on any monitor are relative to this point. This is how it's done on basically every multi-monitor article/documentation/system that I've ever seen. So we would then just provide a sf::Display::getCount() and sf::Rect sf::Display::getRect(displayId) or similar. Then, if a user wants to, they can easily work out a (0,0) for each monitor if they need it. This also means that we don't need to (and wouldn't even make sense to) specify a display in functions like sf::Mouse::getPosition, which is much cleaner.

Also, we should keep in mind that if we are going to make SFML high-DPI aware (which becomes even more important in multi-monitor setups), we will need to report resolution in screen coordinates and not pixels.

12
I've never used the book myself, but by the looks of code listing here, the function just does a simple conversion from a Aircraft::Type to Textures::ID. This is just fine, as it makes it possible to do the one-line constructor for mSprite.

When people say that globals are evil, they are referring to global objects, not functions. These cause problems as the order of initialization is not specified, and so heavy-weight objects, such as sf::Window, can cause the program to crash. They also indicate a design flaw, as potentially any part of the program can modify the variable. Both of these obviously do not apply in this case.

13
Are you referring to using RenderTarget::draw() with normalized coordinates, such as

sf::RectangleShape rectangle(sf::Vector2f(0.5, 0.5));
rectangle.setPosition(0.25, 0.25); // Remember that this sets the top left corner of the rectangle

window.draw(rectangle);
 

to produce a rectangle that is centered on the window and with half the size of the window? If so, you can accomplish this using views by using window.setView(sf::FloatRect(0.0, 0.0, 1.0, 1.0). If that's not what you meant, could you provide some example code to show exactly what you would like SFML to do?

14
Feature requests / Full Support for High-DPI Displays and DPI Awareness
« on: December 25, 2014, 04:26:41 am »
While SFML currently has partial support for high-DPI displays, their are some issues that cannot be resolved without making SFML's API DPI aware. I've done some research and compiled a list of links to how this is handled on various systems / libraries:
  • OS X - Comprehensive documentation for OS X
  • Windows - Introduction tutorial for Windows
  • Windows - Comprehensive documentation for Windows
  • iOS - Section from the iOS documentation
  • Android - Description for Android devices
  • GLFW- Small section describing DPI handling in GLFW
I was unable to find any good resources for Linux, but it seems like it is a limitation in X that prevents correct DPI awareness (although supposedly Wayland has support for it).

For those who are new to DPI awareness, I would highly recommend the introduction in the OS X documentation: it's not too long and explains the basic concept very well (and has pictures!).

For the most part, it seems like all the systems use the same basic design: window management, mouse coordinates, etc. use a more abstract system for screen coordinates, with various names being used for the measuring unit ("points", "density-independent pixels", "screen coordinates", etc.), whereas lower-level drawing commands ,including most interactions with OpenGL, using the actual pixel coordinates. Then a scaling factor is exposed in the API to convert between these two systems. Since SFML encompasses of these domains, it should make a distinction between these two systems in its own API.

I took the liberty of going through the SFML API and identifying the changes that would have to be made in order to make SFML fully DPI aware. First, the following would have to be changed to use screen coordinates rather than physical pixels (this includes making these values floats):

  • sf::Event::MouseButtonEvent: x, y
  • sf::Event::MouseMoveEvent: x, y
  • sf::Event::MouseWheelEvent: x, y
  • sf::Event::SizeEvent: width, height
  • sf::Event::TouchEvent: x, y
  • sf::Mouse: getPosition(), setPosition()
  • sf::VideoMode: width, height
  • sf::Window: getPosition(), setPosition(), getSize(), setSize()

The following should continue to use physical pixels:

  • sf::RenderTarget: getSize()
  • sf::RenderTexture
  • sf::Texture
  • sf::Image

Other classes in SFML (such as views, shapes, etc.) already use coordinate systems that are not tied to pixels/screen coordinates, and are thus not affected.

In addition to the above changes, the following should be added to the API:

  • Add the function sf::Window/RenderWindow::getScaleFactor() that would retrieve the current scaling factor for the window.
  • Change the default view generation for sf::RenderWindow so that it is based on screen coordinates rather than pixels. This way, the default view is independent of the DPI of the screen it was created on.
  • A scaling field should be added to sf::Event::SizeEvent for cases like when a window is moved between displays with different scaling factors. Alternatively, we could do similar to GLFW and create a new event type that deals exclusively with scaling events (sf::Event::ScaleEvent?).

There is one more modification that needs to be made that concerns sf::RenderWindow::getSize(). Since sf::Window::getSize() should use screen coordinates, as it is part of window management, and sf::RenderTarget::getSize() should use pixels, as it works with OpenGL, which way should sf::RenderWindow::getSize() go?  Here is a short list of ideas:

  • Rename the getSize() methods so that the one inherited form sf::Window is kept distinct from the one inherited from sf::RenderTexture.
  • Add a bool argument to getSize() to signal which version we want.
  • Exclude sf::RnderWindow::getSize() from the public API so the user has to explicitly specify render_window.Window::getSize() or render_window.RenderTarget::getSize().
  • Use composition rather than inheritance between sf::RenderTarget and sf::RenderWindow.

None of these options are very clean, however. I'm also not sure of all the other changes planned for SFML 3 though, so maybe they affect this issue somehow, hopefully for the better?

Two final notes: First, dynamic changes to the scaling, such as the user moving the window between two monitors with different scaling factors, does not require full multiple monitor support, as it is possible to query the current scaling factor for a given window directly (at least on OS X and Windows 8.1), so this does not depend on complete multiple monitor support in SFML.

Second, although above I called them physical pixels, it turns out that even what OpenGL works with does not always correspond to physical pixels on the screen. For example, on my Retina display MacBook, the virtual screen is 1440x900 and the physical screen is 2560x1600, but the scaling factor is 2.0x. This is because OS X renders everything to a framebuffer of 2880x1800, then scales it in hardware back to 2560x1600 for output. This happens well after SFML, or even OpenGL, is involved, and we aren't really supposed to be concerned with it, but it is interesting nonetheless.

Anyways, is full DPI awareness support something we should target for SFML 3? And, if so, is it too soon to start work on implementing it, especially considering that it does change quite a lot of types in the API?

15
Feature requests / Re: sf::Texture::Texture(std::string file)
« on: December 24, 2014, 09:20:17 pm »
Exceptions won't be added into SFML 2.x, as they would be too major of a change, but they will most likely be added in SFML 3.

Pages: [1] 2 3 4