If you're using a game engine then forget it. If you're making your own, then the only thing you really need to know is variable timestep and building your physics based on it. It allows your framerate to be adjusted to any number, and the game will work at a consistent speed regardless of framerate changes or fluctuations.

There's other things that probably aren't very surprising; make sure controller input gets accounted in the game logic as soon as you can make it (e.g. at the start of the current frame, not at the end). Make sure that it's possible to press a button multiple times in a single frame without it being interpreted as 1 press, and make sure you can press and release a button inbetween a single frame without that press being skipped. Never ever use vertical sync, or any kind of effects/techniques that require you to delay frames or the game tick.

In regard to opimization, it probably doesn't matter because the chances you'll build something that modern computers struggle to handle isn't very high. But if you want to be sure, just get into the habit of building things with "data-oriented design" in mind. Basically be wary of object oriented techniques (it's not all bad but most of it is), avoid RAII, never ever use a linked list, any data structure in a list that needs to be looped through very fast should be as small as possible...

>>77
>If you're using a game engine then forget it.
Nah, I want to learn to hows and whys, besides, I find prebuilt game engines to miss the point, since you're basically not using 99% of what they offer you just waste resources.
>variable timestep and building your physics based on it. It allows your framerate to be adjusted to any number, and the game will work at a consistent speed regardless of framerate changes or fluctuations.
I didn't know that! Thanks!
>make sure controller input gets accounted in the game logic as soon as you can make it (e.g. at the start of the current frame, not at the end).
Wouldn't it make it so that, were lag to happen, you could get double inputs or even eaten ones?
>"data-oriented design" in mind.
Good to know.
>any data structure in a list that needs to be looped through very fast should be as small as possible...
One way I wanted to try and see if it made anything faster was to assign different statuses to just one byte of information and then test it using a mask rather than just checking individual attributes, I know it's bad for updates but still.

Thanks a lot for your input, if you've got anything else, I'm all ears.

>In arcades most of them use CRT displays something that is lacking in modern games and arcade machines, CRTs are extremely fast and display the image and it turns to 'black' right after the image is displayed. LCD screens 'sample and hold' the image leading to your eyes perceiving the images as motion blur.
>Black Frame Insertion renders the game in 120hz but for every 2nd frame is a black image, this is used on LCD Screens to emulate how CRT display images and remove that 'motion blur' effect.
>Overdrive on LCD Screens try to predict the brightness of the next frame, on most monitors they may 'overshoot' and have this weird color fringing effect almost like chromatic aberration.
>Dealing with frame stutters even at rock solid 60fps due to drivers, sync with the display and other gay shit (hard to solve with the tools you have at the moment, see related link for good info: https://medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92)
>Abuse L1 & L2 Caches for optimization and do not ever read multi-dimensional arrays from 'left' to 'right' then 'top' to 'bottom', caching information is essential. Take the data-oriented design pill.

>>80
>Take the data-oriented design pill.
/throd.
http://gameprogrammingpatterns.com/data-locality.html

>>81
Isn't Civ IV developed via a data-oriented design? I recall their devs talking about it and how it allowed people to easily mod shit in and out of the game.
>>80
Thanks lad

>>82 They were probably talking about data-driven design, where your gameobjects, particle effects etc., are defined by some kind of text file, JSON or something, then read in by the game engine to construct the actual gameobjects.

>>121 Not sure if that's DDD. DDD from what I understand is a method is used to layout the whole project. Pretty much as high level as possible. It can be pretty much summarized by the quote from the 90s "Write programs that do one thing and do it well.", but made into an entire concept for pajeets and managers.

>>122 >but made into an entire concept for pajeets and managers. nah, it's easy to mix up the component design pattern applied by unity and DDD. A game built around DDD will generally have a bunch of component which are absolute barebone member variable of a struct. Then you'll have entities which are just container of component. Then there's the system, which handle entities. Instead of calling the update() function in every single entity, you call the system's update() which is one function call instead 150 update() of 150 game object. In this context you separate the data from the logic entirely. It's extremly efficient for RTS. DDD is the first article of the first section of game programming gems 1: The magic of Data-Driven Design. It's usually harder to work with, but It's fun to work with because if you push the idea to the limit, even the number of team can be written in a text file.