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!


//Lumia

Member Since 22 Dec 2012
Offline Last Active Yesterday, 01:48 PM

Posts I've Made

In Topic: Are you the "From Scratch" type?

19 June 2015 - 05:11 PM

I would say that I'm a "From Scratch" type all the way.

 

I like to have full control over the things I do. This extends to "I NEED to have full control over the things I do" if there is anything mission-critical involved. The latter is not always possible when using 3rd party code.

 

Another point that's great about writing stuff from scratch: you will learn a lot.

And that's a huge benefit in situations that might force you to decide whether to write the thing from scratch or go with an existing solution. The reason for this is that your knowledge empowers you to take several things into account that you might not really know about if you weren't writing something similar from scratch in the first place. You are even able to compare existing solutions on a more fine grained level which is always a good thing if you're trying to find something that fits your needs.

 

 

It would also be great to hear from people that were mainly using 3rd party solutions on projects that failed by doing so. (What are the reasons for this?)


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)


PARTNERS