Nursery of naughtiness 

My favourites come from translating something from English to Japanese, then copy the results back in and translate it back into English.  For example:

"Learn from yesterday, live for today, hope for tomorrow."

becomes:

"Learn from yesterday, today and hope to live for tomorrow." 

Unless I'm actively doing something I'll almost always have a magazine in my hands so I can roll and crinkle the pages.  I like the feeling and sound it makes, especailly if you roll a bunch of about 10 pages at once, kind of like making waves along the pages with your fingers and thumb.  It guess is kind of relaxes me.  At my home (and at work when I was working in a studio) I have a fairly large collection of these magazines spread around just for this purpose so I always have one to hand whether I'm gaming or coding or just watching telly or anything along those lines.  Its a habit I picked up a long time ago and I've been doing it so long now I actualy get a bit stressed if there's not a suitable magazine around when I get the urge.

It's quite specific as well.  Its got to be higher quality glossy paper like you get in the more expensive magazines, not the cheap throw away ones you get in the news paper.  Also a magazine is only good for so long, once I've played with one too long and the pages have become too crinkles and mucky I need to swap mags.  Fresh sealed mags are the best since I also love the smell of whatever they use in the manufacturing/printing process.

On a similar note I cant touch news papers or phone books or anything like that.  I really hate the feel of that kind of low quality rough dry paper, it makes me feel really uncomfortable.

An elipse can be thought as a circle which has a different scale factor in each of its x and y axes.  Therefore you could use any method you've gotten to work for a circle but scale the x and y components by different amounts to create an elipse.

Watched 8 episodes of Disney's Gummi Bears cartoon from the 80's in a row .... and still going.

Cheers for the feedback folks. 

The Sony SIMD maths library is interesting, I've used it before or at least something very similar since I used to work for Sony in the past, I didn't realise it was open source.  The only problem I have with it though is that I'm really not a fan of the distinction between vectors and points.  It's a sensible distinction to make when it comes to rendering and geometry maths but I've found it gets in the way when doing more abstract or game logic type mathematics.  Its probably a bit much for my small needs right now too.

The GLM library looks interesting too, I've dabbled with GLSL in the past but I'm not sure its exactly what I'm looking for, it's clearly very rendering orientated.

Hmm I think for the time being I'll see how I get along with clm.  It kind of supprises me that there isn't an abundance of stand alone math libs considering its a pretty important thing to have, but then I guess most platform/game sdk's come with their own built-in ones.

PS: @ _Tommo_:  The difference between AoS and SoA is pretty simple.  Imagine you had an array of 4 vectors with x,y,z, and w components, ie:

Vector4 myArray[4];

In AoS which is what you are probably already used to, the vector elements in the array would end up arranged in memory as 'xyzwxyzwxyzwxyzw'.  Using SoA however this would end up as 'xxxxyyyyzzzzwwww'.  The reason this is useful is that SIMD can perform an operation on four floats in the same register simultaneously for the same price as if you did the same operation on just one float (providing that the operation you perform is the same for all 4 floats).  Therefore if you use SoA, then all your x values for 4 vectors are packed into one simd register, all the y values in another, and so on.  Therefore you can now do vector arithmetic 4 times faster as long as you wish to perform the same operations on each vector.

Heya folks, I'm looking for a good fast stable math library to slot into my c++ game engine.  Necessary features are:

• must be written in c++
• must have no dependancies on or require the inclusion of any platform specific libraries or sdk's
• must include vector and matrix methods

Optional features I'd like include:

• a mixture of fixed vector and matrix sizes and/or dynamic sizes
• quaternion mathematics and quaternion matrix conversion
• spline mathematics
• standard operations implemented with operator overloading rather than function calls for ease of use and readability of coded equations
• source code available
• free license for commercial uses but I'd be willing to pay for something very good
• configurable between column and row dominant matrix modes

Currently I'm considering cml (Configurable Math Library), does anyone have any experience with that one and would you recommend it?  Alternatively does anyone have any other suggestions which fit the above?

Cheers folks  

Although I dont wish to get into an epeen waving contest, I have to disagree with your advice that pointer storage is more effective in this scenario, particularly if your arrays contain a large number of objects.  The number of objects you'll have to iterate through every frame (potentialy several times every frame) will pretty much always far outweigh the number of object additions and removals per frame you need to make.  This should make object iteration and processing your primary concern when considering performance.  On modern hardware, given that the speed with which memory can be accessed hasn't progressed as quickly as cpu speeds which are now far faster in comparison, special consideration should really be given to ensure you prevent thrashing the cache in these kind of tight loops since cache load stores will quickly add up to become a very significant percentage of your overall processing time spent in the loop.

Although I see where you're coming from with additions and removals which could be very costly if implemented badly, this cost is easily avoided with a bit of forethought.  For a start as I discussed previously, you should pre-allocate all your elements during initialisation so you are not growing the vector at crucial periods of your game.  Removing an element can be as simple as marking it dead which means it will be skipped over during iteration, there is no need to physicaly remove it.  This makes element removal as simple as changing an alive flag from true to false.  If you keep track of your dead elements, then when you wish to add a new element you then simply need to change this flag back to true for one of your tracked elements and re-initialise that element with your new parameters.

This does have an issue that if your number of elements can vary by a large amount during your game, then during periods with low numbers of elements following a period with a high number of elements, your array will contain lots of spread out dead elements.  This could be thought of as fragmentation.  I dont really think of this as an issue though since you should really only be concerned with your worst case performance, ie: when you have the most elements.  As long as your worst case performance is optimal then does it matter if your good case performance isn't as optimal as it could be?  After all your good case performance will be lower than worst case anyway and so will fit in frame as long as your worst case does.

As an aside, if your objects are small and it is not important to maintain element order and you're not tracking elements externaly, the you could even optionaly copy the last element over the 'removed' element and pop_back() if you really dont like the idea of having dead elements in your array.

Also about using function calls versus direct implementation.  Again I see where you're coming from but I just wanted to add that if you're function implementations are small then I'd rather leave them as functions for code clarity and ease of refactoring and reuse.  Small functions can be inlined which eliminates the function call overhead, and in fact many compilers will automaticaly do this for you anyway when appropriate.

To add my two pennies worth to some of the comments being thrown around lately:

If you wish to use an array, there's really not much in it whether you use a fixed C style array or an stl vector.  For an stl vector you can get the same behaviour as a fixed array by simply pre-allocating the memory and/or objects by using vector::reserve() or vector::resize() during your initialisation.  Going with a stl vector however will give you a little more safety since it does internal bounds checking if using the correct element accessors, and also a little more built in flexibility and functionality.

If using an stl vector try to pre-allocate enough memory from the beginning as discussed above since this will prevent costly memory allocations and array copying during critical periods of your game.  Also avoid the use of vector::erase() if this is something you'll need often like in a bullet manager.  The reason being that using erase will cause the remainder of the array after the erased elements to be copied over to fill the gap left over so that all elements are adjacent to each other.  This can cause issues since this memory copying can be slow for large arrays and also it will cause the index into the array of elements after the erased elements to change which could be an issue if you are tracking bullets by index.  Therefore if using an array you will need to implement a method to track dead elements in the array and assign these elements back out when a new element is requested.

The real benefit of using an array in this situation (whether that's fixed or stl vector) is that all the elements contained in that array are stored adjacent in memory which leads to fast cache friendly iteration through the array when processing those elements.  To get this benefit you have to store your actual objects in the array, for example using std::vector<Bullet>.  If you store pointers to your objects in your array instead and assign your objects individualy (using std::vector<Bullet*>), then you stop taking advantage of this benefit since you force memory jumps when dereferencing those pointers which will result in cache misses.  If speed isn't an issue and you wish to go with pointers to gain the benefits of polymorphism or whatever then there's no real benefit to using an array over a list other than saving yourself a little per element memory overhead (a list must store an element header per element).  In this case you might as well use an stl list since it then solves a lot of your other issues such as fast and easy insertion and removal of elements.

Disclaimer:  There are of course many ways to go about solving different problems and often the best solution is very dependant upon the exact nature of what you are implementing and the hardware its intended to run on.  Therefore the above suggestions are only my opinion based upon my past experience and my understanding of what you wish to acheive.  At the end of the day use whatever you feel is most appropriate for you and your exact situation.  And of course, if you're not concerned with getting maximum performance or flexibility but just want something easy to understand and implement to get your game finished then just stick with whatever makes sense to you and only consider changing it if it starts to cause problems.

The main issue with my 'simple' code, is when you get relationships between objects. Enemy dies, all his bullets need to be killed. In my game it's almost no problem, 'bullets' just keep going there. But I had this water snake, made out of different segments, and that's becoming a real hell to manage.

Take a look at my post just above, that might help if you weren't already aware of these methods (which I guess you probably are  )

I suppose then Daid's method would work for bullets as well as the tilemap. Would I be correct in assuming that the idea here would be to have a super array of object types that has members like tilemap, bullets, players, mobs, etc that each have a .draw() that I can iterate through to populate my display? Is that the idea we're seem to be getting at here?

Unless I've mis-understood, what Daid is essentialy proposing here is a scene graph, in this case a flat one.  Scene graphs are a common feature of game engines and have proven themeselves time and again, so for your general entity management I'd say this is a good way to go.  Given that this is a common pattern in game design there's also plenty of good resources available out there on the internet to help you out which is a bonus.  For a start I'd recommend having a look at the wikipedia scene graph entry to get yourself familiar with what they are and what they can do and then search for more specific things from there if there's anything you want to find out more about.

If you decide to go down this route then there's two things I think you should consider before you start coding it all up.  Firstly decide on whether you can get away with a flat scene graph such as in Daid's suggestion or whether a tree like scene graph would be more appropriate.  Generaly speaking, if you dont intend to have many entites which have dependancies on each other (parent-child like relationships), and also if you wont need to often search through your scene graph or you only intend to have a small number of objects in it anyway so searching isn't an issue, then a flat scene graph should be fine.  Otherwise you might want to consider building a tree like scene graph for the speed increase and/or the built in method of easily defining object relationships, for example where child objects should move relative to their parents such as a spaceship with orbiting satelites.

Secondly consider what should and shouldn't be its own node in this scene graph.  The scene graph is really just an orginisational structure you use for convinience to ease development and keep things structured.  Its great for managing a large variety of different object types which all have common needs such as updating, drawing, moving, etc.  In the case where you have a large quantity of the same small object type however such as particles or bullets then you might not want to burden your scene graph with treating each instance of these objects as its own node in the graph.  In this case using some kind of particle/bullet manager like has been discussed is the better option since it allows you to optimise for that specific case.  There's no reason that your bullet manager cant exist as a node in your scene graph however or that you must only have one such manager.  For example in some shmups, certain enemies can spawn a large number of bullets, but killing the enemy that spawned the bullets also destroys the bullets it spawned.  In this case you could take advantage of both worlds by having a bullet manager instance as a node in your scene graph which is a child of the enemy ship's node, therefore when the ship is destroyed it also destroys its children, in this case the bullet manager which would take care of cleaning up the bullets it owns.

Anyway I hope you manage to extract something useful out of that  .  If you intend to go down the 'super array' route of managing your game objects then I'd definately recommend doing some research into scene graphs first.

Nice work, this engine looks pretty sweet.  I used to do a lot of work with physics engines myself, its interesting stuff.  Your performance tests look pretty solid but if I was to make any changes myself I'd probably mix up the shapes and sizes of the objects to try and simulate a more natural environment. 

Also you might want to include the option for each test to periodically remove a random bunch of objects and then insert a fresh batch of objects at random locations to test how well your engine copes with insertions and removals and whether this causes any significant performance spikes.  You could ramp up the number of removals and insertions over time to measure when it starts to become an issue.

You might also want to consider creating stability tests as well as performance tests.  Common stability tests include:

-> How high can you stack boxes on top of one another before they begin to show significant jitter and cause the stack to collapse.  Variations include the tower stack and pyramid stack.

-> Place a small low density cube on a flat plain and drop a large high density cube on top of it to create a 'sandwich' collision.  How massive can you make the dropping cube and how high can you drop it from before the collision starts to cause issues.

-> Create a low density long and thin cube and drop it into an environment.  How long, thin, and lightweight can you make it before the instabilities prevent it from settling.

I'm sure there's more but off the top of my head that's all I can think of right now  .

PS:  The high resolution timer on windows can be accessed with 'QueryPerformanceCounter'.  Have a look here -> http://msdn.microsoft.com/en-us/library/aa964692%28v=vs.80%29.aspx

I wouldn't use an stl set for something like this if you intend to have many simultaneous bullets, you've got no need for keys and a set is massively inefficient and wasteful for that kind of thing.  If you're looking to manage a large amount of bullets, for example for a shmup or run-and-gun game, then you might want to check out this tutorial at my website -> Basic Bullet Managment Tutorial.  If you're requirements are pretty small however then go ahead and use whatever you find easiest since it's not likely to cause any bottlenecks anyway.

PS:  When it comes to stl containers and deciding on the most appropriate one to use, you might find the following diagram helpful:

Just Visual Assist here.  I've used it for over 6 years now and cant imagine coding without it.

Personaly I use Perforce, its pretty solid and comes with a lot of nice features and is free as long as you dont need more than two users or five workspaces.  I'm suprised no-one has mentioned it yet, its the nicest source control I've ever worked with.

Throwin' some shapes in the church of dance, ooh yeh

You might be an indie programmer if you can go days with no pants on whilst still being productive (.... or a porn-star)

PS: Hey guys

Hiya guys and girls.  I've been a lurker here for quite a while now and figured its about time I joined  .  My name is Daniel Stoneley currently hailing from Liverpool UK.  I've always had a deep interest and love of games from childhood, being brought up in Southport (a seaside resort) I spent much of my yoof hanging around in the once great games arcades which existed there (sadly now all replaced with slot machine parlours  ).  I've been around pretty much from the beginning and experienced a bit of everything from the Acorn BBC micro B and Amiga etc through the gameboys, snes, dreamcast et al, all the way up to the current generation.

After graduating from uni (master of astrophysics ) I decided I wanted to pursue a career in the games industry and so re-trained myself and learnt to program.  A year later I landed my first proffesional game developer job working for Acclaim Studios and have since been a pro game developer for the past 8 years and in that time I've also worked for Psygnosis and Bizarre Creations.  Given that Bizzare have just closed however and also taking into account the current unstable nature of the games industry in the UK, I've decided its now time for me to strike out on my own as an independent developer.  Interesting times ahoy c'ptain  .  I've only just started down this route so I've nothing much to report yet, but if you're interested in following my progress I intend to blog about it on my new development site, Forbidden Function.

When it comes to games I'm a massive fan of arcade style gameplay, likely due to my early exposure to and immerssion in the arcades as a younger gamer.  Therefore stuff like Metal Slug, Street Fighter, Guilty Gear etc are what float my boat.  What really gets me horny though are shmups, aka shoot-em-ups.  Stuff like Gradius, R-Type and Ikaruga, and in particular I'm a massive fan of almost anything by Cave such as DoDonPachi and Mushihimesama.  I've got a pretty extensive collection of all things shmup and aspire to owning my own candy cab loaded with cave pcb's someday  .

Speaking of shmups, that is likely where some of you may already know me from (I certainly recognise a few names around here) since for the last few years I've also been the owner of ShmupDev, a game developer community focused around the creation of shoot-em-ups.  We've run various compos and stuff in the past, many of the entries for which have been featured on the font pages here at some point or another, so even if you're not familiar with the site you probably already know of some of the creations it has helped spawn.

Anyway, I look forward to taking part and becoming a member of the community.  Cheers folks