9286
Graphics / Re: sf::clear doesnt fill my window
« on: November 08, 2012, 07:40:12 am »
Read this... 
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.
9287
General / Re: Grid-based sprite movement
« on: November 08, 2012, 07:39:28 am »I'll 'soon' try to make a tile based game too, but don't want to hang the complete game when trying to move your character. Is it a good idea to trigger a thread dedicated to move the player?Why would you believe that the the game will hang?
Moving one object is a very cheap operation, so you won't run into performance issues. And after ou've moved the player, simply adjust the sf::View to move the world with the player.
9288
Graphics / Re: vSync sf::View bug (SFML 2.0)
« on: November 07, 2012, 11:48:59 pm »Hahaha lolQuoteSorry I've lost my magical crystal ball last year, so I'm unable to see your not provided code...Lies! You still had it in august this year:QuoteDepends on your code change which my magic ball unfortunatly refuses to show...
Okay, okay I confess: I slipped the other day, it fell out of my hands and broke into two pieces. Tried gluing them together but it didn't work.
9289
Graphics / Re: vSync sf::View bug (SFML 2.0)
« on: November 07, 2012, 11:05:48 pm »
Sorry I've lost my magical crystal ball last year, so I'm unable to see your not provided code...
On a serious note, you should always provide an example of what your doing, because in most cases it's not SFML or anything else related to the problem, but the programmer itself has made a for him not so obvious mistake. Also read this.
On a serious note, you should always provide an example of what your doing, because in most cases it's not SFML or anything else related to the problem, but the programmer itself has made a for him not so obvious mistake. Also read this.
9290
General discussions / Re: Philosophical question: What defines what should or should not be part of sfml?
« on: November 07, 2012, 08:22:04 pm »
For the users it's 'simple': Laurent decides what gets into SFML and what not.
From my understanding the original idea was to provide the most basic elements that should help you build your stuff on top of it. As of now the library supports actually way more than that original idea would require, e.g. a high level class as sf::Sprite isn't really something basic and can be easily done on your own.
On top of that you should stop looking for an All-In-One library, because does do not exist!
SFML is already quite hard to maintain, since it has many facets and if you'd add just one more this would need again many extra hours. Thus libraries get developed for specific tasks/topics on which the developer can spend all his freetime and doesn't need to care about a hundred different aspects.
Besides that, SFML has an abstract sf::InputStream class, with which give you the possibility to have a portable and independed way of loading resources (e.g. from a networks stream or a zip files etc...).
From my understanding the original idea was to provide the most basic elements that should help you build your stuff on top of it. As of now the library supports actually way more than that original idea would require, e.g. a high level class as sf::Sprite isn't really something basic and can be easily done on your own.
On top of that you should stop looking for an All-In-One library, because does do not exist!
SFML is already quite hard to maintain, since it has many facets and if you'd add just one more this would need again many extra hours. Thus libraries get developed for specific tasks/topics on which the developer can spend all his freetime and doesn't need to care about a hundred different aspects.
Besides that, SFML has an abstract sf::InputStream class, with which give you the possibility to have a portable and independed way of loading resources (e.g. from a networks stream or a zip files etc...).
9291
SFML projects / Re: Collision shapes for SFML
« on: November 07, 2012, 05:53:13 pm »I am not sure what the plan should be next. Should I create Classes for these and that way classes can contain multiple convexShapes to make more usefull collision objects. Should I go as far as some lightweight physics? In any case I am not going to have it do any scene management.Well it's your code, you should decide what you want to do with it.
It would be quite nice if you'd clean up the classes and put them on the official wiki, so others could use it too.
What collision detection are you using in the back?
Btw. how did the talk about the book motivate you to create this collision class?
9292
General / Re: Grid-based sprite movement
« on: November 07, 2012, 05:48:23 pm »
Well there are hundred different ways to achieve what you want.
The basic idea behind is that you don't really make the movement depended on the keyboard input, but just 'trigger' the movement mechanism once a key is pressed. The movement then needs to be calculated framerate independently until the entity is at the new tile position. The calculation is a simple movement formula, e.g. sprite.move(direction.x * speed.x * dt, direction.y * speed.y * dt), where direction is -1, 0 or 1 depended on the key input, speed is a fixed or variable value and dt is the delta time. Then you simply check if the entity has moved far enough with some tolerance and if so you hard set it on the tile position.
I hope this gives you a bit of an idea.
The basic idea behind is that you don't really make the movement depended on the keyboard input, but just 'trigger' the movement mechanism once a key is pressed. The movement then needs to be calculated framerate independently until the entity is at the new tile position. The calculation is a simple movement formula, e.g. sprite.move(direction.x * speed.x * dt, direction.y * speed.y * dt), where direction is -1, 0 or 1 depended on the key input, speed is a fixed or variable value and dt is the delta time. Then you simply check if the entity has moved far enough with some tolerance and if so you hard set it on the tile position.
I hope this gives you a bit of an idea.
9293
SFML projects / AW: Re: [Utility] Stroke
« on: November 07, 2012, 02:24:47 pm »Impressive! Why not put the code on GitHub?Because the original code is not mine and the new code is a dirty adaption which isn't fully tested and Spidyy said he'd have a new version soon...
9294
General / Re: Continuous sprites
« on: November 07, 2012, 01:54:39 am »
Read the tutorials again and learn how things work with SFML.
You have to move the sprite every frame iteration and not all at once in a while loop...
You have to move the sprite every frame iteration and not all at once in a while loop...
9295
SFML projects / Re: [Utility] Stroke
« on: November 07, 2012, 01:52:37 am »
You're quite bold to bring up a two year old thread for you first post.
Luckily around community doesn't have anything against that...
Anyways the original author stated that he doesn't have the example anymore but he's working on a new version + example.
See here:
Also I've made a dirty port of the library to SFML 2 here.
Luckily around community doesn't have anything against that...
Anyways the original author stated that he doesn't have the example anymore but he's working on a new version + example.
See here:
Quote from: Spidyy
Someone really wanted to use the Stroke class, so I'm working on it to port it to SFML 2.0 and give it a few enhancements.
Also I've made a dirty port of the library to SFML 2 here.
9296
General / Re: VS 11, and variadic templates with std::thread
« on: November 06, 2012, 03:56:55 pm »What would you recommend instead of VS?As a matter of fact Microsoft announced a CTP (customer technology previews) which should support more C++11 features a few days ago. But for a really official support it will still take longer... - Uhm Laurent was faster.
I've seen good and bad reports for netbeans, and I have also heard good things from eclipse *and use eclipse for java* but have no experience with it for C++
I've also heard mixed reports for code blocks.
What to choose is a controversial topic and nearly all the arguments are just about personal preferences.
At the moment I'm using Code::Blocks to develop, but obviously not the very old official release from 2010 (iirc), but the nightly builds that come out every week or so. One just needs to download the new build and replace it with the old one, the settings etc. will all be preserved.
Personally I don't like Eclipse that much, since it's running with Java and uses quite a bit more resources than it needs to, but since I haven't really used it, I can't judge more about it. Neither can I comment on Netbeans.
If you feel like it then gVim + terminal is always a nice way, although for a new beginner not the most comfortable one.
More important than the IDE discussion is the compiler (version). I'd really like to see a working Clang compiler on Windows that comes with mostly all the essential libraries (so one could use SFML with it), but this will probably take a few more years...
So you're stuck with GCC/MinGW. The official/original MinGW32 project is a bit behind with the compiler version (4.6ish) and thus you might want to take a look at the TDM MinGW32 port. If you feel like getting a bit into a more experimental world, then you should most definitely check out the MinGW-w64 port, which reorganizes the MinGW32 project and additionally provides a 64bit compiler. But as I said the 264 project isn't the most stable and you can run into some problems which can't really get resolved atm.
What I've left out is the Cygwin vs 'native' discussion. Cygwin is a very nice to get the Linux world to Windows, but the problem is, that it's not exactly a 'native' Windows build, but you'll have to provide a Cygwin 'runtime' library. Next to this, their compiler (gcc) isn't really uptodate either. So I'd rather suggest to use MSYS. I only use Cygwin for Git interaction and other nice Linux features.
9297
General / AW: VS 11, and variadic templates with std::thread
« on: November 06, 2012, 10:45:10 am »
Easiest solution: stop using VS.
I've pretty much abandoned VS since they feel like C++11 is nothing urgent...
Otherwise you can create a struct/class that hold all your wanted data and pass everything as one argument.
Btw for generic C++/programming question I can suggest to you StackOverflow. There you'll get answers quickly and often from people with quite a bit experience.
I've pretty much abandoned VS since they feel like C++11 is nothing urgent...
Otherwise you can create a struct/class that hold all your wanted data and pass everything as one argument.
Btw for generic C++/programming question I can suggest to you StackOverflow. There you'll get answers quickly and often from people with quite a bit experience.
9298
General / Re: How do i make an installer for my sfml 2.0 game?
« on: November 06, 2012, 01:19:01 am »I just finished my game and i want to show it to my friend.I personally like a simple (7)zip archive for smaller games, which don't need an installation.
How do i make and installer for it?
i used "Advanced Installer" and i just had to include some redistributable files and some allegro dll. files.The same way but instead of including the Allegro dlls you include the SFML dlls.
But what should i include with sfml?
9299
SFML wiki / Re: Tutorial CMake
« on: November 05, 2012, 01:40:51 am »9300
General / Re: GUI rendering frequency
« on: November 05, 2012, 01:17:42 am »
First up, SFML wasn't developed as a rendering system for GUIs, thus if your aim is a GUI-only application, then you maybe should consider other possibilities.
Knowing the developers of SFGUI, I can only tell you that the bigger performance breaker is the rendering part with SFML.
TBH I don't really see any reason for the project. Everything that has to do with web frontend development are very often just 'hacks', because you're very limited on what you can and can't do. If you have C++ and SFML (/OpenGL) on the other hand you get (nearly) maximum freedom and thus trying to copying the hacks & workarounds for a limited system into a freedom system seems kind of strange.
There isn't that much difference, because for both operations you'll draw all the pixel of the whole window, thus what would count is rather the logic on calculating the positions and perspectives etc., which if done right shouldn't take up that much time.
- Render every GUI element each frame.
- Render only when an element requests un update, on a screen-sized texture that is rendered on the screen every frame.
Knowing the developers of SFGUI, I can only tell you that the bigger performance breaker is the rendering part with SFML.
TBH I don't really see any reason for the project. Everything that has to do with web frontend development are very often just 'hacks', because you're very limited on what you can and can't do. If you have C++ and SFML (/OpenGL) on the other hand you get (nearly) maximum freedom and thus trying to copying the hacks & workarounds for a limited system into a freedom system seems kind of strange.