1
General discussions / Re: Sprite DLight - Instant normal maps for 2D graphics
« on: December 15, 2014, 01:39:40 am »
Just realised the KickStarter campaign has finished and I forgot to pledge 
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
General discussions / Re: Sprite DLight - Instant normal maps for 2D graphics
« on: November 28, 2014, 01:01:42 am »
I backed sprite lamp a long time ago. Just wondering what this adds?
3
General discussions / Re: What is wrong with my tutorials?
« on: July 10, 2014, 03:46:07 pm »... because I'm a UNI student too and I know what it feels like to get trolled by the professors. One of them in my Intro to Programming Languages course is partly responsible for my addiction to #defines and global variables!Bit off topic. I really don't understand why anyone ever expects to learn(master) a programming language in university. Here down under where at the university I'm attending. We don't have any units that are focused solely on learning a specific language. Most lectures focus on the theoretical stuff and project codes usually have poor coding practice. Doesn't help the lab computers always come with out of dated compilers. I've come to understand that learning a language should be done on your 'own' time and unis only provide guidelines and deadlines on the theoretical stuff that you should be learning at best.
4
General discussions / Re: Does std::chrono replace sfml::Clock completely?
« on: June 22, 2014, 12:47:06 pm »Quote
Does std::chrono replace sfml::Clock completely?
IMO, no. std::chrono was designed to be fairly generalized and does not provide a necessarily easy to use interface. sf::Clock is opposite of that. sf::Clock can use std::chrono internally if it wants to where it provides equal if not better precision than the platform specific APIs, but that's a different story.
5
General discussions / Re: SFML 3 - What is your vision?
« on: May 31, 2014, 07:13:39 am »Quote
Tello might be something worth looking into. Here's the feature tour and an example:
https://trello.com/tour
https://trello.com/b/nC8QJJoZ/trello-development
This might work!
Nate, the author of Spine (a skeletal 2D animation tool for games) uses it for the Spine editor and runtimes. There are several running list of tasks/features and stuff that he's working on and everyone can comment and vote for features.
https://trello.com/b/dle5mTBW/spine-runtimes
https://trello.com/b/frGlgsF7/spine-editor
6
General / Re: Laggy rendering.
« on: May 04, 2014, 01:46:09 pm »
I'm lost :S I would suggest writing a minimal sample that can replicate the problem.
30-100fps sounds way too low for something this barebone. From the video I can definitely see that the movement of the red square is very jerky. Hopefully the residential SFML gurus can help you
30-100fps sounds way too low for something this barebone. From the video I can definitely see that the movement of the red square is very jerky. Hopefully the residential SFML gurus can help you
7
General / Re: Laggy rendering.
« on: May 04, 2014, 03:37:38 am »
It looks a lot like EntityX. I'd be interested in how your getComponent<> and hasComponent<> methods work.
I will take a stab at it. Depending on how the systems are stored in your data structure (and therefore ordered). During a single loop cycle, they might not get updated in the order you want (e.g. input->update-position->render), so the position update might not get updated till the next loop cycle (e.g. update-postion => input => render). I'm not sure how noticeable that would be though since it's only 1/60 of a second.
A few potential improvements:
I will take a stab at it. Depending on how the systems are stored in your data structure (and therefore ordered). During a single loop cycle, they might not get updated in the order you want (e.g. input->update-position->render), so the position update might not get updated till the next loop cycle (e.g. update-postion => input => render). I'm not sure how noticeable that would be though since it's only 1/60 of a second.
A few potential improvements:
- In the input system, poll your inputs only once and store them, before iterating through all the objects.
- Your render is still coupled to the logic loops since you've added the render system to your engine. It gets updated along with all the other systems?
8
General discussions / Re: SFML 3 - What is your vision?
« on: April 26, 2014, 03:38:22 am »Doesn't even the SFML tutorial say that you should use C++ 11 threads where possible? If SFML 3.0 makes C++11 fully required, then I could see why it's being removed-You are right. Personally I use std::thread and have never used sf::Thread.
I think I confused sf::Thread with some other API that exposes functionalities such as setting priority, and pause and resume
The sf::Thread's delayed thread launch looks nice though.
9
General discussions / Re: SFML 3 - What is your vision?
« on: April 25, 2014, 12:55:40 pm »* removing sf::clock and sf::thread and friends in favour of the C++-versions of it.sf::thread, maybe.
Removing sf::clock is definitely a no no for me. It's a useful utility class and provide higher precision than VC12's std::chrono::high_resolution_clock due to the library not using native high precision API.
Quote
* a technique to insert an event (example: my_triple_mouse_click) to the event loopThese could all be done by implementing your own event system on top of SFML's event facilities, which would be more flexible and far superior for your game logic needs. I think sf::Event should be kept to what it is now, for window and input related events.
* timer events
10
General discussions / Re: SFML 3 - What is your vision?
« on: April 24, 2014, 02:56:15 pm »
Things I could think of on top of my head:
updated: I remembered more!
- Better input handling (mouse grab, scancode & etc).
- Expose OpenGL handles.
- Modern OpenGL backend and context creation options.
- C++11
- Separate window and it's draw methods? (having both the view and renderer all in one object seems kind of strange to me :S)
- More awesome features!
- Replace the vector stuff with GLM (could also pave path for 3D support).
updated: I remembered more!
11
General discussions / Re: The new SFML team
« on: April 22, 2014, 01:56:16 am »
This is very exciting news! Hopefully SFML will become an even better SFML with more frequent updates and fixes, more features and flexibility!
A whole heartedly welcome to the new official SFML Team, and thanks to all the contributors. I hope to become one of you some day.
A whole heartedly welcome to the new official SFML Team, and thanks to all the contributors. I hope to become one of you some day.
12
General discussions / Re: Unofficial Nightly Builds
« on: April 10, 2014, 10:54:17 am »
Thanks! I think I'm going to use this instead of compiling my own nightlies manually
+1 for SFGUI!
+1 for SFGUI!
13
General discussions / Re: Future release of SFML 2.2 (feedback needed)
« on: April 02, 2014, 11:22:50 am »Keyboard handling + mouse lock. Plus at best any open non-API breaking issue on GitHub.+1!!
Especially mouse lock, would've saved me quite a bit of time and ugly workarounds in my last project.
14
General discussions / Re: Any idea on when SFML 2.2 will be out?
« on: February 01, 2014, 04:18:30 am »If further SFML releases are stalled by the Android and iOS ports, then the ports should probably be postponed. Otherwise we won't see any new releases in a probably very long time.
I have to agree with both Tank and eXpl0it3r
Pages: [1] 2