Jump to content

  • Log In with Google      Sign In   
  • Create Account

__SKYe

Member Since 10 Jun 2011
Offline Last Active Today, 08:38 AM

Posts I've Made

In Topic: Include file not found in GCC, due to path size?

29 August 2014 - 02:56 AM

Well, that sure solves my probblem. You guys are awesome.

 

I guess a still got quite a bit to learn about multiplatform coding/compilers.

 

Also, i really forgot to say, and even though it doesn't really matter know, the GCC version is indeed 4.8.1, and the OS is Windows Vista. If anyone is wondering, this is also the reason why i use Visual C++ 2010 and not the most recent, because Vista is no longer supported.

 

Thanks a lot, really.


In Topic: Books and resources to learn from ground up

16 August 2014 - 08:24 PM

First, you should learn the language first (C++ in this case).

You can, and should, take a peek or two at some coding styles, good practices, etc, while you're learning, but i'd say try not to overwhelm yourself with too many information at once.

If you follow some of the tutorials i will list below, you should be fine.

Then, when you have a solid understanding of C++, you can start learning OpenGL. One thing i'd advise, is that you don't learn old, fixed function OpenGL, because it is not relevant today. If you don't know what 'fixed function' means yet, don't worry as you'll know when you follow any OpenGL tutorial.

About math, you do need some, but in the OpenGL books/resources that i will list, there is normally a chapter or two about the math required to, al least, get you up and running.

 

For learning C++, you can check C++ Primer.

You can also check Effective C++ and More Effective C++. These present many tips and guidance on proper use of the C++ language.

Last, but not least, you should check Design Patterns: Elements Of Reusable Object-Oriented Software, which is probably the most extensive guide on design patterns, what they are, when you should use them and when you should not.

 

For OpenGL, OpenGL SuperBible 5th Edition, which besides being a reference guide on the API, provides a step-by-step guide on how to use modern OpenGL. (meaning shaders, vertex buffers, etc). It also contains bits of information about the math required to work with OpenGL.

If you're also interested in GLSL, you could read OpenGL 4.0 Shading Language Cookbook, which contains a lot of shader code to provide most, if not all, of the visual effects you see in modern games, for GLSL.

 

Other books that i would highly recommend are Game Engine Architecture and Game Coding Complete 4th Edition.

They both provide an in-depth view on how a game engine works, the components it consists of, a healthy amount of code, etc.

I must mention though, that the second book does not discuss OpenGL, but Direct3D instead, although if you pick these books, it should be for the overview of a game engine, and not a particular graphics API.

 

On a last note, the GPU Gems book is freely available here. While this doesn't quite fit you're request, you could try to give it a read, if you're interested (it's free anyway).

 

Here's some links for online resources:

 

C++

 

http://www.cplusplus.com

http://www.learncpp.com

 

OpenGL

 

http://www.opengl.org/wiki/Main_Page

http://nehe.gamedev.net

http://ogldev.atspace.co.uk/index.html

http://www.opengl-tutorial.org

http://arcsynthesis.org/gltut/index.html

 

Really the last thing.

Not very related, but if you required 3D models while you dabble with OpenGL, you can find many here (for free, of course).

 

Hope it helps.


In Topic: Good render loop organization resources

09 August 2014 - 06:33 PM

Another great article about what Scene Graphs are, and how they should be used, can be found at: http://lspiroengine.com/?p=566

You should also check the other articles in that site, as they are quite useful.

 

Here are some more notes on the rendering part.

 

You may want to consider trying/experimenting using Z-Prepass/Early Z-Test.

It basically involves sorting your renderable objects by their position, front-to-back, and writing to the Z-Buffer only, and not writing to the Color Buffer.

This way, you avoid lighting/rendering pixels multiple times if an object is occluded by another object.

 

Then after this, you'd sort the renderable objects by material, and render them while switching rendering state as little as possible.

 

Keep in mind that the above only works for opaque objects.

 

For translucent/transparent objects, you have to sort them by position, back-to-front.

Here, you must accept the cost of material change, because if translucent/transparent objects aren't sorted back-to-front, visual anomalies will ensue.

 

Also, if your scene contains alot of lights, you may want to consider using deferred rendering, as forward rendering's performance degrades quickly when many lights are added/exist (as each pixel will be lit multiple times, as oposed to deferred rendering, where regardless of the number of lights, each pixel is only lit once).

 

Of course there are other considerations to take into account, like the need to use multiple framebuffers in deferred rendering, etc.

 

As a last note, if you plan on having a 2D GUI/HUD on your project/game, then the 2D stuff would be drawn after your 3D scene is rendered.

 

You may already now this stuff, and if so, ignore it, otherwise, i hope it helps.


In Topic: Calculate GPU memory usage

30 December 2013 - 12:10 AM

Well, then i guess this really ins't as simple as i thought.

 

Many thanks to you all.


In Topic: Calculate GPU memory usage

29 December 2013 - 10:01 AM

Thanks, that's helpful to know if you're within VRAM budget.

 

But while it is helpful to know the amount of memory used, it still won't help much with what i'm after.

 

You see, what i mean to do is basically to keep track of how much memory i allocate for the various types of data that resides in the VRAM.

This can be textures, vertex/normal/texcoords data, the color/depth/stencil buffers, etc.

 

Again, i don't mean to track every single byte of memory that is in the GPU, i just want to keep an "in-house" estimate of the VRAM used.

 

As an example, think of how you would create your own memory (normal RAM) tracker, to get stats like:

 

General:   2312083KB

Audio:         195421KB

MAP:       29383467KB

 

etc...

 

And the VRAM equivalent could be:

 

Color Buffers:     503918214KB

Depth Buffer:        78216928KB

Textures:        23487654303KB

Geometry:          489279345KB

 

etc...

 

Note that i don't mean to query the GPU for the amount of data i sent, or the memory in use.

What i'd do is to calculate the amount of memory a resource would use when i create/upload it in/to the GPU.

 

Again, image i load a R8G8B8A8 128x128 (uncompressed) texture from disk, and upload it to the GPU. Here i'd calculate the memory required for the texture (which would be 128*128*4 -- assuming the internal storage is also RGBA, etc) and perhaps add it to a counter of the total texture memory used.

 

I know that the GPU can remove textures from the VRAM if you upload more textures than the available memory, among other issue, so it's just an estimate.

 

Sorry if the explanation isn't clear.

 

Thanks again.


PARTNERS