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.


Topics - Ixrec

Pages: [1]
1
I haven't done very much with OpenGL, but my understanding is that if SFML 3 were to use only the "modern" shader-based pipeline instead of the fixed functions it currently uses, it would have to do things like apply a drawable's transform matrix inside a vertex shader and a drawable's (interpolated) color(s) inside a fragment shader.

It seems like this would require SFML to have default shaders and shader parameters as implementation details which users like me would have to know about when using our own shader code.  Does this seem like a problem?  Or is sf::Shader a sufficiently "advanced" feature for that to be a non-issue?

2
General discussions / Why is ImageLoader a singleton?
« on: December 28, 2014, 02:37:38 am »
In another thread (http://en.sfml-dev.org/forums/index.php?topic=17106.msg123011#msg123011) someone pointed out that SFML has a "global" variable in the form of the ImageLoader singleton, presumably implying that globals aren't really that bad.  So I looked at the ImageLoader code for a minute to see if there was an obvious reason for that which I could mention in my response...and I couldn't find one.  The ImageLoader class appears to have no state, doesn't inherit from anything with state (there's only an sf::NonCopyable), its constructor/destructor are empty, and I didn't see any static variables or lazy initialization going on in the methods, so it seems like this might as well be a class of only static methods.

So purely out of curiosity, why is ImageLoader a singleton?  Did I miss something, or is it just historical reasons?

3
I'm still trying to set up MinGW and Code::Blocks to use the latest SFML code from Github.  Unfortunately I haven't been able to build and run a single program linked against SFML that doesn't crash (except for two of the examples), though I've had a few that will do something simple like printing Hello World! before crashing.  I can build and run a "pure" Hello World! program from the command line without any problems.  I don't get anything resembling a stack trace so I have no idea which .dll or build setting is wrong.  I also tried downloading the SFML 2.1 libs for MinGW and linking my test program against those, but the crash didn't change.

This is essentially a follow-up to http://en.sfml-dev.org/forums/index.php?topic=16519.0 since my initial problem of CMake/MinGW not working has been resolved.  I am now able to build debug/release/static/dynamic SFML libs from the latest Github source.  The problem now is that any attempt to use them produces crashes.

To try and remove Code::Blocks from the equation (though I did set it to use exactly the same mingw32 binaries I'm building SFML with), I also tried the example programs that get built by CMake/MinGW when I set SFML_BUILD_EXAMPLES to true.  After building I copy all the .dlls from <build dir>/lib and <source dir>/extlibs/bin/x64 into examples/pong (and the other examples that are easy to test).  Then double-clicking pong.exe gets me this:
---------------------------
pong.exe - Application Error
---------------------------
The application was unable to start correctly (0xc000007b). Click OK to close the application.
---------------------------
OK   
---------------------------

Trying the x86 extlib .dlls produces an entirely different problem: The pong window frame will momentarily appear then disappear.  Nothing ever gets drawn inside the frame and there's no indication that an error or crash took place.

The "window" example works perfectly fine for some reason.  The "sound" example did work perfectly fine but for some reason after I rebuilt everything from scratch it started getting the 0xc000007b dialog box.

The "shader", "win32", "opengl" and "shader" examples fail in various ways, from making a window appear and immediately disappear to immediately crashing with the "_ has stopped working" dialog box.

Since all I've got right now is a set of random crashes and not-quite-crashes with no clues to follow up on (and yes, I googled everything, as usual none of the hits were remotely relevant), I need to ask for help again.  What do I need to do to figure out what's wrong with my setup?

4
A few minutes ago, I checked out the latest SFML from github using TortoiseGit, I downloaded and installed cmake-3.0.2-win32-x86.exe from http://www.cmake.org/download/, and I downloaded and installed MinGW Builds from http://sourceforge.net/projects/mingwbuilds/.  After I gave CMake source and build paths, and told it to use CodeBlocks - MinGW Makefiles (or just plain MinGW Makefiles), it fails with the following error:

CMake Error at cmake/Config.cmake:16 (message):
  Unsupported architecture
Call Stack (most recent call first):
  CMakeLists.txt:20 (include)

I'm currently running a Dell Latitude 3540 with Windows 7 Professional 64-bit.  Inspecting the cmake/Config.cmake implies that CMake and/or MinGW is under the impression that my architecture is neither 32-bit nor 64-bit.  I don't have the slightest idea how that could be possible unless one or the other is simply broken (since I've had no trouble with CMake in the past, and I've never ever gotten MinGW to work before, I'm highly inclined to assume the latter is broken somehow).

Note that I also installed CodeBlocks earlier so its version of MinGW may be interfering somehow.  I was going to try specifying native compilers myself in CMake but I can't seem to find where either set of actual compilers was installed (I really hate it when software feels the need to hide itself...)

Searching this forum got me one or two hits that appeared to be completely different problems, and the workaround described in one didn't come close to working so I don't think those are relevant.

Any ideas?


Edit: Found the MinGW binaries that came with CodeBlocks.  Specifying them in CMake did not change the error, so maybe these are the broken ones.  But I still can't find the MinGW Builds binaries so I can't test those.

Edit: The MinGW Builds installer emits an error dialogue containing the text "ERROR res", and then proceeds to finish and claim it installed successfully (hence I forgot about this earlier).  Googling this error got me nothing.

5
General discussions / "Web SFML" using HTML5/Javascript/WebGL
« on: October 27, 2013, 03:00:53 am »
I've been trying to learn a lot about web development lately, and in the back of mind there's always been the idea of "porting" SFML to "the internet" (whatever the correct terms for that are), especially once 2.2 comes out and we have an OpenGL ES implementation to refer to.

Not that I'd actually start working on this anytime soon, but I wanted to ask what people thought of the idea and make sure that some of the rather strong conclusions I'm coming to aren't misguided.  So please correct me if any of these are wrong:

1) If a web page is to contain a "real-time game" of any sort (eg, a platformer as opposed to sudoku), that game's code must run client-side.
2) There is simply no good cross-browser/platform/etc way to do client-side C++.  CGI and FastCGI allow for server-side C++, and the Wt toolkit is based on that sort of thing, but that doesn't help us.
3) The one and only cross-everything client-side web programming language is Javascript.
4) The C++ concept of a "game loop" doesn't cleanly translate to Javascript, so any direct cross-compilation would be a pain in the ass at best (basing this one on my brief tests of emscripten).

Assuming these impressions are correct, it seems like a "web SFML" simply could not be a C++ library, and the closest we could get would be one or more Javascript scripts/.js files with a bunch of convenience functions wrapping around WebGL as well as the event handling/image loading/audio playback/etc already built into HTML5/Javascript.  Perhaps SFMS--Simple and Fast Multimedia Script?  Does anyone here think a project like that would be worthwhile?  Quick googling implies the existing WebGL libraries are mostly 3D engines, not 2D like SFML.  Or would it be better to try and get SFML support into emscripten, like its existing SDL support?

Edit: Now that I've stumbled across Pixi.js, it looks remarkably similar to SFML in spirit, design and graphics functionality (it even calls itself a "fast lightweight 2D library that works across all devices").  I'm gonna spend some time on a detailed comparison of these two.  It might be that the best implementation of "SFMS" is a wrapper of Pixi.js plus whatever bits of SFML it doesn't have but still make sense in a web page (eg, audio).

6
Window / Sporadic Icon Failure in Ubuntu
« on: October 18, 2013, 04:38:16 am »
So I've been trying to figure out how to give an SFML program the right icon or set of icons on each OS so that you see all the right-sized icons in all the right places, just like any professional program.

On Windows and Mac I believe I've already accomplished that (after modifying the SFML source code a little), but on my Ubuntu VM I'm getting some ludicrously inconsistent results, and I have no idea whether to blame myself, SFML, Ubuntu, Unity, X, or VMware.

When building from source I use CMake just as the tutorial describes, with BUILD_SHARED_LIBS turned off (I like static linking) and SFML_BUILD_EXAMPLES turned on (since they make great test programs), and all other variables left on their default values.  The source code itself is the official 2.1 release (I don't recall seeing any chances since then which might affect icons on Linux).

For the record I did a LOT of tests besides what I describe here.  I'm posting this one because here I decided to "steal" Firefox's icon in order to make absolutely sure I wasn't using the wrong size or wrong format or wrong folder or anything like that.

So after building everything, what I did was make a simple desktop entry with "Icon=firefox", since that's the exact line used in Firefox's desktop entry, and have its Exec line point to the SFML example program called "opengl."  I also modified opengl.cpp so that it loads firefox.png into an sf::Image which it then passes to setIcon().  I've confirmed that I'm loading the right firefox.png because changing its name causes the real Firefox to lose its icon too.  I've also confirmed in Pinta that it's exactly 128x128, which is the size I pass to setIcon.

For some strange reason, at best I get the Firefox icon in the sidebar and alt+tab menu but very blurry.  Sometimes I get Ubuntu's placeholder question mark.  And sometimes I get no icon at all; my program simply doesn't appear in the sidebar or the alt+tab list at all.  I've taken screenshots of all three of these cases, with the real Firefox browser running at the same time so you can clearly see the difference in icon resolution.  You can also see the code I added in opengl.cpp and the desktop entry I used and part of the opengl test window itself (with the spinning wooden cube).

These pictures were taken with my iPhone because it appears impossible to take a regular screenshot with the alt+tab menu open.

Case 1: Blurry custom icon in both places, Firefox has non-blurry custom icon


Case 2: Default question mark icon in both places, Firefox still has non-blurry custom icon


Case 3: No icon at all in both places, Firefox still has non-blurry custom icon


These three screenshots were taken during the same series of tests.  All I did was close and reopen the "opengl" test program several times (and I opened it by double clicking on the desktop entry, of course) until all three cases appeared.  How common each one is seems to be completely random, though I feel like the frequency of #2 is correlated to how recently I recompiled.

So, any idea what layer of software I should be blaming for this bizarre behavior?  I want to think it's Unity/Ubuntu, but every other program consistently has a non-blurry custom icon.  So then I want to think it's SFML, but what the hell could it be doing to cause a random distribution of these three behaviors?  I guess it could be VMware, but then it makes no sense that this would only be happening to my test program and nothing else in the VM.

I *think* that's all the potentially relevant information, but do tell me if I left something out.

7
General discussions / SFML on Solaris (failed attempt)
« on: September 22, 2013, 10:27:18 am »
A few days ago I downloaded Solaris because I figured it'd be fun to check out another OS and see if I could get SFML to build in it, since I'm very curious as to how portable C++ code really is across all the *nixes.  The short version is it didn't work (as I expected), but since I don't see any other Solaris threads (ignoring a few from before SFML 2.0 came out), and the errors I got were much stranger than I expected, I thought someone might either be interested in what happened to me or be able to tell me some simple thing I did horribly wrong.

So here's a brief summary of the procedure I went through:

1) Download Oracle's Solaris 11 pre-made VM for VirtualBox.  For some reason it was marked as .gz even though it was supposed to be a .tgz, so I had to manually add the tar part before I could extract the .ova file you're supposed to give VirtualBox.

1a) Make sure you enable 3D hardware acceleration (or else OpenGL won't do much) as well as audio (or else OpenAL won't do much).  The default ICH audio chip worked fine for me.  I believe these are the only VirtualBox settings you should have to mess with.

2) Boot and install Solaris like any other OS.

3) Inside Solaris, download the CMake package, the GLEW sources and the OpenAL Soft sources.  Compile GLEW and OpenAL Soft yourself, then copy the headers and libraries into any of the standard *nix directories for them so that CMake can locate them. (this part took me days to figure out even though in retrospect it was pretty straightforward and easy; let's just say it was a very educational experience)

3a) For some reason Solaris' CMake has a curses interface instead of regular GUI.  Fortunately, adapting to it is really easy, since the interface essentially includes a tutorial.

4) Change various bits of the SFML code that won't compile on Solaris.  Since this was just for fun, not a serious porting effort, I naively removed what didn't seem to work.
a) Comment out all Joystick-related code.
b) Remove the FD_ZERO macro wherever it caused a "'memset' not declared in this scope" error.  I believe this rendered the entire networking module unusable (lol).
c) Change Config.cmake and Config.hpp so that SFML won't simply refuse to compile on an OS it doesn't recognize.  I decided to try #define SFML_SYSTEM_FREEBSD since that was the only *nix-but-not-Linux system the files had a macro for.
d) In Linux/WindowImplX11.cpp the one line that calls basename() gets a "'basename' not declared in this scope" error, which I had no idea what to do with so I simply commented it out.  In retrospect this seems like the most obvious potential source of the weird crashes I got, though all my googling efforts failed to turn up any hint as to where this basename() function comes from, so I had no idea how to resolve the scope error.

5) Now simply build SFML and its examples using CMake per the usual tutorial.  Change the CMakeLists.txt file in the examples folder so that the networking examples don't get built.  All the other examples I built without a single error or warning.

6) Test the examples and watch what breaks!
The opengl and window examples run perfectly fine, until you close them.  Then VirtualBox crashes.
The shader example crashes VirtualBox on startup.
The sound example seems to hang for a little while and then exit without doing anything.  Note that other sources of audio (eg, the terminal beeping at me whenever tab-completion fails) were working just fine for me.
The pong example seems to do nothing but open a window and immediately close it again.  It continues doing this even after I remove all the window-related code (or literally all of the code except main()) and rebuild it.

Just to clarify, I was expecting this to fail.  This is not meant as a help request, which is why it's not in the help section.  It'd be cool if someone actually has an idea how to make the non-networking examples work, but I didn't have my heart set on doing any Solaris porting in the near future.  It just seems like a good idea to at least have one thread about this topic somewhere.

8
Me again.  So I finally got my program to compile on Linux after much headache (and turning it into one of the SFML examples so that CMake would do the linking for me), but when I try to run it I get this error:

Quote
AL lib: pulseaudio.c:331: PulseAudio returned minreq > tlength/2; expect break up
Segmentation fault (core dumped)

I do see a window try to flicker into existence just before this error happens and kills it, so hopefully that means the non-audio stuff is working fine.

I tried copying my version of libopenal.so into the folder where my program is, but that had no effect.  Since I'm still a linux noob, do I have to worry about distributing libopenal with the linux version of my program? Or is that something I can assume is already installed on every other linux box in such a way that it gets automagically linked for me?

If it matters, the "sound" example program is working fine for me.

9
At the moment I'm just trying to compile the sample program from this page: http://www.sfml-dev.org/tutorials/2.1/start-linux.php.  I've been using the 32-bit Linux GCC build under the downloads section, which I think is what the tutorial refers to as the "SDK."  I'm running Ubuntu 12.04 LTS inside VMware Player 5.0.2 on my Windows 7 Professional 64-bit laptop.  All of these things I downloaded and/or updated within the last 24 hours.

For a while I tried to do what the tutorial said, and one of my many guesses was that it wanted me to put the contents of SFML-2.1/include/SFML into /usr/include/SFML and the contents of SFML-2.1/lib/ into /usr/lib/SFML, then use "-I/usr/include/SFML/" and "-L/usr/lib/SFML/" and some -l's in the g++ command.  In the end none of my guesses came close to getting g++ to realize these libraries existed, much less produce an actual executable.

Out of my dozens of failed combinations of file placement and command line arguments, the errors I typically got were either: 1) an "undefined reference" to every single SFML function in the sample main.cpp, 2) "/usr/bin/ld: cannot find -lsfml-graphics" or any of the other libraries I tried including with -l, or 3) several "undefined reference"s to glew macros (that was a really weird one...)

So how exactly are you supposed to compile an SFML program on linux?  Where am I supposed to put all of the files in the "SDK"?  Should I only move the .hpps and .so's?  Do I need to treat the .so, .so.2 and .so.2.1 libs differently in some way?  Should I be trying to preserve the placement of certain subdirectories?  Should I be doing anything with the lone .cmake file or the .pkg files?  What should my actual g++ command look like?  The tutorial just doesn't tell me any of this.

Incidentally I've been using SFML on Windows for weeks now and it's been almost effortless there.  I've also used gcc/g++ from the command line before in Cygwin, though I've never had to figure out how to make them link with a library they didn't automagically know about already.

10
Window / Do SFML windows ignore embedded icons?
« on: July 25, 2013, 06:56:37 pm »
I have no experience with the Win32 API or anything, but I'm under the impression that when an icon is embedded in an .exe, Windows will automatically use the icons it contains in the following places (maybe more):
1) Windows Explorer
2) The Taskbar
3) The top-left corner of the application window
4) The box that appears when you hold Alt+Tab

However, when I try embedding an .ico file in my SFML program's .exe using Resource Hacker, it only appears in Windows Explorer and the Taskbar, not in the application window or the Alt-Tab box.

Is this actually standard Windows behavior, and I'm supposed to use setIcon() to get uses 3 and 4 to work?  Or is SFML actively setting its windows' icons to the OS default instead of letting Windows use the embedded icons?

I have tried setIcon(), and it does work, but it's not a complete solution because it only accepts a single array of pixels rather than an .ico file.  Since icon uses 2, 3 and 4--the ones that setIcon() seems to affect--often require different sizes, that one array of pixels ends up getting upscaled or downscaled, both of which look quite bad.  Is there some workaround for this?

I've also seen the wiki tutorial on embedding the pixel array into your source code, but that won't make the icon appear in Windows Explorer (...right?) and it can't get around the fact that getIcon() only takes one array so that doesn't seem like a solution either.

Of course, this is a very minor problem in the grand scheme of things, and aside from this I'm absolutely loving SFML as a library and am almost done with my first big program in it (which is why I'm trying to add niceties like icons now).  So I won't be devastated if there is no good general solution.

I've been using Microsoft Visual C++ 2010 Express, dynamically linking SFML for debug builds and statically linking for release builds (for some reason the debug build is unbearably slow with static linking) on Windows 7 Professional 64-bit.  Same behavior on both builds.  I've never used Mac OS X or Linux much, so I know nothing about how they deal with windows and icons, so maybe I'm unaware of some portability issues that affect this.

Pages: [1]