Jump to content

  • Log In with Google      Sign In   
  • Create Account


Trienco

Member Since 22 Aug 2001
Offline Last Active Yesterday, 09:31 PM
-----

#5010079 Bullet animation

Posted by Trienco on 12 December 2012 - 11:34 PM

4) The method Xaer0 suggested may move the bullet several pixels at each time the formula is executed, which may lead the bullet to bypass something it shouldn't (such as a wall). The method that I suggested will give the bullet trajectory, pixel by pixel.


This might be a good place to point out that if you do collision detection in "pixel space", you are doing it wrong and should have a close look at why proper collision detection is very different from "checking for intersections every frame". After that you will realize why brute forcing collision detection by moving stuff in a painful pixel by pixel fashion to check every single one along the way is getting you down voted.

Sorry, but every time someone is throwing trigonometry at trivial problems it's making me cry.


#5009334 Crash in std::set::insert()

Posted by Trienco on 10 December 2012 - 11:24 PM

Now I completely solved the problem.
I have no idea why the crash occurred.


Not to rain on your parade, but those two statements are usually mutually exclusive.


#5008988 2D Platformer - Shooting in the direction of the mouse cursor

Posted by Trienco on 09 December 2012 - 11:08 PM

Not sure why anyone would want to deal with angles, when your problem sounds like all you want is "mousePosition - shooterPosition". If all throws are supposed to be equally strong, normalize and multiply with appropriate value. Otherwise just multiply with appropriate factor (and maybe clamp). However if distance to player decides initial speed, it makes aiming weak throws more difficult.


#5008397 Transferring from java to c++

Posted by Trienco on 08 December 2012 - 12:26 AM

Neither is going to help you learn C++, especially since both are pure C APIs. You might be better off trying to use C++11 features or boost. While it's not a big difference, SFML might be a better choice than SDL in that regard as well.


#5006977 C Do/While Loop problem

Posted by Trienco on 03 December 2012 - 11:37 PM

Result being uninitialized and as such potentially x, not even entering the loop is exactly the kind of bug I love so much. "We have a few customers reporting a really weird bug, but we are completely unable to reproduce it and have now wasted several weeks running test scenarios on a bunch of machines and staring at many thousands lines of related and semi-related code to figure it out. Turns out somebody ignored #1 in the coding guidelines: ALWAYS immediately initialize your variables and never justify laziness with 'better performance'."

So if x is unknown, you would have to initialized with something like "result = x+1" to be safe, resulting in awkward code that is more confusing than it has to be..


#5005961 Is C++ too complex?

Posted by Trienco on 01 December 2012 - 01:10 AM

I am still of the opinion that exceptions are too costly to use for anything but exceptional situations.


To be fair, that's why they are called "exceptions" and not "common stuff happening" or "code flow control construct". As such you could easily argue that someone using exceptions for situations that aren't actually "exceptional" errors is probably using them wrong.

vector::at throwing at an invalid index is fine (it IS kind of a big screw up), std::find throwing if an element isn't found would be silly (as it's a perfectly expected case). Which leads to a nice anti-pattern called "expectation handling".

c++ is not too complex, just you need some dedication and you can easily learn the c++...
first try to learn c it will help you in learning c++ easily and in efficient manner..

dynamicmounting.com


Strangely enough, everytime I hear someone claim "C++ is easy" it is accompanied by "C with classes" and the person in question not even knowing enough about C++ and its countless dark corners to realize just how little he/she actually knows.


#5004115 Code::Blocks "warning: deprecated conversion from string constant to ‘ch...

Posted by Trienco on 25 November 2012 - 11:24 PM

I use tolua++ to generate Lua bindings and unfortunately, as it currently stands, the generated binding code is filled to the brim with these warnings.


Maybe I'm confused by the name, but ++ suggests that it creates bindings for C++. Everything producing "char*" instead of "const char*" (unless the function might actually modify the string) should be considered flat out broken and worthy of a bug report. Mostly because I'm extremely sick of having to add hacks and workarounds when using C++ strings and c_str. Casting away the const feels like slapping a time bomb and copying the string to a vector<char> is just irritating.


#5003384 [C++] Delayed action of srand() - coordinates for object

Posted by Trienco on 22 November 2012 - 11:27 PM

Well, L.Spiro has a version that will at least trigger at all (when one coordinate is getting close enough), while the other version looks like in the end the ball will reach one coordinate first, then start jittering around on one axis, move only along the other axis and finally find a new destination. It also means that if one coordinate is reached, the balls will effectively move at only half the speed.

So obviously I second the approach of using vectors, simply because the other code only allows for 45° steps in motion and I doubt that sudden changes of direction while heading towards a destination are intended.


#5001444 Completed Tic Tac Toe - Critical Critiques and Advice

Posted by Trienco on 15 November 2012 - 11:18 PM

I think you will get the most in terms of learning experience and better design by not assuming a fixed board size and hard coding every possible win condition. After all, the real core of programming isn't knowing language X or memorizing whole libraries, but about problem solving.

How would you write it, if the board size can be configured to 4 or 5? Ironically, you should find that your code will get a lot shorter, cleaner and contain way fewer messy if-else and switch-case constructs.

Once that is working, how would you handle the win condition not being n in a row (where n equals the board size), but a value that can be configured independently? You should find this to be a very small adjustment to your existing code (okay, I'm lying, unless you didn't realize that only two diagonals need to be checked for n = board size).

What if the board doesn't have to be square? Again, this should end up being only a minor change.


#5000465 Switch vs if else

Posted by Trienco on 12 November 2012 - 10:59 PM

That's a bit too general, don't you think? Without using switch or a bunch if-else statements, what does an event dispatcher look like? How do you implement a factory function?


Event dispatchers can use runtime type information or simply strings and just forward events to all handlers that registered themselves for certain message types. I'd actually be a bit sceptical if my event dispatcher starts switch/casing over event types. Same for a factory. A factory using a big switch/case is usually considered the "naive" approach and while typically good enough, it's probably the least desirable implementation. Generally you do not want to touch your factory (or event dispatcher) every single time a new class/message is added.


#4997877 C++ pointer strangeness

Posted by Trienco on 05 November 2012 - 11:31 PM

Of course reversing a string in C++ is kind of boring:

string original("some text");
string reversed(original.rbegin(), original.rend());


It also avoids all the other bugs and issues in the C-style implementation above (loop too short, calling strlen on every single iteration, passing pointer by value, the dreadful "function internally allocating memory" thing).


#4997443 Error accessing vector member

Posted by Trienco on 04 November 2012 - 11:21 PM

Of course now you have to ask yourself who is responsible for cleaning it up and when should that happen. Rule of thumb: for every "new" that isn't assigned to a smart pointer, there must be one (and only one) "delete".


#4996096 Manual construction and destruction

Posted by Trienco on 31 October 2012 - 11:55 PM

//Delete old location (without destructing).
delete memoryA; //How's it know how much memory to delete? Do I need to cast back to void* before calling delete?


If you want to know that in detail, try showing the memory right before your allocated chunk. Chances are your compiler placed all the memory management info right there.

An easier answer: in the same way free knows how much memory to free when pointed at malloc'd memory.


#4988956 A strange issue with the scope of the << operator

Posted by Trienco on 10 October 2012 - 10:40 PM

If in doubt, never rely on expressions to be evaluated in any particular order (this behavior can change even between debug and release builds).

Notable exceptions: logical operators (&&, ||) and the comma operator (the operator, not just any comma like in parameter lists)


#4985281 tictactoe

Posted by Trienco on 30 September 2012 - 01:24 AM

This piece of code: "rand() % 9 + 1"generates a number between 1 and 10. In C++, arrays begin at 0, so you may not want the +1 there.
(An array with 10 elements, goes from 0 to 9)


Nitpick: the number will be between 1 and 9.

About the implementation of the second option. You actually fooled me, as my first impression was you determine a number between 0 and emptySpaces, then make as many steps from the start (skipping filled spots). In that case you should never have to wrap around. But with your approach of starting at the selected spot and then skipping ahead until the first free cell, is the first part even necessary (as in: does it produce better randomized results)?

My impression would be that it might make it less random. If the first 4 spots are filled, you would ways end up with the 5th spot: 5 spots are empty, so spot = rand() % 5 = 0-4. In each case you get spot = 4.

So I think you should either always create numbers 0-8 and skip empty spots as above, or if you do create a number using only the free spots, it would probably be something like this:

int steps = rand() % numberOfEmptySpaces;
int spot = -1;

while (steps >= 0)
{
	//If free, decrease step count
	if (board[spot] != 'O' && board[spot] != 'X')
	{
		 --steps;
	}
	++spot;
}

place_marker(spot);

I believe that should create an equal probability for each spot.

Alternatively (and somewhat more cumbersome) you could add an extra layer of indirection by keeping a list of empty spots and randomly picking an index from that list.

   //Declared somewhere and initialized with the board
   vector<int> freeSpots; //Fill with 0 - sizeOfBoard


   const int idx = rand() % freeSpots.size();
   place_marker(freeSpots[idx]);

   freeSpots.erase(freeSpots.begin() + idx);

Since erasing from anywhere but the end of a vector requires moving stuff in memory, a common method is to not remove a value, but swap it with the end and reducing the size of the vector.

swap(freeSpots[idx], freeSpots[freeSpots.size()-1]);
freeSpots.pop_back();

By not removing the last element and instead keeping track of the size yourself, you can keep reusing the same vector and just need to reset the size

vector<int> freeSpots(SIZE_OF_BOARD); //Initialize once when starting up


//When placing a marker
swap(freeSpots[idx], freeSpots[--numberOfFreeSpots]);

//When resetting the game
numberOfFreeSpots = SIZE_OF_BOARD;

Since all random numbers should be equally likely, it doesn't matter in which order the numbers are stored in freeSpots.

Personally I like this approach for simulating a deck of cards, as you don't need to do any initial "shuffling".




PARTNERS