Khatharr

The "single exit point" restriction always bothered me. I understand that it can be confusing in a large or complex function and result in later changes being incorrect, but I think the proper solution to that is not writing overly large or complex functions. Because of this I write things like AABB checks thuswise:

 

bool checkCollide(RECT &thisRect, RECT &otherRect) {
  if(thisRect.left   > otherRect.right)  {return false;}
  if(thisRect.right  < otherRect.left)   {return false;}
  if(thisRect.top    > otherRect.bottom) {return false;}
  if(thisRect.bottom < otherRect.top)    {return false;}
  return true;
}

It's true that you have to engage your brain for a moment to see that it works, but that's true for other solutions as well. This way is compact and straightforward. Once you understand the method, any potential errors are immediately visible.

This code is just in response to what you asked me about. There's still problems here that other people have touched on. Additionally, your render code seems too close to your logic. You should try to separate these into different sections unless the program structure is exceedingly simplistic.

const int MOVE_DIST = 42;
const int BOUNDARY_MIN = 0;
const int BOUNDARY_MAX = 378;

//Handle movement (see other people's comments about testing against SDLK_ constants)
if(SDLK_UP)    {PlayerLocationy -= MOVE_DIST;}
if(SDLK_DOWN)  {PlayerLocationy += MOVE_DIST;}
if(SDLK_LEFT)  {PlayerLocationx -= MOVE_DIST;}
if(SDLK_RIGHT) {PlayerLocationx += MOVE_DIST;}

//Correct out-of-bounds condition
Message = NULL;
if(PlayerLocationy < BOUNDARY_MIN) {
  Message = DeniedMessage;
  PlayerLocationy = BOUNDARY_MIN;
}
if(PlayerLocationy > BOUNDARY_MAX) {
  Message = DeniedMessage;
  PlayerLocationy = BOUNDARY_MAX;
}
if(PlayerLocationx < BOUNDARY_MIN) {
  Message = DeniedMessage;
  PlayerLocationx = BOUNDARY_MIN;
}
if(PlayerLocationy > BOUNDARY_MAX) {
  Message = DeniedMessage;
  PlayerLocationx = BOUNDARY_MAX;
}

//Render
if(Message != NULL) {
  int mess_x = (ScreenWidth - Message->w) / 2;
  //This next line is not clear. Get rid of the magic number and clarify order of operations
  int mess_y = (ScreenHeight - Message->h + 420) / 2;

  ApplySurface(mess_x,mess_y,Message,Screen,NULL);

  Message = NULL;
}
else {
  ApplySurface(0,421,Sprites,Screen,&TextBox);
}

 
The key here is that the things you're likely to change are easy to change and it's clear what's going on. You can change the constants at the top or the render stuff at the bottom and not have to worry about changing it all 4 times. The organization and alignment of the first set of tests also makes it easier to spot if there's any errors lurking there, such as having PlayerLocationy where there should be a PlayerLocationx, or a - where there should be a +.

I think you're going to save yourself a lot of time, now and in the future, if you immediately remove all the repetition here. As it is, any change you make to the core routine here has to be made 4 times, and that means 4 times the probability that you'll make another mistake.
 
DRY

Have a separate distro for each platform?

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.