Messages

16

General / [Solved] Designing questions

« on: June 16, 2008, 06:17:52 pm »

When I get home, I could send you the current state of my event dispatcher if you wanted I've created it so that the standard dispatcher just has one listener and then created adapter listeners that can have multiple listeners on them (and they forward the events to each one). It works, and is pretty much complete but I'm not entirely happy with how my event structure works in it though It's still good enough to show how the idea works, and probably easy enough to use anyway

17

General / [Solved] Designing questions

« on: June 16, 2008, 05:03:10 pm »

It depends on the observer pattern... with a state machine like that, I think I'd personally set things up so that there is a second 'interface' between the event publisher and the states that keeps track of the active state. It receives all events and queries the active state as to wether or not it wants a particular event and forwards it on.

The other solutions would be for your state manager to deregister the old state and register the new state for events when they get switched, or to have an event publisher that only has one observer at a time (which is a valid design, and the easiest to implement .

As for the actual implementation of the publisher... decide upon an interface for your observers, then have a class that implements your event loop and accepts pointers or references to observers in register and deregister events. You then store these internally and (if they are set) call the interface methods on them when the correct events occur. It doesn't take too much code to do, although if you start making it complicated you can require a fair amount of code to track things like stray events.

18

General / [Solved] Designing questions

« on: June 15, 2008, 11:23:29 pm »

Yes there are other ways to do it.  I gave a simple straight-forward one.  He asked for the proper way to do what he was already trying to do, which I gave.  And singleton is a perfectly viable design pattern that is used in professional projects.  Creating a dispatcher system is far more complicated than singletons and almost certainly a bad idea for his first app-design problem.  Also, singleton is probably the fastest (execution speed) design pattern.  Passing pointers and references around everywhere isn't just "extra typing."  It's extra execution time too.

I never said singleton wasn't viable. I said that using a singleton as a 'design pattern' stand-in for a global variable wasn't correct usage. I know that singletons are used in professional projects, and I personally think that about half of them are probably just to have global variables without someone saying that global variables are bad.

Talking about execution speeds of design patterns seems a bit away from the point though. Singletons can be very fast... so can smart pointers (another design pattern) facades, or any other design pattern. They can also all be slowed down considerably because of other design constraints (such as singletons checking access rights, or performing lazy creation of expensive objects, or smart pointers doing all sorts of fancy stuff). It all depends on the design And a singleton requires an extra function call. An extra parameter requires one extra parameter added onto a function call that is already being made. An extra function call is frequently more expensive than an extra parameter to an existing call (especially if your singleton uses lazy creation and is less likely to be inlined because of it, or you can't inline it because you are using a singleton to an abstract interface and don't want to expose what you are actually creating).

19

General / [Solved] Designing questions

« on: June 15, 2008, 08:39:15 pm »

Do some research on "singleton design patterns."  That's probably the most straight-forward method.
Basically, it involves creating "manager classes" that only have one instance for the entire life of the program, for example a Renderer class (that could contain the render window.)  The class includes a member that is a static pointer of its own type.  Then you make a static function to get that static self-pointer, which points to the only instance of that class.
So the "renderer" can than be accessed from anywhere in the program.

Bzzt... incorrect use of singleton detected

Seriously though... a singleton used like this isn't really a singleton, it is a fancy wrapper for a global variable. A correct singleton is a class that you have gone through the design process of your choice for and it has come up as a requirement (note that is requirement, not convenience) that it should only ever have a single instance of it in existence in the program at a time.

Using a singleton as a global variable doesn't avoid the fact it is a global variable with all the usual problems. Honestly, the best thing would be to pass a reference or pointer for your RenderWindow into each function that uses it. It may be a bit of extra typing but the advantages are that you can more clearly see where it is being used (explicit parameters, rather than globals which can be used as implicit parameters), and you don't need to rewrite 90% of your code if you suddenly realise that it would be a good idea to be able to have 2 RenderWindows (which isn't exactly a stretch). Global variables (and singletons masquerading as them) are a good example of the violation of Einstein's idea that 'things should be as simple as they need to be, and no simpler' by being too simple.

For the events, I typically have an event 'dispatcher' that has an event loop and you register components as being interested in certain events with it. The dispatcher then sends out only those events that a component has registered an interest in (for example, in it's current incarnation, I have window events, mouse events, keyboard events and joystick events. If something has no interest in window events, it doesn't register for them and so never needs to handle them). It is called the Observer pattern (and sometimes the publish and subscribe pattern) and is fairly useful for things like event systems

20

Feature requests / Support UTF-8 in String? (->GNU/gettext)

« on: June 10, 2008, 03:42:52 pm »

As I haven't posted it here yet, there's also:
http://www.joelonsoftware.com/printerFriendly/articles/Unicode.html
which is nicely described as 'The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)'

That was a very useful document for me when I had to deal with UTF-16 to UTF-8 stuff at work.

21

Feature requests / Roadmap: copying

« on: June 09, 2008, 05:58:18 pm »

The more useful part of vertex shaders in SFML would be to have them available for us peeps that use full OGL. It would be pretty useful to have a nicer interface for loading shaders for use in OGL, and it would be interesting to see what people come up with as uses for 2d vertex shaders as well

22

Feature requests / Support UTF-8 in String? (->GNU/gettext)

« on: June 09, 2008, 05:55:55 pm »

UTF-16 is UCS2 with support for surrogate pairs (which are 32 bits wide) in order to extend the unicode support of the encoding from the BMP(basic multilingual plane) to the entire unicode set of code points.

23

General / [SOLVED] Visual Studio 2008 Professional Problem

« on: May 27, 2008, 03:41:41 pm »

Yup I try not to post problems until I've been stuck on them for about a day nowadays... and I still end up solving them about a minute after posting

I think it's something to do with the thought process required to articulate the problem. You go through it, then you suddenly realise which step you haven't tried yet and that solves it

24

Graphics / Drawing Everything

« on: May 21, 2008, 11:05:28 pm »

It only works if you have arranged your images into a regular 'grid' with a specific width and height for each. Then you can use integer division on the mouse position to get a 'cell' in the grid and find which image you are over.

If you have an irregular grid or no grid at all, what you probably want instead is (using boost FOREACH as it's easy):

Code: [Select]


BOOST_FOREACH(Sprite s, vSprites)
{
   if ((MouseX > s.GetLeft() && MouseX < s.(GetLeft()+s.GetWidth())) && (MouseY < s.GetTop() && MouseY > (s.GetTop()-s.GetHeight()))
   {
      //Mouse position is over this sprite, do something about it here
   }
}

As usual, this is written straight into the browser so please forgive me for any syntax errors or minor issues

25

Graphics / [Solved] Opacity for Sprites?!

« on: May 21, 2008, 10:58:39 pm »

It would be very simple to change the function into one that could take an image and alter all the alpha values to a specific value as well Or (possibly better) to subtract an amount from the alpha values to make it more transparent (or less) as then it will preserve the existing transparency

And yeah... functional requirements (such as requiring jpeg support) are always annoying. There are some great ones on my project at work that just seem to be there to make things awkward (such as allowing the user to regenerate encryption keys... across a mobile network... that could fail at any point... with no transaction support. So many defects with that, mostly to do with the user selecting it when they have no signal and destroying their devices encryption keys :/).

26

Audio / Stop() method

« on: May 21, 2008, 11:38:42 am »

or try the latest svn

27

Graphics / [Solved] Opacity for Sprites?!

« on: May 21, 2008, 11:28:21 am »

I'd suggest using png format for images personally as then you get lossless compression (no jpeg artifacts or anything distorting your image) and an alpha channel but if you don't want to (using jpg, bmp or another format without built in alpha support) then you could always use the function I suggested here and use a separate image as a greyscale alpha channel (you may need to adjust how the colour channel values are blended together

28

Window / [Solved] Control Game Speed without Framelimiter

« on: May 19, 2008, 05:19:57 pm »

and pos should be changed to using floats, as otherwise your motion will only change when your velocity happens to be more than 1 unit in the elapsed time. Let SFML worry about turning your position into integer amounts (or more precisely, OGL which can use some anti-aliasing to give sub-pixel precision to your drawing with fancy fading effects

29

Graphics / Drawing Everything

« on: May 18, 2008, 07:04:18 pm »

With a vector, I think indicies may be slightly faster, but are less flexible (you can only use them with vectors, deques and pointer-arrays) whereas iterator semantics can keep the same codewith any container, as long as you only use forward-iterator features (this is all you need to step sequentially through every element in a container, so pretty much all you need). The better method is to use structures that remove the need to worry about iterators in any way, shape or form though, such as with boost FOR_EACH, or writing a map-algorithm that can take a function (or functor) that will apply a function to each entry in a container. C++ 0x should contain much easier ways of doing this as well (such as an improved for_each construct and lambda functions ) but that is still in the future. Performance wise though, indicies will be pretty much the same or worse than iterators when using anything other than a vector (and even then, iterators will be so close to index access that it makes no real difference. After all, a vector iterator is a really easy construct

30

Feature requests / Not clearing the contents of a RenderWindow after Display

« on: May 18, 2008, 12:03:18 am »

The code required to check which pixels have changed is more inefficient than brute force pixel pushing with todays hardware, yes. Especially when doing such an 'optimisation' will frequently require you to do things like get the rendered image from the hardware which is hugely inefficient in todays rendering pipelines as copying data to and from the graphics hardware is frequently a bottleneck. If a software renderer is introduced into the SFML library, then I'd expect issues like this to start appearing (or for laurent to implement it in such a way that redrawing things that haven't changed become a no-op if possible