Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 13 Sep 2012
Offline Last Active Yesterday, 11:48 PM

Topics I've Started

OpenGL 4.5 spec is out

11 August 2014 - 11:31 AM

You can grab it from http://www.opengl.org/registry/


Khronos Next Generation OpenGL Initiative thread http://www.gamedev.net/topic/659754-next-generation-opengl/

Display draw/vsync flickering

04 August 2014 - 05:12 PM

Hi! I'm having some weird display sync/fbo clear issues right now, have a look:


Attached File  bug-opengl.jpg   92.66KB   3 downloads


As you see there is this weird band in the middle of the screen. This is actually a recreation since I can't take a picture of the bug (it doesn't shows if I make a screenshot), but it looks just like that.


It actually flickers when in movement, gets worse if the framerate isn't 60 fps (ie, well above 60fps gets me a blank screen, below 60fps gets flickering incrementally).


It seems the band follows the line of the fullscreen quad I do for the (deferred) light pass. For now I just have a geometry pass and then a fullscreen directional light pass. Nothing fancy.


Flickering patterns change if I set it to fullscreen or windowed, but it's always present in one way or the other.


My current gbuffer setup is:


albedo: GL_RGBA8, GL_RGBA, GL_UNSIGNED_BYTE (texture)

normals: GL_RG16F, GL_RG, GL_HALF_FLOAT (texture)

view-space depth: GL_R32F, GL_RED, GL_FLOAT (texture)

depth-stencil: GL_DEPTH24_STENCIL8 (renderbuffer).


I draw stuff to the gbuffer, then blit the depth data to the default framebuffer, then do the light pass writing light + albedo to the default buffer (fullscreen quad in the far plane, GL_GREATER depth test, so not to lit the background) while sampling from the gbuffer.


Before drawing to the gbuffer I clear depth, color and stencil. Before drawing to the default buffer (light pass), I clear color only (depth is blit from gbuffer and preserved).


I might not be clearing the proper color attachments in the gbuffer, I'm not sure, I have to check.


I've tried with swapBufferInterval 1, 0 and -1. With and without LWJGL's "Display.sync" call (it basically sleeps CPU to synchronize). swapBuffers is called only once after rendering. The actual calls made are:

renderer.render(); // Draw all.
displayContext.swapBuffers(); // Swap buffers.
displayContext.sync(); // Do LWJGL's Display.sync() call if configured to do so.

I guess that's all the relevant information, if you need more just ask.

Editor ate half of my journal entry

30 June 2014 - 08:40 PM

There I was, writing, editing, when It happened... I hit "save draft" button, and saw what was left of my entry. It ate half of it, maybe more.


I am not pleased. I am the opposite of pleased actually, to put it mildly. Where do I ask for 2 hours of my life back?

Can't access the site.

09 June 2014 - 06:06 PM

Well, I can access it from here, but in my home I cant.


Tried with Chrome 35 and 37, and with Iceweasel (Firefox) 29. I'm using Debian Jessie x64.


Chrome says "connecting..." for a while, then it stops loading and says the page can't be reached. Funnily enough, if I try to access gdnet from my phone in the same network, I can read the mobile version (I doubt the thing could handle the whole page), but logging in fails, I put my nick and password, and it returns me to the main page without getting logged in.


Its some sort of IP blacklisting or something? huh.png

Memory allocator. Maintaining free list.

01 June 2014 - 06:42 PM

Hi! I have some issues trying to implement a (sort of) memory allocator, it has to be tailored to the peculiarities of Java.


First and foremost, I'll describe what I have in Java instead of malloc() and friends:


Direct ByteBuffers, they're an object representing a chunk of memory outside JVM's heap, so it can't be moved by GC. They're used for interacting with native libraries (such as OpenGL, or Bullet). ByteBuffers expose methods for putting things into the buffer, they have a capacity and with some magical casting, you can free them manually.


ByteBuffers, unlike Java arrays, can be sliced via "byteBuffer.slice()" method. You get a ByteBuffer slice starting at the current position mark of the ByteBuffer, and a capacity equal to the remaining bytes in the backing buffer.


So what I wanted to do is the following:


Have a BufferAllocator that would allocate a big backing buffer (couple of MBs), and that it would manage slices of the backing buffer, so to avoid allocating/deallocating small buffers all over the codebase. "capacity" field of the slice can't be modified, so I modify it by reflection, so the user of the returned slice can't step on the memory that lies beyond their slice.


The ByteBuffer doesn't "knows" how much of it is being used. It only has a position mark, a limit mark, and a capacity. You write data into it however you want. So to manage the backing buffer I need an additional structure that can represent which parts of it are free and which parts of it are being used.


I decided to try a simple ArrayList of int[] arrays of size 2 representing the "free block list". First element of the int array is the offset of the block, second element is the end of the block.


Say that I want to ask for a 32 byte buffer, the allocator has 1KB capacity.


The allocator starts with a free block list containing a single element, a int[] with 0 as start value, and 1024 as the end value.

The allocator finds the smallest free block that can hold the 32 byte buffer it was asked for (ie, the only free block we have).

The allocator makes a slice starting at the free block start, ending at the 32 byte mark.

There is still a single contiguous free block, but now it starts at the 32 byte mark, and ends at the 1024 byte mark.

A ByteBuffer slice with capacity 32 is returned.


Have in mind this free block list is just a list of values to do the free block bookkeeping, not the actual memory.


Now, to "free" a ByteBuffer slice, I'd need to find roughly its position inside the free block list.

If there is a neighbor free block (ie, the freed block isn't between two used blocks), I'd need to modify its start/end offsets as required.

Otherwise, create a new int[] instance that holds the freed block's start and end offsets, then insert it into the free block list.


The problem is that if the block I'm trying to free is between two free blocks, I'd need to merge all 3 (left free block, the block I'm freeing, and the right free block). That would mean, removing one of the adjacent free blocks, and expanding the remaining one to cover the block I removed and the block I'm freeing.


Both things: I'm not sure how to do that without a chain of 10 if/else statements (hell, I even tried with lots of if/else statements and I still can't get it to work). And I'm obviously not making the most efficient lookup for finding free blocks to slice.


Here is my (broken) implementation so far:




Any help?