Messages

9511

General / Re: SFML installing on Visual Studio 2010 Professional

« on: October 08, 2012, 11:13:49 am »

All which i found, there was said "View - Property Manager". I have not that. Only "Properties Window" and "Property Pages".

I'm not sure what you were following that stated you have to search in the view menu...
The official tutorial only says "In the project's properties" which obviously implies Project->Project Properties. As you can see in the image blow:


To get the project menu entry to show, you have to open a project and you need to select the project in the Property Manager.

Finding yourself around menu entries etc is very basic stuff on how to operate with your computer and should be easy for a developer...

9512

General / Re: A little confused in the "Getting started" Tutorial

« on: October 08, 2012, 01:44:03 am »

Yes it works as long as you really just get one event per iteration which is mostly not the case.
For example try to limit the framerate (window.setFramerateLimit(60) and then move your mouse around the screen or press some keys and move the mouse around simultaneously and you'll notice that more than one event is triggered within one iteration. Thus if that would happen constantly and you'd use an if-statement your event queue will slowly fill up (since you can only process one event ever iteration and every iteration two or more get added) and running your application long enough will eventually eat your whole memory and crash the application, also all the events would start to be extremely delayed.

Thus it's advised to use a while loop for polling events.

9513

Feature requests / Re: Rewrite the entire library in C

« on: October 08, 2012, 01:37:25 am »

C++ is also a horrible thing. No-one should use it to create a user app. C/C++ are fine to make low-level things. SFML does low-level things by interfacing with the windowing system. When you create a high level application you should use a high-level language. There are several high-level languages with very good performances. There are even some that provide the same performances than C/C++. Programming with a high level language makes you write things more easily, quickly, and with less bugs. The result will be easier to maintain, contributors will contribute more easily with a higher level language.

C is ugly, yes that's true, C++ is not better, it is a very complicated programming language. A lot of people around even say often that this is one of the most complecated programming language.

Opinions, opinions there are many and everyone claims to have the truth.
If you can't accept that people which are into C++ don't like to see C code then you'll have a hard time, not only on this forum, but in mostly all C++ related forums/IRCs/etc.
Also degrading C++ to a low level language makes me think about what your definition of a high level language is or if you've ever looked at low level languages. C++ is a high level language and in my humble opinion there's no reason the switch to another language just because your opinion is that C++ isn't good to work with.
Additionally the language you choose does rarely have something to do with the possibility for maintenance nor contributions, this depends way more on the code design and the public interest.

And I can only mark this again in bold: this is my opinion.
Feel free to have your own, but getting newly on a forum and starting to call people trolls within the first few posts, just because he/she has a different opinion, doesn't really make a good look on yourself and it doesn't help to have a pleasant ambiance in here.
So please accept others opinion and if you want to discuss things do it without 'insulting' people you barely know.

9514

SFML projects / Re: Spartickes Engine

« on: October 06, 2012, 10:54:25 pm »

Well your images are still not what one would want, like this:



Also it would've been interesting if you had added an example to your code, so we could actually be able to test it, without having to go through the code and figure out how things work...

9515

Graphics / Re: Positioning relative to sf::RenderWindow isn't quite working as expected...

« on: October 06, 2012, 04:36:23 pm »

I'm not sure, but it could be related to the issue #216...

9516

SFML projects / Re: COSMAGERS - new 2D MMORPG developing

« on: October 06, 2012, 10:20:23 am »

Has to me sense to recode the project on version 2.0?

The SFML 2 API got cleaner, introduced nice features and got ride of some very annoying bugs.
So I'd switch to SFML 2 as soon as possible.

9517

General / Re: Correct way to handle physics time-stepping

« on: October 06, 2012, 12:05:12 am »

An often referred to article is this one.

9518

Graphics / Re: 2.0 ,At Which point should i set OriginPoint in Sprite Objects?;

« on: October 05, 2012, 03:20:18 pm »

eXpl0it3r , Thanks for fast replays

Glad I can reply.

well my sprite have different dimension in some frames, that's why I'm having problem to where set the origin, since the move, setposition depend on the origin point of the sprite.

That's what I suspected and that's why I said you should change the frames, so all have the same size. You'll safe yourself quite some trouble...

Is it good to have the origin point at (W,H)?

Good or bad always depends on the problem you have infront of you. As I said I'd use a fixed size for all of my frames and could eliminate all the problems (scaling etc) with ease, but I guess setting the origin to (W, H) could also work, even though with some side effects.

It's your code, so you have to decide.

9519

Graphics / Re: 2.0 ,At Which point should i set OriginPoint in Sprite Objects?;

« on: October 05, 2012, 01:48:45 pm »

I'm not sure, but when changing the texture rect, do just change it's position or also it's size?
You should keep the size of the rect always the same and only change the 'position' of the rectangle on the texture. With that you set the origin once and it always applies to your character.
Of course it will 'waste' a bit more image space, since you'll have empty places above the crouch frames, but that doesn't really hurt...
As for collision detection and other physic stuff that would depend on the sprite rectangle, it's better to separate the graphic and logic part, thus you should use the texture rect as your input for the collision detection (or if so convert it to match the current state).

9520

Graphics / Re: Divide the image into parts for animation.

« on: October 05, 2012, 01:36:58 pm »

No, since there's no such thing as a 'default' rectangle (except if you'd count the [0,0,0,0] one which the sprite gets initialized with).
For animation you should structure the texture in a way that you can only increase one or two value by a constant factor of the rect, so you'd only have to check if the end is reached and things could start again from the beginning.
Alternatively you can also hardcode all the different rects, but that not a very smart solution...

As we've mentioned earlier you should take a look at the already existing animation class in the wiki, so you get the idea better on how to do things. And if you want a nice implementation (and possible more features) you could check out Thor.

9521

Graphics / Re: 2.0 ,At Which point should i set OriginPoint in Sprite Objects?;

« on: October 05, 2012, 01:32:02 pm »

I don't quite follow you, but it seems to me that you're doing a rather uncommon thing for animation.

Usually if a character has different animation frames, it's a good practice to have all of those different moves in one image which then gets loaded as texture. If you now want to change the frame, you simply change the texture rect (setTextureRect) of the sprite and the new frame will appear.
If the animation is done that way, it doesn't matter what the origin is and you get slightly better performance since changing the texture rectangle is a relatively cheap operation.

9522

Graphics / Re: Drawing darkness around player

« on: October 05, 2012, 08:41:10 am »

If you need an example you can take a look at the one I wrote a few days ago on GitHub.

9523

SFML website / Re: Missing 'sf::' in Documentation

« on: October 04, 2012, 12:12:01 pm »

Documentation isn't really top notch possibly because sfml 2.0 is rc, but it's not extremely misleading. Off the top of my head I remember that sleep function is kind of.. hard to find Unless you spot it's header among hpp files or see it mentioned in tutorial or something, keyboard hpp on site is old so it(and documentation generated from it) is missing 'unknown' key.

And you wanted to say with that want exactly?
Yes the online documentation is mostly outdated and if you need it then check the BUILD_DOC in the CMake process, or build it manually.
As for the hard to find thongs, well Doxygen is the generator in use which creates the documentation automatically. So to get functions to show better one would probavly have to create a custom site...

Btw already fixed

9524

General / Re: Compiling SFML for VS2012

« on: October 04, 2012, 01:07:10 am »

Awesome thanks, but the link is broken xD

Silly me. xD
I only c&p the filename and forgot to add the stuff in front of it. *fixed*

9525

General / Re: eXpl0it3r's Small Game Engine

« on: October 04, 2012, 12:49:59 am »

When he clicks on the "MainMenu" button, wouldn't I just change the state to the MainMenu instead of calling the pause function?  Then after doing things in the MainMenu, just do a return and be exactly where he left off?

Yes this would work perfectly.

Why call the pause function and then the resume function after doing things in the pause function?  An example would be really helpful for beginners like me.

The two functions are specially useful if you call them manually. For example you have a game with enemies etc and now you stop at a certain location at which enemies could attack you if you don't keep moving, but since you have to grab some food, you'd want to pause the game. By pressing P for example you could then call the pause() function, which will set a Boolean and in the update & draw call you now don't update the enemies etc anymore but show a semi-transparent overlay saying "Game Paused". When you return you could press ESC which then calls resume() which changes the Boolean back and your game can proceed.

That's just one example, there are many different use cases...