Bacterius

You could analytically divide the curve into n segments and take the limit of the sum as n goes to infinity, this should give you the formula. Or use the integral form which would give the same result (by definition). Did you try this (google cache since the site seems to be down/dead)?

MDI windows used to be the "big thing" a few years ago for this sort of thing but they're pretty much obsolete today. Usually you'd separate each viewport into its own window layer (or "panel" or "client area" or "frame" or whatever it's called in your case) and render there, and if you wanted to be able to resize viewports there is a "splitter" (or something) component that you can use which will allow the user to resize with the mouse. Even more work is needed if you want to make it modular (to move the viewports around, add and remove them, and even detach them as separate windows).

Or some frameworks have docking features which make this GUI stuff easier. What language/framework are you using to design the interface? It will be easier to answer you if you target your platform, this is too broad a question at the moment.

Can't you just change the ambient light value depending on the surrounding tile types? If you walk into a cave, bring the ambient down to (16,16,16 or 32,32,32). You can even adapt that towards the whole game and always interpolate the ambient value based on terrain type and time of day.

Do you have specific cave tiles? Just do a check to see what type of tile the player is standing on. If grass tiles only appear outside, and cave tiles only appear inside a cave with cave roof tiles overhead, then it's an easy assumption to make.

I think the OP wants something like when you break a few tiles off the cave roof, daylight floods into the cavern (with a direction depending on the time of day) and illuminates it a bit. You'd need to take into account geometry, or at least identify which tiles are "lit" and propagate that property to nearby tiles with a realistic diffusion algorithm (perhaps a sweep algorithm could work here if the world is divided in chunks)

Have you looked at ambient occlusion techniques? Although if you have a voxel world there might be better ways to achieve what you want.

What was your journey to becoming proficient in the languages you know? I know myself I love hearing how people got to be who they are today and the steps they took. Feel free to share here, if not that's fine! I know beginners love to here others' success stories.

Since most of the previous posters give insight into how they got into programming back in the time when computers and the internet weren't exactly commonplace, here's my story from the point of view of someone that started out in the 21st century with most of the stuff available at a few clicks' reach.

• Started at 10 when my dad introduced me to Object Pascal (with the Delphi IDE), whipped up a few crappy apps/games with the RAD interface
• Two months later, I discovered pointers and indirection mechanisms and my world changed that day
• For the next six years, honed my skills to become quite proficient in that language and with hardware, but with intermittent 6-month "coding breaks"
• Got interested in math only when I was around 15, figured I could use my knowledge of programming to make homework less tedious
• Picked up Python when I was 16 and played around with it. Never really got proficient but I love writing short algorithms with it
• At 17 I went to my first "programming class" which was available at my high school
• Subsequently had to learn Java, did not like it much but survived
• Had to learn C# the second year, liked it a lot as a productivity tool and got proficient (with the syntax at least, lol, but checked out a few libraries)
• At 18, built my first actual desktop computer with - omg - an actual graphics card
• Immediately learnt XNA, but found it too convoluted and used SlimDX/C# instead
• Six months later, got bored to tears with computer graphics, learnt OpenCL and crunched numbers big time
• Learned some x86 and x64 assembler shortly after (just general knowledge for when I need to inline stuff)
• Begun university, have to use Java for computer science courses, which is slowly turning me into a code monkey
• Turned 19 and three more years to go before I get those degrees <- I am here
• Looking forward to learn some functional languages, such as F# or Haskell and some database stuff (which I've ignored completely for some reason)

Not exactly a "success story" but I feel I'm not doing too bad in terms of picking up new languages and frameworks (it certainly could be better, but I got... hmm... sidetracked with other things).

My advice is to just "do it" and don't worry about what you learn, it's not like your brain has a limited capacity, and any experience you obtain in one area can often be reused elsewhere, as the whole programming/computer science field is very modular. I can safely say my extensive knowledge of Pascal and all the underlying algorithms/syntax/constructs made performing all of the subsequent bullet points about a thousand times easier (plus, it makes my discrete mathematics and logic course an absolute breeze). Whatever you learn cannot hurt you.

For what it's worth, I have very little knowledge of C++. OK, whip me now!

This has been debated so many times before, just roll with C++ since you already know some of it, and change when you get bored of it, or if you find it too hard or convoluted or just want to check out new stuff... it's not difficult to change languages, takes a download and two days to learn the IDE/syntax. You'll probably end up learning both C++ and C# eventually anyway.

Game logic isn't any more difficult in C++ than in C#, it's the same thing, except in C++ you tend to get more boilerplate stuff which is often abstracted through syntax in C# (especially with frameworks, which also exist for C++ by the way), and C++ has a reputation of being less forgiving to beginners with rather cryptic bugs and error messages - although I believe this to be a non-issue once you get some experience under your belt. And language-independent stuff, is, well, language-independent, so you kind of answer your own question here.

Really, the choice you make here does not matter. The basic concepts of game programming generally carry over across languages, so stop worrying about your future and just pick one. You'll have weeks/months to make the change later, once you need to.

My search for this is over now ...

Yeah, it only took you five years

Please check the age of the topic before leaving a reply... the last activity in this thread dates from April 2007.

2. How exactly are the drivers such as tridef working? .. apparently they listen in on the dx calls, but with everyone rendering in different ways, how is the magic working?

Well, ultimately, at the end of their pipeline, most standard games output a frame buffer (containing color information) and a depth buffer (containing depth information). This should be enough to reconstruct the three-dimensional world as viewed from the observer - the driver just interprets this information and correctly plots the data on the 3D display. Games are free to use however many passes they see fit while rendering, as long as they give the driver the information it needs at the end (which is conveniently exposed through standard D3D resources).

This should go in the Lounge (don't repost, threads can be moved).

I recommend a laptop with 6-8GB memory, a decent processor (quad core if possible, but a nice dual core would work too), and if you can, an SSD. And a mid-level mobile graphics card if you are going to be doing game development. Make sure you get a big screen with a large resolution! There should be various options around your price range for this, I can't recommend but for instance, something like this (USD $1000) as a baseline model, default options are quite nice except the hard drive, otherwise there's this one with a lower starting cost so you can customize it a bit (I added more memory, increased the screen to 1920x1080 and added a small SSD all under $1000) but the graphics card is an inferior stepping. Of course these are just examples, I don't endorse the brand or anything and am simply making general statements about what kind of hardware you could be aiming for - although the Sager/Clevo laptops are generally pretty good.

If you are just looking for the cheapest one though you can probably find a functional laptop somewhere for $600 or less, but to be honest if you are going to be buying a laptop you might as well get one that will last you a while.

A single unit vector isn't enough to obtain a three-dimensional camera basis, it'll only give you two angles (azimuth and inclination) which can be extracted via spherical coordinates, but not the third (rotation around the view vector).

It's fairly easy to understand why intuitively: if you are looking in a given direction, you can't tell whether your head is tilted left, right, or you are standing on your hands with your head upside down - the direction vector remains the same in all cases. You need more information.

From a mathematical point of view, a normalized 3D vector only has two degrees of freedom, since z = sqrt(x^2 + y^2), so the third component effectively adds no information. It should then be obvious that it is impossible to uniquely translate this vector to a representation which includes three degrees of freedom, i.e. your three angles.

I want to write a bidirectional path tracer, but I'm not sure how. My understanding:
1: Two paths are generated--one from the light and one from the camera.
2: The vertices of the paths are connected in all possible ways to form a number of complete paths from the light to the camera (paths that pass through opaque objects are discarded). I.e., all paths that use some light path vertices, jump somewhere on the camera path, and then use the rest of the camera path vertices.
3: Each path is evaluated by weighting the probability of each interaction occurring, producing a sample.
4: The sample is averaged into the final pixel's color

That is essentially correct, just remember that you cannot use the camera position as a node for obvious reasons (that'd be one weird camera), so make sure you start at the first intersection on the camera path.

In standard path tracing, I use importance sampling (e.g., for a diffuse surface I generate random rays with a cosine weighted distribution, then just weight all samples equally). For bidirectional path tracing, I speculate that both the light subpath and the camera subpath could be generated in this way, but the interactions at both ends of the connecting step would need to be weighted manually (because you can't just choose the endpoints randomly) by the interactions' PDF.

Exactly, this is why you can't just use any intersection point on your light and camera paths as nodes, because many materials simply cannot be handled in that way. For instance, perfectly specular and dielectric refractive materials essentially have no PDF (it's a Dirac function, i.e. zero everywhere except at a single infinitesimal point), so they cannot be importance sampled, since the probability of a ray randomly bouncing specularly to a given point is by definition zero.

It depends on what your light sources are. Are they physical, e.g. have an area, or are they omni point lights? If they are point lights, I see only one solution so far: once you've cast your direct sampling ray to the light source, you walk along it and see if the ray gets deflected somewhere (either it hits something, or gets refracted away, etc...). Doing this you will trace your ray through the sphere and correctly identify that the sphere poses no obstacle to the ray, so the direct sampling path still counts. Of course, this sucks in terms of speed and possibly floating-point accuracy. So basically, a more elaborate version of a shadow ray.

However, if you have area lights, and I also suspect you do since you mention "small lights", then you might be using the wrong model, because it would seem that any semitransparent media (e.g. glass, water) would fail horribly. However, if they don't, and you are able to generate caustics nicely, then you can simply view the "transparent object with refractive index identical to air" as producing a degenerate caustic exactly the size of the hypothetical "shadow", but which does not show any change in brightness (so effectively, no difference). An unfortunate "special case", in other words. If that makes sense.

Of course, the obvious solution is to preprocess your scene and delete invisible objects... I mean, why have them there if they are going to be invisible?

Probably zero impact, considering all the cryptography you'll ever need has already been implemented securely in many libraries (openssl, bouncycastle, etc...) and you almost never (and should never) implement it yourself. But learning about cryptography certainly is worth it (but until you actually know what you're doing you shouldn't use it in your commercial projects).

Furthermore cryptography in general is not a very useful tool when it comes to preventing cheating etc... Cryptography solves these problems:
- confidentiality (controlling who can read what you wrote)
- integrity (making sure a given message arrives intact to some destination)
- authenticity (knowing who produced/sent data)

In general these are not the problems you want to solve when making games.

How about... both?

A few remarks on top of Hodgman's:

- Your test is hardly fair, most of the matrix operations are implemented using MMX/SSE opcodes in assembler but C doesn't get that luxury (I wouldn't bet on the compiler figuring it out and using SIMD on its own). You could use intrinsics. As it is now you may as well pepper your C code with random sleep()'s because the results will be just as meaningless.

- Benchmarking the smaller functions like zero vector and copy vector is useless, as the processor will spend most of its time pushing/popping to/from the stack (especially in C, since the compiler usually leaves the standard push/pop's even when unnecessary just to be sure, and assuming their cost will be amortized over the function's effective instruction count - which obviously is a flawed assumption for trivial functions)

- In some of your C functions, you call other functions (like in matrixCamera, you call a bunch of vector* functions) - function calls are not free. However, in assembler - surprise - you inline the extra work instead... although I suspect a good compiler would inline too (but likely not as efficiently)

So, in conclusion, yes, assembler is faster, but you really aren't helping C to compete. Your test heavily favours the assembler implementation, and as such doesn't give very relevant measurements.