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

Pages: [1]
1
After a lot of running around I haven't gotten very far.

While snooping around I did notice https://github.com/SFML/SFML/pull/2442 which added Mesa support in order to allow software rendering in the CI. Is it possible to compile SFML to use Mesa and LLVMpipe in order to sidestep the driver issue? The performance hit would be irrelevant in my use case, since I'm only drawing one frame.

2
I'll try asking the OSMC people about it and also hunt around google a bit more. If I figure it out I'll post the solution here.

Thank you for helping me get this far!

3
So I grabbed the SFML 2.6.x source from GitHub, and I installed as follows:
Quote
mkdir build
cd build
cmake .. -DSFML_USE_DRM=TRUE
make -j4
sudo make install
sudo ldconfig

and then I was able to build my project with:
Quote
g++ main.cpp -lsfml-system -lsfml-graphics -o imgGen.exe

but when I run the exe I get:
Quote
No drm device found!
Could not open drm device
Error initializing DRM
Segmentation fault

I'm not familiar with DRM. Do I need to install/include some driver libraries for it or something?

--

Reading a little more about it, it seems that it has something to do with "/dev/dri/card*". I have card0 and card1 in there.

4
Oh, cool.

Thank you!  ;D

5
General / Run SFML without a window for linux with no X11 installed
« on: March 06, 2023, 01:55:41 am »
Hello. I've used SFML in Windows to create a utility that will generate a png representation of some text data. The program does not create a window, since it's just rendering to an sf::RenderTexture and then getting the texture out of that and saving it to a file. I'm intending to use this on a Raspberry Pi 4 that's running OSMC (2022.03-1) in order to generate a background image for my media center.

I was able to install SFML and compile the program, but when I try to run the program I get the output:
Quote
Failed to open X11 display; make sure the DISPLAY environment variable is set correctly

X is not installed on this device, since the OS generates its own GUI. I'm wondering if there's something I can do to bypass the requirement for it, since SFML is not being required to draw to the screen. I'm fine with downloading the SFML source and making changes, but I'm not familiar enough with the situation to know where to start looking.

Any advice would be greatly appreciated.   :D

6
SFML website / Re: Binaries for VC++ 2015
« on: September 28, 2015, 09:35:15 pm »
Setting the Debug Information Format to C7 Compatible will prevent generation and references to pdb files. Alternatively, ensuring that the Program Database File Name is set to a non-static path should fix it, but "things happen".

The pdb files are only relevant if users want to actually step into the SFML code files from the debugger, so the /Z7 option may be the better method since not many users actually have the SFML code laying around in the correct locations for the debugger to open and step into.

Image is attached showing the location of the option in the IDE.

Note that this is only relevant in debug builds. If the /DEBUG flag isn't on then pdb's aren't generated. I think it may disable the /Gm option, which is part of minimal rebuild, but since you're building libs that's not really relevant for the final product.

Edit: After reviewing the C7 option, it turns out that it just embeds the symbol information in the lib itself rather than in a separate file, so you're actually not losing any debug capability by going that route.

7
SFML website / Re: Binaries for VC++ 2015
« on: September 28, 2015, 09:21:05 pm »
Not sure if you caught my very subtle request or not, so I'll state it explicitly:

In the future please compile libs without static pdb paths, as it causes problems for end-users.


8
SFML website / Re: Binaries for VC++ 2015
« on: September 28, 2015, 07:49:02 pm »
Thank you for the speedy response. Those build but I get pdb errors as follows:
(click to show/hide)

Would rebuilding them with CMake help this?

Edit: Rebuilding from CMake still gives the link errors. Is the source release not updated yet? It would be helpful if the download links were dated.

9
SFML website / Re: Binaries for VC++ 2015
« on: September 28, 2015, 07:36:01 pm »
Hey, I'm trying to compile statics and I'm getting a couple linker errors. I can't seem to resolve them by pulling in the rebuilt deps that people are suggesting, so I'm wondering if I'm missing a dep or something.

I'm using VS2015 on Win7 Ultimate x64 (all of my build stages are x86).

The contents of my lib folder are as follows:
(click to show/hide)

This is the file I use for linking, which gets included once at the entry point:
(click to show/hide)

And this is my build output:
(click to show/hide)

I've tried getting the extlibs from eXpl0it3r's repo, but they appear to match the binaries that are included with the SFML source. (I tried them anyway and got the same errors.) I tried following the link posted by Nexus here, but it's a dead link.

In case it's relevant, my CMake config is as follows:
(click to show/hide)

Any help or advice would be greatly appreciated.

10
General / Re: Stack corruption with static linkage
« on: April 07, 2015, 01:47:07 am »
It usually happens when you mix Release/Debug (or otherwise different configurations). When you built SFML yourself, have you paid attention to build exactly the same configuration, with same compiler version and settings?

Yes, but since it's failing I suppose I can try starting the whole thing over from scratch in case I've changed a project setting somewhere along the line and forgotten about it.

Why is there <Windows.h> and a WinMain() function? Remove that and use a standard main(), the point of SFML is to avoid platform dependent code ;)

I appreciate that portability is one of the design goals of SFML, but from a usage standpoint that's not the feature I'm interested in for this project. Using the SFML main would obfuscate the arguments to WinMain(), which I may want to use at a later point.

Edit:
How infuriating. I replicated the project starting from scratch and it works correctly.

I made a specific point of not fiddling with the project properties, but apparently something was changed or else just went insane on its own. Oh well.

Thanks for the response.

Issue resolved: PEBKAC

11
General / Stack corruption with static linkage
« on: April 06, 2015, 03:41:58 pm »
Hello.

I'm trying to get SFML 2.2 to link statically in VS2013.

I'm building in debug mode targeting x86.

I'm linking to the following libraries:
SFML:
sfml-main-d
sfml-system-s-d
sfml-network-s-d
sfml-audio-s-d
sfml-window-s-d
sfml-graphics-s-d

Misc Deps:
openal32
sndfile
freetype
glew
jpeg

OS:
ws2_32
opengl32
winmm
gdi32

I've done this with the binaries provided in the SFML 2.2 release and also with binaries I built locally by following the cmake tutorial.

I'm compiling and running the following code:
(click to show/hide)

When I run the project in the debugger, as I close it I get a notification from VS that the stack around 'window' is corrupted. Do I need to link different versions of the dependencies or is there some other problem that I'm missing here?

Pages: [1]
anything