Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


//Lumia

Member Since 22 Dec 2012
Offline Last Active Dec 12 2014 04:49 PM

Posts I've Made

In Topic: Gathering information on input systems

04 February 2014 - 04:00 PM

It depends on where you draw the border. I've running a thread to gather input, to translate it from OS to engine events, and push them into a queue. The thread that runs the game loop reads the queue when the InputServices is updated. This services instance has the ability to plug-in input listeners, so to say. Entity components like the PlayerController puts to use this, as well as sub-systems can do so. E.g. the Graphics sub-system can install an input listener to get window size changes. And the loop itself could install a listener to detect quit conditions if wanted so, or even better the GameServices instance should do so.

Yeah that's right.

The procedure that you've explained will get important right after the input has been gathered in a raw state.

Nevertheless i would separate the window input and the usual game input. A very raw sketch of my thoughts to this is attached to this post.

The "IOHandler" will be the entry point to the system. One can't dive deeper into it to keep it as high level as possible. So in order to this, you need to register or deregister listener right there.

 

 

Btw if you want multi-platform in input, you are going to have to write platform specific code, dealing with hardware devices is pretty hardwired into the platforms. Even between console generations of the same manufacturer this is different. The only other way out is writing your own HID interface but even then you run into platform differences, when dealing with hardware on different OSes sadly you will always have to write platform specific code.
 

I guess you are right.

One way would be to implement a high-level api that uses low-level stuff depending on the platform that you're using. So you have to deal with platform specific stuff just at a single point in the low-level part (Please correct me if i'm wrong).

For sure it's sad to see everything being high-end and then one is struggling when implementing an input system caused by platform specific "standards".

 

But libusbx needs a chance. Even if it's just for the sake of learning something new i'll go to try it out.

Thanks for the feedback so far.


In Topic: Gathering information on input systems

04 February 2014 - 01:51 PM

Hi NightCreature83,

 

thank you for your reply.

Your offered links are pretty interesting and cover a lot of things i was thinking about.

Unfortunately it is based on Windows and i want the input system to be running on other platforms as Linux and Mac as well (sry, i didn't mention this in my initial post).

So in order to this there is a need for some standard that needs to be supported by all of these platforms and USB seems to get it right (on a low level).

 

While looking for some HID APIs, i came across the following one:

http://libusbx.org/

It looks right for testing some stuff and trying to implement a prototype using it.


In Topic: Gathering information on input systems

04 February 2014 - 12:06 PM

Thank you for your reply.

The timestamp is a nice hint though - didn't think of this.

 

Some events you need to get are actually bound to a window, like window resizing and closing. Such event must not be ignored when running in windowed mode, of course.

 

That is quite true, but this is exactly the point that i want to avoid.

Events related to a window should be handled by a window handler or a similar instance because that isn't input that will affect the behavior of entities within the game (like a player that is moving). Ok, if you're closing the window, then the game is affected but i think this would also be part of the window handler. This instance has to make sure that this kind of event is propagated to a kind of main system that is able to shutdown all parts of an engine, or a game in more general.

 

So this is why i found it pretty awkward that a window instance is required to handle game related input. But maybe its just me thinking in a wrong direction.

But i will definitely have a look on a HID API and try to implement a prototype of my input system using it (Sending information to a USB device, like ForceFeedbackInformation seems to be an advantage over other libraries, like the ones mentioned in my initial post).


In Topic: Accessing base class functions

16 January 2014 - 04:01 PM

Hi,

 

I'm actually not sure if C# provides namespaces because there should be packages. But they are aiming at the same goal anyway.

So if you are working with a base class from another namespace make sure to "mark" this in your code as well.

Here is a short example:

#include <iostream>

namespace cars {
class Car {
public:
	void move() {
		std::cout << "The CAR is moving" << std::endl;
	}
};
};

class Audi:public cars::Car {
public:
	void someFunction() {
		move();
		cars::Car::move();
	}

	void move() {
		std::cout << "The Audi is moving" << std::endl;
	}
};


int main(int argc, char* argv[]) {

	Audi audi = Audi();
	audi.someFunction();

	return 0;
}

The Code above results in:

The Audi is moving.

The CAR is moving.

 

But as long as you're not overwriting the base-class method it should be called anyway because you derived from that class.

#include <iostream>

namespace cars {
class Car {
public:
	void move() {
		std::cout << "The CAR is moving" << std::endl;
	}
};
};

class Audi:public cars::Car {
public:
	void someFunction() {
		move();
		cars::Car::move();
	}
};


int main(int argc, char* argv[]) {

	Audi audi = Audi();
	audi.someFunction();

	return 0;
}

This code results in:

The CAR is moving,

The CAR is moving.

 

In addition to that i think that this is a bad code practice. Please correct me if i'm wrong but i can't figure out a situation that forces me to do things like that (I'm either overwriting the method or using the derived one)


In Topic: Can someone make this VS 2010?

19 December 2013 - 03:37 PM

Hi again,

 

my suspicion is that you are not compiling the code with the MinGW compiler as mentioned in the Readme of the repository.

If so then the built-in VS compiler will try to do the job.

Referring to this Thread (sorry for cross-site linking) http://stackoverflow.com/questions/8525470/porting-c-compilation-from-mingw-to-visualstudionmake there can be several situations that are not covered in the standard or differ depending on the standard that is used.

 

So if you aren't compiling with MinGW as it is recommended please get active and do so.

You can ignore my post if you're already using MinGW.

 


PARTNERS