How does a game run in Windows?

[fredreload]

I'm curious as to know how a game runs in Windows, does it goes into DOS mode? If the game is 60GB after installation does the game use all of them when it runs? Does the game select the files it needs to run? If you can provide a video to the basics of how a game runs it would be cool, or answer these questions for me, many thanks

 

Edited November 22, 2016 by fredreload

[Sensei]

I'm curious as to know how a game runs in Windows, does it goes into DOS mode?

No.

Unless they're ancient one. Really ancient like from '90.

Majority of modern games use full-screen OpenGL (so it can be easily ported to other platforms which support OpenGL),

and full-screen DirectX/Direct3D (Windows exclusive games).

Majority of modern games also use one of many game engines, like Unreal, Unity, and similar.

Each major game producing company has their own game engine.

Modern games also use vertex-shaders and pixel-shaders, built-in the all gfx cards, for maybe the last decade or so. Or even GPU (programmable f.e. 1024+ cores on board of gfx card)

f.e. Counter-Strike: Source, and Half-Life 2, running on poor gfx card with poor implementation (or missing) vertex-shaders, pixel-shaders, didn't have bumpy water waves, didn't have reflections on water.

 

If the game is 60GB after installation does the game use all of them when it runs?

No.

When player is moving from location to location,

between levels,

between maps,

they're unloaded, and new one loaded.

GFX cards have very little on-board memory (at least in comparison to physical memory available to CPU),

therefor 3D vertexes, triangles, textures must be loaded from physical memory to gfx card memory,

for optimal performance.

 

Does the game select the files it needs to run?

Say you have city. It's split to quarters, which at single time can be seen by player. Once player is moving from one quarter to other quarter, game is loading it.

It could happen in idle time, while player is moving, in little chunks, so he/she does not have idea that there is transfer of data.

When there is really large transfer needed, there is visible progress bar, to warn user.

 

There is also often used fog-effect, disappearance of locations that are at large distance (Z-depth in screen-coords) (blending with black or white color). It's nice for user. But also shows where is quarter border, "end-of-world".

Edited November 22, 2016 by Sensei

[fredreload]

No.

Unless they're ancient one. Really ancient like from '90.

Majority of modern games use full-screen OpenGL (so it can be easily ported to other platforms which support OpenGL),

and full-screen DirectX/Direct3D (Windows exclusive games).

Majority of modern games also use one of many game engines, like Unreal, Unity, and similar.

Each major game producing company has their own game engine.

Modern games also use vertex-shaders and pixel-shaders, built-in the all gfx cards, for maybe the last decade or so. Or even GPU (programmable f.e. 1024+ cores on board of gfx card)

f.e. Counter-Strike: Source, and Half-Life 2, running on poor gfx card with poor implementation (or missing) vertex-shaders, pixel-shaders, didn't have bumpy water waves, didn't have reflections on water.

 

 

No.

When player is moving from location to location,

between levels,

between maps,

they're unloaded, and new one loaded.

GFX cards have very little on-board memory (at least in comparison to physical memory available to CPU),

therefor 3D vertexes, triangles, textures must be loaded from physical memory to gfx card memory,

for optimal performance.

 

 

Say you have city. It's split to quarters, which at single time can be seen by player. Once player is moving from one quarter to other quarter, game is loading it.

It could happen in idle time, while player is moving, in little chunks, so he/she does not have idea that there is transfer of data.

When there is really large transfer needed, there is visible progress bar, to warn user.

 

There is also often used fog-effect, disappearance of locations that are at large distance (Z-depth in screen-coords) (blending with black or white color). It's nice for user. But also shows where is quarter border, "end-of-world".

Very interesting, thanks for the detailed explanation. I had little experience with openGL using flat shading from school lol, it was interesting. I never got into game programming and my code is just messy while having the industry as being time consuming and fast paced. Although designing a game engine does sound interesting. Making a good one would require experience and skills.

 

I looked a bit and I got a bit curious of the potential of using a real time database for the terrains instead of individual object files. This would make a lot of the objects reusable after all they are all code chunks that can be loaded from the database. I heard it can be time consuming, well, do you think loading and rendering an object from the real time database would be a problem? I think it's worth a try. I'd like to hear your thoughts on it

 

I never really got into loading difference scenes in game design, most of my projects are just one scene, so I didn't really have the experience of piecing the map together. The experience I had with the newest Doom game is good, the loading between scenes, not levels, take almost no time. Right you could load chunks of data while the player is moving, but how do you know what to load? What if I decided to go back in level instead of progressing? That is another question I have.

 

So, while having a bit of programming knowledge. I'm not really a game designer, so don't take my words too seriously

 

 

P.S. I really like the idea of real time, personally I think all computers should run on that standard

Edited November 22, 2016 by fredreload

[Sensei]

Comparison between couple different game engines.

 

 

"Top 5 Game Engines (Frostbite, CryEngine, Source, Unity, Unreal Engine)"

 

To create plants (f.e. grass), rocks, leafs, etc repeatable elements, there are used instances.

There is kept just position, rotation, scale, and id of source element, etc. instead of the whole geometry of the all millions grass blades.

 

To animate grass, leafs, to simulate wind effect, there is used vertex-shader (or GPU), to transform (translate, rotate, each vertex in element independently).

 

To animate characters, organic geometry, there are used bones.

Each bone has weight map with assigned to it vertexes.

Typically one vertex is controlled by one bone, rarely more (some engines require one vertex-one bone).

 

Rain, snow, fog, are typically implemented as sprites.

 

Essential technique used in the all game engines, is double-buffering.

It is used since '80 years.

Engine renders to off-screen buffer, while user see on-screen, previously render buffer.

Then they're swapped. Off-screen buffer becomes on-screen buffer, and on-screen becomes off-screen.

Then it's cleared. And new frame is rendered to off-screen. And cycle is repeated.

Without it, there will be visible blinking, and how CPU/GPU is rendering each triangle.

Edited November 22, 2016 by Sensei