Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 03 Feb 2008
Offline Last Active May 26 2015 09:53 AM

#5202983 C# seems good, but....

Posted by Kaptein on 08 January 2015 - 08:36 PM

I suggest Java or C#, since you won't get bogged down with all the complicated stuff that C++ has. Not to mention finding and utilizing all the right libraries just to get a window up. And setting up a toolchain. If you're gonna use C++, at least use multiplatform libraries and GNU compiler suite. If you just want to program inside of Windows for Windows, use C# for everything. It's going to take a long time (years) before you should even think about speed. Java and C# are not slow. It's just that C++ let's you do certain things manually, such as memory management and placement new. Which is an expert level topic.


Depending on what you want to achieve, or if you're like me, just want to program games - there are 1000 things to learn, which is why its not a good idea to start with something slow like C++. You'll want to learn about programming in general, data structures, object-oriented programming, basic memory management, lots of algorithms, linear algebra (which lets you do cool stuff like rotate objects), timestep/tick combined with physics, networking. And so on.

So, it doesn't matter what language you choose. What matters if what you learn, and what you think is fun and interesting to do. Pick a language that is easy to get started with and has a gigaton of material. Avoid choosing a complicated language (C++), or one with less material to choose from (Basic derivatives). You don't want to get stuck on small things that don't matter.


Good luck :)

#5189860 OpenGL Bump Map -- Texture artifacts ?

Posted by Kaptein on 28 October 2014 - 09:55 PM

White & black dots can be the result of math that produces errors. 99% of the cases are sqrt(negative number) and ~zero-length vectors.

Flickering is usually uninitialized variables.

Completely white/black is usually missing/empty texture, or missing/uninitialized uniforms etc.



Check your inputs for errors.

Transfer normal and tangent to pixel shader (interpolated) and show their magnitudes. color = length(vector);

white = good, black = bad


Eventually you will find the issue. It helps alot to know what values certain things should have. For example, directional vectors (normal, tangent, binormal) should all be length == 1 (white).

#5189604 OpenGL/GLSL version handling

Posted by Kaptein on 27 October 2014 - 10:20 PM

A core context can be created for OS X now at least, although it does seem like the devs don't really understand the pros (and in other cases -necessity-) of using core contexts explicitly.

At some point it will be added, I guess.


See: https://github.com/LaurentGomila/SFML/issues/654

#5187437 Texturing problem - weird swap

Posted by Kaptein on 16 October 2014 - 11:18 AM

It looks like you are either using repeating texture coordinates (with tri/bilinear interpolation), or you are simply reading outside your own texture (also because of interpolation).


Google keywords: texture bleeding


Some explanations:




And a zillion others :)

The "problem" itself is just a result of how linear interpolation samples nearby pixels.


Solutions include, but not limited to:

1. Using clamping (GL_CLAMP_TO_EDGE)

2. Have your texture coordinates well inside a sub-image on a texture atlas (watch out for mipmapping issues)

3. Use texture 2D arrays (need to be square sized)

4. Use shader magic to avoid sampling outside of image, or centroid sampling (centroid not recommended)

#5185569 How to prepare myself to get a job in a AAA game company?

Posted by Kaptein on 07 October 2014 - 10:50 AM

Make demos that are polished and proves a point, aka. portfolio.


For reference I googled for art portfolio, and found someone I think could get a job in game industry:



More relevant for computer engineers, someone with a website with demos and code examples:



Which reminds me.. I tried sooooooo hard to make this, and I failed in the end:


#5184971 C# trouble obtaining a decimal value.

Posted by Kaptein on 04 October 2014 - 10:31 AM



When you start to really use floating numbers they will always have errors in precision (up to a point).

In this case you could just use rounding, and the problem will go away.

#5184936 Knowing my REAL OpenGL version - RESOLVED

Posted by Kaptein on 04 October 2014 - 06:53 AM

That is bad advice, aks9. There's nothing to learn when it comes to context creation, other than what a nightmare it can be if you have older (or buggy) drivers. I just look at the whole thing as risky, since if you take that code with you to other projects, one day one of the people trying the game/program out will simply not be able to run it because their driver requires a workaround.

You can do the same exact things with SDL or any other library, except you will have less grief during the process. Most of the time, anyways.


See 2:



Really, why do this:



When SDL does it all for you in 10 lines of code. And it will work on every platform. ;)


EDIT: I downvoted you aks9, but I can't undo it. :( Your post is helpful, so I'm sorry.

#5184014 trying to draw with modern opengl but am geeting wrong result

Posted by Kaptein on 30 September 2014 - 02:49 AM

A small tip:

template <typename T>
class Vector3D
    // stuff
using vec3 = Vector3D<float>;

vec3 vector;


// old: for (size_t i = 0; i < faces.size(); i++)
// new:
for (auto& face : faces)
    v.push_back ... face[0]

It looks like the "faces" you have may be 3x vertices linear in memory?

If Face is sizeof(float) * 3, then your usage of vector<> may mean that you can simply memcpy directly from one place to another:

// reserve enough space (in elements)
v2.reserve(v2.size() + faces.size() * 3);
// if Face is a vector, copy everything from v1 to v2
std::copy(v1.begin(), v1.end(), std::back_inserter(v2));
// or, in the no-vector case, either use memcpy() or copy element by element (as you are already doing)

Reserving space by itself can help alot with the speed, and isn't risky in case you change things later on




is unnecessary, and only reverts you to immediate mode in a compatibility context.


You don't need to do much to at least use GLSL 1.3 (or 1.5, using #version 150 for OpenGL 3.3):

#version 130

out vec4 color;

void main(void)
    color = vec4(1.0, 0.0, 0.0, 1.0);

(although I recommend even newer!)

Here is a good example I found: http://www.lighthouse3d.com/cg-topics/code-samples/opengl-3-3-glsl-1-5-sample/


I don't see any problems other than perhaps you are rendering using wrong mode: GL_TRIANGLES

Perhaps the model requires indexes.

What is faces supposed to do?

#5182626 GLFW errors during c++ program compialtion on ubuntu

Posted by Kaptein on 24 September 2014 - 06:42 AM

It's a different problem yes.. but you can just install XVFB: http://linux.die.net/man/1/xvfb

Problem solved smile.png


Run it with xvfb-run ./program [params]


EDIT: Use xvfb-run instead

xvfb is to set up the server, but on ubuntu you can just use xvfb-run:


#5182477 GLFW errors during c++ program compialtion on ubuntu

Posted by Kaptein on 23 September 2014 - 02:11 PM

Install cmake:

sudo apt-get install cmake


Download from glfw.org, unpack it to a location, enter directory, type this in terminal:

cmake .
make -j4
sudo make install



Here is my output for static linking:

pkg-config glfw3 --libs --static
-L/usr/local/lib -lglfw3 -lrt -lXrandr -lXi -lGL -lm -ldl -lXrender -ldrm -lXdamage -lX11-xcb -lxcb-glx -lxcb-dri2 -lxcb-dri3 -lxcb-present -lxcb-sync -lxshmfence -lXxf86vm -lXfixes -lXext -lX11 -lpthread -lxcb -lXau -lXdmcp

So, to use that, add the command to linking process using `` qoutes, for example: -Llib -llzo2 `pkg-config glfw3 --libs --static`

#5181052 Creating multiple OpenGL contexts with GLFW on different threads

Posted by Kaptein on 17 September 2014 - 11:42 AM

OpenGL is not very helpful with multi-threading, and you may simply be trying to do something that is going to be inherently inefficient or widely supported. I'm sure someone here will eventually chime in on the current state of affairs.

See: http://www.gamedev.net/topic/656684-cases-for-multithreading-opengl-code/


One thing you can do is utilize SSE though, especially for multimedia (textures). You are pretty much guaranteed SSE3 support these days, so if that helps you, you could take a look at where the bottlenecks are and see if you are IO bound or there are real cases for vectorization.


You can load and parse your resources on another thread, I guess, and then simply upload them on the rendering thread using pointer swapping with locks (as that will reduce allocation).


The IO also doesn't necessarily have to block in your main thread though, but I don't know anything about multiplatform asynch IO.

I only have a passing familiarity with linux AIO: http://man7.org/linux/man-pages/man7/aio.7.html

#5181006 Opengl Spazzing out for no reason

Posted by Kaptein on 17 September 2014 - 07:56 AM

I can only agree with BitMaster. You are probably seeing undefined behavior either in OpenGL or C++. You are lucky though, since you can clearly see the error with 100% reproduction rate no less.


Perhaps first start with trying the project out on a different computer.

#5180960 Deferred rendering shader spaces issue

Posted by Kaptein on 17 September 2014 - 03:50 AM

vec4 _col=vec4(col.x/255,col.y/255,col.z/255,col.w/255);


you can just write col.xyzw / 255.0 here, or col / 255.0. 255 is an integer though and might not compile on stricter implementations (im not actually sure)


vec3 calcNorm=normalize(normMatrix*cross(vertex[1].pos.xyz - vertex[0].pos.xyz, vertex[2].pos.xyz - vertex[0].pos.xyz)) * 0.5 + 0.5;


is invalid and will likely not compile on stricter implementations, it should be + vec3(0.5);

#5180858 Trouble Drawing Sprites with Orthographic Projection...

Posted by Kaptein on 16 September 2014 - 05:42 PM

Well I worked it out in the end by shifting the texture coordinates in. Strange though, 0.5 of a pixel wouldn't work right because it was cutting out a pixel of texture, and I think even 0.25 had some problem or other... perhaps the movement looked distorted or something; either way it seemed to get better with smaller values. Seems fine now.


One last thing though... if I want to avoid unnecessary draw calls by batching together sprites that use the same texture, is instancing the standard way to go about that? I've only looked into it a little bit but it seems to be what I'd need.


If you are just using quads, just brute-force it and call it a day. You aren't going to be bandwidth limited, you aren't going to be CPU-limited (except on potatoes, and they are thankfully close to extinct now), and the GPU is more or less going to be idle.


About "perhaps the movement looked distorted or something"

Depends. If you're drawing without interpolation then yes - there's going to be subpixel movement/aliasing. Nothing you can do except tighten the shift more, or use supersampling.

For a regular 2D game with nothing special going on 2x supersampling is probably not going to faze the GPU. All that means is rendering to an offscreen buffer that is twice the size of the original screen, then use glFramebufferBlit to downsample to normal size.


It all depends what you are doing. If you are going to render 3k quads per frame (you have no choice), then you will need to render efficiently and write minimal shaders. Otherwise, just write good code and make sure you're in a good spot, architecturally, with your thingamajig.

I'd say just sorting by shader->texture and sending everything that is actually on screen to GPU each frame is the most simplest flexible-enough case, as it lets you animate tiles without effort.

If your screen is very large and there are say 500+ tiles on-screen at all times, you may want to consider only updating tiles when something actually changes.

But I think that is largely futile as mechanically good players generally have high speed. It just feels like optimizing for a scenario that isn't worst-case (and just adds more if() statements). I guess it also depends on physics vs rendering update ticks. If you can prove that you have 1 camera update per 2 frames, it will pay off. But then that just sounds like a frameskip scenario. Which is simpler to implement. I guess.


Bah. Just do what you think you need to do.

#5180442 Small but noticable seam on Skybox...

Posted by Kaptein on 15 September 2014 - 06:49 AM