Also when the premature optimisation misquote is trotted out for the umpteenth time

Sounds like a mismatched calling convention between the precompiled SFML DLLs and your compiler settings. If you search for "SFML calling convention" there are a few threads on this, but all the advice boils down to "recompile SFML"

e.g. http://en.sfml-dev.org/forums/index.php?topic=8320.0

What compiler are you using, and what was used to compile SFML?

Will

Heheheh. Performance, but at a cost

I haven't read the log, I imagine it's not intended for public release, but:

In the general case, it's common for console games to be developed in parallel with an in-house PC build, since it can be easier to get the PC build up and running, there are often tasks like content creation which work better in a PC environment, and console devkits are usually in shorter supply than PCs.

That doesn't mean that the PC build is in any way a complete game fit for release. Think of it as an internal development tool or a level editor rather than a game. Don't infer anything about a PC release from the existence of a PC build.

You appear to be applying gravity based on the position of the sheep relative to the origin:

Code:

    p = Vec2d(body.position)
    sqdist = p.get_length_sqrd()
    g = (p * -gravity)/(sqdist * math.sqrt(sqdist))

i.e. your gravity vector is in the direction of -p, so the sheep all go towards p = xero. Which looks in your video to be the lower-left corner of the screen.

Try working out the mean position of the sheep (add up all the positions and divide by #sheep) and subtract that from p:

Code:

    p = Vec2d(body.position) - mean_position

with the rest the same. Obviously you'll need to do this every frame so the sheep move towards the centre of the flock.

However, I suspect you'll get instability - if you're using a physics engine this kind of thing really ought to be implemented using constraints. If you find everything bounces all over try turning down your very high gravitational constant to stabilise things.

I'd also go and read about Boids which attempts to produce exactly the kind of behaviour you want:

http://en.wikipedia.org/wiki/Boids

In particular the bit about alignment, so your sheep head in the same direction as well as cluster together.

HTH,

Will

I'd assume some of the macros you're calling might use them, but you don't seem to be passing them anything that would identify the label to jump to.

Extreme pedant mode: CPP macro syntax looks like function call syntax, but you don't really call a macro, it's just a text substitution.

W

The neat thing about Dishonoured is that the stealth/peaceful route can feel very aggressive.

I found it quite boring and annoying at the start because I was playing it like any other stealth game - waiting, watching and creeping up behind people. But the various powers (particularly blink and slow time) allow you to move very very quickly and e.g. knock out a guard and hide the body right under the nose another.

It turned out to be quite a unique play style, whereas the opening prison level made me think the stealth was going to be no fun at all.

You're right that it does mean you miss out on playing with some of the fun toys though...

Wlll

I changed a fixed-length T[N] into a variable size Buffer<T> in one of my gameplay components, and without changing anything else (*) I was to run the game, have it rebuild the assets, and it worked.

Will

(*) except that the change uncovered a couple of arcane bugs in the asset builder which took a while to fix, but still!

Productive AND bubbly! Epic win!

If you do get time to do a clean version, I'd be interested to see it.

I find that most of the messy stuff in mine is on the gameplay side - my pilot needs to set forces on the physics body, for example, and some game logic needs to manipulate sprites. But the engine-provided components are completely isolated from each other. As things solidify I've tended to move these interactions to messages.

I suspect if I added scripting into the mix then most of the that mess would hide inside it and it wouldn't distress me so much My progress on all of this is glacial, but I don't get to write gameplay code at work anymore so it's nice to have somewhere to try things out.

If you allocate the components in a pool by system you can save more and still get the flexibility, especially from tight loops working over each component pool (data cache friendly and instruction cache friendly).

Yep, that's how I have things set up already.

You can actually cast off the idea of "an entity" completely and just organise pointers to the components however you like.

At the moment all my entity construction is data-driven so I don't have any specific types. I like how straightforward that approach is though.

I dealt with the constant-time access thing a bit differently in mine - since all the work is in components (well, in their systems) it's actually the components that need to refer to each other. So if a component has a member which is a SomeOtherComponent* then the runtime wires that up to a suitable target when the entity containing both is created.

This still feels like a bit of a crutch - I have messaging as well but I haven't embraced it for everything yet.

Will

I figured some people would be saying that,

You could have smooth gradient backgrounds on the Amiga, I believe by using the copper to change the palette entry on the horizontal retrace. So it makes perfect stylistic sense to me, and I think you're right, it does help fit into a non-pixelled environment.

Will

This still certainly doesn't let you have >1 of the same type of component, and wastes memory on pointers to nothing for every entity - I guess you've got a static size for g_entities,

If you allocate the entities from a pool then the fixed size can save you quite a bit in allocation overhead, alignment slop etc.

I do something similar but don't label the slots, so there's no problem having multiple sprites or whatever - like you say, that's really powerful. Labelling the slots is great for constant-time access to components though, but if you don't do much e.get_component(type) then that won't really benefit you.

Thinking about it I could get the best of both worlds (fixed size, no overhead) by having just a head pointer in the entity, and threading a linked list through the components themselves. Hmmm....

Will

I found that in the end I quite liked some of the def objects - I was able to embed them in my resource data and use that to quickly create the live physics objects at runtime. It would be better with more of a separation between def and state though.

Will

I'm not an AS3 person so I don't know what the implications are for unintialised variables, but it looks like you have a case where t can be uninitialised when you're computing the entry and exit points.

In your small D branch (close to edge?) you continue the loop skipping the calculation of t if N is positive. You could have this happen on all iterations, in which case you wind up exiting the loop and using the undefined value of t.

Not sure if that *is* happening in your case, but worth checking.

If AS3 initialises everything, this is a non-issue. Likewise if the maths mean this situation never comes up for all points it's a non-issue, but maybe it'll offer a clue.

W

There's a Western game in that series (Desperados?) which is really good as well.

Porting my stuff to Android. The engine lib compiles, but things are missing. Still, it's progress

Also, by design you should not be printing stuff from the background threads.

I dunno, I found the two most useful tools for debugging SMP/AMP/MT issues were:

1) Being able to log (whole lines!) from any core/thread, with the core/thread ID prepended to the log message.

2) Being able to quickly switch any async code to run synchronously instead.

A lot of multithread/multicore problems are hard to debug (either because they're really wide, or because they're timing dependent) so it's easy to capture some good log spew and pore over it to spot the issues. Plus being able to run code synchronously without recompiling makes it easy to spot if an issue is caused by the asynchronicity or not.

YMMV, naturally

Will

So how do you decide when to interrupt the main thread? Does the thread manager thing get ticked, and save up all the main thread lambdas to call then?

W

Making this even more obnoxious is that the YouTube API only works locally in Firefox, so to test my page in Chrome or IE, I have to upload it to a webserver first. I've been trying to solve this one issue for days.

For testing this kind of thing, you should absolutely install a webserver on your PC and run it on e.g. 8080. No uploads, proper testing.

Use LAMP/WAMP and it's very easy: http://www.wampserver.com/en/