Messages

31

Window / Re: Main while loop is not executing

« on: January 22, 2013, 08:34:06 pm »

Exploiter, you cannot clear a window, renderwindow yes but not plain window.

There's glClear() for that, the parameter depends on whether you use a depth buffer or not.

I'm just new to C and C++. But yes, I am using OpenGL.

JOGL before I suppose.

32

Graphics / Re: Free image memory

« on: January 21, 2013, 10:19:18 pm »

Allocating it to heap and deleting it, letting it go out of scope. I don't see the point in the question, what exactly do you want to achieve? Please explain better.

http://en.sfml-dev.org/forums/index.php?topic=5559.0

33

General / Re: Issues with game speed

« on: January 21, 2013, 04:47:27 am »

Also, if it wouldn't hurt, could you guys tell me if my code looks okay? I feel like I could be making a mistake here. There's pretty much only one object instantiated of the playerCharacter class. I feel like that's a mistake, because I currently only need one player, but I also think I need the organization of data that classes provide. Are there cleaner alternatives, or is what I'm doing okay?

I assume that the reason for having everything public in the class is for simplicity in testing and making the code minimal. If not then you should make all variables that are not needed as public private. The usage of references instead of pointers and usage of initialization lists in the constructor. Those are all good programming habits that are worth learning and implementing, but it's become obvious that the problem most likely doesn't lie in that.

There are surely better ways to structure it by going through what is considered to be good programming practice and other standards that make code far more readable.

However if you ask for improvements you can go for that.

The update function should be a member function, not a friend. cmath instead of math.h. #Define when you could have a math global const (in a namespace for better handling). Enums could be used for explicit state handling instead of using a char (even more with C++ 11 enum classes and changes in enums). Static_cast instead of C casts and the list can go on.

Now for the real problem, let passed time in the update function be sf::Time instead of sf::Int32 and use the FPS clock to return time to it directly. Inside the function convert time to seconds (casting microseconds to float may not be right) and check the results.

The call should look like this:

Update(teabot, gameClock.getElapsedTime());
///Using a reference to teabot, not a pointer.
///As it would receive an sf::Time variable this is valid.
///Note that you make the conversion to seconds or whatever time unit you want inside the function.
 

Take note that your char Distance 'F' doesn't change back to another value when there's no input, so that may be a possible cause. An enum (with good naming) would make what you want to do with the class a lot clearer.
And the variable is never initialized, which can be potentially bad, as it can have a random value that has the possibility of being 'F'.

I'll probably test it tomorrow (as I can't right now), but try that for now.

34

General / Re: Ray casting in 2D (Not related to SFML)

« on: January 21, 2013, 03:47:44 am »

That type of graph is common in linear algebra, I hadn't seen one in months after I won the course in my uni.

That aside your algorithm is pretty much complete in that aspect, you could try skipping the sqrt whenever possible (there are cases where it matters not whether you have the squared magnitude or not), but overall all it could possibly lack is inlining if you need your vector class very often.

35

Graphics / Re: Inherited sf::Drawable crashing

« on: January 21, 2013, 12:40:21 am »

Note that your class constructor uses a sf::texture* and it doesn't check whether the texture that is being pointed at exists or not, try removing the line that sets the texture and if it doesn't crash any further then it was probably a pointer to an invalid texture.

Also, something that may sound like a dumb beginner mistake (suggested as a way of removing any possible error) but its still worth checking: Are the values rows and columns below 16? If they were higher or not even initialized (the compiler just puts some random number when you don't initialize a numerical variable) then the cause for the SIGSEV would be obvious.

36

General / Re: Issues with game speed

« on: January 20, 2013, 06:00:35 am »

I'm going to sleep now, but I'll try to help tomorrow in the afternoon with some more time, however a small note on some code skimming: Don't use Real-Time Input  when you don't need it, it's pretty much overkill to use it to close the window, verify whether it's necessary or not to use real time input and if not then use events instead.

37

SFML projects / Re: Game Development Design articles

« on: January 19, 2013, 09:59:03 am »

Great! I've been expecting this one for a while now, after reading more on move semantics this seems like the best way to go on what I've been wanting to learn lately.

38

General discussions / Re: A new logo for SFML

« on: January 19, 2013, 09:56:36 am »

I can try and make a possible logo myself. I may not be a seasoned artist, but I plan to be one in the future. Maybe after I finish what I am programming right now though, which may take around a week or hopefully less.

39

General / Re: Can't even do the simplest thing right

« on: January 19, 2013, 01:32:30 am »

hmm as it is now it just stacks the figures, so it doesn really clear the display in every iteration, plus the for loop does 1500 shapes and then goes back to the main loop so that would't be an issue.

Display should only be called once per iteration, not 1500 times. Also note that if you set a frame limit the display function will call sf::Sleep on it's own, so you don't have to call it explicitly and you can have an average speed in your program.

I'm following a series of tutorials that use 1.6 so I'm not quite ready to jump to 2.0 yet.

Much of the concepts used in 1.6 still apply for 2.0 and unless you start working with the low level API or doing crazy things right away you will only notice a few differences, which end up being far better than anything else 1.6 has to offer.

40

General / Re: Can't even do the simplest thing right

« on: January 18, 2013, 06:15:46 pm »

I don't have much time to test and analyze this through yet I will give you some tips.

If you are going to use iostream don't use cstdio(stdio.h) and the same applies backwards, that's mixing C and C++ which isn't exactly a good practice. Also use the c-libraryname, instead of libraryname.h in order to mantain the consistency in your programming.

Check that the random values are being assigned correctly, sometimes some freaky errors can be avoided by checking the data of the values you are assigning.

Make a minimal example in order to realize what is it that makes them not move, the amount of code for a trivial problem such isn't good. Make it as small as possible while reproducing the problem.

SFML 2.0 is far better than 1.6 as it fixes many bugs and has a better graphics API with many new features for both high and low level rendering. 1.6 may be "stable", but it is actually deprecated in many aspects and hasn't been touched in two years.

Read this: http://en.sfml-dev.org/forums/index.php?topic=5559.0 and this: en.sfml-dev.org/forums/index.php?topic=10306

The recommendations of eXpl0it3r apply very well and may solve the problem though it may (unlikely) be somewhere else.

41

Feature requests / Re: Support for OpenGL Array Texture in future SFML2.x

« on: January 18, 2013, 03:30:56 pm »

Correct me if I am wrong.

I think the main reason for the "not yet" is the fact that it's OGL 3.0. As an owner of a crappy GPU (and now computer in general) I would not be able to use this feature at all because my GPU supports up to OGL 2.0. And while I may know the reason why, most new users in similar circumstances would wonder why would there be a feature that can't be used unless you have X hardware and up. Mostly the reason why SFML uses the deprecated (but still supported) OGL 1.x.

42

Graphics / Re: Parallax background with a couple of images

« on: January 18, 2013, 03:14:15 pm »

Then you'll have no problems, FPS tends to lower once the amount of sprites goes beyond thousands (depending on your specs of course).

43

Graphics / Re: Parallax background with a couple of images

« on: January 18, 2013, 03:00:44 pm »

Btw: If you care about performance you should start using sf::VertexArray (or std::vector<sf::Vertex>) instead of sprites. The boost you get is incredible, but the scenery might be a bit hard to work with.

Depending on what you may need you can use a class in the wiki for that, mainly the tile-map classes if I understood well what you want.

44

General / Re: AlexxanderX problems...

« on: January 18, 2013, 05:06:21 am »

Could you describe your problem a bit better. I hardly understood what was wrong.

You could also consider using a tile-map class, there are two (I think) in the wiki.

45

Graphics / Re: Can't get different font

« on: January 18, 2013, 04:55:01 am »

I meant the SFML 1.6 being that bad, not SFML 2.0 being that much better.

While I understand your point I can tell that both Nexus and eXpl0it3r are right. If you haven't heard of it then look for the ATI bug that 1.6 had. Not working well for a large portion of hardware is a grand sin for a multimedia library, that has (and mostly could have only) been overcome with time and experience. The whole graphics API was rewritten for a reason.

For your project 1.6 may be fine, but for anything else is non-sense unless you have a real reason for not changing, honestly I can't think of one other than your case.