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

Pages: [1]
SFML website / HTTPS support?
« on: October 08, 2014, 07:37:07 pm »
It would be awesome if this site had HTTPS support (especially for logging in). You can get one cert (for sfml-dev.org and one subdomain) for free with StartSSL. 2 more 5-year certs (for en. and fr.) can be bought for $46.40 from ssls.com.

There are other certificate authorities, but regardless of exactly which one is used, I would love to see some HTTPS support on this site. And they can be obtained for relatively cheap.

General discussions / Do you use radians or degrees?
« on: September 21, 2014, 10:07:24 pm »
SFML uses degrees. In my experience, it's the only thing that uses degrees (except for old, deprecated, and removed OpenGL stuff, which I ignore in this modern era).

I always use radians for things. Standard C and C++ trig functions take radians. OpenGL shader trig functions take radians. HLSL trig functions take radians. Whenever I do various geometric things I use radians. Honestly, the only time I ever "use" degrees is when I'm reporting them to the user; but even then I'm not really using radians; I'm just formatting the number as degrees for printing to screen. Whenever I actually use an angle, I use radians.

What about others? When do you use radians? When do you use degrees? How often do you need one or the other?

Side note: this isn't a "SFML should use radians" feature request, so I'm not looking to debate whether SFML should be radians/degrees. That kind of debate can happen in another thread. I'm trying to understand what users of SFML use, in real life.

SFML website / SFML 2.0 docs aren't up
« on: August 19, 2014, 05:32:03 pm »
Going to the 2.0 documentation results in just seeing the 2.1 documentation. Can this be fixed?


Feature requests / Condition Variables
« on: May 29, 2013, 02:08:30 am »
Condition variables would be incredibly useful with multithreaded programming. Can we please get them? (I know, not now, but at least in the future?)

General discussions / SFML Mobile Issues
« on: May 25, 2013, 06:46:27 pm »
Hi Laurent (and others). Sonkun and I have been working on an Android port of SFML, and some of the issues we're seeing are going to be issues for iOS as well, so I thought we could at least talk about them to try and figure out a good direction to take.

First, OpenGL ES does not support redering quads (only triangles, lines, and points). This requires the vertex buffers for sprites to be different. For individual sprites (where only one quad is drawn per draw call), a triangle strip can easily be used without increasing memory consumption. For "grouped" sprites (where multiple quads are drawn in a single draw call, like sf::Text), GL_TRIANGLES will have to be used. Would you prefer to continue using glDrawArrays, or would you prefer to optionally switch to glDrawElements and use indexed draw arrays? I'm assuming you'll want to stick with glDrawArrays (I think it'll save 8 bytes per quad), but I wanted to try and get your (and others) input.

I thought I had more things to bring up, but I can't think of anything else. If I do, I'll post here. I know I and others are eager to contribute to SFML, and hopefully this will help us better collaborate.

On the download page it says the second OS X option is "Clang (OS X 10.8+)". Why 10.8+? Shouldn't it be 10.5+?

General discussions / Android Support and OpenGL ES 2.0
« on: April 30, 2013, 09:52:26 pm »
I want to help with Android support. I've read Sonkun's post and didn't want to derail that thread further, so I'm starting this thread.

Questions for Laurent:
  • What can I do to help get Android supported?
  • OpenGL ES 2.0 would be awesome. At what point do you think SFML would use OpenGL ES 2.0? I assume after SFML 2.2.
  • Is there anything I can do that would help get OpenGL ES 2.0 support into SFML (even if it's quite awhile down the road)?

Questions for Sonkun:
  • Are you using a NativeActivity? Or are you using JNI?
  • Is there anything I can do that would help you in your work as well?

General discussions / More Community-driven Development
« on: February 11, 2013, 10:11:55 pm »
Currently, Laurent is pretty much the only SFML developer (with Marco doing OS X stuff). This is nice because there's a good level of consistency and sanity maintained in the codebase. However, we also only get a handful of commits each month, meaning things move quite slowly.

I've worked a little bit on other open source projects, like FFmpeg, and while FFmpeg has a much greater learning curve, I feel like it's easier to contribute to it. There are a number of people who have said "X would be a good idea/feature" and Laurent will say "Yeah, but it will require a decent amount of changes to SFML so don't do it; I will do it to make sure it's designed like I want it to be," which means users end up waiting on Laurent rather than being able to contribute.

This isn't necessarily a bad thing, as I've said, as it helps with a consistent and clean API in SFML, but I feel like SFML could really benefit from more community contributions and I'm wondering how that can be stimulated while still keeping full control in Laurent's hands.

There are, of course, a list of bugs the community can work on fixing (and hopefully I'll get to contribute to this during this summer), but there are other features that I know people are itching to have (like Android/iOS and OpenGL|ES 2.0 support) or other road blockers (like documentation/web stuff for the 2.0 release) that I think people would love to contribute to.

What would help encourage the community to contribute? Here are some of my thoughts, and I'm hoping others can contribute ideas/suggestions/comments:

More road maps or architecturing. Particularly, for things where Laurent says "Don't work on this, I'll do it so I make sure it's done how I want it," what if instead a skeleton/architecture was designed so that either Laurent can fill in the skeleton/architecture himself or someone else can implement it and send a pull request. That way the API and design will stay how Laurent envisions it, but eager users can contribute instead of wait.

A web page for contributing. There's some instructions at the end of SFML's README, but they're quite minimal and nowhere on the website. I think if there was a "Contribute" tab on the website that talks about contributing and helps users get involved in contributing to SFML, that would help.

Prioritized issues. If I want to contribute to something, I'd like to know what you'd like me to contribute to. Sure, contributing to any issue is nice, but prioritizing issues (maybe with tags) will give people a sense of what needs contributing the most.

Mini intro to working with github (and pull requests). I'm more familiar with the mailing-list style patch submission and review, like is done with FFmpeg. I just spent the past while poking around github trying to figure out how pull requests work and if I submitted a patch, how it would be reviewed and (if needed) updated/fixed. I think I understand how it works now, but if the entry barrier can be minimized as much as possible I think people will be more inclined to contribute.

Any other ideas, or any responses to these ideas?

General discussions / Please update the SFML OS X tutorial for C++11
« on: January 25, 2013, 03:24:48 am »
I was following the tutorial for making SFML with C++11 support, but I kept getting linker errors with anything that used anything from the standard library. The one thing I had to add that wasn't in the tutorial was setting CMAKE_C_FLAGS to be stdlib=libc++ too (not just CMAKE_CXX_FLAGS).

This is exactly how I had to do it:
export CMAKE_OSX_ARCHITECTURES=i386;x86_64

cd <sfml folder>

mkdir build

cd build

cmake -G "Unix Makefiles" -DCMAKE_CXX_COMPILER=/usr/bin/clang++ \
-DCMAKE_CXX_FLAGS="-stdlib=libc++" -DCMAKE_C_FLAGS="-stdlib=libc++" ../

make -j8

sudo make install

Notice the -DCMAKE_C_FLAGS="-stdlib=libc++" at the end. Without it, I kept getting the following errors when making an Xcode project that used clang & libc++ for C++11 support:

Undefined symbols for architecture x86_64:
  "sf::RenderWindow::RenderWindow(sf::VideoMode, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, unsigned int, sf::ContextSettings const&)", referenced from:
      _main in main.o
  "sf::Font::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _main in main.o
  "sf::Image::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _main in main.o
  "sf::Music::openFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      _main in main.o
  "sf::String::String(char const*, std::__1::locale const&)", referenced from:
      _main in main.o
  "sf::Texture::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, sf::Rect<int> const&)", referenced from:
      _main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hopefully I'm not crazy...

Also, thanks for SFML! I'm really looking forward to 2.0's official release (and then I'm really looking forward to 2.x when OpenGL ES 2.0 is supported!)

Feature requests / Setting Sprite Z (Depth) for Draw Order
« on: April 08, 2012, 10:50:32 pm »
I know this wouldn't be a part of SFML 2.0's initial release, but I think it'd be really useful to be able to set a sprite's z-depth so that sprites can be overlapped and rendered correctly.

For example, imagine a 2.5D RTS (like Starcraft). For the most part, units don't overlap too much, but they can a little bit (put two drones by each other). If I could set the sprite's z-depth based on their (x, y) locations, it would be easy to ensure a consistent drawing order. In addition, flying units could be given a distinct depth offset so that they always appear on top of other units, but they overlap other flying units in a consistent way as well.

It's possible to sort the sprites in a specific way and then render them in order, to simulate the depth effect, but that's not nearly as efficient as just setting the z value for each sprite.

Your thoughts?


In my example above, I could easily do this with a shader (and using a vertex shader may even be more efficient in this case) with something like z = x + y * mapWidth + isFlying * flyingOffset. I'm not sure if the vertex shader would be the most appropriate place to do this in all situations though; I haven't thought of one where a vertex shader wouldn't work well yet, but I'll give it more thought.

Feature requests / Fix links to old forum
« on: March 31, 2012, 11:03:42 pm »
Normally, I've found a lot of stuff on SFML's forums through google. However, since the forum moved, all the links from Google are invalid and result in this page.

Is there any way to make these links to old threads redirect to their current location?

Network / UdpSocket visibility issues with destructor & vtable
« on: March 14, 2012, 04:24:24 am »
So I've been excited to use the latest SFML, but I'm getting some weird warnings.  Things still work and my program runs, but I'm not sure if this is just my build system or if it's an issue with SFML.  I'm using the System and Network modules of SFML, and I've build and configured them with no warnings or errors.  However, my program is trying to use the libraries and I'm getting the following warnings at link time:

Code: [Select]
g++ -g -L../sfml/lib -lsfml-system-s -lsfml-network-s -L../protobuf/lib -lprotobuf -I../sfml/include -I../protobuf/include -o client main.cpp Message.pb.cc
ld: warning: sf::UdpSocket::~UdpSocket()has different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: sf::UdpSocket::~UdpSocket()has different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: vtable for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: typeinfo for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: typeinfo name for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o

It's complaining about the visilbility of the UdpSocket destructor, as well as the vtable and typeinfo for UdpSocket.  I'm positive the headers and source files are all the same version, as I just did a clean checkout.  I can't see anything wrong with UdpSocket either.

Does anyone thing this is an issue with SFML or is it probably an issue with my computer?  What more can I do to narrow down the problem?

If needed, my setup is:
OS X 10.6
g++ 4.2.1
SFML revision d592b2a

Pages: [1]