16
General / Re: Wont run on windows 10
« on: November 26, 2015, 08:24:47 pm »
Try running the program from the command window to see if SFML is spitting out any errors as well.
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.
17
General / Re: Linking on Linux
« on: November 15, 2015, 08:31:40 pm »
Thank you for posting that. It looks to me like you didn't change your linker libs from the previous post you made so the difference between arch and ubuntu is my problem. I'll investigate it further later.
Last thing I would say is you seem to want to make a guide for using CodeBlocks. I personally don't like CodeBlocks and if I need to use an IDE on linux I use CodeLite for a couple of reasons.
For one, CodeLite's abilities are less intrusive to me than those of CodeBlocks. Talking about things like code completion mainly.
Second, in order to use CodeLite you need to be more familiar with your tool chain. To me this is a good thing. CodeBlocks automates a lot of the tool chain functions by making checkboxes to turn on/off options. For CodeLite you need to know the command line usage of the tool chain and put those commands into CodeLite's compilation settings. Imo this is better. Knowing your tool chain and how it operates helps immensely in diagnosing problems that come up through compilation and allows you to use the command line when small code or quick and dirty testing code is created and a full IDE just isn't necessary.
The CodeLite does maintain a PPA for ubuntu distributions so you should be able to easily add that to your repository list to get their current build to have a look at it.
Last thing I would say is you seem to want to make a guide for using CodeBlocks. I personally don't like CodeBlocks and if I need to use an IDE on linux I use CodeLite for a couple of reasons.
For one, CodeLite's abilities are less intrusive to me than those of CodeBlocks. Talking about things like code completion mainly.
Second, in order to use CodeLite you need to be more familiar with your tool chain. To me this is a good thing. CodeBlocks automates a lot of the tool chain functions by making checkboxes to turn on/off options. For CodeLite you need to know the command line usage of the tool chain and put those commands into CodeLite's compilation settings. Imo this is better. Knowing your tool chain and how it operates helps immensely in diagnosing problems that come up through compilation and allows you to use the command line when small code or quick and dirty testing code is created and a full IDE just isn't necessary.
The CodeLite does maintain a PPA for ubuntu distributions so you should be able to easily add that to your repository list to get their current build to have a look at it.
18
General / Re: Linking on Linux
« on: November 15, 2015, 08:11:51 pm »That seems to have got it working (full rebuild) except for the fact that I was relying on C++14, which the version of g++ that came with Ubuntu doesn't support, so I'll have to find out how to update that (EDIT: found out how) and then rebuild the libraries using CMake. Thanks for the information on ldd Spirro. Would it be possible to get the fact that winmm and gdi32 are only necessary on Windows and that all the other libraries have to be linked put into the codeblocks tutorial, seeing as codeblocks is multiplatform so I don't think it's right to make the tutorial only for Windows.winmm and gdi32 ARE Windows only. If you want the tutorial updated for linux you will need to learn how to make a fully working compile on your distribution and submit it for review to one of the maintainers of SFML and see what happens.
I believe the reasoning behind not providing a library listing for static linking on linux is that static linking on linux is more frowned upon than on any other OS.
One of the big reasons I did not like using the ubuntu distributions is that the tool chains were a few generations behind the most current up to date tool chain(speaking mostly of gcc here, but also cmake, git, g++, etc...). That's why I moved to arch. There are tutorials out there to upgrade the default gcc compiler chain, but I never got them to fully work properly after upgrading.
And if you do not mind, please post what you linked to get a fully working static link on ubuntu. I got it almost fully working. I just need to investigate how opengl is being linked to fix the display of the 'shape' in the example tutorial code.
19
General / Re: Linking on Linux
« on: November 15, 2015, 07:27:28 pm »
First, let me restate I am running arch so to get things to work some, if not all, of the linker options I listed before will have different names on ubuntu distibutions. The method I used to get things as far as I did was to compile with options:
http://www.sfml-dev.org/tutorials/2.3/compile-with-cmake.php
as reference to give me a good guess at where in the link order to put the added library for linking. Now the shape was not drawn properly on my last attempt last night, but the program compiled and gave me a symptom to look in to to fix it.
Second, those errors look a lot like one of the beginning points I made in that it seems the wrong toolchain is being used. i386 architecture tends to be 32bit and the linker is, I think, trying to use a 32bit lib with 64bit libs. That's something you need to look in to. If you can, start from scratch and use the method above to see if you can follow the chain of errors to figure out the right libs to include and see if that works out, but you do still need to look at the tool chain.
Personally I never liked any full ubuntu distributions. If you like that one then get more info on it. Particularly information on compiling from source and linking.
There is also a tool for linux called 'ldd' look it up. With that tool you can run it on the various SFML .so files and it will list out the dependencies that library has. That will help you figure out what you need to link.
Edit: dabbertorres posted while I was typing this up and backed up my thoughts that you need to check your tool chain and linked libs to find out what they are doing.
Quote
sfml-graphics-s;sfml-window-s;sfml-system-s;freetype;jpeg;I believe(booted to windows on the reply.) The one difference is I probably had a mesa lib after sfml-system-s. What would happen here are lots of unresolved references so I would grab the one at the top of the list and search on it. Once I found what library that reference belonged to I would include it by using this page:
http://www.sfml-dev.org/tutorials/2.3/compile-with-cmake.php
as reference to give me a good guess at where in the link order to put the added library for linking. Now the shape was not drawn properly on my last attempt last night, but the program compiled and gave me a symptom to look in to to fix it.
Second, those errors look a lot like one of the beginning points I made in that it seems the wrong toolchain is being used. i386 architecture tends to be 32bit and the linker is, I think, trying to use a 32bit lib with 64bit libs. That's something you need to look in to. If you can, start from scratch and use the method above to see if you can follow the chain of errors to figure out the right libs to include and see if that works out, but you do still need to look at the tool chain.
Personally I never liked any full ubuntu distributions. If you like that one then get more info on it. Particularly information on compiling from source and linking.
There is also a tool for linux called 'ldd' look it up. With that tool you can run it on the various SFML .so files and it will list out the dependencies that library has. That will help you figure out what you need to link.
Edit: dabbertorres posted while I was typing this up and backed up my thoughts that you need to check your tool chain and linked libs to find out what they are doing.
20
General / Re: Linking on Linux
« on: November 15, 2015, 01:57:02 am »
Ok so being the anal personally I am I just had to investigate more. I remembered trying to static link on linux before so I tried again and of course failed. I investigated a lot further and here is where I am stopping for now after looking at it a couple of hours. I do no use an ubuntu variant anymore. Previously I used mint, but run arch now. I tried staticly compiling the source on this page:
sfml-graphics-s;sfml-window-s;sfml-system-s;OSMesa;GL;freetype;xcb-image;jpeg;udev;pthread;xcb-randr;xcb;X11;X11-xcb
I do get it to compile and link, but not work entirely. I get the following message from the command console:
I didn't investigate further because I'm hungry and it's been a while so stopping to eat and may look at it later tonight. But for your information, this is what I send to the linker to get it to compile:
Hopefully this is enough information for someone better informed than I to point out the problem. My guess is I need to check and see if I have hardware accelleration enabled and check to see why when I link I am using opengl 0.0(if that's actually true?).
Edit: Forgot to mention that the window opens and displays at the settings dictated, but the shape is not displayed. Hence the notation in the command window by SFML.
sfml-graphics-s;sfml-window-s;sfml-system-s;OSMesa;GL;freetype;xcb-image;jpeg;udev;pthread;xcb-randr;xcb;X11;X11-xcb
I do get it to compile and link, but not work entirely. I get the following message from the command console:
Quote
Warning: The created OpenGL context does not fully meet the settings that were requested
Requested: version = 1.1 ; depth bits = 0 ; stencil bits = 0 ; AA level = 0 ; core = false ; debug = false
Created: version = 0.0 ; depth bits = 24 ; stencil bits = 0 ; AA level = 0 ; core = false ; debug = false
sfml-graphics requires support for OpenGL 1.1 or greater
Ensure that hardware acceleration is enabled if available
I didn't investigate further because I'm hungry and it's been a while so stopping to eat and may look at it later tonight. But for your information, this is what I send to the linker to get it to compile:
Quote
sfml-graphics-s;sfml-window-s;sfml-system-s;OSMesa;GL;freetype;xcb-image;jpeg;udev;pthread;xcb-randr;xcb;X11;X11-xcb
Hopefully this is enough information for someone better informed than I to point out the problem. My guess is I need to check and see if I have hardware accelleration enabled and check to see why when I link I am using opengl 0.0(if that's actually true?).
Edit: Forgot to mention that the window opens and displays at the settings dictated, but the shape is not displayed. Hence the notation in the command window by SFML.
21
General / Re: Linking on Linux
« on: November 14, 2015, 11:48:26 pm »
I don't think I have anything else I can add here then, unless what I am reading is that you need to link to 2 libraries, not just one. That's something you'll need to investigate to see if there is another lib file to add to your linker settings from one of those two areas.
22
General / Re: Linking on Linux
« on: November 14, 2015, 11:38:34 pm »
If you read the quote I posted again it states you have to link against:
Are you checking to make sure your libraries match both criteria?
Quote
libX11-xcb and a version of Xlib built with XCB support
Are you checking to make sure your libraries match both criteria?
23
General / Re: Linking on Linux
« on: November 14, 2015, 11:26:58 pm »Firstly, I've been working off those and going over them carefully, I'm fully aware of how precise you have to be. Secondly, I've got rid of gdi and winmm from the linker and that's got rid of those errors, I now have only a single error which is undefined reference to XGetXCBConnection. I've gone back through the libraries that you have to install for Linux and rechecked all the ones to do with XCB and I'm fairly sure I'm not missing any. Any ideas? And thanks everyone for all the help, I know how annoying the constant I can't set it up posts can be.
A quick search found this: http://manpages.ubuntu.com/manpages/maverick/man3/XGetXCBConnection.3.html
Quote
The XGetXCBConnection function returns the XCB connection associated
with an Xlib Display. Clients can use this XCB connection with
functions from the XCB library, just as they would with an XCB
connection created with XCB. Callers of this function must link to
libX11-xcb and a version of Xlib built with XCB support.
Maybe that helps.
24
General / Re: Linking on Linux
« on: November 14, 2015, 11:19:11 pm »gdi and winmm are Windows only.
I never had the problems shadowmouse is having, but if the above is the case then imo shadowmouse should toss his compilation from before and redo it making 100% sure he's correctly followed instructions on the pages I linked earlier in the thread.
Edit: Also be sure the proper toolchain is being used for compilation. I'm sure it was, but if windows versions of libs are being asked for then perhaps a MinGW crosscompilation tool chain was used? I don't know, but check something along those lines as well.
25
General / Re: Linking on Linux
« on: November 14, 2015, 10:09:37 pm »Yes I do have the 64 bit install, which I hadn't realised would be a problem. I'll have a look into catfish, and what do you mean by the mesa 32 bit drivers?
Some programs on linux require their 32 bit versions to run. For example, I don't know if you use steam on linux or not, but the client is 32bit so even on a 64 bit install it pulls in 32 bit versions of several libs so it will work properly. Mesa is one of the video driver sets and it has two versions. 64 bit and 32 bit. From what you last posted as needing, opengl32 and gdi32 that tells me you need the 32 bit versions of those libs. You'll just have to check your repo for 32 bit versions of those drivers, and install them as well. Again, I'm guessing you need the 32 bit mesa drivers, but check your hardware to be sure of what particular video driver you need. For gdi do the same.
26
General / Re: Linking on Linux
« on: November 14, 2015, 07:49:04 pm »I've installed the libraries using cmake and checked and it made all the files and things, but Codeblocks says it can't find -lopengl32 -lwinmm or -lgdi32, and I can't find any of those in the Ubuntu package manager and CMake built it, indicating that I had installed all the necessary libraries. What am I doing wrong?
EDIT: I forgot to say, but I'm linking statically and I built the project in CMake as a Codeblocks- Unix Makefile.
I'm guessing you are using a 64 bit install. With your system saying it needs opengl32 and gdi32 you will have to install the 32bit versions. For opengl it should be the mesa 32 bit drivers. gdi I'd have to look(on windows atm) I forget what winmm was when I installed dependencies, but if you install catfish from your repo you can use it as a gui to search your computer for those files to see if they are actually there and you need to export links to them if they are.
27
Graphics / Re: I have been toying with sprites and textures and found an oddity
« on: November 14, 2015, 07:44:28 pm »
Thank you Hapax. As I posted this is kind of a trial period so I will just make adjustments to get things the way I expected them to be.
28
Graphics / Re: I have been toying with sprites and textures and found an oddity
« on: November 14, 2015, 06:49:09 pm »Please post a complete and minimal example that shows the problem. The code you showed doesn't show the transformations you are using so we can't try to reproduce the problem. It might even be a good idea to include the texture you are using.
Yes you're right. At the time of posting I didn't think that was necessary, but after sleeping on it I figured it out. I do rotate the sprite 90 degrees to change the direction it faces and that would be the problem with the inverted width and height, but I don't understand why it would be implemented that way. To me, the new width and height would be the desired returns from getting the bounding box.
29
Graphics / I have been toying with sprites and textures and found an oddity
« on: November 14, 2015, 06:53:11 am »
I have been working on various things setting up for a small game program and came across something odd. I am no an artist by any stretch so I found a placeholder graphic on opengameart to use as a ship, however I couldn't find a suitable size. I thought scaling would be fine so I did so and plopped the sprite in the middle of the display and it looked off. Thinking it had to do with the scaling I investigated a little.
The image is 150 by 120 pixels and the render area is 320 by 200. I scaled the image by 0.5f for both width and height, placed it at what should be the center of the render area and printed out the screen render size, sprite global bound and local bounds in the console window. What was odd to me is that the local bounds size of the sprite shows to be 150 width and 120 height, just as the original image, but the global shows as 60 width and 75 height. Note that the values are inverted. It should show as 75 width and 60 height. I did make sure to recheck the code used and it seemed in the proper order.
Note that shipSprite is defined as sf::Sprite higher up in the code.
Edit: Sorry I forgot to put the version of SFML I used was compiled from the master branch on GIT. 2.3.x
The image is 150 by 120 pixels and the render area is 320 by 200. I scaled the image by 0.5f for both width and height, placed it at what should be the center of the render area and printed out the screen render size, sprite global bound and local bounds in the console window. What was odd to me is that the local bounds size of the sprite shows to be 150 width and 120 height, just as the original image, but the global shows as 60 width and 75 height. Note that the values are inverted. It should show as 75 width and 60 height. I did make sure to recheck the code used and it seemed in the proper order.
Code: [Select]
sf::FloatRect shipBounds;
shipBounds = shipSprite.getLocalBounds();
std::cout << "Ship local bounds size...X: " << shipBounds.width << " Y: " << shipBounds.height << std::endl;
shipBounds = shipSprite.getGlobalBounds();
std::cout << "Ship global bounds size...X: " << shipBounds.width << " Y: " << shipBounds.height << std::endl;
Note that shipSprite is defined as sf::Sprite higher up in the code.
Edit: Sorry I forgot to put the version of SFML I used was compiled from the master branch on GIT. 2.3.x
30
General / Re: Linking on Linux
« on: November 13, 2015, 09:15:34 pm »I've just switched from using Windows 10 to using Ubuntu and installed libsfml-dev using the Ubuntu Software Centre. However I'm confused, as the package that is installed contains only header files and when I attempt to link to the libraries in codeblocks, it says it cannot find -lsfml-graphics-s etc. Am I missing something? Do you have to compile the library yourself if you download it from the software centre (option 1 in the tutorial)? Sorry if it's a stupid question.
Generally speaking, on linux, when you install a dev package it installs the headers and binaries, but seems as though that didn't happen in your case. You can look at the dev package you installed and find the matching binary package and install it as well, or as Roseme suggested, compile and install it yourself. Information on that is found here:
http://www.sfml-dev.org/tutorials/2.3/start-linux.php
and here:
http://www.sfml-dev.org/tutorials/2.3/compile-with-cmake.php
Just be sure to fully read the first page as installing from source tends to put libraries in non-standard locations, so to use what you have compiled you will need to set environment variables properly so the system can find what it needs to run your programs.