Sign in to follow this  
  • entries
    63
  • comments
    56
  • views
    43863

Daedalus progress

Sign in to follow this  
rick_appleton

195 views

Although it's been a while, I have been able to do quite a lot of things.

I've uploaded a few demos which I made about a month ago to test some of the more advanced OpenGL functions. Click the images to get the executable(s). (edit. Unfortunately, I currently check for supported extensions at init, regardless if they're used or not. I'll update the FBO and VBO samples this evening to not check for PBO support. Until then, the samples only run on nVidia cards with the correct drivers)

VBO
This is pretty much a standard implementation of VBOs in OpenGL. Not much to say about it actually.


FBO
First implementation of OpenGL Frame Buffer Objects. These allow OpenGL to render to a texture. Very useful for things like mirrors and such. In this sample, I'm rendering the scene to a texture, then using that texture to index into a 3d noise texture. The darker the color, the more noise, and thus the darker the resulting image. The effect is ok, but is a bit spoilt by the spinning of the model I think.


PBO:
OpenGL now has Pixel Buffer Objects on nVidia cards. This allows OpenGL to use a vertex buffer as a texture basically. It can be used to make a particle engine on the GPU, as I've done here. The particles update is controlled through the pixel shader (written in GLSL in my case). The two noisy texture on the left are the two textures I'm ping-ponging between for the update. rgb correspond to xyz position of the particles. The red line on the top right of the image are the particles. The shader currently updates them along the line of parabole. However, since the particles are initialised at random, changing the shader can lead to some other interesting effects.
Note: this demo only works on nVidia cards, as Ati cards don't have support for PBO yet.


Besides these visible changes, I've completed most of a new resource manager, which is threaded. Still deliberating a bit over the interface. The manager immediately gives you back a handle which you can use to access the resource. If you access a resource that hasn't been loaded yet, it's loaded ASAP. So in theory there's no need for the user to know that the resource manager is async. I'm wondering if my interface should reflect this. Any opinions on this?

Also, I've been working to load OpenGL dynamically, instead of linking to opengl32.lib. It's been relatively easy to get all the pointers, unfortunately for me, the entire thing comes crashing down if I actually remove the dependency. For some reason wglCreateContext fails. After a lot of searching I've found a small project doing this also, which does work. And doesn't do anything significantly different as far as I can see.

Lastly, I've been making a lot of progress on the Nintendo DS build of Daedalus. It can now load models and textures, and use them with an OpenGL like syntax.
Sign in to follow this  


0 Comments


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now