Advertisement Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

650 Good

About //Lumia

  • Rank

Personal Information

  • Role
  • Interests
  1. //Lumia

    Quaternion Class Implementation

    Hi Dirk, thanks for your reply. So since quaternions are used in other game systems (e.g. physics, as stated by you) taking the shortcut route seems to be wrong. You have a good point on expecting a quaternion class to do everything that makes a quaternion (not just a unit quaternion). The only thing that seems to be worth thinking about at this point is whether one is using an existing physics library or writing it from scratch. I would expect the library to come with a quaternion implementation that suffice this specific context. My own quaternion class could be used for the graphics context. But then again mixing two quaternion classes throughout the code base for different intents is also somewhat cumbersome and worsens readability. Think I will go for a rotator class that uses quaternions under the hood as you suggested. Thanks again for the input. Very helpful.
  2. Hii, short question regarding the implementation of a quaternion class. I was wondering if quaternions are used for anything other than rotations within the graphics programming context? If this is not the case then one could take several shortcuts implementing specific functions (inverse; to matrix conversion etc.) and boost performance. So, when implementing such a class would you strive for a general purpose class or for one that deals solely with unit quaternions making shortcuts possible? Looking forward to some feedback since I can't decide which route to go down. Thanks in advance.
  3. Thank you all for your replies.       I will take a closer look at this option. Based on your link this seems to work quite good for a log system (though a pretty simple one):   Logger.h: class Logger { public: void log(const std::string& message) { // get the time etc. auto completeLogMessage = /* build one */ log_impl(completeLogMessage); } private: virtual void log_impl(const std::string& completeLogMessage) = 0; }; CommandLineLogger: class CommandLineLogger : public Logger { private: virtual void log_impl(const std::string& completeLogMessage) { std::cout << completeLogMessage << std::endl; } } It would also be possible to add a specific implementation that is logging to a database etc. which is pretty cool. This surely does not represent the full potential of this idiom but I will keep this in my mind and try to apply it when dealing with a more complex scenario.   @SeanMiddleditch: This is the way my prototype is working at the moment since I didn't trust the pimpl   @Servant of the Lord: Thanks for pointing out Qt - I will have a look at the source code so some things might get more clear when seen in production code. Based on my limited experience I would tend to not trust anyone especially after reading through some posts of the "Coding Horrors" section   @swiftcoder: Since my project is not going to be a library you might be right. But in my opinion there's nothing wrong with trying to apply some techniques primarily used for APIs to the internal stuff if it makes some things cleaner. I will see how this works out and the good thing is the project is nothing mission-critical so learning new things is what it's all about.
  4. Hi,   so recently I was starting out on a new simple project in C++ and I was thinking about an overall structure on how to organize my code in a proper way. At this point modules came to my mind. The main point here is that I don't know how to properly seperate the implementation from the interface so that no implementation details of module Y are exposed to module X that is using module Y. Unfortunately C++ does not support modules in a native way because header files do serve as a class definition and interface at the same time...   So I already read about the pimpl idiom and I can see its advantages but there are also some drawbacks in using it (e.g. dynamic memory allocation).   All this is leading to the important question(s): How do you handle this topic within your projects? Do you know some techniques beside pimpl to achieve a clean separation between the interface and the implementation? If yes, how do they work and are they field-proven? Do you know of some open source code that handles this topic quite well? (for further investigation)   Thank you in advance.
  5. Hi ArThor,   my opinion might not be the most valuable because there are much more experienced and skilled people on this forum but I was in a very similar situation trying to find a solution. So here are my 2 cents:   As I was starting to find a solution to this problem a pretty long time ago (1 year+), I was constantly browsing the web trying to gather as much information on this topic as I could. Relatively early in this process I noticed that most of the information were based more on experience than on some recipe that could be applied. This is also the reason why I would say the solution is not always in the books, regarding this topic.   Later on I stumbled upon a slideshare of Joshua Bloch stating the following: "Write to your API early and often." This is what helped me a lot.   But this statement can be expanded even more - to something like: "Let others write to your API early and often." In this way you can easily locate issues with your code design because others might not think the way you do and the code was designed for. Furthermore you can get input from someone that might use your code in the near future and you will know how he expects to interact with it. As soon as the API design is on a pretty decent level you can start implementing your code. And because the API acts as kind of a boundary, your code (the actual implementation with all its details) is forced in the right direction. Yeah, it's still possible to create a monolithic class handling all different things but it will feel wrong because you will need to work against the API.   The slideshare mentioned above can be found here: Google API Slideshare
  6. //Lumia

    Are you the "From Scratch" type?

    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?)
  7. Thank you for this great article.   Your thoughts on technical debt pretty much reflect the lousy situation that i'm experiencing right now. The project itself has deadlines from hell. This is because the executives want to satisfy the customer with no regard for anything. In such situations you are always working on the limit especially if the team isn't that large. So you are making compromises on tasks that will lead to shippable software (hopefully) with a total mess under the hood.   So here is the bad news: You know that the software is badly written at several points but the next features need to get implemented to satisfy the customer "one more time". Hence you can't do anything about the critical state of the software. Instead you're building something on top of an unstable construct - what could go wrong :-/ After several iterations of this process you will come to a point where you can't implement anything without breaking the whole thing at another part you weren't aware of.   The amount of time that is needed to "repair" this huge clusterfuck your project has become could be pretty huge. In some situations you are better off hitting the delete button and throw it all directly into the trash bin.  But if one decides to tackle the task and do a massive refactoring you are loosing time. For sure the customer won't understand why you are not able to put all his requested features into the next version anymore. Consequently there is a chance you are loosing the customer in the worst case.     Conclusion (based on my personal experience): Never let the technical debt exceed a specific limit (depends on the size of the project, team size and several other factors). Otherwise you will pay the price - and it will be expensive!     I would love to read more articles from you :) Until then i wish you all the best with your project and your family.
  8. 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.   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.
  9. 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: It looks right for testing some stuff and trying to implement a prototype using it.
  10. Thank you for your reply. The timestamp is a nice hint though - didn't think of this.     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).
  11. Hi,   i'm currently trying to gather as much information on input systems as possible. In order to this i looked up some different libraries like GLFW and SDL. While getting in touch with them, i noticed that it is required to have an instance of a window to actually gain input information from the underlaying OS via that libraries.   So here is my question(s): Would you call it a bad practice if one would try to gain input information directly from the OS even if there is no window instance? (the input system should run fine without a window to do its job) The game itself would then decide whether to handle the input event that is emited by the input system or not because it has some knowledge about the window it is running in. If the window of the game has focus then the event would be handled. If the window has no focus then the event would be consumed or whatever but not handled. If doing so - are there any pitfalls one would have to deal with while the project is growing? What are typical approaches in commercial products to do things like this?   I really appreciate any information on this subject. Thank you in advance.        
  12. 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)
  13. 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) 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.  
  14. Hi there,   if I hit the link in your initial post I am redirected to the projects page on github. There is a Readme on the lower part of the site. It says clearly that this project has external dependencies including "libcurl" and "jansson". Furthermore there are Links offered so you can go there and download the libs mentioned above: libcurl jansson So import the project and download these 2 libs. After that you have to link against them. You are doing this by changing your project properties. If you have finished this steps everything should be fine and you are ready to build the project.   I hope this helps you out.
  15. //Lumia

    conditional object creation

    Hi there,   i'm sorry for not replying until now. So there are 3 Options i can choose from: a catalog system to map the elements used in the xml to its corresponding entities reflection existing xml marshalling frameworks like JAXB   So i tried out the reflection approach during the weekend and at some point i realized that i am not able to generalize all possible entities due to the fact that a button maybe has different attributes than a label.   A catalog system seems to be a much easier way to handle this. But in my opinion there is another problem: For every entry in the catalog system, representing a special widget, there must be another dictionary that contains every possible attribut for that special widget. This can grow a lot since more and more widgets are implemented.   In the end i will try out JAXB. As far as i read through some examples its mostly based on annotations and should be working fine. So thanks to all of you for your advices, it helped me a lot.
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!