Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Jun 2006
Offline Last Active Today, 04:45 AM

#4813856 Threading an event and actor system

Posted by Katie on 21 May 2011 - 08:16 AM

"Unless your goal is to learn."

But you're also talking about writing a game engine AND a game.

You should pick one thing to learn, and you should pick it carefully. You will finish at most one of the things you will choose to learn -- usually the one closest to the thing you decide to learn.

If you decide to spend your time playing with a threading system, your threading library is what you're most likely to ship -- you'll never get to the rest of your "engine" or the games.

Most IT projects, big or small, which fail fail because they decided to try and do more than one thing. They decide to not only solve a business problem but ALSO to learn a dev system or use a new design process or port something to new hardware.

If you want to ship a threading library, faff about with threading fundamentals. If you want to ship games engines, write games engines.

If you want to ship games, write games.

#4810366 VBO Concept Question

Posted by Katie on 13 May 2011 - 12:43 PM

VBO is just a block of memory which lives on the graphics card.

The point is that the card can read the vertex data when you ask it instead of having to send it every time.

There are multiple ways to use the VBO data.

The simple way is that you can just put the billboarded vertex data into the VBO and draw it. The draw will complete faster because it will no longer block on the CPU feeding vertices to the card.

Next up is putting the real world particle coord into the VBO along with a corner number and other data for each particle x each corner. The shader turns those into a billboard centred on the coord.

Next up is using instancing and reading the vertex data out using the shader texture read calls (using the instance number) so you only have one copy of each particle's data.

#4809886 The importance of hardware knowledge?

Posted by Katie on 12 May 2011 - 12:28 PM

"EDIT: For example, how did Braben make his Raspberry Pi?"

Well, for one thing he ambled down the road and had a chat with ARM... who're supplying the CPUs.

#4809722 Faster than Switch

Posted by Katie on 12 May 2011 - 03:43 AM

You are optimising the wrong thing.

The switch, and its evaluation, will form a tiny section of the cost of doing your updates.

It will be far outweighed by the cost of not doing all the updates of a certain type together.


Because however you decide to go to a different lump of code, if you keep going to different lumps each time, then you will keep causing cache misses. Those first instruction fetches which miss the cache will cause blocked CPU time far exceeding the cost of your determination code.

If you then update the elements randomly, you will cause data cache misses. If you want this to be optimal, you need to keep the objects clustered together by type and then run over them doing the work.

Conveniently, clustering the objects like this is also probably the way you want to be rendering them in order to minimise state changes.

In order to run on multiple cores, a sensible optimisation is then to run each type of update on a core. If a core finishes early it can grab another update type to do. If you do this make sure that the memory containing the different types are separated by at least the size of a typical cache-line. This will prevent cache line grabs fighting each other at the overlap.

If you order the updates by world segment and by pending time, you can make sure that nearby updates happen regularly but more distant systems are only updated if there's time. If you fail to update a segment/type grouping, tick up a counter which will make it more likely to be done in the future. Again, while some cores are doing distant updates, you can be drawing nearby non-translucent objects on your graphics context core (if you run out of drawing bandwidth, skipping more distant segments is better than closer ones). Translucent objects require more complex handling. An easy solution is to "defer" their rendering task, keep track of how large those accumulated deferments are and if it approaches your remaining frame budget, switch to drawing them in reverse order. Note that these should already be in segment order, and hence just need sorting within it to be correct,

Once you've done all that, you might need to start looking at the switch statements.

#4809703 Computer science or game programming?

Posted by Katie on 12 May 2011 - 02:15 AM

"Personally I've seen people with a formal education in CS sit in front of a videogame project and understand close to nothing and seen people with barely a highschool diploma pick things up quickly and naturally,"

Those people are exceptions.

In the general case, people with CompSci or related degrees make better software engs. Hence, since they are recruiting for the general case, companies apply filters to the floods of incoming CVs. And the first is "a relevant degree".

I've been at companies where they don't do this. At one, we used to advertise in the local paper. All the engineers got put on rota answering the calls. The phone rang night-and-day with people who thought they might be good at computers and wanted a job as an SoftEng. It's a great job; it's indoor work, pays well and doesn't involve touching blood, wee or other people. It appears to have no difficult entry level -- it's just typing, after all, right? Brrr.

I've worked for a bank which hired people off the streets as well. Hired random people, handed them "learn C++ in 21 days" and test them 21 days later. If they pass a basic C++ test, congratulations, you're a "grade 1 programmer". Fail the test and congratulations, you're an "assistant project manager". Fear the quality of THAT software.

I've worked for a place which did financially critical systems using custom hardware. Oooh, and made a point of hiring non-compscis for at least 50% of the engineering staff. Wow. That was scary. When you're in a 'meeting' about some lump of code and more than half the people present answer questions about things like "possible race hazards" with things like "don't both me with that university wordy crap, this'll work"[1]...

Having done this a lot, worked in a lot of places, banged my head against a LOT of brick walls generally I'd say that the companies which don't apply those filters are insane. And lo, it turns out that sane companies do do this filtering. All sane companies do that filtering[2]. Remember, they don't need to find the 1 exceptional person. They just need to find one person who can do the job. Yeah, they'll never interview Leonardo Da Vinci. But then Leonardo won't ever get a job either. Oh, and bluntly speak, chances are that the exceptional people have degrees as well. Because... well... them degrees is easy if you is actually smart.

So go get a degree. Everyone's special, I know you all are too. You're all too smart to need one. But just go get one because it doesn't half make applying for jobs easier.

[1] It didn't. When it turn out to be fraudable we paid a couple of million in compensation. Never mind eh? Better luck next time.

[2] Not all companies which filter on "relevant degree" are sane tho.

#4809366 The importance of hardware knowledge?

Posted by Katie on 11 May 2011 - 05:44 AM

You'll have much bigger problems to worry about. Without electricity, you don't have petrol or diesel or oil. You won't be pumping any more any time soon. The stuff to hand will be gone either when it's used up or in 6-12 months as it degrades.

You no longer have refrigeration. You will be needing to preserve food. Where is your nearest supply of salt? That you can get to without power or fuel. And KEEP accessing -- you're going to need salt, a lot of it, for the rest of your life. You will almost certainly want to use the last of your petrol moving you and anything you need to a location which has woodland (fuel and material), fertile soil (crops), fresh water and a coastline (salt and food).

Even then, how will you plough fields without fuel? Certainly no-one's bred carthorses in large numbers for a while now, and the riding horses you see about aren't up to the workload. Do you know how much land you need to plough to get a decent crop? Do you know how to thresh wheat by hand assuming you grow some?[1]

You spend your time faffing about trying to build computers and you will starve very quickly.

[1] Medieval historians are going to be fairly useful in this new world...

#4808590 Double-buffered VBO vs updating parts of a VBO

Posted by Katie on 09 May 2011 - 10:20 AM

"just loop through your models setting up matrices"

Or pass the matricies in through vertex attributes to save modifying uniforms which is more expensive.

#4808227 MMO Worldbuilding

Posted by Katie on 08 May 2011 - 02:06 PM

"It really ins't hard to go on Steam, and sell 300k copies of your game."

Have you actually sold that many games?

#4807847 Registered subsystems

Posted by Katie on 07 May 2011 - 05:03 PM

This sounds like you're about to re-implement COM.

Why do you want to do this?

Is it because you don't want tons of pointers in the global namespace? If you know all the subsystems, just have a "Game" container which contains a bunch of pointers to the subsystems and you make that global. {It's OK to have SOME global variables.}

Is it because you don't know (at compile time) which subsystems may exist in the system? {Perhaps because you're going to load them from DLLs?} In which case, you probably want to give each DLL an entrypoint to start it up, and that entrypoint could return you a pointer to something describing the subsystem. Try and use an interface class rather than a void* pointer for things like this -- it adds flexibility in the future so you can return extra data if you need to.

How will you access the methods in the subsystems if you don't know their interface at compile time?

#4806585 How to convert gl_FragDepth to real world depth ?

Posted by Katie on 04 May 2011 - 03:20 PM

Would this not be easier by using gl_FragCoor?

The .z of that contains the window normal z, so you just need to add the near plane distance to it.

#4797143 Improving particle system

Posted by Katie on 11 April 2011 - 09:12 AM

You may be able to get away with sorting more distant particles less often, concentrate on the nearby ones.

If your set is already almost ordered, generic sorts often don't perform well -- consider the bubble sort. (No, really. It performs well on nearly ordered sets. Also; you can halt it at any point in the sort. This makes it easy to allocate a "sorting budget" and stop when it's spent).

Set things up so you sort your indicies and not the actual vertex data -- the index sets will be much smaller.

Have two buffers -- one can be being sorted on the CPU while the GPU is drawing one of them.

Rather than culling particles during your physics session (meaning you need to dynamically shuffle the previous frame's sorted data), arrange your sort to pull them to the front of your queue. You just start drawing later into that list. New additions can use that space before you need to start extending the array.

#4797137 Improving particle system

Posted by Katie on 11 April 2011 - 09:00 AM

Another option is to check whether you care if your particles are sorted; if your particles are "hard edged" like (say) snowflakes, you might be able to get away with a scissor test and thus avoiding painting translucent pixels. And thus avoid needing to sort.

If you can turn your particles into either additive or subtractive colours (flames can be the former, dark smoke is the latter) then again you can get away without sorting.

If your particles don't move very far in any given frame, consider not sorting them all each time -- you could sort 1/10th of the array each time and still be sorting each particle more than once a second.

#4785028 Pathfinding in a space-based RTS game

Posted by Katie on 12 March 2011 - 05:32 PM

Once you've plotted your ideal route, put tags along the route into the oct/quad tree that you're using for things like culling. The tags know when the unit is expecting to be at that point.

Each of the tags "watches" bits of the routes. As you create objects and move them around inside the space, they can notify routes that they're blocking and unblocking them. The ship owning the route can decide if it's something it needs to think about now, or later. If the obstruction goes away later, then the ship need never have done anything.

The same thing can be used later on for sensor systems watching for intruders and so on.

When you plot a route, you can check for potential collisions a long way off; displacing your route if you find something else there, kicking them out if you think you should have priority.

Planetary orbits are collections of tags into the tree which know about the orbital period.

If something intervenes in the route and it's quite close, that's the trigger for doing a local replanning.

Solving the "who moves" is easy. Serial number every unit. Small units give way to large units. In case of a tie in sizes, highest serial number wins.

#4769424 Compiling GLIBC on Linux. Oh golly gosh!

Posted by Katie on 04 February 2011 - 02:59 AM

"I really don't want to have to set up a whole new installation with an old version of GLIBC just to recompile it again"

That's not how you do this. You do this with what is called a "chroot".

A chroot (pronounced "chuh-root") is a unix environment INSIDE another unix environment. It's not virtualisation or emulation, it's much more lightweight than that. You simply build a file tree containing a build environment -- typically it will be just the basic minimum packages to do the build, and including *specific* versions of libraries to link against. You then copy your source (or partially built system) into it, and perform the final link.

Here's a document which talks about setting up a chroot;


It's actually about how to build blender, but it's got the general stuff in it. Basically chroot starts a new shell and will execute commands, but after setting an environment where / is actually somewhere else. The shell (and its children processes) aren't allowed to peek outside their particular part of the file system.

So you set up a new directory somewhere, and it'll have its OWN /etc, /bin and so on. Of course, it's not a full operating system, so you don't actually get an /etc/passwd in there. What you do then is copy packages somewhere in that tree and then have chroot execute a shell script which installs them. It'll install them into its /bin directory. Then you chroot a script which does your build inside it, then you copy out the completed build.

Building the chroot for the first time can be a little expensive, but you can keep it lying around for when you need it. Many software development teams check the completed chroots themselves into their revision management systems, or keep pristine copies of them on fileservers so they can be just cloned onto build servers when needed. Another reason for doing this is that it makes your build independent of your development environment. You don't need to worry about installing games or whatever on your machine, because even if they upgrade (say) your opengl libraries, you KNOW the version in the chroot is the one you actually want to build against. You don't have to stop doing local builds either -- you can still do that which means all the symbols and source are easy to get at and so on.

Also, you can then (reasonably trivially) build cross-distribution software. For example, I routinely build red-hat RPMs for various version of redhat on my Ubuntu desktop. Why? Well the chroots are fresh -- so I can install anything I want in them, it doesn't have to be the distro on my desktop. So I've got a RedHat 5.6 chroot, and a RedHat 6.0 chroot and also a Suse Enterprise chroot and I can build things in there that will run on those different distros.

There are two things you'll encounter. One is you'll need to find a sufficiently low version of glibc in order to install it in the chroot. Good news is you often get away with just nicking the file itself from somewhere and overlaying that onto a package install.

The next thing is what'll probably get you. The reason that your program is demanding those symbols to dynamically link at runtime is that they're part of a feature in glibc that you're using in your app which only appears in later versions of the library. That's why they're there. It's not Linux being crazy, it's a safety precaution to stop you running apps which need features which aren't present in the local version of glibc. In other words, even if you forced this to work, your app is going to crash. Eventually it'll call an ioctl not supported by the kernel or look-up a glibc entrypoint which doesn't exist or something.

This is how, for example, you get new API calls safely added to glibc. They have an internal versioning system which says "this'll only work on THIS version or higher". Windows, by the way, does exactly the same thing only instead of complaining about missing symbols like that it pops up a message box saying something like "This program cannot be run because there are parts of its environment missing" but crucially doesn't tell you which version of the c runtime will be sufficient to run it...

You *can* solve this by finding out what's dragging those symbols in and programming around that. The STL is particularly fond of this, but other things will do it as well. If you can locate them and it's something you have an alternative for then you can simply use the alternative. I've fixed compilation errors in this way before -- ISTR one was something like an STL linked list operation needed the feature but the equivalent for vectors didn't so I rewrote the one container which was causing the problem to used a vector, took the performance hit for vector resizing (which was small enough not to worry) and now my app "just worked" on the target systems.

#4762326 Proof God doesn't exist?

Posted by Katie on 21 January 2011 - 05:09 AM

And I wouldn't worry about being an atheist. It's perfectly possible to be a rational considered atheist. Considered means that you've actually thought about it and made a positive choice rather than merely being a lapsed faithful. And rational means that you understand and accept the implications.

The former is easier than the latter. The latter means abandoning much of the sort of "warm fuzziness" that even the majority of the non-religious have. There is no god, there are no souls -- which even lapsed religious people seem to hold dear to. True atheists accept that we are just thinking meat.

On the other hand -- we are meat that THINKS and can understand the universe. How cool is that???

And people die. And there is nothing afterwards -- and that means that people are important alive. They do not go to a reward and to meet us again in the future; they just go. We do not go to a better place; if we want a better place we must make THIS a better place.