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