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

Pages: [1] 2 3
General / Re: Building multiple targets for MingW with CMake
« on: May 03, 2013, 11:56:18 pm »
Quick additional question!

The tutorial didn't make it clear for me. If I want to create the static version of the libraries with cmake, do I just need to turn off the "BUILD_SHARED_LIBS" variable, or do I also have to select "SFML_USE_STATIC_STD_LIBS"? I understand I can't have both on at the same time, I'm just not sure if the second one is actually necessary for building the static library.

General / Re: Building multiple targets for MingW with CMake
« on: May 03, 2013, 11:22:43 pm »
Ah, right. The not-dumb way of doing it. Should have thought of it before :) And a batch file automates the rest of the process.

I just need to add a script to check the repository for updates, download changes, and build everything.

General / Building multiple targets for MingW with CMake
« on: May 03, 2013, 04:22:46 pm »
Hi, I was wondering if it is possible to crate a makefile that will build Release and Debug versions of SFML with CMake.

What I'm doing now is load CMake, set target to Release, Configure, Generate, then run mingw32-make install, then go back to CMake, set the target to Debug, and repeat. I was wondering if there was some target that automatically built both versions.


General / #defines necessary for OpenGL
« on: May 15, 2012, 04:30:46 pm »
Not so much something I need help with but an oddity I was wondering if anyone else experienced, and if so how they dealt with it.

When I #include <SFML/OpenGL.hpp>, I need to add

#define GLAPI extern
#define APIENTRY

ahead of it.

This is only required once, but not having it causes conglicts in gl.h where there's a bunch of lines such as

GLAPI void APIENTRY functionname();

The preprocessor commands there seem to try to figure out the compiler and set defines for GLAPI and APIENTRY, but for some reason my MinGW installation isn't getting it right so I have to do it manually. But I'm not happy with sticking that there, knowing that if I try to rebuild the project elsewhere it's going to have to be removed.

I've tried to get it into the #define section of the project options, so it wouldn't sit in the code itself, but when I did I had the same problem as before, it complained that it could not recognize GLAPI and APIENTRY in gl.h.

Any ideas why this might be happening?

Using latest version of MinGW and Code::Blocks. I'm also including SFML/OpenGL.hpp ahead of SFML/Window.hpp and SFML/System.hpp, if that matters.

Some leading questions that might help people help you:

Have you had trouble downloading the MinGW source files? Have you had trouble compiling MinGW for Linux? Have you managed to get MinGW for Linux working? Can you compile a simple program for Windows and get it to work? Are you having trouble compiling an SFML project specifically? What SFML libraries are you including?

Unless you describe your problem in detail, including everything you've tried and managed to get to work, no one is going to be able to help. These questions are just for giving you an idea of what information would be helpful. Don't just run down the list with yes/no answers either. Be as explicit as possible.

General discussions / Should we post compiler warnings from SFML?
« on: May 08, 2012, 05:59:00 pm »
I was wondering, should we bring up any warnings that the compiler throws at us here?

I've recently been working on tightening up my own code (proper documentation, turning up all warnings on the compiler, etc), and looking through the options in GCC I found a bunch of warnings not covered by -Wall (which is really counter-intuitive). Turning those on gave me a bit of work, and also pointed out some warnings from SFML itself.

I was just curious if we should bring these up at all. They're things like:

"..\..\libs\SFML-2.0-rc\include\SFML\System\Mutex.hpp | 48 |
warning: base class 'class sf::NonCopyable' has a non-virtual destructor."


"..\..\libs\SFML-2.0-rc\include\SFML\System\Mutex.hpp | 48 |
warning: 'class sf::Mutex' has pointer data members but does not override 'sf::Mutex(const sf::Mutex&)' or 'operator=(const sf::Mutex&)' "

It's actually just those two for a bunch of classes.

And I suppose I already brought it up, so not really much point asking if I should. Hmm. Sorry?

System / Re: New line in sf::String
« on: May 07, 2012, 08:29:57 pm »
I keep forgetting about that whenever I work with files. Thanks.

System / Re: New line in sf::String
« on: May 07, 2012, 06:06:48 pm »
Let me check something, be right back.


Hmm. The problem is apparently with Notepad, everything else shows it correctly.

What I was doing was creating an sf::String with the constructor that takes a string literal, then using the fstream write method to write the string to a text file. The relevant code:

Code: [Select]
void Log::write(sf::String const& line)
    logfile.write( line.toAnsiString().data(), line.getSize() );
    // logfile is an fstream object pointed to a file opened with the trunc, output and binary flags

Log log;

log.write(sf::String("1st line\n\n2nd Line");

The problem I was seeing was that notepad put squares where the new lines should be. Copying to the browser's textbox however added new lines. And opening in a more versatile text editor (TextPad) displayed the new lines as well.

I should just delete notepad.exe .

System / New line in sf::String
« on: May 06, 2012, 11:36:11 pm »
I'm sure this has been answered a hundred times, but the search function couldn't help me. Terms are too generic I guess.

I'm wondering how to stick the "new line" code in sf::String. I'm currently creating strings from ANSI literals; sf::String string ("The text"); but if I use the new line character '\n' it doesn't seem to be converted or stored. What's the proper way to do this?

SFML projects / Asteroids!
« on: November 14, 2011, 05:55:56 pm »
Giving shape to the world - One step closer to the dream.

SFML projects / Asteroids!
« on: November 07, 2011, 04:51:31 pm »
Been a while. New demo out :D Lighting now works. So shiny!

Looking good. Looking real good.

Framework-0.0.8 - Moved to zip files so that people didn't have to deal with unpacking 7z files.

SFML projects / Asteroids!
« on: October 10, 2011, 09:08:29 pm »
New Demo out! Now with collision detection worked into it.
Framework-0.0.7 - Bouncy
Also posted on the blog, how space partitioning helps cut down on the computation required for collision detection.
Collision Detection - Part 3 - Space Partitioning - Divide and Conquer

SFML projects / Asteroids!
« on: October 03, 2011, 05:07:04 pm »
Been a busy week, couldn't get a lot of work in, but I had time for an update to the blog.

Collision Detection - Part 2 - Resolution - What do we do after detecting the collision?

SFML projects / Asteroids!
« on: September 26, 2011, 10:04:18 pm »
Just a post today. Tackling a pretty complex issue right now.

Collision Detection - Part 1 - Detecting it - I'm going to spend a few weeks explaining how I go about doing the collision detection in the program, with hopefully a working example by next week.

SFML projects / Asteroids!
« on: September 12, 2011, 04:11:30 pm »
New update and post!

Framework-0.0.6r - Shooting is important.

It's full of stars! - Working on the background, so I can get rid of the green lines.

Deus Ex is fun, but it kills productivity.

Pages: [1] 2 3