• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Rattenhirn

Members
  • Content count

    678
  • Joined

  • Last visited

Community Reputation

3114 Excellent

About Rattenhirn

  • Rank
    Advanced Member
  1. I don't know anything about the PS4 pro's checkerboard upscaling, but I think it is highly unlikely that image quality would be improved by connecting a higher res display. Checkerboard upscaling might look better than regular upscaling, I believe that. Using checkerboard upscaling combined with downscaling might improve AA on low res displays, but then they would be doing that already. Get a cool soundsystem! ;)
  2. Perforce is free for up to 20 users and handles binary data very well.
  3. In principle, avoiding the texture would be better. In practice it will not make a difference, because all shaders have a certain minimum execution time, based on the length of the execution pipeline of the GPU. I personally don't use a texture for drawing solid color objects.
  4.     I have used many build systems and tools based on cygwin in my career and it has always been an unpleasant experience. I'd rather cobble together an arcane cmd batch script than enter the world of cygwin.   However, with the Win10 anniversary update, MS has added bash on Windows (turn in on in "Optional Features") which seems to work great and almost seamlessly, despite being a beta version. It basically gives you a familiar debian/ubuntu based CLI and has managed to run everything I have thrown at it so far, with the exception of "screen". Another caveat is, that integrating "bash.exe" with other script is made a lot harder by the fact that "bash.exe"'s stdout and stderr can't be redirected. This can be worked around, but it is an annoyance and will hopefully be fixed.
  5. The most complex part of a humanoid are usually the shoulders, which has is evident by the use of HUGE shoulder armour pieces to mask any problems there. Equally or more difficult  would probably be the hip / thigh area, however most games get away with a small range of motions there (walking, running, jumping). But when your character is supposed to do Yoga poses, then these areas will become critical.
  6.     As others already have explained, this is fine. Just as a comment, I use myPtr.get() instead of *myPtr for extra clarity.
  7. As others have already stated, std::function is a good solution. But beware if you ever want to implement a remove listener method, because std::function cannot compared to each other. In that case you'll need to resort to some c-style trickery again.
  8. Unity

    Buy a license for TexturePacker, it is indeed the best tool for the job.
  9. In fact, in you example you could get rid of the base class entirely and gain expressiveness and performance.   Polymorphism and inheritence are powerful tools that should be used only when absolutely necessary. If things have a relationship in real life that can be modelled with inheritence is no reason to do it. Only do it if you want classes to be accessed via a common interface AND having it callable without exposing the actual classes. Good examples of this are actually pretty rare!
  10. C++ is also great and definitely super useful. There are also loads of resources out there, but it has no real recommended best way of doing things. It's a multi paradigm language, where as most try to stick to a certain paradigm like OOP, functional, prototype based, purely procedural, ... Different resources will constantly contradict each other. This is not a bad thing (in fact, I think it is a good thing), but it can be very confusing to beginners and adepts alike.   But ultimately it's up to you. No language will  make learning to program super easy, because it is hard and takes more than a lifetime to master. All the starting language can do is to move common pitfalls that cause frustration when learning out of the way. Even if a language manages to hide a certain complex topic away really way, at some point you'll need to tackle this topic. There's no escape, all abstractions are leaky! :)
  11. People recommend Python because they hear other people recommend Python.   It's not a bad choice and it's available for free on pretty much every platform and there are tons of resources available. I don't think closeness to spoken language is a good thing, it just leads to more confusion. Otherwise, everyone would recommend COBOL. :)   Personally, I prefer strongly typed languages and would recommend starting with C for system level programming or C# for application level programming. They are also available for free on pretty much every platform and there are also tons of resources available.   I would not recommend Swift. It is not very well established and is still changing rapidly. It is really only useful in an Apple environment, and Apple wants to move its users as far away as possible from mainstream technology to keep their scent of exclusivity. Also, since it is still relatively new and not widespread at all, the number of resources at ones disposal are also limited.   However, as you correctly pointed out, ultimately all programming languages uses similar context, because they are abstractions of how computers work. So, if a language teaches you programming concepts and how computers work, it will be fine.
  12. I think the fundamental confusion for you here is, that in C++ there's a difference between these two cases: Case 1: MyClass myObject = MyClass(12345); // calls the MyClass constructor Case 2: MyClass myObject; // calls the MyClass default constructor myObject = MyClass(12345); // creates a temporary MyClass object, copies it into myObject and destroys the temporary again   When you write a constructor that initializes members in the body and not in the initializer list, like you did in MainMenuState, you have Case 2. Besides being a bit inefficient this usually is no problem, unless MyClass cannot be copied safely, as is the case with sf::Texture.   For this reason, I discourage the use of the "initialization written as assignment" notation, so this situation can never arise: Case 1: MyClass myObject(12345); // calls the MyClass constructor Case 2: MyClass myObject; // calls the MyClass default constructor myObject(12345); // compile error!   In additon the NonCopyable idiom I referred to earlier should be used to make it impossible to unintentionally copy objects of classes that can't be copied safely.   Here's a longer example illustration the issue, I've written and tested it here, so you can just paste and run it. #include <iostream> using namespace std; class InternalTexture { public: InternalTexture() : data(123456) { } int data; }; class Texture { public: Texture() : internal(new InternalTexture()) { cout << "Texture::ctor" << endl; } ~Texture() { cout << "Texture::dtor" << endl; delete internal; } InternalTexture* internal; }; class Sprite { public: Sprite() { texture = Texture(); } Texture texture; }; int main() { // Case 1: { cout << "Texture only:" << endl; Texture texture = Texture(); cout << "texture.internal = " << texture.internal->data << endl; } // Case 2: { cout << "Texture in sprite:" << endl; Sprite sprite; cout << "sprite.texture.internal = " << sprite.texture.internal->data << endl; // crash in Texture::dtor } return 0; } InternalTexture can't be copied safely, so Case 2 will fail. This is what I think happens inside sf::Texture, although the implementation there is more sophisticated as it knows that it refers to an invalid "InternalTexture" and handles it by that dreaded white square.   You can try to fix Case 2 be doing one or more of these: 1) Fix "Texture", by correctly applying the "rule of 3" (look it up) and implementing copy constructor and copy assignment operator 2) Fix "Texture" by making it "uncopyable" by making copy constructor and copy assignment operator private (NonCopyable idiom) 3) Fix "Sprite" by correctly using initializer lists to initialize its members. Note that Sprite would need to be fixed by applying 1 or 2 as well. 4) Make everything way more complicated (and fun!) by learning about C++ 11 move semantics   I hope that helps!
  13. The code looks complete now and you replaced inheritance with composition, great!   What struck me when reading it is, that you copy the Sprite once in the GameObject constructor. Here you should really use initialization lists when initializing members in a constructor, and that might also be the cause of the issue.   Here's how to initialize a member without making an extra copy: GameObject::GameObject(std::string m_texturePath, float m_x, float m_y) : _sprite(m_texturePath, m_x, m_y); { } I don't know much about SFML, so I took a quick peek at the documentation. Google took me here: http://www.sfml-dev.org/tutorials/2.0/graphics-sprite.php   Curiously it has a section talking about the "white rectangle problem", which tells you that you have to manage the lifetime of sf::Texture instances very carefully. That's not very beginner friendly, but I'm sure they had their reasons. Unfortunately it seems that they didn't put any measures in place to stop people from committing this mistake.   So, given the fact that you (probably unintentional) copy both the sprite and the texture around, it is unlikely that their internal state is still consistent. The above code snippet should fix that.   Bonus info: If you have a class that can't be copied safely, like your Sprite class, you can emply the non copyable idiom to get the compiler to tell you if you do it by mistake: https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-copyable_Mixin   I hope that helps!
  14. Let my start of by concurring with the previous posters about your apparent architectural choices.   Now on to the thing you actually asked about. Unfortunately, the code you provided is incomplete and misses details needed to accurately diagnose the problem.   A stab in the dark: The constructor sets the position of the sprite, the Create method does not. I can't determine what the default position is, but it might just be off screen...   Some questions that might help with the diagnosis (if you don't want to post all the relevant source code): Where is "_created" initialized? How is the GameObject you call Create on created? Does GameObject have a default constructor? What does it do?   Some general hints: Pass non trivial objects like std::string by const reference and not by value. Checking m_x and m_y for NULL seems confusing. It's will just check if their value is equal to 0.0f.   I hope that helps!