Messages

31

Graphics / Re: Image.loadFromFile() also fails in SFML 2.0

« on: May 26, 2013, 07:12:02 pm »

Found your problem.

if(!CaptchaImage.loadFromFile(Filename));    //Load the file into our Image
{
    std::cout << "I couldnt read the image from " << Filename << std::endl;
    exit(12);
}
 

Look VERY carefully at these lines. Notice anything? You have an extra semicolon in there. Try removing it.

32

Graphics / Re: Image.loadFromFile() also fails in SFML 2.0

« on: May 26, 2013, 07:36:54 am »

It's nice to know what output you print, but you HAVE to tell us what output SFML itself gives, or we CAN'T help you.

ALSO, please post a COMPLETE and MINIMAL code that demonstrates your problem so we can see if it's a problem with your code or with SFML itself.

33

Graphics / Re: Bug with texture rendering

« on: May 23, 2013, 07:55:39 am »

I think that this engine is with bug.

Sometimes it works nice and after some minutes all the sprites is like that screenshot, bugged. I try open the program more times and everything works ok.

You may be suffering from a Schrodinbug. I am so very sorry.

No, I don't think anybody here claimed pointers were causing the bug. They are, however, extremely dangerous, and we wanted to help save you from the headaches they will cause down the road.

Again, we cannot help you further unless you create a complete and minimal code that demonstrates the bug you are experiencing.

On a purely speculative note, have you made sure your video drivers are up to date?

34

Graphics / Re: Bug with texture rendering

« on: May 23, 2013, 05:01:48 am »

If you read the other posts, YOU WILL SEE THAT I ALREADY PUT A LITTLE PIECE OF CODE!

I only put the full source to complete if anyone need.

Like I said, we need a COMPLETE and MINIMAL code. This means source code compressed into one single file that can be compiled on its own with every single line irrelevant to your problem removed. This is standard practice on this forum, and you have so much code that it's hard to know where to begin to look.

I'm asking for help as a favor, I'm not forcing anyone to do anything.

We know this, but we can't help you unless you post complete and minimal code.

Ah...and i dont use DELETE.... i dont know where you see it.

This is exactly why new and delete are considered no-nos. Whenever you use new, you MUST use delete. Otherwise, your computer will suffer from memory leaks, and if enough memory is leaked, your system will become highly unstable. Not to mention it's damn near impossible to have an instance of delete for every instance of new, especially if the program crashes due to a bug.

35

Graphics / Re: Bug with texture rendering

« on: May 23, 2013, 04:45:19 am »

NOBODY is going to read all of that code, and nobody is going to help you unless you post a complete and minimal source code that demonstrates your problem.

However, I did take a brief look at some of your code, and noticed a rather large problem. You are using new and delete for a large number of variables. You should never use new and delete. Ever. And in the very rare case you do need new/delete, you should use smart pointers, NOT raw pointers.

36

General / Re: How to avoid alpha blending on .gif images?

« on: May 20, 2013, 05:19:05 am »

First of all, GIFs are almost NEVER the same quality as BMPs or PNGs. They are limited to 256 colors at max. In your case, that's not too limiting, but in general it's a pretty strict limit. Secondly, GIFs do not have proper support for alpha transparency, so if your images have alpha transparency, GIFs are very bad.

In general, PNG is FAR better than GIF. It has very high compression rates, zero loss in quality, and very high decoding rates. The best option, honestly, is probably to just use PNGs and be done with it.

EDIT: Just realized I misread your post, you don't want alpha in your sprites. In that case, still use PNG, but use a program like GIMP to remove the alpha channel. If you do that, no alpha information is saved into the PNG.

37

Graphics / Re: Double Buffering

« on: May 19, 2013, 07:26:31 pm »

SFML forum,

 Some graphics libraries will automatically save the pixels behind a
 sprite before it's moved and automatically replace those pixels after
 the sprite is moved.

 I will do some timing but I'm almost convinced the SFML method is as
 fast as anything else.

 Thanks for all the replies.

Jerryd

No, the calculations behind that process are both CPU and GPU intensive, and in general, if you have multiple sprites moving (which you WILL), it is FAR slower than just redrawing everything.

38

Graphics / Re: Double Buffering

« on: May 19, 2013, 08:06:23 am »

Why would you want to do this? There is no advantage to it, and it is a LOT slower because it has to copy everything.

As far as I know, double buffering is something that happens by default. SFML should be drawing to a buffer, which get's displayed. While the "front" buffer is on the monitor, we would be drawing to a "back" buffer which will be switched with and becomes the front buffer during your monitor's refresh. And it happens again and again.

Um, yes, that's why I think he shouldn't be bothering with this. Double buffering is already implemented by default, and is far better than what he wants to do.

39

Graphics / Re: Double Buffering

« on: May 19, 2013, 08:05:09 am »

OniLinkPlus,

 Flipping has to copy to and from both bitmaps,  seems like that
 would take longer than just a simple one way copy.

 If it flips and there was a sprite move I have to completely
 rewrite the off-screen buffer.

 With a simple copy I only need to move the sprite,  the pixels
 behind the old sprite position are automatically restored, and
 then just copy to the on-screen buffer.

Jerryd

Unless I'm misunderstanding, you seem to think that double buffering copies the contents of the buffers to each other? This is completely false. All that happens is that a pointer is swapped. One frame, the graphics card reads from one buffer. The next frame, it reads from the other. There is no copying involved.

If a sprite "just moves," you have to completely redraw the buffer anyways, or you'll have a "ghosting" effect where the sprite appears in both its old position and its new position. You could redraw both where the sprite was and where the sprite is now to be rid of the ghosting, but determining what sprites will have to be redrawn and then redrawing them only in those spots would be needlessly complex and time consuming for the graphics cards, especially if you have multiple sprites moving, which you almost definitely will. In fact, it's far more efficient in general to just redraw everything each frame.

40

Graphics / Re: Double Buffering

« on: May 19, 2013, 06:49:35 am »

Why would you want to do this? There is no advantage to it, and it is a LOT slower because it has to copy everything.

41

Window / Re: Multiple joysticks - Joystick IDs

« on: May 05, 2013, 08:58:12 am »

I'm sorry, but I don't understand your problem. What's the relation between SFML and Xinput? What "lights" are you talking about?

The XBox 360 controller has a ring of 4 lights around its center button. One of these four lights will light up on each controller that's plugged in, telling the player which player number they are. The ID SFML gives to each controller for sf::Joystick::isConnected( id ) and similar functions does not match up with the light on the controller. Additionally, when he uses XInput to tell a controller to rumble, he tries to use the ID given to him by SFML. This results in the wrong controller rumbling.

You can see the lights on the 360 controller here.

42

Graphics / Re: How to Fix White Square?

« on: May 01, 2013, 12:46:13 am »

My question is why are you using new/delete? You don't need to use new/delete, and you really shouldn't be using them in the first place.

Also, please show us your complete and minimal code so we can give you proper assistance.

43

General / Re: AW: sfml 2.0 undefined reference to getDefaultFont

« on: April 26, 2013, 12:09:24 am »

From where did you get SFML from?
In the latest version there's no default font. To me it seems like you're mixong old header files with the new SFML 2 lib files.

He's not using a default font. He's loading it from arial.ttf.

44

General discussions / Re: A new logo for SFML

« on: April 21, 2013, 07:36:41 pm »

I vote for this one.

45

General discussions / Re: What physics engine to use?

« on: April 13, 2013, 04:04:10 am »

Except it's commercial, incredibly overpowered for anything 2D, and known for having some pretty bad bugs.

Ah, but it usually makes games a lot more popular, just look at Skyrim/Fallout 3 and Half life 2.
You wouldn't be able to enjoy those games the same way without it... Glitched physics engines are more fun than the average run of the mill engine. And to say you cant use a 3D physics engine on a 2D game is kinda dumb as well... just don't use the Z axis... better yet... use it to your advantage(Think Little big planet and how they switch layers). If I had the money and time I would totally use Havok over Box2D just for my 2D platformer, because I can. Also if the game is good and you have made lots of money off it you can flop to 3D, making Havok better taken advantage of. Doing different things on your games makes it unique and more fun.

I hope I made some sense.

Uh, no, not at all. 99% of the people who play those games have no idea what Havok is, nor do they care. I can also assure you that they don't play those games for the physics, I assure you I don't. If they did, they would be playing GMod or Angry Birds or something along those lines instead.