Messages

61

General discussions / Design flaw in my game ?

« on: August 16, 2011, 04:28:10 pm »

So, polymorphism is not the best way to write such a state manager, is it ?

I think it's a fine way to do it.  It's how I do it myself.

IMO, The problem is you're trying to build something that has nothing to do with states into your states.

I think you're making this more complicated than it needs to be.  I would just do this:

Code: [Select]


struct GameEnvironment
{
  // .. various "game wide" data that can be used in every state

  // throw the Save function in here
  void Save();
};


Create one instance of that class in main and pass a pointer to it to each game state when they're created.

62

Graphics / Sprite Sheet Animation problem

« on: August 16, 2011, 04:59:21 am »

You need to watch how much time has passed and only advance frames accordingly.  Something like this:

Code: [Select]


void Animation::Update(int ms)
{
  // this function would be called every update (every "frame")
  //  ms is the number of milliseconds passed since the last
  //  frame
  time_remaining -= ms;  // subtract the time passed from the
         // time remaining in the frame

  // then keep advancing frames until time remaining is above zero
  while(time_remaining < 0)
  {
    AdvanceToNextFrame();
    time_remaining += ms_per_frame;
  }
}


63

General discussions / Design flaw in my game ?

« on: August 16, 2011, 04:54:04 am »

I don't think the GameStates should own a Save function.  That doesn't really make sense.

Does the game you save differ from state to state?

If no, then it doesn't make logical sense to put it in every state class, and it would be a bunch of duplicate code anyway.

If yes, then how do you plan to load it?  What if you try to load a game in state A that was saved in state B?  Would you have to switch to state B?


I would have game saving/loading part of the overall Game class.  States should have access to "Game wide" info in one form or another anyway.  Just throw the save function with that.

64

Feature requests / sf::String removal

« on: August 16, 2011, 12:08:18 am »

You make good points.  This will take more thought.

I've been wrestling with how to approach this topic with my own project.  I originally decided on sf::String, but using it for anything other than conversion (ie:  finding, replacing substrings, etc) becomes a real chore.

65

Feature requests / sf::String removal

« on: August 15, 2011, 11:47:39 pm »

Use std::back_inserter

Ah.  Nice.

Still, you'd want to calculate X for a reserve() call at least to avoid unnecessary reallocation.

A simpler solution would probably not be bad, but the iterator approach is very flexible, for example for transforming only parts of strings or other containers holding characters.

I agree completely.  The iterator solution is great and should not be removed.  I just think there should be something simpler for common tasks.

At the moment, you can still perform the conversion in a very simple way via sf::String.

But that involves the overhead of copying the string to an intermediate buffer.  If you're using sf::String solely for the conversion, it doesn't make sense for it to keep a copy of the string buffered.  That's kind of why I think it should be removed.

Not really. For example, you can't initialize std::basic_string<sf::Uint32> with string literals, what makes code like sf::Text::SetString() calls unnecessarily complicated.

There are solutions for this besides having another string class.  The most obvious is to give SetString more overloads.

Although maybe a better option would be to have a conversion class that doesn't buffer the string.  That way you could still have implicit casts but without the need for the additional buffering.

66

Feature requests / sf::String removal

« on: August 15, 2011, 11:30:15 pm »

Gah I had a big post here but my connection swallowed it.

sf::Utf fits the bill, but lacks direct support for strings.  The iterator interface is good, but I think another layer could be put on top of that.

Currently, if you want to use sf::Utf to convert a string, it's a multi-step process that is very unintuitive for beginners:

Code: [Select]


std::string my8; // utf8 string
std::wstring my16; // utf16 string

// we want to convert my16 to my8

my8.resize( X );  // where 'X' is big enough to hold a my16 in UTF8 form.
std::string::iterator stop = sf::Utf<16>::ToUtf8( my16.begin(), my16.end(), my8.begin() );
my8.resize( stop - my8.begin() );


Not only is that overly complicated, but it's also error prone.  The user shouldn't be expected to calculate X.  That should be up to the conversion routine.  There's not even any way to guard against potential overflow here, if X is calculated incorrectly.

I'd like to see something like this:

Code: [Select]


// simple:
my8 = sf::ToUtf8(my16);

// this would work too, but it's too verbose for my taste:
my8 = sf::Utf<16>::ToUtf8(my16);



With these kinds of conversion routines not fixed to any one class, the need for sf::String dissolves and can be replaced with std::basic_string.

67

Feature requests / sf::String removal

« on: August 15, 2011, 10:18:41 pm »

sf::String suffers from "another string class" syndrome.

It's true that it adds handy conversion and locale functionality, but when it comes to other fundamental features of a typical string class (like std::string), it falls short.

I don't think increasing sf::String functionality is the solution.  I think that would only serve to be extra work and write code that already exists in the standard library.

Instead, I think sf::String should be removed entirely.  And instead, all the conversion and locale functionality it offers should be placed in a separate series of global utility functions that operate on external objects (rather than trying to manage the string data themselves).

With such conversion functions in place, instances of sf::String could be replaced with std::basic_string<sf::Uint32>.

68

Feature requests / Ability to set the window title.

« on: August 13, 2011, 06:44:44 pm »

Fair enough.

69

Feature requests / Ability to set the window title.

« on: August 13, 2011, 05:45:00 pm »

Why does SetTitle take a std::string?  What if you need Unicode characters / characters not part of the machine's current locale/codepage?

70

SFML projects / SFSL - SFML File System Library

« on: August 10, 2011, 10:27:28 pm »

Work keeps me very busy so I don't have as much time to work on this as I'd like.

I'm still making progress but it's sparadic at best.  I wouldn't expect anything for at least a month or two.

71

General / homing missile

« on: August 09, 2011, 05:04:31 pm »

Here's an example to show how my approach works.  It really is much simpler (and faster since you don't really need any trig function calls), so I recommend you try it out:



Note I might have the sign backwards on the PerpDot (maybe counter-clockwise is Positive, not Negative), but that'll be easy to figure out if you try it.  If the missile moves away from the target, just flip the sign and it should work.

72

General / homing missile

« on: August 09, 2011, 12:21:00 am »

Assuming you have a missile X/Y velocity, you could greatly simplify this by employing linear algebra.  You could eliminate the atan2 calls altogether and substitute it with perpendicular dot product.

Code: [Select]


template <typename T>
inline T PerpDot(const sf::Vector<T>& A,const sf::Vector<T>& B)
{
  return (A.x * B.y) - (A.y * B.x);
}


Given 2 vectors A and B, PerpDot(A,B) gives you sin( theta ) * length(A) * length(B).  (Where 'theta' is the angle between the vectors)

For example, if A and B are parallel, PerpDot(A,B) would be zero.  You can use this to determine which "side" of a vector another point is on.


You have 3 key points:
i) the missile's current position
ii) Any point along the missile's current trajectory (missile's current position + missile velocity)
iii) The target point

Vector A would be ii - i.
Vector B would be iii - i.

Run a PerpDot on those vectors.  If the result is negative, rotate one way.  Or if it's positive, rotate the other way.

If the result is zero, then the target point is either directly in front of (or directly behind) the missile.  In which case you can do a Dot product to figure out which:

Code: [Select]


template <typename T>
inline T Dot(const sf::Vector<T>& A,const sf::Vector<T>& B)
{
  return (A.x * B.x) + (A.y * B.y);
}


Dot(A,B) gives you  cos(theta) * length(A) * length(B).

The result here is that Dot(A,B) will be positive if the missile is heading towards the target, and negative if the missile is heading away from it.

73

General discussions / Window drag keep rendering (solution) [SFML 2.0]

« on: August 05, 2011, 03:58:31 am »

I can see a lock-free system working where:

1)  There are never fewer than 2 nodes in the queue
2)  only 1 thread is adding things to the queue
3)  only 1 thread is taking things from the queue

As soon as you step beyond any of those criteria, I'm lost as to how you can retain thread safety without a blocking lock.

74

General discussions / Window drag keep rendering (solution) [SFML 2.0]

« on: August 05, 2011, 01:15:56 am »

I'd be very interested in knowing how you could make it safe without a lock.  I have been thinking about it, and the more I think about it, the more I'm convinced a lock would be necessary.  But I've been wrong before.

Can you show an example?

75

General discussions / Window drag keep rendering (solution) [SFML 2.0]

« on: August 04, 2011, 09:04:47 am »

An alternative approach to this would be to make a new Window class.  One that has the same interface as sf::RenderWindow, but runs all the messages through an internal (threadsafe) messaging system (I'd use a list or deque over a vector, though.  Deque is probably the way to go).

That way the end user doesn't need to worry about spawning a new thread and keeping it threadsafe, and people who want to add this functionality don't need to rewrite their code -- they just use this new class instead of sf::RenderWindow, but all function calls and whatnot are the same.