Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 18 Oct 2007
Offline Last Active Jan 25 2015 01:27 AM

#5200650 C++: Easiest way to implement an in-game Time/Date system?...

Posted by Satharis on 29 December 2014 - 03:31 PM

When comparing to the DeWitters game loop, I can see they both use an interpolation value to render in-between the actual physics states, but the main difference is the introduction of the constant dt value which is independent from the actual time between updates, that being represented by frameTime.
If I understand this correctly then the end result is that:
- Updates will happen exactly every dt mlliseconds (assuming we're using milliseconds) on average, with updates only taking place for every whole multiple of dt milliseconds. Though the real time between updates will still presumably fluctuate.
- Unexpectedly long times between frames will result in skipping render frames to catch up with more update frames, with the simulation progress between update frames being capped at a certain level, resulting in the simulation actually slowing down.
- Due to the update frequency fluctuating, interpolation is used to smooth rendering between updates (which come dt milliseconds apart on average, but aren't consistent).

The interpolation value is because if you are drawing at say, 60 FPS and only updating at 30 hz, you're drawing every ~16.6 ms and only moving things every ~33.3 ms. The point is to conceptually think of real time and game time as separate.

When you're using variable time you're literally injecting the time that passed since the last frame into the game update(at least as accurately as we can measure it.) If it took 9.12 ms then we will be telling game objects to update by that much. With a fixed time step its more like you collect time in an accumulator and the simulation consumes it when it needs to advance, if it took us 90 ms to draw then the update loop will run once, subtract the time spent(~33.3 ms) ~56.7, run the loop again, ~23.4 ms. Now we have run two simulation loops in a very small window of time but the game code jumps ahead as if it were simulating fixed sets of time.

The interpolation value comes into play because when you aren't updating, nothing in your game will move, you'll literally be drawing the same scene redundantly. In that case you might as well have the FPS locked to whatever the update rate is. We get around that problem by using interpolation, we take the previous and current position of objects and draw states inbetween, to give the illusion the game is in motion still, even though it isn't actually updating. This all happens in a millisecond window, so it is hard if not impossible for the viewer to actually understand we are a frame behind, but the smooth motion makes a very noticable impact.

I also notice the integrate() function... that's not relevant for the general case of a game loop is it? It looks to me like it's just a continuation of his article on integration that he links to at the top of the page. Considering dt is constant and he passes dt into integrate(), I assume it's just for the specific example...

He passes dt into integrate because integrate is basically pseudocode for "do a bunch of physics simulation" even if your timestep is fixed you probably want to pass time to the simulation, because if you don't then all of your code will be relying on how many times it is called rather than a value passed in, if you decide to adjust the fixed update rate of the game, suddenly everything is moving at a completely different speed or your debuff timers are counting down faster or slower than they should, quite awkward!

Passing in time is a sensible way to make it so you can change the top level code without any of the lower down code having to worry about -how- you get that time value, simply that you are getting it.

What kind of data type would be appropriate for keeping time?

In a purist sense? A 64 bit unsigned integer would probably give you the most accurate results. In practice you could use something like a double because of the extreme precision, but ideally you always want to keep your time values as accurate as you can until you use them. I.e. if you want to interpolate between two positions don't turn that time into a float value until you actually divide the two times, then you only lose precision at -one- point. Integers in general will always be superior to floating point in terms of accuracy, unless your clock is giving a float value an int value will always retain perfect accuracy, even if it doesn't match up ideally to real time.

#5200457 Is Unity good for learning?

Posted by Satharis on 28 December 2014 - 02:09 PM

Thanks for the extensive reply to both!
I have very modest goals when it comes to the game i would like to make as it's more about getting an understanding of the many aspects involved.
I'll give Unity a try, follow a few tutorials and see how it is, is there any particular Framework you'd suggest that goes well with C#? As i've mentioned i've done little work with XNA but it seems outdated these days as on their website the latest news are from 2 years ago (was it mainly for Xbox360?)
A Framework that facilitates the publishing on a given platform (prefer PC) would give me an edge as for motivation to see the project through, even if i don't end up releasing it in the end.

Not entirely sure what popular frameworks/libraries are used on C# right now, you could always go for Monogame, the cross platform port of XNA, last I checked that was still getting updated even though they discontinued XNA.

#5200354 Getting Rid of "char*"

Posted by Satharis on 27 December 2014 - 07:04 PM

You should probably read the thread, or at least my posts before writing such a long post telling me string is fine as is.
It was a proxy problem for a different problem I am having whose solution was similar.
EDIT: Good advice re: optimization however.

I've read the thread and posted in it twice already I believe and here a few days later I'm still going to tell you that you're wasting time and trying to optimize something that you clearly have no idea to optimize and there are few options actually TO optimize without losing something else like wasted memory.

If you're actually having this problem I'm gonna go ahead and bluntly say that your code is wrong, you are doing something else wrong, you could be using ten thousand strings and it is almost completely unrealistic to assume that the string class is to blame for performance problems. Plenty of AAA games/engines get away with using dynamic strings and don't have a problem. In fact I've yet to see the engine that switched to making all their strings templated or used c-style char array strings for the sake of performance, it would make code extremely un-maintainable.

String is fine as is.

#5200351 Is Unity good for learning?

Posted by Satharis on 27 December 2014 - 06:44 PM

Using an engine like Unity can teach you a bit about programming if you're a total beginner, but frankly its more designed for productivity than anything, you'll maybe learn the syntax of the language and get some work in with it, but not necessarily complex topics. You'll learn more about making games as an overall production experience than you will about coding them in particular, you'll have a lot of drag and drop where you would be coding yourself.


If you don't want to learn to make games but just to program you probably should be starting with tutorials or something and just making some simple applications, sure you can make things like console text games simply, and they test your language knowledge. That said, trying to make something like a 2d or 3d game from scratch, even with the help of a framework like XNA or even SFML or something, is extremely challenging. Frankly you'll learn a lot of stuff that won't even be remotely useful to you in a lot of programming fields, and some that will be.


Game coding in particular tends to take an amalgamation of other programming fields and shove them together to make games. We focus a lot of graphics and 2d/3d world interaction(simulation is all about this) we might end up writing GUI systems for ingame menus and user interfaces that rip the event based model right out of your standard GUI programming libraries like QT, we end up having to deal with time, on a very precise level as well as things like physics, ai, audio. A lot of that stuff isn't even remotely applicable to certain fields.


I guess what i'm trying to say is that you should be specific about what your most important goal is, making games can be fun but in general its a -lot- of work, even just making tech demos really puts your coding knowledge through the wringer sometimes, forget the people doing innovative stuff like inventing new ways of doing everything, its a challenge just to implement existing things usually.

#5200350 do most games do a lot of dynamic memory allocation?

Posted by Satharis on 27 December 2014 - 06:34 PM

Its rather hard to exclusively use the stack for everything, for example if you have even a basic kind of resource manager(especially if its loading a lot of data) it has to be able to control the lifetime of objects, even if you know the size of everything ahead of time you don't necessarily know how many of the thing you want. Anytime you're using a container class like vector even you're already working with heap memory, since vector has to be able to allocate as much space as it needs when it needs to resize.


If you talk in terms of number of objects, usually a ton of tiny objects you just create and throw away will be on the stack, a lot of things related to math in particular. Data, especially large chunks of data, are much more suitable to be stuck on the heap. I'm not sure its fair to same a game like Braid actually should be boasting that it uses a ton of dynamic memory or something, but I've watched the person you're talking about before and to be honest hes a bit of an essentric with a lot of his theories about games and programming sometimes.


In terms of AAA games and large engines you get into completely different territory, in that case the number of resources spirals to ridiculous levels really quickly so there have been a lot of novel attempts to improve CPU caching, lowering the number of allocations, etc. The problem with dynamic memory is that usually it ends up making even closely related objects be fragmented quite a bit since they'll just be pointers to some deep dark corner of RAM. Books like Game Engine Architecture list quite a few ways that engines can handle memory to make it more performant than just newing everywhere.

#5200236 Design Patterns: MVC in games question

Posted by Satharis on 27 December 2014 - 05:36 AM

Simplest way is to sit down and think about the dependencies when you write a class.


For instance you talk about AI's having to find a player. Okay that makes sense, so we have a dependency there, if the enemies in the game have to run their own ai code and decide to target the player and start moving towards him then we need to find the player. So what does that make our dependency? Well we can either give the player to the enemy, either passing it to it's update function or something. We can also pass an object like a scene to the enemy that it can query if it needs to find something like the player in the scene.


You could also do stuff like make a global or singleton that the class can query to determine the location of the player(it may search for the player or in a simplistic game it might just return you a reference to the player so you can check its position), or even pass the player object to the npc when you create it so that it can refer to the player when it needs to. There isn't a "right way" to do any of this but usually things like passing dependencies to objects(passing the player itself or the scene or something) is better for reducing coupling. Your object is essentially stating "I have a dependency, I need a player in order to do my job, so give me a way to locate him."


Delving a bit deeper into the basic theory, how you construct your game/engine will depend a lot on complexity as well, if you're making a simple 2d shooter with multiple screens maybe you'll want to have GameStates or something, maybe a GameStatePlaying for when you are actually in the combat portion of the game and a GameStateTitle for when you are on the title menu. Maybe the playing state contains the player object and a list of enemies and it can pass the player to the enemies when they do an update or some kind of ai "think" function.


The important part is there isn't one solution to what you're asking, you'd probably benefit more from just starting to code and accrueing some experience than trying to plan out everything ahead of time unless you are very experienced. There are ways to create very generic interfaces between objects in a game, ways to make things essentially "autopilot interact" where you can fire off some event script and a bunch of code runs to properly handle it and communicate between objects and states and change large parts of the game, but that all requires lots of code and lots of time. Nobody can give you some golden "Heres how a game engine should be" response, if they try to then they're just pulling wool over your eyes.

#5200234 Where To Start Programming My Game? (Visual Studio 2013)

Posted by Satharis on 27 December 2014 - 04:56 AM

Really vague and not much information here..

  • 2d or 3d game?
  • What is your goal in creating this game?
  • Do you even want to learn to code?

Unless you say your goal is to go to school and become a programmer at Valve or something most people will probably direct you to an existing engine like Unity rather than coding yourself. Or even something like game maker. If coding and making a portfolio is your desire then the response will be completely different, although learning to use an engine doesn't hurt.

#5200056 Getting Rid of "char*"

Posted by Satharis on 26 December 2014 - 07:43 AM

Part of the reason I reimplemented std::string is because I wanted to have a string class that I could use as a replacement for preallocated character arrays, with the same performance characteristics and locality of memory.
To do that I require a string which allocates memory to the stack, and to specify the amount I want I need to pass it as a template parameter.
EDIT: Also, reimplementing std::string has little extra code due to it mostly calling into the methods of my reimplemented std::vector tongue.png

So do you actually have a reason for reimplementing standard library classes or do you just assume they're more performant or something?

Very rarely(as in, AAA production) do I see someone talk about replacing something in the standard library and not actually making their code -worse-.

#5198503 Starting my own game engine - please don't laugh.

Posted by Satharis on 16 December 2014 - 04:36 AM

I see a lot of

Write games, not engines.

around here usually. A line that is both completely right and completely wrong at the same time.

If you want to learn about the bare metal of a game engine, writing a game is certainly a decent way to do it. If you think about it, having to implement a game from bare metal yourself means you'll have to face and tackle each obstacle as you go, that both makes you research each part and gives you experience.

The other part that most people don't seem to mention is that making games takes -a long time-. If anything making even a half-assed game takes quite a lot of effort, you'll end up teetering into design and art and mechanics and audio more than just focusing on code. You'll end up dinking around with data and planning things and trying to make an actual game at the expense of a LOT of your free time. Often if you want to work on a side project you have to be rather choosy about what it is, since coding is such a long term effort.

Basically I'm just throwing out there a little advice: it's awesome you want to make your own engine, but remember to take small steps! Don't try and write some convuluted resource manager or something when your engine doesn't even have an identity. I would pick a simple goal to work on, something like.. "make a simple 3d shooter where you're in a room with a paintball gun and have to fire at pop up targets," something like that. The same applies to a 2d engine really.

#5198472 0 experience in programming and game development

Posted by Satharis on 16 December 2014 - 01:27 AM

i love playing games and thats why im choosing to start in this trade

Making games is nothing like playing them.

In much the same way that designing and manufacturing a car is nothing like driving one.

Maybe that answer will hit home a little better.

Frankly you shouldn't think about going into game development unless you like some trade -related- to game development: programming, art(modeling/concept/etc), animation, audio(music or sound effects.) You have to love the profession AND games.

#5197916 C++ Number guessing

Posted by Satharis on 12 December 2014 - 09:07 PM

#include "stdafx.h"
  • You don't actually need this, and probably aren't using it. Look up precompiled headers to get an idea of what it does, this early in your coding adventures you probably don't need to bother or worry about using one.
  • Your code style so far is very much like C rather than C++, although there are quite a few differences between the languages the main one would be the concept of classes. You'll want to read up on classes at some point to get some ideas on how to format your code in a more object oriented way.
//Defining Functions
int main();
void menu();
void gamePlay();
  • A nice matter of style for code usually is to order functions by the order you expect them to be called in. Of course you can't get this perfect but usually it makes for a nicer read. For example your game starts with main at the top, then it calls menu, and finally you either get to gamePlay or end up exiting. Don't be shy about forward declaring functions just to do less typing.
int choose = 0;
int randomNumber = rand();
int tries = 10;
int guess;
  • Prefer to declare variables in the smallest scope that you use them, and right before you use them. For instance you declared all four of these as globals outside of any function, but choose belongs solely to menu and the other three belong solely to gameplay.
if (choose == 1){

  • You call gamePlay at the end of menu and then call menu again at the end of gameplay. When you make a function call the function essentially gets pushed onto a stack, you can think of a stack like one of those plate holders you see at buffets. You put a plate on it and push it down and the last one that was put on top gets removed by visitors first. Basically when you call each thing back and forth like that it will infinitely keep adding more "plates" to the stack, until it runs out of memory. In practical example this probably won't happen, the stack is rather large. But it could certainly happen if you kept doing that in the future, you always want your code to return at some point.
Anyway here is a revised version, let me know if you have any questions.

// Guessing number.cpp : Defines the entry point for the console application.
#include <ctime>
#include <iostream>
#include <string>

using namespace std;

// Functions
int main();
void Menu();
void PlayGame();

int main()
    // Seed the random number generator so we get actually random results!
    srand(static_cast<unsigned int>(time(NULL)));


    return 0;

void Menu()
    int menuChoice = 0;
    bool running = true;

    while (running)
        cout << "Guess the Number\n\n";
        cout << "-Menu-\n\n";
        cout << "1-Play\n";
        cout << "2-Exit\n\n";

        cout << "Enter your choice: ";
        cin >> menuChoice;

        cout << endl;

        if (menuChoice == 1)
        else if (menuChoice == 2)
            running = false;

void PlayGame()
    int randomNumber = rand() % 1000 + 1;
    int tries = 10;
    int guess;

    cout << "Guess the random number between 1 and 1000!\n";

    while (true)
        cout << "You have " << tries << " tries remaining\n\n";
        cout << "Enter a number: ";
        cin >> guess;

        cout << '\n';

        if (guess == randomNumber)
            cout << "Congratulations, you guessed the right number: " << randomNumber << "!";
            cout << "\n\n";

        else if (guess < randomNumber)
            cout << "That guess is too low!\n" << endl;
        else if (guess > randomNumber)
            cout << "That guess is too high!\n" << endl;

        if (tries == 0)
            cout << "Sorry, you're all out of guesses! The random number was... " << randomNumber << "!";
            cout << "\n";
As a challenge to yourself you could try expanding the game a bit, or work on a different one. I did a lot of little changes to give the game more sensible behavior. You of course don't need to copy my style, its just an alternative to give you inspiration on how you might tackle some of the problems you run into.

#5197798 Assets first?

Posted by Satharis on 12 December 2014 - 10:00 AM

Just as I don't know what goes into making a game, you most likely haven't ever messed with music beyond an iPod or calling sound files up in a program.

Yes but most people tend to still assume that something like "realistic, 3D FPS" lies on the tougher end of the game development spectrum, just like MMO. They usually just seem to assume that its like carrying water from a well to their house with an eyedropper, that if they do it long enough it will just happen.

I'm not offended, most people here probably aren't. I was just giving you a reality check, in particular the way you ended what you said with:

By the way, a huge thanks ahead of time for any advice that is formatted with an awesome can do attitude

Just struck me as like.. "Hey I want to make this hard thing, I probably won't finish it.. but yeah I'm just gonna do this hard thing because I can, and don't tell me I can't do it or imply I shouldn't be doing it." Probably just me being paranoid, but trust me I've seen my fair share of people that literally got completely offensive when someone suggested they can't make WoW after they download visual studio.

But, I wouldn't be anywhere near slightly offended if someone mentioned wanting to do it in their spare time...  I might laugh and say, "Get your checkbook ready, learn to eat Ramen Noodles, and make sure your back seat is good for sleeping."

Which is why I laughed and gave you some advice, I meant exactly what I wrote, unless you plan to become a full time game developer or something you probably will -not- benefit from learning to code a game from scratch with just a language, you'd be much better off using an engine.

The spare time I mentioned goes hand in hand with the comment about "which may never see the light of day..."

Which is why I usually tell budding developers to do the same thing I did and a lot of others did, start small, simple. Even if a game engine is completely drag and drop(like game maker or something) most people will not finish a game just because the fact is a game takes a lot of time, a lot of repetitive work, a lot of just staring at the same thing for weeks and months. Adding the frustration of having to figure out how to code it and make art and design maps and.. yeah, its a test of interest.

Which is why if you aren't even sure if you'll stick to it, you probably will not. But if you have fun dinking around with it, who cares? Go ahead and try.

#5197787 Assets first?

Posted by Satharis on 12 December 2014 - 09:20 AM

So, I'm going to do my own (which may never see the light of day - FPS, realistic, 3D, boundless maps to some extent, single player PC)

Yeah thats not going to happen, you wouldn't be the first person around here to say they want to make something fancy. People don't seem to equate game development as being the same as real work, I doubt many structural engineers get random people asking them where to start building a garage from scratch, yet we rather consistantly get people wanting to make some amazing game or an MMO.

This is a spare time kind of thing as I have other responsibilities, but I'd like to ask of y'all, "Where should I start?  Is it abnormal to start on the part that you actually know (in my case, assets.  Except I thought they were called animations, music/sounds/foleys, textures, etc...)?"

Generally for a one person project I would say getting the code going first is preferable, but it really doesn't matter either way. Everything in games in visual, even for 2d games you end up having to make lots of mock sprites(i.e. programmer art) to test how things interact.

I know your intention was to be nice but the way you word things is rather belittling about the difficulty about what you're talking about doing. If you don't know how to code and don't plan to spend the next 10 years of your life programming as a hobby or a job I would certainly not recommend trying to make a game from nothing. At the very least you'll want to use an engine like Unity.

I would give you some long master plan of things to learn but frankly the whole "I want to make..." thing is pretty commonplace, you should probably pick an engine and actually tinker with it a bit and see if you have any serious ambition of making a game.

#5197730 C++ | DirectX | Class system ?!

Posted by Satharis on 12 December 2014 - 12:58 AM

If I were to be really blunt you might do well with a bit of humility, to me reading all your posts so far most of them seem to have this air of "Well this only works this way so I can't do this thing, I know it works this way!" when in reality a lot of the things you've said so far don't even make sense.

Java has negatives over C++ yes, if you had a team of AAA developers trying to squeeze every ounce of performance out of the language than C++ is probably going to give them a much wider range of control than something like Java or C# ever would, that's why we still use C++.

But Java isn't inherently just going to give your game 12 FPS, your game probably was performing badly because it needed to be optimized or it was trying to do way too much in way the wrong ways.

I also don't really get your confusion over COM, COM is weird yes but it's really just a bunch of references to hidden internal objects somewhere. There's no "main class" your COM objects do not have to be created in a main class, main is not a class it is a free function.

Even the stuff you said about static vs objects, a lot of how that works is almost identical between C++, C# and Java. If you were abusing the heck out of new in C++ I would at least understand, but I really don't understand a lot of your issues. Most of your issues just seem to come from you not having popped open a tutorial and trying to learn C++ first before you make a game.

You should stop making so many assumptions and actually ask some questions, it would make you sound less arrogant. Not to be rude but nobody really cares if you "worked on a bunch of big projects, very experienced blah blah blah" if you clearly don't even know what you're talking about.

#5196209 First big game. Which engine and how to handle multiplayer?

Posted by Satharis on 04 December 2014 - 03:04 AM

Any evidence that supports your notion "concentrate on mobile to make money"? AFAIK, mobile space has become a highly competetitive one where even AAA games cannot ask for more than maybe 5-10$

Well for the first point, its like I said, its all about the level of entry, in terms of difficulty of making a game and getting it infront of customers mobile has significant benefits over desktop, desktop you end up with a lot of stuff like appealing to steam greenlight or trying to advertise in other ways. Steam is probably one of the best selling platforms out there, as evidenced by a lot of small developers saying sometimes 80-90% of their sales come from steam.

Unless you're targeting the casual audience most people looking for "desktop quality" games are going to look for more substance than the average phone game, 3d is usually a big draw, and people tend to be more suckered in by a promising concept than a finished game, as evidenced by how many early access games are topping the best sellers list on steam.

Flappy bird, although an extreme example of simplicity, demonstrates how simple a game can make money on mobile, the problem these days is that the market is getting flooded so that is much harder to do. The barrier for entry hasn't really changed at all, just the level of competition.

But we are talking about one game out of a billion released. Goat simulator took more than one person to build, sold as much, while being a one out of a million lucky hit maybe.... yeah, your chances are not much better, but really, game dev IS a highly competitive field, so don't expect too much either way smile.png

Well that's why I would never suggest becoming a game developer if you want to get rich, unless you aim for AAA you're probably going to be lucky to scrap together a midrange salary, and if you do land in AAA you're going to be working for that money, generally much harder than a coder or whatever other profession in different lines of work.

Labor of love.

mobile app stores are flooded to the brim with games, and income per sale is much lower. On the PC side you have to find your niche, use the Indie / Boutique game craze going on at the moment, and find the right outlet (Steam, if you can make it).... still, you could ask 5-10$ for a game that you might not get 1$ for on mobile, and still some people would pay it, if the game is good enough.

Yes games are worth less on mobile but there is also a much bigger audience and people are, quite frankly, a lot less frugal with their money when they go around seeing a bunch of one dollar games. Some people buy a pretty ridiculous amount of them and almost never play them. A lot of mobile games are taking that pay to win swing as well, free app and then milking people out of money through paywalls.

Don't get me wrong I'm not saying like, MOBILE OR DEATH, I just personally think if all you want to do is churn out games and not worry about mastering coding or something you'll probably do better financially aiming for something like that, or maybe website games.