Messages

1

Graphics / Re: Weird error in sf::Font initialization

« on: July 04, 2014, 02:46:18 pm »

Ah yes, cache! Now works.

2

Graphics / Re: Weird error in sf::Font initialization

« on: June 29, 2014, 12:44:18 pm »

@Nexus, i mean, FindSFML.cmake doesn't even check that lib-files exist. Does it just assemble library path based on include path instead of actually looking for libs?

3

Graphics / Re: Weird error in sf::Font initialization

« on: June 29, 2014, 02:54:50 am »

@Nexus,
Reordering libs gives no effect.
SFML_LIBRARIES contain /usr/local/lib64/libsfml-graphics.so/usr/local/lib64/libsfml-window.so/usr/local/lib64/libsfml-system.so
Minimal example was compiling with -g and -O0 already.


Now things i did (note it's 4:49 am here, maybe i missed something):
1. I removed libsfml package in my package manager, deleted libsfml* in usr/local/lib64. Installed libsfml back in package manager. To get a fresh start, yeah.

2. Rerunned cmake and somehow it still find libsfml in /usr/local/lib64. Of course build failing as there is no such files. I've exported SFML_ROOT=/usr/lib64/ where .so really are. Cmake still finds libsfml in /usr/local/lib64.

3. Okay, i'll try other way. Commented out lines with find_package and related checks, replaced target_link_libraries with that:

target_link_libraries("Test" /usr/lib64/libsfml-graphics.so
        /usr/lib64/libsfml-window.so /usr/lib64/libsfml-system.so)

to eliminate any FindSFML module influence.

With libs specified explicitly, font initialised fine.

I guess i had leftovers of libsfml 1.6 in /usr/local/lib64 and at the same time FindSFML wasn't checking /usr/lib sticking to /usr/local/lib instead and linking with libs of 1.6 version. Now leftovers gone and i'm sure libs installed are fine and not corrupted and code okay and cmake okay too. FindSFML is probably guilty of all that, what do you think? 

4

Graphics / Re: Weird error in sf::Font initialization

« on: June 28, 2014, 12:29:41 am »

Were you able to reproduce it?

5

Graphics / Re: [SOLVED] Weird error in sf::Font initialization

« on: June 22, 2014, 09:12:07 pm »

@Nexus, inside pretty long FindSFML.cmake and Terminus.ttf font, same as in my game, though you may try with any other font, i guess it doesn't matter anyway. Cmake module could be taken from repo as separate file.

I don't link window because error reproduces without it. (Should i link anyway?).
Linking order didn't change anything: cmake build still broken, manual still ok.
Anyway here is CMakeLists.txt

cmake_minimum_required(VERSION 2.8)

project(Test)

set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -g -O0 -std=c++11")
set (CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake_modules" ${CMAKE_MODULE_PATH})

set (TEST_SOURCE test.cpp)

add_executable("Test" ${TEST_SOURCE})

find_package(SFML 2 REQUIRED window graphics system)
if(SFML_FOUND)
        include_directories(${SFML_INCLUDE_DIR})
endif()


target_link_libraries("Test" ${SFML_LIBRARIES})

file (COPY Terminus.ttf DESTINATION ${CMAKE_CURRENT_BINARY_DIR})
 

And test.cpp:

#include <SFML/Graphics.hpp>

int main(int argc, char* argv[])
{
        sf::Font font;
        font.loadFromFile("Terminus.ttf");
        sf::Text text("OOPS", font, 14);
        return 0;
}
 

6

Graphics / Re: [SOLVED] Weird error in sf::Font initialization

« on: June 22, 2014, 08:44:59 pm »

dafuq. It appears i already was using official cmake module. It links against libs in /usr/local, which symlinks to my /usr/lib and /usr/includes, so libs and includes themselves are ok.

A bit more experimenting and i managed to make minimal example (attached). Example doesn't crash like my game, but font is corrupted. And i don't know if it would reproduce outside of my machine.

So:

1. unpack
2. mkdir build
3. cd build
4. cmake ..
5. make
6. break on line 7 of Test executable and inspect font variable
7. ???
8. m_pages = std::map with 140737488347824 elements<error reading variable: Cannot access memory at address 0x18>
 

Now do:

1. rm -rf * (inside build dir)
2. g++ -g ../test.cpp -lsfml-system -lsfml-graphics
3. break on line 7 of a.out and inspect font variable
4. ???
5. m_pages = std::map with 0 elements
 

ldd output of bad executable:

ldd Test
        linux-vdso.so.1 (0x00007fffdcc00000)
        libsfml-system.so.2 => /usr/local/lib64/libsfml-system.so.2 (0x00007fdd06d90000)
        libsfml-graphics.so.2 => /usr/local/lib64/libsfml-graphics.so.2 (0x00007fdd06b48000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007fdd06840000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fdd06548000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007fdd06330000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fdd05f88000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fdd05d68000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fdd05b60000)
        libsfml-window.so.2 => /usr/lib64/libsfml-window.so.2 (0x00007fdd05948000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007fdd056a0000)
        libGLEW.so.1.10 => /usr/lib64/libGLEW.so.1.10 (0x00007fdd05410000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007fdd051b8000)
        libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007fdd04e68000)
        libSM.so.6 => /usr/lib64/libSM.so.6 (0x00007fdd04c60000)
        libICE.so.6 => /usr/lib64/libICE.so.6 (0x00007fdd04a40000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007fdd04708000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007fdd044f0000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007fdd042e0000)
        libudev.so.1 => /lib64/libudev.so.1 (0x00007fdd07178000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fdd06fa0000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fdd040c8000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fdd03eb8000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007fdd03c80000)
        libnvidia-tls.so.340.17 => /usr/lib64/libnvidia-tls.so.340.17 (0x00007fdd03a78000)
        libnvidia-glcore.so.340.17 => /usr/lib64/libnvidia-glcore.so.340.17 (0x00007fdd00e60000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fdd00c58000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fdd00a50000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007fdd00830000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007fdd00620000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007fdd00418000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007fdd00210000)
 

Good:

        linux-vdso.so.1 (0x00007fff75ff8000)
        libsfml-system.so.2 => /usr/lib64/libsfml-system.so.2 (0x00007f6adff08000)
        libsfml-graphics.so.2 => /usr/lib64/libsfml-graphics.so.2 (0x00007f6adfcd0000)
        libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6 (0x00007f6adf9c8000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f6adf6d0000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libgcc_s.so.1 (0x00007f6adf4b8000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f6adf110000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6adeef0000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f6adece8000)
        libsfml-window.so.2 => /usr/lib64/libsfml-window.so.2 (0x00007f6adead0000)
        libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f6ade828000)
        libGLEW.so.1.10 => /usr/lib64/libGLEW.so.1.10 (0x00007f6ade598000)
        libjpeg.so.62 => /usr/lib64/libjpeg.so.62 (0x00007f6ade340000)
        libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f6addff0000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6ae0118000)
        libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f6addcb8000)
        libXrandr.so.2 => /usr/lib64/libXrandr.so.2 (0x00007f6addaa8000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f6add890000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f6add680000)
        libpng16.so.16 => /usr/lib64/libpng16.so.16 (0x00007f6add448000)
        libnvidia-tls.so.340.17 => /usr/lib64/libnvidia-tls.so.340.17 (0x00007f6add240000)
        libnvidia-glcore.so.340.17 => /usr/lib64/libnvidia-glcore.so.340.17 (0x00007f6ada628000)
        libXext.so.6 => /usr/lib64/libXext.so.6 (0x00007f6ada410000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f6ada208000)
        libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f6ad9fe8000)
        libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x00007f6ad9dd8000)
        libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f6ad9bd0000)
        libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f6ad99c8000)

I guess there is something with cmake

7

Graphics / Re: Weird error in sf::Font initialization

« on: June 22, 2014, 07:41:34 pm »

Found the thing. SFML libraries was wrong, so Nexus was right after all.
Cmake in game project was linking against sfml libs from /usr/local/ and in minimal examples i was linking with -lsfml-smth which was linking against libs from /usr/lib64. I only spotted difference by diffing ldd output for good and bad executables.

I'm using FindSFML.cmake module copypasted somewhere from internet and /usr/include and /usr/lib is not even in search path there. Though i don't know how it managed to find libs in /usr/local (which was never there, as emerge installs libsfml into proper /usr/{include,lib}. But whatever.

Is there official cmake module for finding sfml?

p.s. sorry for being an ass.

8

Graphics / Re: Weird error in sf::Font initialization

« on: June 22, 2014, 05:08:38 pm »

I can't provide minimal example, unfortunately. As i said earlier - same construction works as minimal example, but doesn't work ingame. I'm asking for some clues where to look for a problem. I don't know where to look exactly because font already malformed after initialization and my code doesn't use multithreading.
(I checked library, it's the same sfml that cmake was founding before crash appeared, now i'm emerging it with debug flags to look inside)

UPD. I'm confused. Through git bisecting i found that that crash present in very first commit where line with font loading is added.

9

Graphics / Re: Weird error in sf::Font initialization

« on: June 22, 2014, 01:20:48 am »

Well then, does anybody got an idea why sf::Font initializes itself with m_pages being std::map with insane number of elements somewhere in 0x000000018?

10

Graphics / Re: Weird error in sf::Font initialization

« on: June 17, 2014, 04:48:52 pm »

Erm... Should i report a bug?

11

Graphics / [SOLVED] Weird error in sf::Font initialization

« on: June 13, 2014, 02:06:34 pm »

Hi, recently my game begin segfaulting with this backtrace

Code: [Select]

Program received signal SIGSEGV, Segmentation fault.
memset () at ../sysdeps/x86_64/memset.S:78
78 ../sysdeps/x86_64/memset.S: No such file or directory.
(gdb) bt
#0  memset () at ../sysdeps/x86_64/memset.S:78
#1  0x00007ffff7994711 in sf::Font::loadGlyph(unsigned int, unsigned int, bool) const () from /usr/local/lib64/libsfml-graphics.so.2
#2  0x00007ffff7994e69 in sf::Font::getGlyph(unsigned int, unsigned int, bool) const () from /usr/local/lib64/libsfml-graphics.so.2
#3  0x00007ffff79b7533 in sf::Text::updateGeometry() () from /usr/local/lib64/libsfml-graphics.so.2
#4  0x00007ffff79b7e83 in sf::Text::Text(sf::String const&, sf::Font const&, unsigned int) () from /usr/local/lib64/libsfml-graphics.so.2
#5  0x0000000000506286 in Computers::Software::Programs::UpperPanel::UpperPanel (this=0x79ac50, os=...) at /home/anrock/Documents/cprl/src/Computers/Software/Programs/UpperPanel.cpp:10
#6  0x00000000005029e4 in Computers::Software::Programs::ProgramFactory::spawn (os=..., id="UpperPanel") at /home/anrock/Documents/cprl/src/Computers/Software/Programs/ProgramFactory.cpp:25
#7  0x00000000004fdf63 in Computers::Software::OperatingSystem::start (this=0x7942a0) at /home/anrock/Documents/cprl/src/Computers/Software/OperatingSystem.cpp:98
#8  0x00000000004f7f51 in Computers::Computer::turnOn (this=0x7fffffffb2a0) at /home/anrock/Documents/cprl/src/Computers/Computer.cpp:44
#9  0x00000000004ec624 in ____C_A_T_C_H____T_E_S_T____14 () at /home/anrock/Documents/cprl/Tests/TestCp.cpp:23
#10 0x00000000004b3396 in Catch::FreeFunctionTestCase::invoke (this=0x74e770) at /home/anrock/Documents/cprl/Tests/catch.hpp:5414
#11 0x00000000004a3a25 in Catch::TestCase::invoke (this=0x74a7d0) at /home/anrock/Documents/cprl/Tests/catch.hpp:6282
#12 0x00000000004b135d in Catch::RunContext::runCurrentTest (this=0x7fffffffddf0, redirectedCout="", redirectedCerr="") at /home/anrock/Documents/cprl/Tests/catch.hpp:5027
#13 0x00000000004b033d in Catch::RunContext::runTest (this=0x7fffffffddf0, testCase=...) at /home/anrock/Documents/cprl/Tests/catch.hpp:4873
#14 0x00000000004b1e2b in Catch::Runner::runTestsForGroup (this=0x7fffffffe010, context=..., filterGroup=...) at /home/anrock/Documents/cprl/Tests/catch.hpp:5164
#15 0x00000000004b1b23 in Catch::Runner::runTests (this=0x7fffffffe010) at /home/anrock/Documents/cprl/Tests/catch.hpp:5145
#16 0x00000000004b2ad0 in Catch::Session::run (this=0x7fffffffe300) at /home/anrock/Documents/cprl/Tests/catch.hpp:5287
#17 0x00000000004b299e in Catch::Session::run (this=0x7fffffffe300, argc=1, argv=0x7fffffffe4c8) at /home/anrock/Documents/cprl/Tests/catch.hpp:5270
#18 0x00000000004a71ba in main (argc=1, argv=0x7fffffffe4c8) at /home/anrock/Documents/cprl/Tests/catch.hpp:8247
Font loaded like this:

        if (!SystemFont.loadFromFile("Resources/Fonts/Terminus.ttf"))
                std::cerr << "Can't load font" << std::endl;
 

No error reported

Then sf::Text field is initialized with this font in another class like this:

username(OS.getUsername(), OS.getFont(), 14)

getUsername() returns std::strings and getFont() returns reference to loaded font.

Now about weirdness i've found.
GDB's "p SystemFont" before SystemFont is initialized looks like this:

SystemFont = {m_library = 0x0, m_face = 0x0, m_streamRec = 0x0, m_refCount = 0x0, m_pages = std::map with 0 elements, m_pixelBuffer = std::vector of length 0, capacity 0}

and after call to loadFromFile:

SystemFont = {m_library = 0x794680, m_face = 0x799cc0, m_streamRec = 0x0, m_refCount = 0x790cd0, m_pages = std::map with 7947120 elements<error reading variable: Cannot access memory at address 0x18>,
  m_pixelBuffer = std::vector of length 0, capacity 0}

I've tried to make minimal code:

#include <SFML/Graphics.hpp>
#include <iostream>

int main(int argc, char* argv[])
{
        sf::Font font;
        if (!font.loadFromFile("Resources/Fonts/Terminus.ttf"))
                std::cerr << "Font not loaded";
        return 0;
}

and look at font after initialization... and it was initialized ok!

font = {m_library = 0x604db0, m_face = 0x6030f0, m_streamRec = 0x0, m_refCount = 0x604a40, m_pages = std::map with 0 elements, m_pixelBuffer = std::vector of length 0, capacity 0}

Also about weirdness: i didn't alternate font loading and related code for a long while. It just suddenly stopped working.

12

Graphics / Re: Text blurred on some positions

« on: April 14, 2014, 01:43:22 pm »

Woah, guys, i made it. Such a trivial edit, lol.

upperPanel.setViewport({0,              0,              0.75f, 0.025f}); //Set panels ratios.
mainPanel.setViewport ({0,              0.025f, 0.75f, 0.975f});
rightPanel.setViewport({0.75f,  0,              0.25f, 1});

Method for setting size of panel (view). Fix is to std::floor calculation result

void OperatingSystem::adjustPanel(const sf::RenderWindow& win, sf::View& view)
{
        view.reset({0.f, 0.f,
                        std::floor(win.getSize().x * view.getViewport().width), //std::floor it!
                        std::floor(win.getSize().y * view.getViewport().height)}); //this too
}

13

Graphics / Re: Text blurred on some positions

« on: April 14, 2014, 12:19:18 am »

Okay, i'll fiddle some more with views and resort to rendering textures if fail.

14

Graphics / Re: Text blurred on some positions

« on: April 13, 2014, 07:34:33 pm »

>Unfortunately, the conflict between text and viewports is probably unavoidable.  Text that gets upscaled or downscaled *after* being rendered is going to look strange unless it happens to get scaled by just the right factor.  SFML can't do anything about that.
And no way to make view not-scaled? Geez, i couldn't ever imagine taking rect area of window would be so hard.

>I have no idea what your scaling needs are (can the user resize each GUI region? or do they all have fixed sizes? a finite selection of sizes?)
User can't resize any window. Views have fixed ratios and sizes are changed depending on window size to keep this ratios.

> my gut feeling is that your subprocesses should only get the data to display in each window, and there should be a separate process for rendering everything (ie, separate graphics from game logic), which would use the default view for drawing the terminals/windows.
I don't think this would be nice solution. You see, this big main panel is where interactive proccesses are run. And they could be just anything - from simple text terminal to gui email client or tetris or whatever. Right now i can inherit class from ProgramBase (with update, draw, input and reference to host-OS) and do whatever i want inside this process and then just render to passed view. If i put all rendering to OS class - it's going to become hardly maintanable god object also making writing new process very-very hard. 

15

Graphics / Re: Text blurred on some positions

« on: April 13, 2014, 05:02:27 pm »

Well, yes, i am trying to do pretty much what you said. For explanations why, please this topic:
http://en.sfml-dev.org/forums/index.php?topic=14759.0
Views worked out well, except this text issues.