Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Jun 2006
Offline Last Active Jul 25 2016 04:59 AM

#4848172 3 years professional experience?

Posted by Katie on 12 August 2011 - 05:41 AM

Send them CVs any way. Make sure you have a good demo. Games companies often don't advertise junior roles -- they have a queue of people already waiting to join them.

Go to job fairs, talk to people there.

Find the developers, talk to them in the pub.

Get recommended by friend who already works there.

Join to do something other than development -- retaining good testers is a nightmare and most companies are always looking for more.

#4847324 Ambient occlusion simulation for AAA projects

Posted by Katie on 10 August 2011 - 02:57 PM

"absolutely anonymously without any chance to track my work"

You are james bond and I claim my five pounds?

#4847114 Can someone help me with tileset dimension

Posted by Katie on 10 August 2011 - 05:03 AM

"why do tilesets have standards in the first place, like 16x16, 32x32, 64x64? Or is 50x50 just as fine?"

Well, one reason is historic; power-of-two numbers are easy to manipulate quickly. Games on 8bit computers and consoles often used 16x16 tiles because it was a compromise between detail, storage space for the tiles, and being able to access the pixel data quickly.

In addition screen sizes were also often powers-of-two. For example on the CPC, 16x16 tiles means you can have a 20x10 screen with 40 pixel lines left over for a status display at the bottom.

When hardware assist started to appear for the graphics, it was often power-of-two oriented, again for hardware simplicity reasons. Early OpenGL and DirectX (and other APIs such as Glide) similarly limited textures to 256x256 for hardware reasons, meaning that 16x16 or 32x32 tiles would fit better and not waste precious texture memory.

#4847109 Negative Reputation

Posted by Katie on 10 August 2011 - 04:49 AM

"It's like being in a meeting.. giving your opinion which is technically correct, and having others in the room shoot your idea or explanation down. That can happen.."

Except in anything but a very badly run meeting, ideas aren't just "shot down" without there being justifications -- particularly when the idea/explanation comes from (say) the highly experienced developer who has historically shipped good product. It's not that the intern in the room doesn't get to have an voice an opinion, it's just that don't get to say "no" without a reason. They're quite allowed to say "Ah, could I just point out this reason why this may not work...", but they don't get to just say "nope". Well, not and keep their job for very long.

Popularity is, historically in a number of fields, a poor way of choosing correctness. No-one likes an answer which is difficult and would prefer an easy one and popularity contents will select the latter; which is fine as long as you can guarantee that there will only ever be easy answers to things.

#4846811 Ambient occlusion simulation for AAA projects

Posted by Katie on 09 August 2011 - 12:47 PM

"So let me start:"

I can't see where the magic technology is. I can see that you've implemented a "hard and soft layers" architecture involving scripting to connect component parts together. Could you be more specific about what it is I'm missing?

#4846805 Ambient occlusion simulation for AAA projects

Posted by Katie on 09 August 2011 - 12:38 PM

"mire 4.5K euros a month"

You turned down E54k a year? E54k a year is a pretty good salary. And for games development??? Blimey. Again, most people here would kill for that sort of offer -- it's the aspirational goal of their life.

"working on technology that is more inferior than my home projects"

There's a lot more to games than the graphics engine. Look at this year's surprise hit. His characters have corners...

#4845842 Create objects only once

Posted by Katie on 07 August 2011 - 11:40 AM

Material* mat = manager->getMaterial("MyMaterial");
if(mat == NULL) {
   // This is the first time someone wants to use this material. So create it

Don't do that.

You're putting in a branch point you don't need. I presume the second call to "getMaterial" should be "createMaterial". Also, you're not checking the error states of anything.

You're putting loads in unpredictable places. You now have several possible disk accesses (which are slow) plus shader compiles inside your rendering cycle. It means the first time a given material appears in view you're going to get chunky frame times.

Just go and load up all the stuff you need before you start. Presumably you are loading up the models anyway which name the material types, so just stick them in a list, then create them all. Then you can go through all the models setting the material pointer. Then you can start rendering, and now you know that all the bits are in place, so you don't need to worry about getting nulls back from your getMaterial call.

Don't put ANYTHING you don't need in your render loops -- anything you can do upfront, do it upfront.

#4845557 Sprite blitting

Posted by Katie on 06 August 2011 - 03:43 PM

OK, I had a look at the code and it's not really something I can "just post" because it uses a lot of my own utility classes.

I can talk you through the main points though.

Probably the easiest way to do this is to evolve your way gently towards it.

So the thing is to put all your images into one texture -- a texture atlas.

Draw your sprites using immediate calls for now setting up each x,y,z and texture coords. You should have a working, but slow engine.

Put a shader in -- the vertex can just pass things through, the pixel shader is a simple texture read.

Pass in uniforms for the sprite X,Y,W,H and rotation. (next step is to turn it into something faster). Also you'll need columns and rows for the images in the atlas and also a uniform to say which image to use. Now your shader can compute the screen X,Y coords and texture coords. You use the supplied coords to tell whether to add width/height values to the coords. Just draw a square at (0,0),(1,0),(1,1),(0,1) in immediate mode after setting up the uniforms for each sprite.

This is still slow but getting there.

Now turn the immediate mode square into a VBO, draw the four verticies out of it each time.

So the next part is supplying the sprite data in a texture buffer...

(to be continued...)

#4843816 Can anyone point me to Mac specific OpenGL 3.2 tutorials?

Posted by Katie on 02 August 2011 - 05:03 PM

There are no big single guides for this stuff. You'll have to go to multiple places.

The superbible should have the mac start-up code which gets you to the point of having a GL context ready to render into.

From there, the GL stuff is common on all platforms.

You'll just need to do things like keyboard/mouse handling, but that's a relatively thin layer -- my X11/unix version is 1000 lines of code including some big lookup tables for the keys. The mac docs will have this in them -- although my copy of the superbible has enough stuff to run with.

As for being all 3.2ey... create VBOs, stuff data into them, create shaders, run shaders. That's pretty much it really. People keep making it out to be a bigger thing than it is.

#4842052 Ray tracing fur/hair

Posted by Katie on 29 July 2011 - 03:31 AM

You don't have to split the hair into segments; you could solve spline against plane intersections directly.

That solution should also give you the coordinates of the intersection, which gives you a depth value... and that will let you do ordering of the contributions.

#4841014 Ray tracing fur/hair

Posted by Katie on 27 July 2011 - 03:01 AM

You're effectively trying to intersect two mathematical lines of zero width which is hard.

(The hairs approximate perfect lines from sufficient distance)

Testing the view ray against the hair is difficult, because you think you need to think of a way of bulking up the hairs so that there's a way of doing the intersection.

Apply some of Katie's rules of software engineering;

1. Ask what it is you actually want.
2. Invert the brute force solution and see if looks easier from there.

What you actually want is not knowing whether the ray intersects the hair or not. What you actually want to know is "how many hairs contribute what colour to this pixel".

Turn the problem around. Your pixel projects back from the camera, effectively occupying a long truncated pyramid shape. Your fur/hair lives in a volume. First off, if those gross volumes don't intersect, the answer is none.

Once you've established that the ray is passing through the volume that the hair might possibly lie in, you can do an intersection between the volume that represents the projection of the output pixel through that volume and equations describing the hairs. The hairs will typically be described as delimited curves which are reasonably easy mathematical objects to handle.

If you can establish that the hair intersects that volume, you can add some of the hair colour to the pixel. (The pixel is unlikely to be fully occupied by any given hair).

The complexity of this then the # of hairs, coupled with the complexity of solving the equations describing the hair. It's relatively easy to make the hair drift, wobble, wave etc, since you then just add more terms to the hair expression.

The gotcha is that you really want the hair/fur to be translucent at the edges, so you'll need to establish earlier intersections first before doing the hair intersections.

#4840421 Few questions about the legal part of a game company

Posted by Katie on 26 July 2011 - 02:44 AM

How much work have you already done?

Do you have the basic infrastructure completed and running? If not, you don't need a lawyer yet.

Go and write the game. You don't need a lawyer until a lot later in the process.

And a bit of advice on lawyers -- the longer you can keep them out of your life, the happier you will be.

#4840414 Question about imperial units

Posted by Katie on 26 July 2011 - 02:32 AM

It gets more complicated than just metric or imperial. There are also things like "metric feet".

A metric foot is 300mm long. It's ~5mm short of an actual foot. Wood, annoyingly, in the UK comes in metric feet lengths. Yes, that's right. You can't buy an 8 foot spar. You can buy a 2400mm spar. The problem arises when you actually need 8 feet of wood because 2400mm is nearly, but not quite 8 foot.


The reason there are different conversion factors is that the units all arose for different things. A foot is about a foot length. A yard is about an arm length. An inch is the last part of a thumb. That sort of thing. A furlong is the distance a couple of oxen can pull a plough in one go before they have to rest. A chain is the width of a bit of land of an acre in area and a furlong long. An acre is the area you can plough with one plough team in a day -- and hence varied depending on what you consider to be "a day", "can" and "team" and hence on things like what the soil there is like.

All of these were then sort of standardised over several centuries, but the measurements needed to be close to what they'd always been, so they ended up with "funny" conversion factors between the units.

If you're doing engineering in imperial (my Dad used to) then yes, you get used to doing conversions and using things like the "poundal" and the "thou". I grew up in the metric era, but I grew up in a household which measured things in imperial. In a discussion in the office a little while ago, I described something as "about 10 thou" and one of the guys here said to the other (younger) team members "See!!! I told you it wasn't a made up unit..."

#4839897 gpu based particle system

Posted by Katie on 25 July 2011 - 02:18 AM

"Of course, this trick only works if their spawn-rate is 1:1 with their lifetime"

It's perfectly reasonable to include some downtime as a ratio inside the particle data. You just draw a degenerate quad/tri if the particle is currently not running. By tweaking the origin times/respawn ratio times you can then generate effects like a fire which flares up and dies down.

#4836082 Microsoft's No-Bid Contracts

Posted by Katie on 16 July 2011 - 12:37 PM

"Where the hell does government get the right to tell me I'm no longer allowed to use DDT to kill the insects in my garden."

DDT's an interesting one. There's a body of opinion that banning it has killed more people (from malaria) than using it would have done. That is; although it's dangerous, it's better than the mosquitos having a good time.