Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 20 Apr 2013
Offline Last Active Today, 12:37 PM

#5120297 Math?

Posted by lightxbulb on 31 December 2013 - 07:24 AM

Saying a computer programmer, especially a 3D game developer, doesn't really need to know much math is like saying a professional musician doesn't need to know anything about scales or rhythm or harmony or composition; all they need to do is be able to play like the guy in the You-tube video.


It really depends honestly, you may be a 3d game dev and, with the abundancy of tools and engines nowadays, never have to go further than the basics when it comes to math. As you usually won't need to be a pro at composition if you're just a performer, the same way you don't need to be a professor in maths to be a 3d game dev. Math is merely a tool in game dev, of course it shouldn't get in the way, but nowadays(with all these "user-friendly" tools) you can make a 3d game with math knowledge from 8th grade. 


The more math you know the better, but that certainly doesn't mean you can't pass up on math depending on your goals and the tools you use, and usually most of the things you would do have already been done and explained step by step, so even somebody with minimal math knowledge can manage. There's also the case when a guy starts delving deep into maths and learns all kind of things that he'll never ever need to use - remember your uni days, you surely have learned some things that you didn't need for tens of years. I would advise learning what you need now, as to keep a precise goal, rather than make maths your goal(lest you like it of course) - I believe you should look at math as a tool being a game dev.


P.S. Recently I got the chance to see some of the code of a relatively successful game, well I must say most things that had to do with math and didn't rely on library and tool implementations, looked pretty bad and the calculations and derivation of solutions to some of the problems were mostly inaccurate and more random than analytical(it was not the case of complexity/speed compromise) - I do not say that this is good, but the point is that you do not necessarily need to be really good at math to be a 3d game dev.

#5120278 Math?

Posted by lightxbulb on 31 December 2013 - 05:23 AM

What type of math do 3d game developers use on a daily basis?

Actually you may not need to use much math to be honest, it depends on what you're working with - you may have everything you need already in a library, if you elaborate on your question maybe people would be able to give a more precise answer. Otherwise, here are a few examples:


For all the coordinate system changes, movement, rotations etc. - matrices (and really transformation matrices mostly that are square and usually 3x3 or 4x4) - basically the basics of linear algebra - something that would take at most 1 month (for students in 1st year in uni I think). Now you may opt to use quaternions too in some cases. Nothing scary really, even if a person is not so great at math - it's mostly basics and not anything that goes too deep.


It may be useful to know what are polar and spherical coordinates and how to pass between Cartesian and polar/spherical coordinates(add to this barycentric and homogeneous coords if you want, though there's nothing much to learn there), something pretty trivial.


Some analytical geometry won't hurt, it will help you the most imo. It's pretty basic too and you don't really need all the small details, some basic vector math, dot and vector product, plane, ray, sphere equations etc. 


These are pretty much all the basics I think you'd need, there's plenty of material on each of these on the net and it's really not that hard and most of the times you'd have most of the math done for you with the help of a library, but it never hurts to have some knowledge of what's happening and if you ever need to do something yourself.


Now if you want to do something harder, like make physical simulations you'd need some basic calculus, you should be able to solve differential equations etc. Here things may get a little more ugly, but it's not something that's as scary as it sounds, and you'll most likely not need to do this.

#5119166 Is using an existing library, actually cheating?

Posted by lightxbulb on 25 December 2013 - 04:28 AM

It is not "cheating"(actually it really depends on your perception of cheating, so for you it may be cheating depending on your goals). I would advise learning C++ "in depth", http://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list , pick a good book and finish it (most important pick a book that you like the style of writing and way of explaining). If you feel so bad about using SDL or whatever you can always try DX or OpenGL, while you would probably need a lot of time to learn it, I believe it is worth it, especially if you like the technical side of things. It's gonna be harder and take a lot more time and effort than using some engine to make a game though. However, if that doesn't seem that bad to you, and you like the journey as much as the goal, you can always opt to go for DX or OpenGL - it's pretty interesting and you learn a ton of things along the way. There are plenty of tutorials on the net (along with the DX SDK there are beginner tutorials in the documentation too):






And plenty of good books:





A word of warning though - you should learn C++ well before doing that, otherwise I believe it will be too hard learning both DX/OpenGL while learning C++. You'll probably also need some basic knowledge of math (and hopefully working with DX/OpenGL you'll start liking math even more) - for example matrix transformations, vector operations etc., and if you decide to delve even deeper sooner or later you'll need some calculus, tensors, spherical harmonics etc.(basically you'll need some math that is needed in physics).

#5118379 computer pong paddle

Posted by lightxbulb on 20 December 2013 - 10:13 AM


well I can get the paddle to move up or down the screen but I cant get it to move up and down and up and down again. here is the code that moves the paddle up the screen.

RECT rect;
if (vel_y <= 0 && vel_y >= -659) 

I'll just give you the way I'd do it, and not fix your code, as CoreLactose mentioned it's more useful if you figure it out yourself(though I believe that sometimes a person needs to have seen how it works numerous times to make it work).

Here's what I would do:

1)I will give my paddle some constant speed for movement (we don't need acceleration just yet I think :) )

2)I will check when the player pressed up/down and resolve these cases

3)I will check for collisions with the walls

Incoming pseudo-code:

//At init:
int paddleSpeed = 1;
int paddleY = screenHeight/2;//considering that is the coords for the center of your paddle
int paddleSizeY = 10;
int upperWallY = 10;
int lowerWallY = screenHeight-10;

//In the main loop:
//where keyPressed is a function that checks if that key was pressed
//And the other statement checks if a collision would occur
If((keyPressed(KEY_UP) == true) And ((paddleY-paddleSizeY/2-paddleSpeed*deltaTime)>upperWallY ))
   paddleY = paddleY-paddleSpeed*deltaTime;

If((keyPressed(KEY_DOWN) == true) And ((paddleY+paddleSizeY/2+paddleSpeed*deltaTime)<lowerWallY ))
   paddleY = paddleY+paddleSpeed*deltaTime;

#5115600 Creating an Open World game

Posted by lightxbulb on 09 December 2013 - 02:47 AM


Thanks to all those that realise creating an open world game is possible but not for a beginner

Such narrow thinking. I've come across several open world FPS games by beginners who made it as their first game using some tool. Torque3D has FPS, RPG, MMO, etc tutorials. UDK has tutorials for making open worlds, FPS, and other game genres. With the tools out there today it is no trouble for a beginner to make an open world game.


Arguing semantics more than 2 times in a thread makes you look like an asshole imo.(hint words:beginner, lua) Of course the guy has some illusions when it comes to game making - but most people do, especially when they are beginners, however that doesn't explain why you sound so pissed every time you reply and start nitpicking every single word. Don't worry, even if a person has unreal expectations of what he can create - sooner or later he'll either manage to make it(at the expense of tremendous efforts), or he'll get disillusioned when it comes to "his dream". Trying doesn't hurt most times.


P.S. Don't bother replying I'm not into E-drama.

#5115423 2D mouse (rotation in 3D world)

Posted by lightxbulb on 08 December 2013 - 12:51 PM

First of all, I hope you didn't take my remarks too hard - they are there only to point out what is wrong so you can fix it.

The biggest issues IMO, is that you were redefining the textureMap, had some dubious ambientLight calculations, used direction for position of your lights, and as a whole the whole algorithm was kinda "stitched up".





I guess my original logic is that if the pixel was not within one of the point lights (isCloseEnough) then it would be struck by a global ambient lighting.

There shouldn't be such an if logic - the pixel should still be struck by global ambient lighting even if it is close enough to the lights. The basic idea is that all lights should add up, only if the object is not in range of a given light you can ignore it.


Another thing is that it's probably not the best idea to make all the "experiments" you do in the main game code. Make up a test project where you can visualize the shader changes better. Try implementing the code I suggested if you can, if you manage to do it then you can add some specular reflection.



Oh and I changed the directional light from subscript 0 to subscript 9. I should have a elaborated on that.

I kinda guessed it was that, but even then the implementation wasn't really right.


Ill make the changes to my shaders and overhaul my lighting system once I get some gameplay down.


Did you bind your camera to your character?


I guess im taking a quick break from lighting to make the game feel more like a game and less like a tech demo that Im more accustom to writing.


Once I add a few more features Ill overhaul the lighting. I got this thread bookmarked ;)


Well, you could just copy-paste my code if you want, here - I revised it so you can copy paste it and it should work:

float4 PS(PS_Input texel) : SV_TARGET
    float4 textureMap = colorMap[0].Sample(colorSampler, texel.tex);
    float4  lightIntensity;
    float4  bumpNormal; //I fixed it to be with 4 coords, don't know why you had just 1 - it's a vector not a scalar
    float4 pixelToLightVec;
    float d;
    float4 C = float4( 0.0f, 0.0f, 0.0f, 1.0f );
    float4 Ka = float4( 1.0f, 1.0f, 1.0f, 1.0f );
    float4 Kd = float4( 1.0f, 1.0f, 1.0f, 1.0f );
    float4 Ga = float4( 0.2f, 0.2f, 0.2f, 1.0f );
    float4 color;

    float4 bumpMap = colorMap[1].Sample(colorSampler, texel.tex);

    bumpMap = (bumpMap * 2.0f) - 1.0f;

    bumpNormal = texel.norm + bumpMap.x * texel.tang + bumpMap.y * texel.binorm;

    lightIntensity = C + Ga*Ka + light[0].diffuse*Kd*saturate(dot(-light[0].dir, bumpNormal));

for (int i = 1; i < 10; i++)
    //considering we use light[i].dir as position and not direction
    pixelToLightVec = light[i].dir - texel.wPos;
    d = dot(pixelToLightVec, pixelToLightVec);

    if(d <= (light[i].range*light[i].range))

         d = sqrt(d);
         pixelToLightVec /= d;

         lightIntensity += Kd*light[i].diffuse*(saturate(dot(pixelToLightvec, bumpNormal))/max(light[i].att[0] + light[i].att[1]*d + light[i].att[2]*d*d, 1 ));

color = saturate(lightIntensity)*textureMap;
return color;

You shouldn't need to change anything this way I believe, try copy paste it and run it.

#5115306 computer pong paddle

Posted by lightxbulb on 08 December 2013 - 02:18 AM

You gotta check for collision with the upper and lower walls. So let's say the upper wall is at y=upperY and the lower wall is at y = lowerY.

You got some radius of the ball, so you would check for collisions kinda like this:

//ball.position.y is the y coord of your ball
if(ball.position.y+ball.radius > upperY )
    //Collision at (ball.position.x, upperY)
    //calculate the bounce-off - we want to "reflect the ball from the wall
    //To calculate reflection of a vector we need the normal of the wall
    // However since the wall is parallel with the Ox basis vector, the normal of the wall
    //is perpendicular to it, so for the upper wall we'll have upperNormal(0,-1)
    //where ball.direction is the directional vector of the ball:
    kFi = dot(ball.direction,upperNormal);
    ball.direction.x = ball.direction.x - 2*kFi*upperNormal.x;
    ball.direction.y = ball.direction.y - 2*kFi*upperNormal.y

//ball.position.y is the y coord of your ball
if(ball.position.y-ball.radius < lowerY )
    //Collision at (ball.position.x, lowerY)
    //calculate the bounce-off - we want to "reflect the ball from the wall
    //To calculate reflection of a vector we need the normal of the wall
    //However since the wall is parallel with the Ox basis vector, the normal of the wall
    //is perpendicular to it, so for the lower wall we'll have lowerNormal(0,1)
    //where ball.direction is the directional vector of the ball:
    kFi = dot(ball.direction,lowerNormal);
    ball.direction.x = ball.direction.x - 2*kFi*lowerNormal.x;
    ball.direction.y = ball.direction.y - 2*kFi*lowerNormal.y

//And you use the new ball direction vector to move your ball once again

It's better if your ball.direction vector is normlized - then you can do this for movement:

//Each frame(if you got a game clock it's better)
ball.position = ball.position + ball.direction*ball.speed*deltaTime;
//Where you can calculate deltaTime each frame like so(not really a great way though):
deltaTime = fps*100/6;
//fps is frames per second

P.S. If something is not clear enough, tell me what it is and I'll elaborate more on it smile.png

#5115301 Best place to learn C++

Posted by lightxbulb on 08 December 2013 - 01:45 AM

For C++(it's not that scary as most people make it sound, though it is somewhat hard in the beginning - but if you find a book that suits you it should be easy):

Things you can check when it comes to books:














#5115177 2D mouse (rotation in 3D world)

Posted by lightxbulb on 07 December 2013 - 01:45 PM


I'm sorry but I'll be blunt(take it as constructive criticism - it's what it's meant to be):

I checked your code thoroughly since I had time and let's say that I am wondering how it even manages to produce an acceptable output. It's my mistake too because I didn't really look hard enough through the last HSLS code you posted before, I did skim it and I said I thought there was something wrong with it, but I didn't think it was "that bad".

I've commented on your code - please do check my remarks - here goes nothing:

for (int i = 0; i < 10; i++) //I suppose light[0] is the directional light
        /*NO! it's light.pos-pixel.pos not light.dir-texel.pos! otherwise it doesn't make sense. point-point = vector, !vector - point = point! - we don't want this */
        lightToPixelVec[i] = light[i].dir - texel.wPos; /* and it's rather pixelToLightVec as it starts from the pixel and ends at the light if it were a vector - which it is not */

        d[i] = length(lightToPixelVec[i]); // needed for attenuation and normalization OK!, no need for an array though

        /* However you could have skipped the square root up top - you need only to check whether d[i]^2 <= light[i].range^2 - if it is not you can skip one square root, if it is you'll calculate the length after the if(){} */
        if(d[i] <= light[i].range) 
            if (i != 9) //why not the 10th light?
                finalAmbient = textureMap * light[i].ambient; /* why are you doing this at all? Physical meaning? Global ambient light? What exaclty was that multiplication supposed to be - textureMap != ambient component!!!*/

                lightToPixelVec[i] /= d[i]; // normalized OK!
               /* How come you calculate howMuchLight before you calculated the bumpNormal currently (0,0,0)? See the first time when you calculate the bumpNormal - I'll move it there */
               // float howMuchLight = saturate(dot(lightToPixelVec[i], bumpNormal)); //use saturate

                // NO! - textureMap != diffuse component!!!:
                if( howMuchLight > 0.0f )
                    finalColor += howMuchLight * textureMap * light[i].diffuse;

                    //Why multiplied and not divided!?!:
                    finalColor *= light[i].att[0] + (light[i].att[1] * d[i]) + (light[i].att[2] * (d[i]*d[i]));

                finalColor = saturate(finalColor + finalAmbient);
                //Do not modify the texture map in memory please!:
                textureMap *= float4(finalColor, textureMap.a);
                //you calculate the bump normal 9 times, even though you need it only once!
                float4 bumpMap    = colorMap[1].Sample(colorSampler, texel.tex);

                bumpMap = (bumpMap * 2.0f) - 1.0f;

                bumpNormal = texel.norm + bumpMap.x * texel.tang + bumpMap.y * texel.binorm;//bitangent not binormal

                //howMuchLight should be here(after the bumpNormal calculation - not before it):
                float howMuchLight = saturate(dot(lightToPixelVec[i], bumpNormal));
                //no need for if(howMuchLight<0.0f) when we used saturate on the dot product

                lightIntensity = saturate(dot(bumpNormal, -light[i].dir));

                color2 = saturate(lightIntensity * light[i].diffuse);

                color = saturate(color2 + light[i].ambient) * textureMap;
                //What? Seriously what?:
                isCloseEnough = true;


                //return color;
    //No! What is this? There shouldn't be such a thing:
    //What you are doing is if(isCloseEnough==false) <=> if(d[8] > light[8].range):
    if (isCloseEnough == false)
        //NO! What is this?:
        finalAmbient = textureMap * light[9].ambient; 

        lightToPixelVec[9] /= d[9];
        float howMuchLight = dot(lightToPixelVec[9], texel.norm);

        if( howMuchLight > 0.0f ) //use saturate(dot(...)) rather than if
            finalColor += howMuchLight * textureMap * light[9].diffuse;
            //Why multiplied and not divided!?!:
            finalColor *= light[9].att[0] + (light[9].att[1] * d[9]) + (light[9].att[2] * (d[9]*d[9]));
        finalColor = saturate(finalColor + finalAmbient);
        //Do not modify the texture map pls!:
        textureMap *= float4(finalColor, textureMap.a);

        //We don't need to calculate the bump normal for a 10th time!:
        float4 bumpMap    = colorMap[1].Sample(colorSampler, texel.tex);

        bumpMap = (bumpMap * 2.0f) - 1.0f;

        bumpNormal = texel.norm + bumpMap.x * texel.tang + bumpMap.y * texel.binorm;

        float lightIntensity  = saturate(dot(bumpNormal, -1.0f));
        float lightIntensity2 = saturate(dot(texel.norm, -1.0f));

        color2 = lightIntensity *  light[9].diffuse; // light[0].diffuse
        color3 = lightIntensity2 * light[9].diffuse;

        color = saturate(color2 + light[9].ambient) * textureMap;

            // color *= textureMap;


I can guess that you probably checked braynzarsoft's tutorials and it became one big mess in your head - stitching up everything together etc., so don't worry about it. Check out the code I'll post if you want.


Now here's what I'd suggest(just fix the names of the variables in your code - because I renamed a few):

/* Let Ka(ambient term), Kd(diffuse term), C(emissive lighting) be vectors with 4 components defining the material of your object ( to make the whole thing work as it is now use Ka(1,1,1,1); Kd(1,1,1,1) ; C(0,0,0,1) ); and Ga (0,0,0,0) will be a global ambient light */

/* We need to calculate the bumpNormal only once per pixel so I moved it from the for loop - there's no use calculating 10 times something you need to calculate only once */
float4 bumpMap = colorMap[1].Sample(colorSampler, texel.tex);

bumpMap = (bumpMap * 2.0f) - 1.0f;

//changed the name of texel.binorm to texel.bitang for correctness
bumpNormal = texel.norm + bumpMap.x * texel.tang + bumpMap.y * texel.bitang; /*Btw are you sure this is normalized? And is the basis norm, tang, bitang orthogonal? Does it need an orthogonalization maybe? */

/*Assuming light[0] is the directional light - let me say this now - it doesn't have a position btw
and there's no attenuation here, so we'll calculate it separately from the point lights: */

/*Lambert's reflectance model - you can easily see the dot product which we used previously multiplied by the diffuse part, we were actually using Lambert's cosine law */
float4 lightIntensity = C + Ga*Ka + light[0].ambient*Ka + light[0].diffuse*Kd*saturate(dot(-light[0].dir, bumpNormal));

for (int i = 1; i < 10; i++)
    //Renamed it pixelToLightVec btw:
    pixelToLightVec = light[i].pos - texel.wPos;
    //No need for an array of distances either, note that I calculate d^2 here
    d = dot(pixelToLightVec, pixelToLightVec);

    /* We skip a square root if here, and the normalization later, and you can even input the range of the light in range^2 so we don't have to make additional calculations*/
    if(d <= (light[i].range*light[i].range))
         d = sqrt(d);
         pixelToLightVec /= d;
         /*Here's the main attraction once again - Lamberitan reflectance model with attenuation this time around - no specular part though: */
         lightIntensity += Ka*light[i].ambient + Kd*light[i].diffuse*(saturate(dot(pixelToLightVec, bumpNormal))/max(light[i].att[0] + light[i].att[1]*d + light[i].att[2]*d*d, 1 ));

color = saturate(lightIntensity)*textureMap;
return color;

If something is not clear enough, tell me and I'll elaborate more on it.


P.S. Just to be sure - is your light direction and position transformed into homogeneous screen space coordinates?

#5114492 2D mouse (rotation in 3D world)

Posted by lightxbulb on 05 December 2013 - 12:45 AM

Actually after making even the base changes to my code you recommended. The result is Actually not bad...

Which of the changes tongue.png ?(too many I'm not sure which you are talking about)

There is still shading and It's humurosly a LOT softer.

After which change of the recommended ones? Did you remove the lightIntensity2 calculations(or is it just the ambient light fix)?


Take a look at 1. and then 2 and 3. 1 is darket then 2 or 3. the same is evident of the additonal pics posted below

Well it probably is, but It's kind hard to discern(probably the low resolution and the light's direction) - at first I thought it was darker because of the lack of msaa, but yeah I think there's a major difference since the first screens. The best way to see if it works correctly is to change the light direction kinda like rotate around the scene - it should be evident then if your shading works alright.


And after making changes to the point light algorithm.



What changes? It kidna seems you lost the attenuation somewhere. I mean it doesn't seem like your light looses its power with distance, and I think it should, as it looks too bright now. Here's what I mean - check the screens: http://imdoingitwrong.wordpress.com/2011/01/31/light-attenuation/


To your credit the bump mapped bricks are prettyier now 

Which of the suggested changes was responsible for fixing up things in this case?


However it's all a bit bright so ill see if I can make it darker.

Well try to diminish the power of the light. Basically something like this:

finalLightColor = lightColor*power // where power can be anything from 0 to 1(like 0% to 100%).

If you want to diminish the contrast between light/dark - make the difference between the ambient light color and the light color smaller, if you want higher contrast make the difference larger.


What's left to do for an even better image for now IMO, is add specular lighting, maybe change the bump mapping algorithm to a parallax mapping one or even tesselation later(tbh tesselation works faster on my PC than bump mapping in most cases - and it usually looks better, not that you should not have bump mapping/parallax mapping - it's just that there are cases you should use tessellation and cases where bump mapping would be better IMO - it's up to you to decide really which are these cases). You can try and check lightmapping.  Ah, and check sampler states etc. for DX if you can.


Here's something you might like if you make levels for your game http://www.blitzbasic.com/Products/maplet.php, the only big minus being the export formats, but I think there were some apps that can convert it to 3ds etc.


Thanks for spending the time to go through this with me. Honestly I think with some adjustments it's looking A LOT better then the initial screen shot

Well that was the goal - to make it look better. Don't worry I am kinda remembering things by the way so it's productive for me too, and I like how your project looks smile.png


Also if you would like to see my updated Shader Code I could post it.

Yeah, I think it would be pretty helpful to be able to see it.


Continue polishing that project and I think it will turn out great - it's starting to look better and better, I hope I get to see more of it happy.png


P.S. Btw I believe we have a 6-12h time difference judging by the post times xD 


P.S. You can check this for more theory(and the images will help I think) on bump mapping http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-13-normal-mapping/


P.S. It's not really important but it's not binormal - it is bitangent, you'll see some people using binormal but it's a mix-up with terms really - your triangle has 2 tangents and 1 normal (there are curves which have 2 normals and 1 tangent at some point- and there would be a binormal in that case).


P.S. I looked through your bump mapping calculations and I think they are correct. Just to be sure - here's what I think you do(if I misunderstood something feel free to correct me):

1) You write two equations for the two vectors of the triangle in both cases presented as a linear combination of the tangent and bitangent vector.

2) From there you find a matrix equation for the two vectors of the triangle(thought you didn't write it in matrix/vector form but rather you did each calculation by components), then flipping it around by taking the inverse matrix for the UV coords matrix, you find the tangent and bitangent vector.

3) After that you can build a basis in your 3d world made up of the normal vector of the triangle and the tangent and bitangent. 

4) You transform the normal vector from the normal map from the texture coordinate system to the one you just built with the tangent,bitangent and the triangle normal (you normalize a bunch of vectors too).

5) You use the new normal in the pixel shader(after world transform etc in the vertex shader) to calculate things.

It looks alright I think - it should work even without an additional dotproduct of the normal vector of each texel against the light, which leads to the question why you didn't have shading in the first screens? Maybe if you post the shader code it would become clear.


P.S. Feel free to ask any other question too btw, I really like your project so as long as I can answer the question I'll try my besthappy.png .(You know how to bind your camera to your model right?)

#5113321 Help with wait function in fps game please

Posted by lightxbulb on 30 November 2013 - 01:26 PM

I can't see the connection you made in this comment without using fps as your game clock

It's better to have a fps limiter acting as your game clock if you don't have such a clock, rather than have nothing at all. It was just an example, because I remember playing an old game of mine on a newer PC - it was a tragedy, and just because the devs didn't add something as simple as a clock or at least a fps limiter. So I think any game should have an fps limiter, they may not add a game clock, but at least an fps limiter. Basically it's a good idea to have something that goes tick-tock even if it's not really accurate - at least it would be better than nothing.

I just think that rendering shouldn't be used to manipulate logic in any way.

It's true in most cases, but sometimes you don't need to do some processes in between frames, so actually "rendering manipulating some of the game logic" may sometimes prove to be useful and can save you some processing power.

#5113318 Newbie and need help about future!

Posted by lightxbulb on 30 November 2013 - 01:15 PM

so what do you think i've to start learning video gaming development along studies or i've to wait for completing of my studies and then after learning programming languages i've to start job?

Do not wait, start now.

However it all depends on what you want to code. I believe the best way to learn is to actually do the thing you want to do. So start making games. Even if they are simple and easy ones. You'll need some experience, so do some simple games like Pong, scrollers etc. You can use some engine, you can try SDL too - it's easy to use and you're studying C++, so i don't believe you'll have much problems. Try to learn various key concepts and techniques for writing video games. For example, some day you might want to make a unit find it's path through a tiled grid, learn how to implement an A* pathfinding algorithm now rather than later. The more problems you encounter and solve, the better you'll get at what you do. Even though I would advise you to check some engines as a beginner, I would advise you against working with things as "black boxes" - I believe you need to know what you're doing even if superficially. So some physics, math, 2d/3d theory won't hurt. It's good to have at least some idea about what's going on when you do something ( example: rotate an image, draw to the screen, resolve collisions etc.)

Good luck in learning and don't give up on your dreams.

#5113203 2D mouse (rotation in 3D world)

Posted by lightxbulb on 30 November 2013 - 01:11 AM


First of all, let me say I didn't quite get what you were trying to achieve, and I believe most people won't. How does a cube "face" "north" or "northwest"? There are six different faces that can face the "given direction". So for now let's assume that you have an object that can actually "face" some direction in a single way(for example a vector). Now I am not really sure what you meat by "north" etc. when it comes to 3d space. "North", "west", "east" and "south" are used for 2d maps as far as I know, in 3d space you can have an infinite number of 2d planes, even assuming you consider only the three main planes you'll have XY, XZ, YZ. I'll assume you meant the the XZ plane as you said you wanted to rotate the cube around (it's?) Y axis. But to rotate an object only around axis, you really need either only the X or Y movement of the mouse. I'll assume however that you want both of them somehow to portray the directional vector for the object.


So if I got you right (which I am not really sure about), you want the directional vector for the cube/object("where it's facing to) to be defined from the vector from the center of the screen to your mouse coords(considering in the center of the screen the mouse coords is the pair 0,0). What I'd do in this situation is to first get my mouse pair coords (Mx, My) and then actually map it to the XZ plane(you want to rotate the cube around Y right?), so I'd get something like this for the directional vector(let's call it v2) for the object:

(Mx, 0, My) - basically the x direction will be defined by how you move your mouse from left to right and the z direction by how you move your mouse forward/backward. And I believe you should get the "mouse on positive Y axis = north" etc. behaviour you're looking for. You should of course consider the scenario when you have a directional vector pair equal to the zero vector:  Mx=My=0 => (0,0,0), then you can use some default direction for the cube.


Now, I do not know whether you have some function to align an object to a vector, but you can always calculate the needed rotation. If you have a default directional vector for the cube v1 and you have the new one v2, then you can calculate the angle of rotation around the Y axis in numerous ways, you can find the angle from the dotproduct of v1 and v2 and then define in which direction it's being rotated by looking at the vector product's direction. You can also write the coordinates of the new directional vector in polar form and then define the angle of rotation from there(you'll only need the angle for rotation around Y) etc.


Hope that helps.



I'd advise the polar coordinate conversion, I believe it will be the easiest.




Decided I won't be stingy and give the full example, after reading your post again and seeing you wanted the "formula":


If the x,y coords of your mouse in the center of the screen are not 0 you'll need to map them there.

Assuming the center of your screen has screen coords x0,y0 then to get the new coords of the mouse relative to a center scree 0,0 you'll do this:

1) Current mouse coords relative to some screen coord system not starting at the center of the screen - (mx0,my0)

2) Converting them to new coords mx,my relative to the new screen coord system (mx = mx0-x0, my= my0-y0) (you may have to do other transformation if the coord system is not witht the same handedness, however I believe that if you're using directX the screen coords start at the left top corner of the screen, so you'll need to have x0= screenWidth/2, y0= screenHeight/2).

3) Here' what you'll have for the directional vector: v2 = (mx, 0, my)

4) To find the angle based on the coordinates: YRotationAngle = atan2(my,mx).

5) Just rotate the cube by YRotationAngle on the Y axis.

#5066473 template functions and STL list.sort

Posted by lightxbulb on 31 May 2013 - 12:12 PM


With C++ I've currently gotten to the part  where I am learning different STL containers. I've been playing around with lists but I get an error, I just want to know why do I get an error when I do this:

template <typename T>
bool sortDescending(const T& in1, const T& in2)
    return in1>in2;


and then I just try to sort some list with it:



If I change my sort function it's all fine:

bool sortDescending(const int& in1, const int& in2)
    return in1>in2;



Can anybody explain why exactly C++ forbids me from writing a more generic sort function?

#5063849 else if question

Posted by lightxbulb on 22 May 2013 - 08:22 AM

Thanks guys!

I won't avoid so much organizing my program flow around return/breaks now.

I still think that this is valid:

building the logical flow in a function around returns may cause me trouble in a bigger and more complex project(I'd have a big issue if I have to find a bug and I've based the logical flow inside my functions around return type breaks). 

But I guess it really depends on what is "complex code" - this of course was a trivial example so maybe it really wouldn't hurt organizing things with return.

As you said:

this stuff comes with experience in writing code

I just don't want to end up with some bad habits/style when programming - because as I've come to see - different books/tutorials promote different style of coding and I guess it's all about getting the best out of each book/tutorial, while ignoring the "bad practices". That's why a forum as this one is especially helpful in such situations.

So thanks once again guys - I really appreciate it! smile.png