Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Apr 2012
Offline Last Active Aug 14 2014 06:06 AM

Posts I've Made

In Topic: Drawing to own buffer?

08 May 2014 - 04:07 PM

First of all, its 32 bit (4 byte) color, not 32 byte color. So your buffer size should be 1280 * 800 * 4.


Second of all, you are writing to the wrong pixels. Each pixel contains 4 bytes, but you assume the size of a pixel is just 1 byte. 

void drawPixel(const int x, const int y)
    int offset = (y * SCREEN_WIDTH + x) * 4;
    back_buffer[offset + 0] = 0xFF; // set R value to 255
    back_buffer[offset + 1] = 0xFF; // set G value to 255
    back_buffer[offset + 2] = 0xFF; // set B value to 255
    back_buffer[offset + 3] = 0xFF; // set A value to 255

I still think the problem is somewhere else. You should better post your whole code. Most probably your problem was that the alpha values might never have been set, making the result fully transparent. The setup of blending could affect the result of such operations, likely ignoring pixels with alpha set to zero.


There are a lot more things that can go wrong and why you don't see an image. I suggest you go through a detailed tutorial and then start doing experiments like this.


Finally, why would you do such a thing? Just use textures and shaders to produce images. You are throwing GPU acceleration out of the window with such an approach.

In Topic: What's the Hot/New/Modern OpenGL Debugger/Profiler?

04 May 2014 - 04:38 AM

There's AMD's CodeXL: http://developer.amd.com/tools-and-sdks/opencl-zone/opencl-tools-sdks/codexl/

CodeXL is a successor to gDEBugger and offers pretty much the same functionality with small updates. CodeXL works also on NVIDIA GPUs, but you cannot debug shaders etc.

Viewing buffer and texture contents works OK. It however does not support direct state access calls, which is a pain in the ass.


The second option is NVIDIA NSight. AFAIK it works only on NVIDIA GPUs (I don't have an AMD to test it), but works really great. 




Both support Visual Studio integration and both really help debugging. I myself consider NSight more mature and somewhat easier to work with.


There was a nice video about Nsight, I think this is it:

In Topic: image layouts in openGL compute shader

02 May 2014 - 09:17 AM

For int and uint layouts, you have to use the corresponding types, prefixed "i" and "u": https://www.opengl.org/registry/specs/EXT/shader_image_load_store.txt


So, if you use iimage1D, it will work.

rgba32ui -> uimage*D

rgba32f -> image*D

In Topic: Spells in entity component systems

04 January 2014 - 08:25 AM

I would make the staff component hold only a reference to the current spell (could be a child entity). You would then have 3 instances of a Spell entity, one for each of your spells, and these would contain in a component all the spell info like cooldown, cost, etc.. Then just keep somewhere a list of all spells your character has, and by pressing Q or E, you just remove the child entity from the staff and add a new entity that is the next spell in your list. The spell entity itself could have some animation specific to the spell and you could be showing it. Very simple imho.


I hope you got the idea :)

In Topic: Vertex Array Object + Direct State Access

03 December 2013 - 01:42 AM

These are described in the actual DSA extension: http://www.opengl.org/registry/specs/EXT/direct_state_access.txt

You can get arguments and their names from that site.


If you are unsure, the usual approach is that whatever you call in a Bind function (BindVertexArray, BindTexture) becomes the first parameters of the DSA call. The other parameters are then the exact same parameters that you would use in a non-DSA function. 


Also take a look at this: http://www.g-truc.net/post-0363.html


Keep in mind that when working with vertex array objects, there is one thing you cannot do with DSA and must use the old way: http://stackoverflow.com/questions/3776726/how-to-bind-a-element-buffer-array-to-vertex-array-object-using-direct-state-a