scgames

It probably has the wrong open source license (its unusable as-is on platforms that don't have dll support), and for the platform's you would need the commercial license won't come with code to run on that platform (PS3, XBOX, etc) anyway, which more or less makes me wonder why the commercial license of SDL costs money.

It's not quite so simple. SDL 1.3 is now zlib (or some similarly permissive license). However, 1.3 is still a WIP (last I checked, at least), and so may not be suitable in some cases. 1.2.x is relatively stable, but is still LGPL (IINM). Whether that's a problem depends on the circumstances, of course.

Naturally, if a library doesn't support the platforms you're interested in or if the licensing terms or cost don't meet your requirements, then it probably won't be of much use to you. That goes for any library though, more or less (SDL isn't unique in this regard).

Graphics API's in the grand scheme of things aren't all that complicated since the hardware does all of the work, using the APIs raw or even making a basic wrapper for one is a pretty trivial thing to do.

Although SDL 1.3 does provide a wrapper over the underlying graphics API for hardware-accelerated 2-d graphics, many people just use SDL to handle windowing and events, and do all the low-level graphics stuff themselves. As such, SDL is still useful even if you want to write all the low-level graphics code yourself.

For C++ the real time consuming things end up being things like serialization, proper localization support and string handling, and memory management (multiple heaps, streaming textures etc)

If you're talking about development time, I'd say it's probably easy to underestimate what goes into a cross-platform library like SDL unless you've actually tried to implement such a framework yourself (that is, a library that supports at least Windows, OS X, and Linux, and offers support for windowing, events, basic audio, and so forth). It can be surprising how much is involved (IMX, at least).

Note that I'm not specifically advocating for the use of SDL here; I'm just responding to the points you raised.

So, if my target platform is, for instance, the big three (Windows/OSX/Linux), using all OGG files loaded in memory is a viable option?

A relatively long stereo sound (e.g. a music track) decompressed can require many MB of storage, so it probably just depends on how many music tracks and/or other memory-intensive sounds you have, and what your memory budget is.

Small tip: these sorts of errors can generally be resolved quickly by using the debugger.

A couple of things I noticed:

1. If transform.forward returns a unit-length vector, you don't need to normalize worldForwardVector.

2. 'dotProduct' should probably be of a floating-point type rather than an integer.

3. Strictly speaking, you should generally clamp the argument to acos() to the range [-1, 1] to correct for any numerical error.

I'm not sure why .x is being zeroed out or what angle it is exactly that you're measuring, but the first thing I'd try is making 'dotProduct' a float rather than an int, and see if that helps.

I already considered making free functions, but I really liked to have everything in my classes.

This is contrary to what's generally recommended, I believe. (Here is an article on the topic you might want to read.)

Maybe don't worry so much and just continue with the book and play with examples. It takes time to really understand programming. :-)

+1.

@The OP: It's probably not so much 'understanding objects' that's the problem here, but rather just becoming familiar with the idiosyncrasies of C++. The fact that you can push a string literal into a vector of std::string has to do with single-argument conversion constructors (as described above), and definitely isn't the kind of thing one would be expected to understand, necessarily, if one were just getting started with C++ and/or programming in general.

So yeah, don't get too hung up on the idea of 'understanding objects'; just forge ahead, and things will gradually start to make more sense.

Regarding the terminology, with the fixed-function pipeline, the 'world' matrix in D3D corresponds to the 'model' matrix in OpenGL, so:

D3D: world->view->projection
OpenGL: model->view->projection

Furthermore, OpenGL collapses the model and view matrices into a single 'modelview' matrix, whereas D3D keeps the world and view matrices separate, so:

D3D: world->view->projection
OpenGL: modelview->projection

With modern shader code, all of this disappears and you just construct and use whatever matrices you need. Typically there'll still be 'model', 'view', and 'projection' transforms in one form or another, but which ones you upload and what you do with them exactly is up to you. (That said, the simplest possible vertex program will typically transform all incoming geometry by a single matrix that represents a concatenation of the model/world, camera/view, and projection transforms.)

Also, I was told to start with either C or Java by a person on a different site, is that true?

That seems like kind of an odd pairing - did the person offer a rationale?

C and Java are kind of at opposite (or opposite-ish) ends of the spectrum, language-wise - C is relatively low-level and has a fairly cumbersome compilation model, while Java is fairly high-level and is conducive to rapid development.

Some people advocate starting with something like C and 'working your way up' towards higher-level languages, but I think starting with something like Java or C# is probably more common (and will certainly get you up and running faster).

I'm sorry, I'm new to this forum. I am creating my own level editor. I am just confuesed on how you could program it so it would let you place a tile that you could select off of a tilesheet

In very general terms:

1. Create a variable somewhere that indicates what tile is currently selected. (It could be 'empty' initially, or refer to a default tile.)

2. If the user clicks anywhere in the 'tile palette', determine on which tile the user clicked, and assign that tile to the 'current tile' variable.

3. If the user clicks anywhere in the editing area, determine on which cell the user clicked, and place the currently selected tile there.

From what I understand, ray intersection functions provided by Direct3D (the graphics library I am using) work with polygons.  So for example, my sphere would need to be made out of (say, triangles) to compute the intersection from the ray to the sphere.

Is this correct?

Nope; you can compute the intersection with the sphere directly (you don't have to use a mesh representation).

So if I know the radius of the sphere in its 3d space, and am given a 3d ray, how would I get these coordinates of intersection?

Google/search for (e.g.) 'ray sphere intersection', 'line sphere intersection', 'sphere raytrace', or 'sphere raycast'. (The algorithm is straightforward and is well documented online.)

I admit that I'd have to read that again (and maybe again after that ;) in order to understand what it is you're doing, but meanwhile, let me ask this. If the objective is to determine the latitude and longitude corresponding to the cursor position, why not simply raycast against the sphere and compute the latitude and longitude from the intersection point?

It sounds like you have it right. First you'll need to pick three mutually perpendicular edges that together have a positive determinant/triple product; if you know the order of the vertices, you should be able to draw an image with each vertex labeled, and then choose the edges appropriately.

If the transform is intended to be applied to the unit cube (1x1x1), then you should be able to simply load these vectors into the first three columns of the matrix (assuming column vectors are being used), as you described. The box position would then be stored in the fourth column.

No debuger = more thinking.

Would a mechanic try to fix a car engine without opening the hood?

The debugger is one of the most important tools available to a programmer, and this is especially the case with languages such as C and C++.

Furthermore, once you've had to diagnose a problem in someone else's code (rather than your own), the usefulness of a good debugger should quickly become clear.

I'm having trouble with, what I believe is, the rounding of angles in my C++ Pong clone.

As Hodgman said, you don't need angles for this (it can all be done with vector math).

So if I setup a rotation matrix do you know if I can just apply it to my code with an opengl call?  I was looking at glMultimatrix and it seems like that may work.  Or would it be better to just compute the matrices and extract the vectors, then use them in my code as I was already intending?

Provided it's arranged in memory the way OpenGL expects (that is, the data occupies a contiguous block of 16 elements and the elements of each basis vector appear consecutively), you can upload the matrix directly using glLoadMatrix*() or glMultMatrix*().