1
SFML projects / Re: Squatbot: A Mobile Platformer
« on: May 02, 2018, 12:21:58 pm »
Wow! Looks great! What are your lessons learnt with iOS and Android? Will you release on PC or the like?
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.
Pages: [1] 2
2
Feature requests / Re: Better gamepad support
« on: April 27, 2018, 10:19:34 am »Yes, I think that it would make sense to keep it as an extension to SFML + I don't want to write it in C++03, to be honest. I wonder if we could have a system similar to SDL's extensions. With libs which are closely related to SDL, but are worked on independently.
I vote for a C++14 library instead of adding it to SFML. Once SFML is C++14 ready then we could integrate it back. So pick the same license as SFML.
4
Feature requests / Re: Anisotropic Filtering
« on: March 29, 2018, 03:30:13 pm »You have to forgive me. I’m disabled and housebound, so the time passes at a different pace to me as to others.
np
I am glad to see more pople being enthusiastic about SFML. Kepp up the good work in any case.
5
Feature requests / Re: Anisotropic Filtering
« on: March 29, 2018, 03:15:24 pm »Seems not :/
Just wait and be patient, this is no real time chat or twitter. People have jobs and lives and coming weekend is easter.
6
SFML development / Re: How to have PRs merged faster without lowering quality
« on: March 28, 2018, 08:50:49 am »
From my outside view visibilty is a problem and the process is not so clear at all. There are SO MANY issues in the tracker! I also find anything under 3 weeks is acceptable.
EDIT: I just had a look at the issues, some are from 2011. Even though those are feature requests those should be implented by now or been closed as nobody seems to need them in the past 7 years. There is something wrong with the process or SFML ist just not attractive.
EDIT: I just had a look at the issues, some are from 2011. Even though those are feature requests those should be implented by now or been closed as nobody seems to need them in the past 7 years. There is something wrong with the process or SFML ist just not attractive.
7
General discussions / Re: Status of iOS support?
« on: March 28, 2018, 08:46:51 am »
As far as I can see we are missing a dedicated maintainer for iOS that has the time AND hardware to test and fix everything for iOS.
8
Feature requests / Re: Add an option to get rid of the udev client libraries on Linux
« on: March 26, 2018, 12:27:30 pm »
Sounds sensible. What is a good way to package an SML application for Linux then?
9
Feature requests / Re: Add an option to get rid of the udev client libraries on Linux
« on: March 26, 2018, 09:38:09 am »
How is the state today with Flatpack and SFML?
10
General / Re: sf::Text destruction causes segfault
« on: March 23, 2018, 09:37:36 pm »
I think my pre build SFML is not working with the compilers I use. With SFML 2.3.2 and g++ 5.4.1 on another machine problem is still the same. gdb points to the destructor.
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x7fff00000006) at malloc.c:2951
2951 malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_free (mem=0x7fff00000006) at malloc.c:2951
#1 0x0000000000486b20 in __gnu_cxx::new_allocator<sf::Vertex>::deallocate (this=0x7fffffffdea8,
__p=0x7fff00000006) at /usr/include/c++/5/ext/new_allocator.h:110
#2 0x0000000000486aee in std::allocator_traits<std::allocator<sf::Vertex> >::deallocate (__a=...,
__p=0x7fff00000006, __n=14757388222308182547) at /usr/include/c++/5/bits/alloc_traits.h:517
#3 0x0000000000486a8e in std::__cxx1998::_Vector_base<sf::Vertex, std::allocator<sf::Vertex> >::_M_deallocate (this=0x7fffffffdea8, __p=0x7fff00000006, __n=14757388222308182547)
at /usr/include/c++/5/bits/stl_vector.h:178
#4 0x00000000004869f8 in std::__cxx1998::_Vector_base<sf::Vertex, std::allocator<sf::Vertex> >::~_Vector_base (this=0x7fffffffdea8, __in_chrg=<optimized out>)
at /usr/include/c++/5/bits/stl_vector.h:160
#5 0x0000000000486987 in std::__cxx1998::vector<sf::Vertex, std::allocator<sf::Vertex> >::~vector
(this=0x7fffffffdea8, __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_vector.h:425
#6 0x00000000004868ba in std::__debug::vector<sf::Vertex, std::allocator<sf::Vertex> >::~vector (
this=0x7fffffffde90, __in_chrg=<optimized out>) at /usr/include/c++/5/debug/vector:208
#7 0x00000000004868f2 in sf::VertexArray::~VertexArray (this=0x7fffffffde88,
__in_chrg=<optimized out>) at /usr/include/SFML/Graphics/VertexArray.hpp:45
I will refrain from using VertexArray anyway and will build SFML myself.
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x7fff00000006) at malloc.c:2951
2951 malloc.c: No such file or directory.
(gdb) bt
#0 __GI___libc_free (mem=0x7fff00000006) at malloc.c:2951
#1 0x0000000000486b20 in __gnu_cxx::new_allocator<sf::Vertex>::deallocate (this=0x7fffffffdea8,
__p=0x7fff00000006) at /usr/include/c++/5/ext/new_allocator.h:110
#2 0x0000000000486aee in std::allocator_traits<std::allocator<sf::Vertex> >::deallocate (__a=...,
__p=0x7fff00000006, __n=14757388222308182547) at /usr/include/c++/5/bits/alloc_traits.h:517
#3 0x0000000000486a8e in std::__cxx1998::_Vector_base<sf::Vertex, std::allocator<sf::Vertex> >::_M_deallocate (this=0x7fffffffdea8, __p=0x7fff00000006, __n=14757388222308182547)
at /usr/include/c++/5/bits/stl_vector.h:178
#4 0x00000000004869f8 in std::__cxx1998::_Vector_base<sf::Vertex, std::allocator<sf::Vertex> >::~_Vector_base (this=0x7fffffffdea8, __in_chrg=<optimized out>)
at /usr/include/c++/5/bits/stl_vector.h:160
#5 0x0000000000486987 in std::__cxx1998::vector<sf::Vertex, std::allocator<sf::Vertex> >::~vector
(this=0x7fffffffdea8, __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_vector.h:425
#6 0x00000000004868ba in std::__debug::vector<sf::Vertex, std::allocator<sf::Vertex> >::~vector (
this=0x7fffffffde90, __in_chrg=<optimized out>) at /usr/include/c++/5/debug/vector:208
#7 0x00000000004868f2 in sf::VertexArray::~VertexArray (this=0x7fffffffde88,
__in_chrg=<optimized out>) at /usr/include/SFML/Graphics/VertexArray.hpp:45
I will refrain from using VertexArray anyway and will build SFML myself.
11
SFML development / Re: sf::Time & sf::Clock vs C++11 chrono
« on: March 23, 2018, 04:48:45 pm »
I vote for complete removal including sf::Time. As the example from JayhawkZombie shows there is so little gained from keeping sf::Time. It is IMO not worth the overhead. The additional verbosity and relying on the standard will lower the entry barrier of SFML und will introduce beginners to more std functions.
12
General discussions / Re: Unfreezing the API
« on: March 23, 2018, 04:36:26 pm »
Oh, that makes sense. I misunderstood. I was wondering what C++1y features would break the API in SFML 3.0. Expect 3.0 to break a lot.
13
General discussions / Re: Unfreezing the API
« on: March 23, 2018, 03:25:02 pm »
So what kind of breaking changes are you talking about? I would remove anything thread related and recommend the usage of std::thread, IMHO even sf::VertexArray would go but what actual API would break when adopting C++11 and C++14 features? Examples? There is a lot that could be already used in work for SFML 3.0
* Move semantics would be added but wouldn't break anything
* Using enum class
* constexpr, auto, lambdas
* Move semantics would be added but wouldn't break anything
* Using enum class
* constexpr, auto, lambdas
14
General / Re: sf::Text destruction causes segfault
« on: March 23, 2018, 11:59:09 am »
Funny, I have a similar problem with sf::VertexArray. I am investigating it with valgrind, it is something the its destructor. I use g++ 4.8.5 and SFML 2.4.2. I'll keep you posted...
15
General discussions / Re: How is Andorid and iOS support coming?
« on: March 21, 2018, 08:54:12 am »
@Alia5 Do you know if something is broken? I am still on 2.3 and I am unsure if going to master or waiting for 2.5 is the better idea. Android is more a nice to have for me atm.
Pages: [1] 2