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

Pages: [1] 2
1
General discussions / Re: SFML 2.0 RC
« on: July 08, 2012, 07:44:45 am »
Building without Arial.hpp makes libsfml-graphics.so 269 KB on my system, so the inclusion of a default font file does add quite some size bloat, looking at it in relative numbers (>100% of the original size). While in absolute numbers, ~300 KB may indeed not be that much, I imagine only a small number of people actually use it, as most of them actually want to switch to their preferred font or write a customized bitmap text renderer.
It looks more like a debug feature to me that is primarily used by people who want a quick prototype program without any other resources, but it is not really something anyone would use in a large-scale project. I actually was not even aware of its presence and always assumed SFML would fail to display text if you didn't load a ttf file, until I checked out the source code.

I second this. Though 300k may not be a lot, I just have this pet peeve on including anything I don't need. Just sort of an unexplained disgust.

2
General discussions / Re: SFML 2.0 RC
« on: May 01, 2012, 05:22:44 pm »
There is a problem when building static libraries with Mingw-w64 (32 and 64 versions). It is in the Macros.cmake file at lines 18-19:

Code: [Select]
            if(NOT ${lib} MATCHES ".*/.*")
                string(REGEX REPLACE "(.*)/bin/.*\\.exe" "\\1" STANDARD_LIBS_PATH "${CMAKE_CXX_COMPILER}")
                set(lib "${STANDARD_LIBS_PATH}/lib/lib${lib}.a")
            endif()

The problem is that the libs are split between a couple of directories. Specifically, in my 32-bit version, libopengl32.a, libgdi32.a, libwinmm.a and a few others are not in <mingw>/lib, but rather in <mingw>/i686-w64-mingw32/lib. This totally breaks the above code, which assumes they are in <mingw>/lib, and the make fails.

3
General discussions / New naming convention
« on: March 14, 2012, 09:48:30 am »
Can we consider the current git checkout a "final" SFML 2? At least as far as the API? Are there only bug fixes left for SFML 2 final release?

4
General discussions / New naming convention
« on: March 13, 2012, 08:34:47 pm »
Quote from: "Laurent"

In other other words: SFML 3 will be released much sooner than you expect :lol:

One release at a time, please. We would be happy to see SFML 2 (no pressure). SFML 3 should wait until at least a week later.

5
General discussions / New naming convention
« on: January 25, 2012, 10:39:32 pm »
I hate to sound impatient or annoying, but since it seems that you have decided and already have the changes done by you, can we expect them to be  committed soon?

6
General discussions / New naming convention
« on: January 23, 2012, 01:51:48 pm »
Quote from: "Laurent"

Quote
Maybe you should commit the changes, update the documentation, and wait a little while? Or you could even think about a beta release, which would look like the real release, except it would have the beta tag attached to it, along with a warning that things might still change. I really think it is important to get this one right.

I don't think people need a release to know which naming convention they prefer. They can write a sample code themselves if they really need to see it in action.
And I don't want to commit this modification until I'm 100% sure that it's the final one. Imagine people who start to convert all their code, and suddenly I go back to the original naming convention... ;)

Myself, I have not tested any changes committed since this discussion started, since I feel it is silly to check out and use a new version, just to have my code break. I am waiting for this naming change to be committed before I do another pull and use the latest source. I assume I am not alone in this. This seems to me to be a good reson to do a commit, even if you are only 95% sure.

7
General discussions / New naming convention
« on: January 22, 2012, 08:25:39 am »
Quote from: "Laurent"
Thanks for sharing your opinions.

camelCase + get/is should be my final decision.


+1

camelCase for no other reason then personal preference (I don't feel any of the above mentioned reasons is really very strong, but I just like it)

get/set/is for making code very clear

8
General discussions / New naming convention
« on: January 09, 2012, 09:32:04 am »
Quote from: "Hiura"
You can have a look at most (if not all) the functions concerned by this new naming convention here. As you can see the dilema has not a huge impact on the overall functions.


There are a lot more here

9
General discussions / SFML 2.0 changes / progress
« on: January 04, 2012, 08:38:08 pm »
Quote from: "Laurent"
Mobile devices, with OpenGL ES 2, will be supported later. That's one of my top priorities for SFML 2.

Thanks! That is great news to hear. :D

10
General discussions / SFML 2.0 changes / progress
« on: January 04, 2012, 06:53:13 pm »
Quote from: "Laurent"
Quote
Will it support OpenGL 4.x ?

The window module already supports any OpenGL version.

Will it support Mobile devices (OpenGL-E, I believe)

11
General / Re: Why is SFML 2.0 crashing?
« on: January 04, 2012, 08:43:28 am »
Quote from: "Criminull"

i downloaded latest include files from github
and libs/dlls  compilted by
http://www.sfml-dev.org/forum/viewtopic.php?t=6548

i just dont know what to do with that, dont wanna go back to 1.6


Those pre-compiled libs are from Dec 21, before the merge of the new grapihics API (Dec 25), while the latest include files from git are after the merge. There were a few major changes, and so your includes files don't match your libs.

12
Graphics / Re: Changes in API
« on: December 30, 2011, 12:53:20 am »
Quote from: "BMB"
Quote from: "Nexus"
It is the new Graphics API, see here.

But how can you only have linker errors? Many identifiers have changed, it shouldn't even compile. I recommend a complete rebuild. The new classes and functions can be looked up in the online documentation.


this was after I did a complete rebuild.


I just realized I was using the old include directory. I will do it again to get the compiler errors ;-)

13
Graphics / Re: Changes in API
« on: December 30, 2011, 12:50:16 am »
Quote from: "Nexus"
It is the new Graphics API, see here.

But how can you only have linker errors? Many identifiers have changed, it shouldn't even compile. I recommend a complete rebuild. The new classes and functions can be looked up in the online documentation.


this was after I did a complete rebuild.

14
Graphics / Changes in API
« on: December 30, 2011, 12:40:40 am »
I just compiled the new version of SFML2 from github, my previous one being about 2 weeks old, and now my programs wont link. Looking at the commit histort, it appears the changes were from the "merge branch 'drawables'" commit. However, as that commit changed a few thousand lines, I cannot just go see what changed.

So...
a) What is this 'drawables' branch that was merged?
b) Is there a list of the changes it caused? A partial list of what the linker reports as missing:
  Sprite::SetSubRect
  Drawable::SetPosition(float, float)
  Drawable::~Drawable
  RenderTarget::Draw(Drawable const&)

15
Window / Closing a window
« on: December 19, 2011, 04:22:37 pm »
Quote from: "Oneiros"
http://www.sfml-dev.org/documentation/2.0/
Quote from: "http://www.sfml-dev.org/documentation/2.0/"
Code: [Select]

         // Process events
         sf::Event event;
         while (window.PollEvent(event))
         {
             // Close window : exit
             if (event.Type == sf::Event::Closed)
                 window.Close();
         }

Thank you. I must of missed it.

Pages: [1] 2
anything