Khatharr

Looks like no one wants to touch this.

 

Maybe you should try to explain your problem more clearly. Looking at both these questions I don't really see why you're having the problems that you're having. Maybe if we knew more about your current implementation we could give some advice.

Write more code.

 

When you complete a tutorial, instead of moving on to the next one, do a project using what you've learned so far. C++ is a more complex language to deal with than Java. That's one of the reasons Java was made. You'll do better with retention if you spend more time with hands-on learning. Just mess around with it and do silly things. Only move on when you feel comfortable with what you've got so far.

Programming is about problem solving, Phil. A language is only a way to express your solutions to a specific problem. You break the overall problem into simpler segments, then repeat that process until the individual problems are simple enough to have clear solutions. You also use problem solving skills to find information and work around obstacles. There are a lot of tools available, and you can make your own tools where there are none. The tool that you need to acquaint yourself with in this case is the debugger. You can keep coming around here and asking us about things if you want, but if you rely on us too much then you're cheating yourself out of the experience of solving problems for yourself.

 

Honestly, I'm not mad at you or anything. You don't owe me anything and I'm not here to grade your performance. I just think you'd be doing yourself a favor if - when you come across some difficulty - you stop yourself and start asking more abstract questions:

• How likely is it that other people have had this kind of problem before?
• What tools are available that could help me understand this problem better?
• What are other approaches I could take that might bypass this whole problem area?
• Where could I find information about this kind of problem, or examples from other people who have solved it?
• Why is this thing happening this way and what can I do to change it?

What Trienco is saying to you is that you have this tendency to encounter a problem and just go, "What's the one-stop-shop solution to this?"

 

If you want to be a programmer then you need to start solving problems.

Sorry, I don't see any of these attempts of an "easy way out" working. Looking at this code and the breakout code, no amount of switching language, UML drawings or doing apps instead of games will allow avoiding to take a huge step back and learn some basic and fundamental programming first. That means understanding and knowing how and when to apply them, not "research" as in "I skimmed over a tutorial and compiled the code".
 
The code is an insane mess of copy/paste, arrays are used, but then stuff is just copied and hard coded for every field in the array, showing a complete lack of understanding WHY an array is used in the first place. 
 
Data that should be grouped in a class or struct is instead spread over a bunch of different arrays, functions are just doing all kinds of stuff. 
 
There's endless if/else-copy/paste replacing a simple division. 
 
Despite making the same mistake in the breakout thread, this function is again presenting an entire frame when it should just set a value (so I doubt that it was even understood what those magical D3D functions are actually doing). 
 
There is also no recognizable understanding of the difference between game logic and graphics. Graphical representation isn't the game, it's what you put ON TOP of the game, so a player can see what he's doing. The "core" of the game doesn't care about graphics, sprites, 2D/3D, keyboards or mice. Inputs are used to trigger functions of the game and graphics are used to display the state of the game.
 
You can't buy a Spanish dictionary, learn how to pronounce two or three words and then try to write an entire novel. You need to learn the grammar and rules, have a decent vocabulary and know common phrases and idioms.
 
In this case: you need to learn programming. The language here isn't C++ (or C#, Basic or any other specific language), it's basic programming concepts. Not just knowing what a loop looks like, but how to use them. Forget about GUI and 3D (or even 2D). Running requires knowing how to walk first. Otherwise you're not getting far and keep hurting yourself.
 
Planning for TicTacToe or a calculator by using ULM and flow charts is overkill. Maybe a nice practice, but if you need a flow chart to understand the game logic behind TicTacToe (of which 95% should be covered by a standard game loop), you are clearly overcomplicating a very simple thing. Frankly, at this point it seems more like avoiding the real issue rather than tackling it. Like constantly "taking a break from programming" it won't magically make you write better code.

Shhhh....

Compile it and look at the assembled function. My guess is that the second method would be slower, but only the good Lord knows what the compiler will do with it.

Stop asking homework/interview questions. At least have some sense of shame and just google the question instead of waltzing in here and asking us.

http://www.google.com/search?q=Given+two+array,1,2,3,4,5+and+2,3,1,0,5+how+to+find+out+which+number+is+not+present+in+second+array

you got it wrong,the book explained in details the effects of friend,but it appears that friend is applied in another way in a namespace

No.

A friend prototype works as a declaration in the scope of the class.

If the class is declared within a namespace then the friend function declaration is within that same namespace. It's declared at the same scope as the class. This is what the book is saying.

rip-off got it as well.

the Model-View-Controller pattern

 

This.

 

The state is only a view/controller of the model, not the model itself. To answer the examples in your question, the player's data and position, etc is stored in a separate object. The active state works by presenting all or part of that dataset to the user and by allowing the user/game-logic to alter that dataset. So when you open the map state the position information is already available in the shared dataset. When you leave the map state the information necessary to restart the gameplay state is sill available in the same dataset. When you open the menu the player stats are all in the shared dataset. The state simply renders that data in a user-readable format and reacts to the player's controls to navigate the menu options, etc.

 

An added advantage of this is that when it comes time to save or load the game, all the persistent data is in one place and can simply be serialized and dumped or loaded and deserialized.

Just pick it up when you decide to start using it. It's only an engine, not a language.

 

I'd recommend getting comfy with STL first if you're worried about your C++. Architectural patterns are the same, regardless of language, but there's bureaucracy in C++ that rivals that in Java, so be prepared for that when you start posting for code reviews.

Now here's a real brain-bender for you. Time is a fourth spatial dimension.

Not quite.

Time is orthogonal to space, and it is a valid dimension for representation purposes.

Time can be traveled. Normally we just go in a single dimension, but numerically and mentally nothing prevents us from examining past and current events or considering future events.

A game is certainly able to use in-game time as a dimension that can be traveled.

This can be an incredibly fun mechanic, as seen in games like Braid.



However, that does not make it a spatial dimension.

Time is not a spatial dimension. You cannot move an object in the spatial directions "forward, up, right, and future". That would break most of physics.

I'd argue that it wouldn't break the math. Only our understanding of it. Consider time for flatlanders. We can make a strip of 8mm film where each cell represents a single instance. If we clip them all out from the strip and lay them on top of one another in order then there's a spatial and even geometrical relationship within flatland. Their time dimension expressed in our 'extra' spatial dimension reveals this.

The only evidence we have of time being different from space is the way in which we experience time compared to the way in which we experience space. This most likely says more about us than it does about time.

Remember the twin paradox. Theoretically I can move an object forward, up, right, and future. I'd have to be really, really fast in order for it to be even slightly noticable, but it's within the realm of physics. Forward, up, right, and past would be significantly more difficult.

Set the model, set the matrix, draw, set the new matrix, draw.

Careful now...

 

 

    if(input>6) //this condition is (usually) not an effective optimization and is mathematically irrelevant
        input = input % 7;
    if(input<0)
        input = (input % 7) + 7; //this is incorrect in cases where input == n * -7

 

Try:

 

 

    input %= 7;
    if(input<0)
        input +=  7;

+1 Hodge

You don't have to do what M$ tells you.

You can also use it to bring a random int into a range:
 

int n = intrand(); //gives random value between 0 and a bajillion
n %= MY_ MAX_RAND; //brings the value into the range 0 to MY_MAX_RAND

 
The circular sequence behavior that ultramailman pointed out can be useful in many situations:

//pseudocode
int n = 0;
loop {
  n %= 5;
  print(n++);
}

0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0.....

D3DXMATRIX matRotateY, matTranslate, matWorld;

//generate the rotation
D3DXMatrixRotationY(&matRotateY, index); 

//generate the translation
D3DXMatrixTranslation(&matTranslate, x, y, z); 

//concatenate them into the world matrix - if you add scaling then it comes first (world = scale * rot * trans)
matWorld = matRotate * matTranslate;

d3ddev->SetTransform(D3DTS_WORLD, &matWorld);