Ansou

Members
  • Content count

    27
  • Joined

  • Last visited

Community Reputation

350 Neutral

About Ansou

  • Rank
    Member

Personal Information

  • Interests
    Design
    Programming

Social

  • Twitter
    @Ansoulom
  1. Unity I want to try Unity

    Unity is not a library, it is a full on game engine. If you're using Unity, you're playing by Unity's rules. Don't expect to have full control over it. If you want to have full control over the system, you need to use your own game engine. Obviously using a custom engine means (probably a lot) more work and losing out on a lot of convenient tools that Unity and Unreal has, but it also has some benefits.
  2. Questions about Error-Handling

    This is well covered in the error handling chapter of Bjarne Stroustrop's book The C++ Programming Language. It's a very good book and I recommend that you read it. To give a short and general answer: Use exceptions whenever an error occurs. That is, whenever something that is not supposed to happen happens. Or what Stroustrup says: When something "exceptional" occurs (something out of the ordinary, could be things other than errors). Using exceptions instead ensures that things can't be left in an invalid state and it automatically destroys every object in the same scope as the exception occurs (very good for resource managment). It also leaves you without the hassle of having to check return values all the time (this is what I don't like about programming in SDL).   So what exactly does 'reject' mean here? Just continue as if nothing wrong happened? It definitely makes sense to throw an exception in this context, unless you have a valid answer to a zero division in the same scope as it occurs in. If an error can only occur because the programmer obviously did something wrong, then yeah, using asserts instead makes sense. A good way to know how you should do error handling is to think to yourself for every error that occurs: What is supposed to happen when this error occurs? Does this function know what should happen? Should the caller of the function decide what will happen? Should the program just crash? Exceptions can't and shouldn't be used all of the time, but if the place the error occurs in doesn't know what should happen, throwing an exception is usually a good way to handle it. Also, don't use try/catch everywhere, not every exception is meant to be caught by every part of the program.
  3. This. Why does it seem like no one has even heard about std::chrono? It feels like I've been repeating myself about it in a couple of threads about time. Yeah, std::chrono::high_resolution_clock uses QPC internally to access time on newer Windows compilers at least. But the plus side is that you won't have to bother with calls to the Windows API and it's very easy to use.
  4. Yeah, considering that it's in the standard library, I would say that it's at least relevant. If it's fast and reliable... Well, it should be, but it's up to the implementation really. On newer Windows compilers, std::chrono::high_resolution_clock is using QueryPerformanceCounter to access time. AFAIK, that's what most other libraries seem to use as well, but with different resolution. std::chrono_high_resolution_clock is supposed to use the highest resolution your machine will give you, so there won't be anything more precise. The really good things about it is that it's completely portable as it's in the standard library and it makes your code look very clean.
  5. First and foremost, I would recommend using std::chrono instead of SDL_GetTicks() as it is more accurate, more portable and it's very easy to convert between different time measures (you could do a type alias for seconds: using Seconds = std::chrono::duration<double, std::ratio<1>>; and then implicitly convert to it from nanoseconds). However, SDL_GetTicks() should still be pretty reliable so it's definitely weird if it would slow down... What framerate do you mean with "very high FPS"? SDL_GetTicks() only returns milliseconds, so if your framerate is around or higher than 1000 I could imagine it being very inaccurate (std::chrono::high_resolution_clock::now returns nanoseconds or the smallest unit your computer can handle). If that is not the cause of the problem, it could be helpful to see a bit of the code that relies on SDL_GetTicks() and maybe parts of your main game loop.
  6. Timer class abstracted

    Have never used the Windows API so I can't give a helpful answer to your actual question, but is there a particular reason why you can't just use std::chrono to keep track of time? Seems like it would save you the work of making different Timer implementations for different platforms.
  7. How to start making games?!

    SDL2 is pretty nice because it provides enough functionality to do pretty much anything you will need, it gives you a lot of control over what you're doing and it's very stable. The problem is that its C syntax doesn't exactly encourage you to write clean and modern C++ code, which means you may have to abstract and make more wrappers, and it also probably has less high-level functionality than some other libs. I did try SFML once earlier and it seemed good for the most part, but because it had some small bugs that I didn't like, I decided to go with SDL2 instead. But they may have fixed those bugs by now, so it could be worth trying.
  8. Well you could always keep a raw pointer or reference to the sprite that you pass to scheduleUpdate.   Something like this: auto spaceship = sprite_sheet_->getSprite("spaceship"); //this returns a unique_ptr // code to intialize spaceship... auto& spaceshipRef = *spaceship.get(); this->addActor( std::move(spaceship) ); // "this" here is a scene this->scheduleUpdate(spaceshipRef , [&](const Actor& actor, float dt) { actor.updateShip(dt); //or whatever } ); It seems like a somewhat decent solution as long as you manage ownership correctly, although I can't say if it's the best solution or not.   We don't know exactly what the getSprite function does though, but if it's not intended to transfer ownership, then you are completely right. Interfaces shouldn't be bloated with smart pointers if the call is not about ownership. But I got the impression that jwezorek wanted the ownership to transfer into the addActor function.
  9. How to start making games?!

    As Lactose said, you really just have to decide what you want to happen in your games and make it happen. Make a basic game loop that handles game objects. Make different objects that has functions for handling logic and interaction between the objects and functions for rendering and just experiment around with making the objects behave in different ways. Start simple and then try something bigger. Once you have gotten into it a bit more, I would definitely recommend reading the book Game Programming Patterns as it can help a quite a bit with getting better structure and design of your game code, although it doesn't focus on teaching the basics of programming game behaviour. Good luck!
  10. I agree that you should keep pixels out of almost all of your code and use another unit, like meters. But to be able to upscale/downscale the images correctly when rendering, you still need to tell the game somewhere which width and height the images were made for, right? Say if a sprite is supposed to cover a meter, then you would need to have a constant or something somewhere in the code that holds how many source pixels a meter is. But for positioning, collision detection and all other game logic, you don't need to know anything about what resolution the images were designed for, you only need to know that when rendering.
  11. Some people still have only one display??   Many people have multiple displays, but isn't it pretty uncommon to play 2D games on more than one display? At least I haven't seen that much, but maybe I'm a bit behind.   EDIT: Having support for multiple displays is great if you go with the option of extending the field of view depending on resolution, but otherwise I don't see a point adjusting to multiple displays. Except for an in-game option to set which display to show the game on of course.
  12. This is a dilemma I've thought way too much about, and the problem is that there is no defined right or wrong. I'm pretty sure that 16:9 is the most common aspect ratio nowadays, so that is what I would recommend to design your game for. Also, for the game I'm currently working on, we decided to make the sprites for 4k (3840 × 2160) resolution because it might become more popular in the coming years, and downscaling usually looks better than upscaling. But if you're doing retro-style graphics, I guess it would be kinda the reversed.   Aside from black bars/frames and letting the player see a different portion of the world depending on resolution, there is also the option of stretching the image to fit the screen. If you decide to fit the game to a specific resolution, you could even let the player choose if they want black bars or stretched images in the options (would probably default to black bars).   In most cases you won't have to worry too much as most players will probably be playing on a 16:9 display and it's totally fine to assume that imo, but making the decision of ensuring that all players see the same portion or not is obvously important as it can affect gameplay (depending on the type of game).
  13. So I get that passing references to unique_ptr's isn't very good. But what about passing collections (say a vector) of unique_ptrs? If I have objects stored in a vector as smart pointers, wouldn't it be problematic to have to make a new vector with raw pointers just to pass the vector to a function?
  14. Thanks for the tips! I know absolutely no Python right now, but I guess it's almost inevitable that I would learn it someday... But I think that will have to wait a little while. We'll see what I do to actually generate the executables. I just discovered the wonderful support that Visual Studio 2017 has for CMake, although that's more fore programming rather than building. Also, out-of-source builds was apparently what I had already been doing, so I'm fine on that at least.
  15.   Sorry if I was being unclear! I never intended to actually store any of the built files on Git. My plan is to set up a batch file (or two as I guess unix needs its own version) that can easily be run to generate the exe file with CMake. The exe file will be generated inside the Git folders, but I will make sure that Git ignores all files in the build directory so it won't take up any space on the repository. Each user will have to run the batch file if they want an up-to-date build.   Regarding art assets and other binary data, I had come to the conclusion that Git could handle that fairly well with LFS. I was also thinking of just storing the work files (like .psd) in the repository and have a script generate the sprite sheets and such from them into the build directory. It just seemed like Git was the best option when I was looking at different version control systems and I would prefer to store assets at the same place as the code. Now the only problem I see with Git is that it doesn't provide file locking, which may or may not become a problem... And of course it can't merge the binary files, but that's just something we have to live with for now.