Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Jun 2006
Offline Last Active Yesterday, 02:13 AM

#4862701 Windows OpenGL and choosing from multiple video cards

Posted by on 17 September 2011 - 01:19 AM

Aren't you supposed to do this by calling EnumDisplayDevices to get the list of video cards and then using CreateDC to create HDCs on those devices? Then you can use wglChoosePixelFormat (which takes the HDC) to get a render context of the right type on the right device?

#4861419 what is a practical use for the determinant of a matrix?

Posted by on 14 September 2011 - 01:40 AM

If you're working in 3D and using 4x4 matricies as transforms, the determinant has an immediately useful value.

If you put a unit cube through the transform, then the determinant will tell you what the volume of the output cube will be; in other words it tells you the volume scaling that the matrix will do.

Hence, well behaved 3D transforms will all have positive non-zero dets; and all rotation/translations which you expect to do no scaling will have a det of 1.

This also helps explain why zero det matricies can't be inverted. In order for it to have det zero, it must shrink one of your unit cube dimensions to zero. Hence there can't be a matrix which goes the other way, because there's no way to reinflate that deleted dimension back to one. Hence there's no inverse for the matrix.

Obviously, since you HAVE to squash one of the dimensions away to go from the 3D world to the 2D render plane, this means all projection matricies must have det = 0. And hence, this is why there is no general case system for taking a pixel in the window and finding it's location in 3D space, because that would amount to being able to invert your projection matrix.

#4861271 How long until c++ disapear from game development

Posted by on 13 September 2011 - 03:43 PM

" I remember reading an article in Dr Dobbs years ago about how REXX was going to make all programmers obsolete"

I remember reading adverts in the 1990s for the languages which would replace C and C++ with languages so easy that managers would be able to write the code themselves... I'll bet no-one's ever heard of any of them these days.

Easily 20 years this conversation's been going.

It's actually getting very very hard to hire good C/C++ people. And that's a problem because Google runs on hardcore C++ stuff; KVM and Xen need good C hackers, performance libraries for Android need C and C++ coders... Just this week Google is talking about tech to run C++ code natively inside sandboxes because they know the world isn't replacing that stuff any time soon. Good. Means my pay will go up for my rarity value...

We've all been waiting 50 years for Cobol to die and it still won't.

#4857146 How to Log and stay Modular

Posted by 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 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 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 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 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 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 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 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 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 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 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 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.