Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 15 Jun 2006
Offline Last Active Apr 10 2015 06:18 AM

#4826851 Gaming for the Disabled

Posted by Katie on 23 June 2011 - 09:58 AM

It's not actually that hard to do some of these things.

Were I to have a go I might be tempted to start with Linux as a base (because the software is much more open). There are extensions to X11 which allow you to inject keypresses/mouse moves into the system from other userspace applications.

Libusb now allows you to write USB device drivers in userspace. As long as the device produces USB and you can find what the protocol looks like, it shouldn't be too complicated to run it. Read some bytes, parse them, emit events, go round in a loop -- you could possibly even do a lot of this in a scripting language rather than needing C. You'd then be able to tweak the translations to fit the situation.

Once you've got X11 events happening, there's a whole bunch of games available -- nintendo emulators, spectrum emulators and a lot of free linux native games; including some fairly well made clones of PC games (eg; OpenTTD or Widelands). Plus there are a bunch of other tools to do things like emulate keyboard input using only mouse movement[1], so it would mean general computing applications would become accessible.

And all of this can be done without any huge investment so you can afford to try things without sinking money into it while you're learning the techniques.

It'd be a bit lashed-together to start with, but it's an entirely approachable project.

[1] Eg; http://www.inference.phy.cam.ac.uk/dasher/ which is a neat tool for writing text using only a mouse.

#4823678 Recycling variables and performance

Posted by Katie on 15 June 2011 - 10:29 AM

1. The compiler will do this for you anyway if it thinks it's safe to happen.

2. You almost certainly do not have the sort of performance problems that this is likely to help with.

#4822365 Memory Allocation Limits (C++)

Posted by Katie on 12 June 2011 - 05:56 AM

" I found that the app was crashing on a memory allocation."

This is almost always caused by something else scribbling into a previously deallocated block and corrupting the linked list that the memory manager puts into the space.

#4816825 Thread Safety, using threads to load models.

Posted by Katie on 28 May 2011 - 11:18 AM

"You can have just two threads, the main game thread and the background-loading thread."

A reason to have many threads in the background is to issue many IO requests. The reason to issue many IO requests is to a) saturate the disk bus (because you want this stuff loaded) and not have any dead time and b) to tell the OS about all the things you want to load. Why? So it can then optimise the loads; suppose you want to load 5 files all on different tracks on the disk. If you tell the OS about all of them (by asking for them) then the OS can order the accesses to go across the disk in the optimal seeking pattern; It may make sense to load #3 first, then #2 then #5 and so on. The OS will know more about how to do this than you probably can because it knows more about the storage device.

Windows overlapped IO does this without the overhead of all the threads (each thread requires a non-trivial amount of memory to be allocated).

#4816513 [RELEASE] World Wars - European Conflicts

Posted by Katie on 27 May 2011 - 12:36 PM

"Kill all Krauts"???

Not good taste that. Not at all.

#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.