Rattenhirn

Members
  • Content count

    680
  • Joined

  • Last visited

Community Reputation

3115 Excellent

1 Follower

About Rattenhirn

  • Rank
    Advanced Member

Personal Information

  • Interests
    Programming
  1. What is with the freemium games on android?

    The best practice for this is to have a free app and then have advanced content unlockable via IAP. If you make two apps (demo & real game), any store ratings, rankings and reviews won't be shared, which can only hurt your exposure. It's also what Nintendo did with their Mario mobile game.
  2. What is with the freemium games on android?

    You are asking if a game that appeals to a wide audience and is free to play will be more likely to be successful than a game that appeals to a core audience and requires up front payment. On Android. When phrased like this, I think the answer is quite obvious. However, you are missing an important aspect: marketing. Nobody will play game number 1, or even know about it, unless it is heavily advertised and featured prominently on the Play store. I guess you don't have the money or influence to achieve either, therefor you actually have better chances with a niche game that might get a decent following through word of mouth and reviews.
  3. 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! ;)
  4. Perforce is free for up to 20 users and handles binary data very well.
  5. Color vs 1px Texture

    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.
  6.     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.
  7. 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.
  8.     As others already have explained, this is fine. Just as a comment, I use myPtr.get() instead of *myPtr for extra clarity.
  9. Getting rid of void*

    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.
  10. Unity Software to slice sprite

    Buy a license for TexturePacker, it is indeed the best tool for the job.
  11. Short question on polymorphism

    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!
  12. Why do most people recommend Python

    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! :)
  13. Why do most people recommend Python

    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.
  14. 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!