316
SFML projects / Re: "Triangle Super" -- A fast-paced minimalist game
« on: May 04, 2013, 11:10:36 pm »
You rock! Good job!! 
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.
317
Graphics / Re: Need an idea how to display only X amount of vertices from sf::VertexArray
« on: May 04, 2013, 01:50:03 pm »
If you will just move around, use sf::View for a camera.
If you actually want to transform the whole vertex array without changing the vertices, use sf::Transform.
If you want to draw only a part of the array, then draw it manually and use glDrawArrays(Primitive, StartVertex, NumVertices); (can only draw contiguous vertices)
That's it, there is always a solution. For maps, better to divide it in multiple regions, and draw them whole only if they are within the screen, moving around with a sf::View only. Try
If you actually want to transform the whole vertex array without changing the vertices, use sf::Transform.
If you want to draw only a part of the array, then draw it manually and use glDrawArrays(Primitive, StartVertex, NumVertices); (can only draw contiguous vertices)
That's it, there is always a solution. For maps, better to divide it in multiple regions, and draw them whole only if they are within the screen, moving around with a sf::View only. Try
318
SFML projects / Re: "Reactor Heart" - SFML indie game under development
« on: May 04, 2013, 01:46:15 pm »
This is looking incredible! Good luck with this game man!!! I bet everyone else in the forum will love it
319
General discussions / Re: Android Support and OpenGL ES 2.0
« on: May 03, 2013, 03:45:43 pm »
After having "converted" SFML into a fully portable library (ios/android) myself, i remember a few bumps on the road:
sf::String -> http://stackoverflow.com/questions/5630255/does-android-not-really-have-wchar-t
Audio -> needs a very specific backend to work
ios EAGL -> the default framebuffer is not the window, but a off-screen fbo now.
OpenGL ES -> went with a renderer base class and specializations for each OpenGL version
Texture::copyToImage() -> not possible anymore, breaks some code
sf::Shader -> would probably need refactoring (GLSL ES and GLSL are not equal)
Assets -> Stored in a zip file, instead of loose files in android. some formats will be compressed unless you do some tricks.
I don't remember the rest of issues right now, but i ll update later if i do. I think it will be a little harder than expected to have sfml fully working in android, in particular.
sf::String -> http://stackoverflow.com/questions/5630255/does-android-not-really-have-wchar-t
Audio -> needs a very specific backend to work
ios EAGL -> the default framebuffer is not the window, but a off-screen fbo now.
OpenGL ES -> went with a renderer base class and specializations for each OpenGL version
Texture::copyToImage() -> not possible anymore, breaks some code
sf::Shader -> would probably need refactoring (GLSL ES and GLSL are not equal)
Assets -> Stored in a zip file, instead of loose files in android. some formats will be compressed unless you do some tricks.
I don't remember the rest of issues right now, but i ll update later if i do. I think it will be a little harder than expected to have sfml fully working in android, in particular.
320
General discussions / Re: Android Support and OpenGL ES 2.0
« on: May 03, 2013, 01:11:25 pm »
For android there is OpenAL Soft with a OpenSL ES 1.1 backend, I believe. That's pretty much the only way you ll find to make portable audio code
321
Graphics / Re: sf::Font wasting resources
« on: May 03, 2013, 01:00:44 pm »
It may have been some bug with my code, which I used to verify this, but indeed changing Page to Page* removed all unecessary copying and ensured only one allocation of sf::Texture
Thanks for the feedback!
Thanks for the feedback!
322
Graphics / sf::Font wasting resources
« on: May 02, 2013, 11:58:07 pm »
Hello Laurent,
I've been looking into the sf::Font source code and I believe I found a considerably serious issue. What I found doesn't stop the class from working correctly, but it still is a bad practice, I think. I did debug and confirm what I will say, but if for some reason I am wrong, ignore the post altogether.
Inside sf::Font, we find the std::map<unsigned int, Page> where we store the texture and glyph information of each character size. The sf::Font::Page class by itself declares a sf::Texture locally. I found this a little weird due to the type of the container. An std::map uses a tree internally to keep all members efficiently ordered and this means that whenever we add or remove an element, the tree will re-structure itself to remain ordered, effectively copying around the Page objects.
So, I looked into the sf::Texture copy constructor, and it downloads all data from the source texture and uploads it to the destination texture. This means that on a font with plenty of character sizes active, there are potentially dozens of texture copies, and lots of data transfering to/from the gpu.
I verified this by making sure when a new page was added, sf::Texture would be copied around a few times in the re-structuring process of the tree. It seems like a huge overkill of the performance when the map could be a std::map<unsigned int, Page*>, avoiding unecessary copies all together (I tested it and it works as good).
I've been looking into the sf::Font source code and I believe I found a considerably serious issue. What I found doesn't stop the class from working correctly, but it still is a bad practice, I think. I did debug and confirm what I will say, but if for some reason I am wrong, ignore the post altogether.
Inside sf::Font, we find the std::map<unsigned int, Page> where we store the texture and glyph information of each character size. The sf::Font::Page class by itself declares a sf::Texture locally. I found this a little weird due to the type of the container. An std::map uses a tree internally to keep all members efficiently ordered and this means that whenever we add or remove an element, the tree will re-structure itself to remain ordered, effectively copying around the Page objects.
So, I looked into the sf::Texture copy constructor, and it downloads all data from the source texture and uploads it to the destination texture. This means that on a font with plenty of character sizes active, there are potentially dozens of texture copies, and lots of data transfering to/from the gpu.
I verified this by making sure when a new page was added, sf::Texture would be copied around a few times in the re-structuring process of the tree. It seems like a huge overkill of the performance when the map could be a std::map<unsigned int, Page*>, avoiding unecessary copies all together (I tested it and it works as good).
323
General discussions / Re: Android Support and OpenGL ES 2.0
« on: May 01, 2013, 05:30:15 pm »
And later when you go to OpenGL ES 2.0, you need to reintroduce sf::Shader, and only shaders are allowed.. If you ever aim to support both versions it will be a little weird.
If you ever aim to support both versions it will be a little weird. 324
General / Re: SFML freezes when mouse moves (VS 2010)
« on: April 29, 2013, 08:53:47 pm »
He is just running binaries in release mode. I am compiling them in a Windows 7 32 bits, Visual Studio 2010
325
General discussions / Re: SFML 2 and its new website released
« on: April 29, 2013, 08:51:24 pm »
Congratulations Laurent! I bet you're very happy today 
326
General / Re: SFML freezes when mouse moves (VS 2010)
« on: April 29, 2013, 03:56:14 pm »
I'd like to ressurect this thread as this problem was verified while someone tested my application.
http://www.mediafire.com/download.php?b6rvmtwtnwx9pj1
That's an actual windows binary in which the problem persists for some users. It may help identify the problem. Its a very simple program, which polls all events correctly from the sf::RenderWindow, and doesn't even do anything with sf::Event::MouseMoved.
Any ideas what can it be? It was reported to me that the game would not draw as long as the mouse is moving inside the window. He was using Win7 64 bit.
http://www.mediafire.com/download.php?b6rvmtwtnwx9pj1
That's an actual windows binary in which the problem persists for some users. It may help identify the problem. Its a very simple program, which polls all events correctly from the sf::RenderWindow, and doesn't even do anything with sf::Event::MouseMoved.
Any ideas what can it be? It was reported to me that the game would not draw as long as the mouse is moving inside the window. He was using Win7 64 bit.
327
SFML projects / Re: Technoport
« on: April 28, 2013, 05:10:30 pm »
Damn I was trying to troll you by effectively stealing your code and idea, and you didn't even care!!
Hehe
Seriously, good work!
Hehe
Seriously, good work!
328
General discussions / Re: A new logo for SFML
« on: April 28, 2013, 02:20:37 pm »
The latter looks very good indeed, but it can't beat the quality in the others I believe
329
SFML projects / Re: Technoport
« on: April 28, 2013, 02:18:34 pm »
Thanks for posting this. I just downloaded your source code and started working on my own game out of your idea and code. Hope you don't mind
330
Graphics / Re: Background Image Not Loading
« on: April 25, 2013, 04:08:25 pm »
Could you be a little more clear on what fails and what succeeds exactly?
From looking at your question and code, I don't see anything wrong that would cause such issues, it should work as-is, unless there's some error going on, like missing image file or something.
What exactly happens?
From looking at your question and code, I don't see anything wrong that would cause such issues, it should work as-is, unless there's some error going on, like missing image file or something.
What exactly happens?