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 ... 10
16
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?

17
I think this one is more clear.

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

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

Same map at the same camera position, but one is fullscreen and one is borderless.

edit:  Just updated my graphics driver to the latest (398.11).  Unfortunately the issue is still happening.

18
It could very well be a graphics card setting or driver issue.  I have a Geforce GTX 780 TI using driver version 391.35.

I've only encountered this problem with SFML programs though.  I'm also not sure what graphics setting could cause this behavior.  When I alt tab with the issue active and look at the nvidia control panel (as well as windows display settings), it shows the resolution still at 1920x1080, despite that clearly no longer being the case.

It's occurring on both monitors, they're a perfect mirror of each other.

Here's a screenshot from another SFML game where you can see the resolution is out of whack with the text.

https://i.imgur.com/9y8obT4.jpg

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

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

21
General discussions / Re: SFML 2.5.0 released
« on: May 11, 2018, 02:33:00 am »
Congrats on the release.  Thanks everyone who contributed for the hard work, looks like a solid release :D

22
Honestly, AppImage is the simplest solution out there in my view.  It's essentially bundling your binary and all of your dependencies into one file, which the user can download, mark as executable, and then run. 

Taken from Wikipedia

Quote
AppImage does not install the application in the traditional Linux sense by putting its various files in the distro's appropriated places in the file system, just like its predecessors klik and portablelinuxapps. The AppImage file is just its compressed image; this is mounted with FUSE when it runs.

It uses one file per application. Each one is self-contained: it includes all libraries the application depends on that are not already part of the targeted base-system. An AppImage of version 1.0 is an ISO 9660 Rock Ridge file (which can be optionally zisofs compressed) containing a minimal AppDir and a tiny runtime.[4] (Version 2 may use other file system image formats like SquashFS [5][6]). An AppImage application can be added to a live CD by adding only one file to the live CD.

AppImage files are simpler than installing an application. No extraction tools are needed, nor is it necessary to modify the operating system or user environment. Regular users on the common Linux distributions can download it, make it executable, and run it.

https://appimage.org/

23
SFML projects / Re: untitled
« on: March 28, 2018, 08:37:26 am »
I replaced the rectangles representing the player with an active ragdoll.  This is a super early first pass, and honesly just about everything in this video needs multiple additional passes.  For the ragdolls specifically, right now they're ingame and reacting to the flight physics of the player.  They also orient themselves to the terrain if they detect they're going to collide soon. 

I need to animate them for charging energy attacks, melee (winning and losing), landing on the ground, and some flailing for when they're being knocked back.  I've been reading and playing around with forward and inverse kinematics, I'm thinking I should be able to come up with something decent.  It helps that the characters are super small and move very quickly, so you're less likely to notice imperfections. 


24
SFML projects / Re: untitled
« on: February 24, 2018, 05:46:29 pm »
I'm playing around with what to do for the background. This geometry wars style grid is one of the experiments. I don't know if I'm going to keep it in as it makes it pretty hard to read the screen



edit: 

It looks like I made a lighting system


25
SFML development / Re: Window state
« on: February 16, 2018, 08:36:48 pm »
There's a fairly strong chance that I'm an idiot, but I can't compile it.

Code: [Select]
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp: In member function ‘void sf::Window::setState(sf::State)’:
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp:379:22: error: ‘State’ is not a class or namespace
         if (state == State::Windowed)
                      ^
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp:385:22: error: ‘State’ is not a class or namespace
         if (state == State::Fullscreen)
                      ^
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp: In member function ‘sf::State sf::Window::getState() const’:
/home/dan/Desktop/SFML-22fd13733499963d3e184fffbb004d26ba624de8/src/SFML/Window/Window.cpp:404:42: error: ‘State’ is not a class or namespace
     return m_impl ? m_impl->getState() : State::Windowed;
                                          ^
src/SFML/Window/CMakeFiles/sfml-window.dir/build.make:374: recipe for target 'src/SFML/Window/CMakeFiles/sfml-window.dir/Window.cpp.o' failed
make[2]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/Window.cpp.o] Error 1
CMakeFiles/Makefile2:170: recipe for target 'src/SFML/Window/CMakeFiles/sfml-window.dir/all' failed
make[1]: *** [src/SFML/Window/CMakeFiles/sfml-window.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....


26
SFML projects / Re: untitled
« on: February 10, 2018, 07:33:22 am »
Finally got around to implementing deformable terrain for this.  I'm honestly amazed that it works as well as it does. 



The video would be longer but I ran out of disk space while recording.  Also, the long black screen in the beginning is OBS, for some reason it takes a while to start capturing frames when I switch to fullscreen.

Anyway, for a repeat explanation on what it is, it's loosely based on the combat in DBZ. You control a very tiny and fast square. It can fly / teleport and shoot energy attacks.

I'm the yellow dude in this video. The circle around me is how much energy I have. Flying, teleporting, and energy attacks drain energy. Energy automatically regenerates after not using any for a short period of time. Energy regenerates 2 times faster if you're (more or less) stationary.

If you fly into the opponent square, a melee collision happens, and the loser gets damaged and knocked back. The winner is determined by whoever was moving faster in the opponents direction. It's all about momentum.

If anyone has any ideas on a name for this thing, I'm all ears.

27
SFML development / Re: Window state
« on: February 02, 2018, 01:56:00 am »
Out of pure curiosity, what's the use case in having a hidden window?

edit:  Also, thank you Foaly.  This is something I've long wanted in SFML.

28
SFML projects / Re: It Usually Ends In Nuclear War
« on: January 21, 2018, 04:49:45 am »
Getting closer to where I want it to be. 


29
General discussions / Re: Why is SFML split with 1 dll file per module?
« on: January 19, 2018, 10:56:18 pm »
Splitting it has benefits which have already been mentioned in this thread.  For me personally, it's never been the source of difficulty or inconvenience, and I didn't exactly have a lot of experience in programming when I first started using SFML.

30
SFML projects / Re: Remnants of Naezith
« on: January 19, 2018, 10:47:54 pm »
It does look great.

How much is it going to cost? 

Were you working on this alone or did you have others?

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