Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Jun 2006
Offline Last Active Aug 21 2014 03:07 AM

#4857146 How to Log and stay Modular

Posted by Katie on 03 September 2011 - 08:02 AM

" but globals are bad right?"

No, they're not. They're bad if you're an academic computer scientist. Academic computer scientists never actually have to ship code. Globals work, use what works, ship code.

"really messes up my goal of keeping things modular."

Don't have a goal of being modular. Have a goal of "shipping code". What value to you is "being modular"? None. It's an **ideal**. It's not a goal. Your goal is to ship code. That means you get to sacrifice ideals sometimes. This could be one of those times.

You're over-thinking this problem. Everyone always does. Everyone thinks there's a problem with "logging" because it's always either too verbose or not verbose enough and it's never quite right and everyone thinks the way to fix it is to somehow make the logging production more complication.

The problem isn't with the logging. It's with the tool on the other end. Make your program be either "verbose" or "succinct" based on a flag. That's all you need on that front.

Then just output strings but have smarter tools looking at the output.

The UNIX world manages to handle tons and tons of logging using "syslog" which is hardly sophisticated. "syslogd", the program on the other end, that has versions which'll do everything up to handling global networks with millions of servers...

Don't try and solve your logging analysis problems during your log generation.

#4855941 Sprite class and memory effeciency

Posted by Katie on 31 August 2011 - 10:07 AM

Oooooh. Interesting. Maybe there's a reputation threshold?

#4850257 What is the fastes way to load textures in opengl ?

Posted by Katie on 17 August 2011 - 05:39 AM

Instead of using an actual image format (such as TGA) which supports BGRA format, why not ship your images as plain image files already in that format. You don't need all the headers, you just need four bytes per pixel.

Lay them all out in a big block of ram, save that to disk, gzip it. When you come time to load it, you're only loading one file -- you hoof it into one giant block of ram (only 1 allocation, only 1 directory walk). Ungzipping a file is pretty easy on loading it. In addition your compression should be even better; larger files generally compress better than a set of smaller files because the compression can find more similarities to reduce.

Instead of generating the mipmaps on load every time, generate them on first run and save them out to disk. Again, do this one big block if possible. On load, pull it in, rattle down it transmitting the mipmap levels individually.

If you're on an OS which supports mapping the files, you don't need to load them or do an actual memory allocation. Map the file into your address space, provide suitable "linear access" hints to your buffer caching system so it will do read-aheads, start accessing the memory and away you go. The OS will try and load pages ahead of your accesses in the background; you don't have to wait for the "read()" call to complete. The effect of this is that you can already be generating and uploading mipmaps for texture 1 while the disk IO channels are still loading texture 20.

Instead of asking the GLU library to generate your mipmaps, you could build them yourself by using rendering of the fullsize image to pixel buffer objects and copies internal to the card to make them. That way the mipmap data doesn't have to transit the host-GPU bus.

#4850020 Best library for doing text in OpenGL

Posted by Katie on 16 August 2011 - 02:15 PM

Pango/Cairo. Drop it on a texture. Draw it to your screen. Cross platform. Renders everything from plain text up to simple HTML markup. Handles i18n. Everyone always ignores this recommendation without trying it I don't know why.

#4848968 Socket automatically closes after recv

Posted by Katie on 14 August 2011 - 08:18 AM

OK, can you use telnet as a client? Because we know telnet won't close the connection unexpectedly -- so this will find out if the problem is with the server or the client part of the connection.

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