Messages

76

Graphics / Error loading Image with SFML [Solved]

« on: November 20, 2008, 09:18:37 pm »

This was solved over here.

77

Graphics / svn: Image.LoadFromFile and Image.Create crashes

« on: November 20, 2008, 09:17:29 pm »

I've only had time to test it on one computer, but it crashed before and it doesn't crash now!

I had one place I was manually coding texture coordinates in and that's now screwed up. I fixed it with the Image::GetTexCoords() function which works like a champ. Moral of the story, don't manually code in texture coordinates.

Thanks a ton, wizardofoz and Laurent.


Edit: I've since had time to test more computers. It's working on all of them.

78

Graphics / svn: Image.LoadFromFile and Image.Create crashes

« on: November 18, 2008, 10:56:33 pm »

I'm 99% sure this is going to fix my problem over here. It's funny how bugs like this look so obvious after someone points them out.

Good work, and thanks, wizardofoz.

79

Window / Best way to get smooth input

« on: November 17, 2008, 02:29:12 am »

Have you tried keeping the while loop but moving all the drawing/stepping stuff outside of it? It's probably best to redraw everything every frame.

I think your problem is that you are only updating/drawing while there is an event. Most if the time there is no event.

80

Window / Best way to get smooth input

« on: November 16, 2008, 10:20:04 pm »

I think the KeyPressed event fires only once when a key is pressed, and then again if it's held down long enough. For example, hold down the a key in a text box. Every time you see it type an a the event would fire.

In the tutorial read the section Real Time Inputs for info on how to test if a key is down.

For example, you may want to try:

Code: [Select]

const sf::Input& Input = App.GetInput();
bool LeftKeyDown = Input.IsKeyDown(sf::Key::Left);


81

Feature requests / Virtual Inheritance

« on: November 09, 2008, 07:46:17 pm »

I guess it's a slightly higher level abstract base class. Since it inherits from Drawable, I do send it directly to RenderWindow.Draw().

The thing is, if I make an ASprite I just want to tell it to move and have it do that. I feel this is much cleaner than making an external loop to update it's position each frame. I feel having it do it automatically repeats less code, is much easier, and divides class responsibility better.

If I'm wrong, or if you have a better way of doing things, please let me know. You're obviously more experienced than I am.

82

Feature requests / Virtual Inheritance

« on: November 09, 2008, 07:21:23 pm »

The way you're doing it rather means you're extending SFML's graphics classes.

That's exactly what I'm trying to do. I want a Sprite, but with extra features like easy animation capabilities.

83

Feature requests / Virtual Inheritance

« on: November 09, 2008, 10:40:28 am »

I didn't explain it very well. Let me try again.

I want to make a hybrid Drawable class that does logic and animation as well as all the standard Drawable features. I do something like this:

Code: [Select]

class Animatable : public virtual sf::Drawable
{
   ...
   void AddMove(Move*); //Adds an animation move to our queue.
   virtual void Update(float elapsedTime); //Call once per frame to update logic and do animation.
   ...
};
Since this class applies move objects to itself, it must know that it is a drawable (or use dynamic_cast). The Move class is an abstract base class like:

Code: [Select]

class Move
{
   public:
      virtual void Apply(sf::Drawable& obj, float elapsedTime) = 0;
      virtual void Alive() const = 0; //should return false when the move is over.
};

In general, this works great for me. I can do custom classes like:

Code: [Select]

class Man : public Animatable
{
   ...
   private:
      sf::Sprite head, body, arms, etc;
};
And everything works great. My only trouble is that I'd like to make an animatable sprite:

Code: [Select]

class ASprite : public sf::Sprite, public Animatable //Bam, diamond problem!
{};
If sf::Sprite used virtual inheritance it would circumvent this problem. Currently, I'm modifying it to do just that (it's adding 1 word).

as the "drawable" side of a class is generally just an implementation detail, not a part of its public interface.

But it is a public interface for Sprite, String, and Shape.

Thanks!

84

Feature requests / Virtual Inheritance

« on: November 09, 2008, 03:03:24 am »

Why doesn't SFML use virtual inheritance?

I love SFML's hierarchy and how nested calls to Render() inherit their parents properties. My problem is that I want to expand the Drawable class with logic specific to my game. This works fine for my custom objects, but I can't use multiple inheritance for Sprites, Shapes, or Strings without running into the diamond problem.

Therefor, I currently modify SFML for my use by making Sprite virtually inherit Drawable. I do the same for Shape and String. This will of course impose a small run time performance decrease, but I think that the extra flexibility is well worth it.

As an example, with my current setup I can do:

Code: [Select]


ASprite test; //ASprite inherits from sf::Sprite and includes move functionality.
test.LoadFromFile("sprite.tga")
...
test.AddMove(new Move::LinearA(0, 0, 100, 100, 1.0f));
test.AddMove(new Move::RotateA(0, 90, 1.0f));
That would make test animate from 0, 0 to 100, 100 over the next 1 second while rotating from 0 degrees to 90 degrees. My specific problem is that my ASprite class must know that it's Drawable inorder for the moves to operate on it. Therefor, if it inherits from sf::Sprite, I run into the diamond problem. Virtual inheritance cleanly fixes this. (an alternative is to use dynamic_cast - that has the disadvantage of run time errors)

I was wondering why SFML doesn't do this already, and if you would consider using virtual inheritance in the future.

Thanks!

85

Feature requests / sfml equivalent of GetMessage()

« on: November 07, 2008, 11:27:34 pm »

I added a question on stack overflow about the memory leak problem, for what it's worth. Looks like half the answerers didn't read the question, and there is a huge variety of opinion.

86

Feature requests / sfml equivalent of GetMessage()

« on: November 07, 2008, 07:40:15 pm »

kfriddile, how would the current "memory leak" effect an SFML user at all? The memory is freed as soon as the application quits. The memory is used until then. The memory usage doesn't grow over time. Why does it make any difference to you what-so-ever?

I think it only has one disadvantage. That is that it shows up as a false positive on tools looking for real memory errors (the kind that accumulate early and often).

Is there any other disadvantage at all?

Why should two windows have the nasty hidden implicit coupling of sharing a context? It's the same reason globals are bad.

Do you think that MDI is always bad then?

87

Feature requests / sfml equivalent of GetMessage()

« on: November 07, 2008, 09:25:08 am »

And you haven't experienced every single situation to say that 100% of leaks can be removed.

Experience doesn't enter into it, just logic.  Anything you create, you can destroy.

If your program is completely sandboxed, then yes. In that case logic says that you can free anything you allocate, no matter how convoluted your design becomes.

However, SFML isn't working in a sandboxed atmosphere. It's calling third party libraries. A third party library could be designed so that you could not free everything you allocate. I'm not saying that's the case here (in fact I very much doubt it is), but that is a possibility (I believe logic should lead you to agree).

Thanks!

88

Feature requests / sfml equivalent of GetMessage()

« on: November 07, 2008, 09:12:29 am »

actually I shouldn't even take in account the 3D API when designing my library, it's just an implementation detail.

Right on, Laurent! Seriously, don't ever sacrifice your ideals.

As for the "memory leak", fix it or don't. It doesn't really matter to any reasonable person, as long as you're aware of it and it doesn't grow. Wikipedia calls a memory leak "where the program fails to release memory when no longer needed." Since you're using this memory the entire time it's allocated, is it really even a "memory leak" at all? If you stopped using the memory at some point and didn't free it, then I'd agree that it's totally unacceptable, but that's not the case.

On the GetMessage()/WaitMessage()/Whatever() topic: If this was added I would use it when my game is paused/minimized. If you added it, I bet a lot of others would use it for the same reason. Other than that, I don't personally have any immediate use for it.

In any case, SFML is already an awesome library. Just avoid taking steps backwards (like forcing the user to reload resources when changing video mode) and it'll be an awesome library for some time to come.

Just my 2 cents.

Thanks!

89

Graphics / Error loading Image with SFML [Solved]

« on: November 04, 2008, 02:40:38 am »

Thanks for pointing that out. I didn't see that.

I have the problem occurring on two computers. One has an ATI Radeon 9550 Mobile, the other has an Invidia Geforce2 MX 200. Both have Windows XP 32 bit and neither has the latest drivers installed. I'd much rather have a robust program that runs with old drivers. I do not expect my target audience to regularly update their graphics drivers (or anything else for that matter).

Anyway, thanks again for your reply. I'll keep researching.

90

General discussions / Problem with Code::Blocks files - debug [Fixed]

« on: November 02, 2008, 08:14:36 pm »

Great!  

probably because nobody uses the Code::Blocks debugger

Actually I don't use it either. (Although I do think it's a great IDE, as far as they go.) I just though that was the easiest/only way to compile SFML with MinGW. Your make files seem to be hard coded for Linux/Unix.

If you used CMake, I'd just have it output MinGW make files. Code::Blocks is pretty easy to compile with though, so I'm not complaining.

Thanks.