Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 28 Sep 2007
Offline Last Active Apr 02 2015 12:05 PM

Topics I've Started

Arbitrary thruster burn solving

24 February 2015 - 11:20 AM



I am attempting to make a system where an AI unit can move itself with an arbitrary set of thrusters.  All movement in the engine my engine is controlled by the physics engine -- to move or rotate an object, a force vector must be applied on the object.


Objects have a list of Thrusters (a thruster is not necessarily a piece of hardware like on a ship -- it's just a designator for where a force can be applied relative to an object).


At the end of each frame, the net force on an object is summed up to find the net force and acceleration.


A thruster has:

x, y, z offset (in local object coordinates)

x, y, z direction (in local object coordinates)

current magnitude (in absolute force units)

maximum magnitude (in absolute force units)


Most of the code interacts with the thrusters by setting their percentage activated.


Currently I have an AI ship that can follow the player and hover, as well as keep itself level when balls are thrown at it, by firing off the correct thrusters to keep its angular and linear velocity a set amount, and its pitch a set amount.


However, I have hard-coded the thrusters to be used at this point.  But I would like to be able to have an arbitrary set of thruster objects pointing in arbitrary directions with arbitrary maximum magnitudes and the AI calculate which thrusters to fire and at what percentage to get closest to its target position, angle, linear velocity, and angular velocity, at the end of each frame.


I'm not great at math and not sure where to start with solving for the thruster percentages.  What is most confusing to me is, for example, the fact that the ship can fire off a back-right thruster, which will turn it left and also propel it forward.  


Bug in vc++ 2014 preview compiler? (std::thread)

10 January 2015 - 05:17 PM



I've recently installed the Visual Studio 2014 preview, and tested compiling my projects in it (instead of 2013).  I've started to have problems now where when making std::threads fairly often (several per second, every couple seconds, but the threads finish quickly -- on the order of milliseconds), sometimes the thread constructor does not return.  This problem occurs in both a webserver I wrote, and a game engine.  I can't replicate this problem in VS 2013, or in GCC.


I am wondering if anyone else has experienced similar issues, and if this actually is a bug in the beta 2014 compiler, or if their new implementation more likely exposes a flaw in my thread safety that by coincidence does not show up in GCC or VS2013.


The strange thing is, I've positively narrowed it down to the thread constructor not returning.  I've also verified that my I/O thread still runs correctly during this time.


Here is an example of the code creating new threads in my webserver. The line constructing the thread object named serverThread does not return -- if I pause the execution in the debugger, the thread manager shows that only two threads actually even exist -- the I/O thread, and the thread responsible for creating threads.  The actual new client handler thread doesn't even become created before it hangs.



bool Server::checkForNewConnection()
	sockaddr clientAddress;
	socklen_t clientAddressLength = sizeof(clientAddress);
	fd_set readSet;
	FD_SET(this->serverSocket, &readSet);

	//block here until a connection is found.
	const auto clientSocket = accept(this->serverSocket, &clientAddress, &clientAddressLength);

	while (threadCount > maxThreadCount)
			cout << "Waiting for available thread..." << endl;
#ifdef _WIN32
		timespec t = { 0, 16000000};
		nanosleep(&t, nullptr);


	if (printThreading)
		cout << "Thread count: " << threadCount << endl;

	if (clientSocket < 0 || clientSocket == INVALID_SOCKET)
		cout << "inv" << endl;
		return false;

	const sockaddr_in* const add2 = reinterpret_cast<sockaddr_in*>(&clientAddress);

	const string clientAddressString(inet_ntoa(add2->sin_addr));
	if (printEverything)
		cout << "Received connection from client with address " << clientAddressString << endl;
	//create a new thread to handle the client's request.
	thread serverThread(&ForkThread, this, clientSocket, clientAddressString, false);

	return true;

#define MAX_REQUEST_SIZE 16284
void ForkThread(Server* server, SOCKET clientSocket, const string& clientAddressString, bool keepAlive)
		char bufferRcv[MAX_REQUEST_SIZE];
		const auto recvLen = recv(clientSocket, bufferRcv, MAX_REQUEST_SIZE - 1, 0);
		if (printEverything)
			cout << "Accept successful from address: " << clientSocket << " with " << recvLen << " bytes." << endl;

		if (recvLen > 0)
			bufferRcv[recvLen] = '\0';
			if (printEverything)
				cout << endl << endl << endl << bufferRcv << endl << endl << endl;

			server->handleClientRequest(bufferRcv, clientSocket, clientAddressString);
	} while (keepAlive);


I made a guide on how to mod any toaster to control PC games in 3 steps.

10 January 2015 - 05:04 PM

I made a guide on how to mod any toaster to control PC games and your PC. It only takes a couple minutes, works with any toaster, and requires no engineering experience.


Confusion programming a server accepting websockets

27 June 2014 - 02:33 PM

I have written a basic HTTP server in C++ that supports regular websites, but am now trying to extend it to support websockets.  All of the networking and parsing is done by my own code, so no libraries -- except I copied and pasted some code for computing SHA1 and converting to base64.


I am reading several guides that describe how to handshake an incoming websocket connection, such as this: http://www.altdev.co/2012/01/23/writing-your-own-websocket-server/ and http://enterprisewebbook.com/ch8_websockets.html


I am stuck on the part where the server needs to take the key from the client's header and append the magic string onto it, then hash it with SHA1, encode it in base64, and send the result back as part of the accept header.


The specific part giving me trouble is the '==' in the key, and the '=' in the resulting string sent back by the server.  I can't find any information stating what to do with these -- do I drop the == from the key before appending the magic string to it, or do I keep them on?  Also, I can't figure out where the '=' at the end of the final server answer comes from -- and why the server's answer only has a single '=' and the client's key has two '='


Lastly, I am confused about why the magic string the server uses is in base16, but the key sent by the client's browser is already base64 -- do I need to convert the server string to base 64 before appending it, or does it not matter?


And when I convert to base 64, am I converting it as if each ascii symbol is the digit (so 'A' in the string would be 10), or am I converting the binary representation of the entire string to a string representing the original binary but with digits of base64?



I made a web app version of the internet.

23 June 2014 - 01:07 PM

I know everyone loves the convenience of Web Apps, but for some reason, we use a native client to browse the web.  I created a solution to this: a web app version of Chrome that runs right inside your web browser.  Now the only things you need to conveniently browse the internet is an internet connection and a web browser.


Here is a demonstration: