I've started to do daily programming puzzles. They have been helping me hone my programming / reasoning skills. I'm going to start using the daily puzzles to learn other languages as well since I think it will be good to learn the constructs of other languages this way (even the smallest puzzles exercise my knowledge of C++ STl...not much, but I were new to C/C++ I would have a hard time).
So the website I've been looking at is http://sixrevisions.com/resources/10-puzzle-websites-to-sharpen-your-programming-skills/ , specifically the first link has tiny little puzzles on it.
So far I've done two from this website (Sum4, Scalar Product), each of them taking a short while to think and program up. They are essentially interview questions.
The other day while reading Ken Thompson's Touring Award speech "Trusting Trust", and I encountered the Quine...a self-reproducing program. For example, in C, you would write a C program that when compiled would produce the original source, character-for-character. This sounds easy, but the naive way to go about solving this will show you that it's a little trickier than it sounds. Anyways, after a canceled flight at DFW airport and a stay in the Holiday Inn Express, I gave it a try. I figured out the solution, and I got it working the next day, It's suprisingly simple once you figure it out...but I saw some of the other results (in C) and it amazed me at just how small you can get the program. In fact, this used to be a little game with Ken Thompson and Dennis Ritchie when they were in College. They used to see how small of a Quine they could produce. This also led me to the discovery of "multiquines": A program written in one language produces source code for another language, which if compiled in run would reproduce the original language's source code...this is so cool!!! I might try it some day. For now, I must move on to work on Oblivion Wars...good day.
Monday, August 20, 2012
Wednesday, August 8, 2012
Very exciting things happening in the new OpenGL 4.3 standard. I'm sitting listening to Mark Kilgard's OpenGL 4.3 talk at SIGGRAPH currently. These are the take-aways:
Compute Shaders - OpenGL now has general CUDA/OpenCL functionality built into the graphics pipeline. Same notion of using a set of threads inside a workgroup is used, and these can all communicate with each other and with global textures. Furthermore, having this inside of a shader allows one to unify the computations and outputs with OpenGL textures, vertex arrays, etc. This means no third-party API is needed for GL <-> GPGPU compute functionality.
Debug - Allows one to annotate and use debug messages help them debug their OpenGL code.
He showed a few examples: a few image processing examples, Soble filtering, Gaussian filtering, etc all in real-time. Looking forward to seeing some of the image processing techniques being used in games. Also showed a particle physics simulation where the compute shader integrated the motion of hte particles and updates the positions in a GL vertex buffer. All without going to the CPU, yay!
Many many many more. Be on the look out for Mark Kilgard's slides on this being posted soon.
Other things: Further Linux support by NVIDIA.
Bindless Graphics: Instead of binding to textures (which leads to a lot of different buffers and textures), you can map all the texture buffers into your GPU address space and access these inside the shader. This means you have access to MANY more textures in a shader, and you don't have to bind them from the CPU side. This is only on NVIDIA's Kepler architecture. Mentions this could be useful for ray-tracing where each ray needs access to the entire scene.
Exploiting the modern graphics pipeline: Similar bindless for Uniforms, materials, etc. MultiDrawIndirect -> Draw several batchs of stuff in a single call. Supports indexed subrouties.
Compute Shaders - OpenGL now has general CUDA/OpenCL functionality built into the graphics pipeline. Same notion of using a set of threads inside a workgroup is used, and these can all communicate with each other and with global textures. Furthermore, having this inside of a shader allows one to unify the computations and outputs with OpenGL textures, vertex arrays, etc. This means no third-party API is needed for GL <-> GPGPU compute functionality.
Debug - Allows one to annotate and use debug messages help them debug their OpenGL code.
He showed a few examples: a few image processing examples, Soble filtering, Gaussian filtering, etc all in real-time. Looking forward to seeing some of the image processing techniques being used in games. Also showed a particle physics simulation where the compute shader integrated the motion of hte particles and updates the positions in a GL vertex buffer. All without going to the CPU, yay!
Many many many more. Be on the look out for Mark Kilgard's slides on this being posted soon.
Other things: Further Linux support by NVIDIA.
Bindless Graphics: Instead of binding to textures (which leads to a lot of different buffers and textures), you can map all the texture buffers into your GPU address space and access these inside the shader. This means you have access to MANY more textures in a shader, and you don't have to bind them from the CPU side. This is only on NVIDIA's Kepler architecture. Mentions this could be useful for ray-tracing where each ray needs access to the entire scene.
Exploiting the modern graphics pipeline: Similar bindless for Uniforms, materials, etc. MultiDrawIndirect -> Draw several batchs of stuff in a single call. Supports indexed subrouties.
Monday, July 18, 2011
Configuring Armadillo
To configure armadillo on Mac OS X
Goto http://arma.sourceforge.net/ and download the newest version.
Decompress.
run cmake . in the directory
run make
It will automatically add the Accelerate framework to the compilation.
Goto http://arma.sourceforge.net/ and download the newest version.
Decompress.
run cmake . in the directory
run make
It will automatically add the Accelerate framework to the compilation.
Monday, May 30, 2011
Game Programming Wiki
Found this interesting vector class on the game programming wiki. It uses the STL very well.
http://www.gpwiki.org/index.php/C_plus_plus:Tutorials:TemplateVector
http://www.gpwiki.org/index.php/C_plus_plus:Tutorials:TemplateVector
Saturday, May 28, 2011
Plans for development of OpenGL wrapper
I want to create a wrapper for OpenGL using standard OO principles. Ideally, this means that all OpenGL commands and such will simply be wrapped in functions which are designed to draw specific types of objects, perhaps the type of Displayable class. The wrapper should will encapsulate as many OpenGL commands as possible, and each one will include an option error checking mechanism enabled through a define. This will both help me with more advanced OpenGL stuff as well as make future projects easier to start out with. Ideally, this wrapper itself will be a form of strategy which can be used in a larger engine. Perhaps another strategy would be the DirectX object.
Wednesday, May 25, 2011
Time stepper and physical object classes
I started writing two new classes today: TimeStepper and PhysicalObject.
The TimeStepper class is designed to take in physical objects, add them to a local list, and then update their state using their own derivative functions. TimeStepper itself is meant to be a strategy class, such that it can contain a pointer to a ConcreteTimeStepper strategy subclass which will implement a particular timestepping algorithm, aka Explicit Euler, Leap Frog, Runge Kutt 4, etc.
The physical object class is much that same as the TimeStepper in that it is a base class consisting of a state vector and methods to manipulate the state vector. For the base class, these are empty methods (accept for things common to all physical objects, such as mass). The state itself is implemented as a vector, and each type of physical object can treat this vector differently. For instance, the ParticlePhysicalObject can treat it as a 6-component vector where the first 3 are position and second 3 entries are velocity values. It also contains a vector of constant accelerations which can be used to add things such as gravity to the mix. Each physical object will contain its own GetStateDerivative vector which returns a pointer through the parameter to an array the same length of the state vector, but with each entry being the derivative of that entry in the state with respect to time. This way, timestepper doesn't need to know whether the PhysicalObject is a particle, a rigid body, or a deformable object, as long as the derivative entries from this function correspond to the same entries in its state, then TimeStepper can use the derivative information to do its thing without a care in the world.
For TimeStepper, I'm thinking about just maintaining a vector of PhysicalObject pointers which can be registered the the TimeStepper.
In the works also is a Collider with it's own strategy. I have found that the strategy pattern is translating very well to these physically based simulations.
TODO - Reread Witkin's course notes on rigid bodies.
The TimeStepper class is designed to take in physical objects, add them to a local list, and then update their state using their own derivative functions. TimeStepper itself is meant to be a strategy class, such that it can contain a pointer to a ConcreteTimeStepper strategy subclass which will implement a particular timestepping algorithm, aka Explicit Euler, Leap Frog, Runge Kutt 4, etc.
The physical object class is much that same as the TimeStepper in that it is a base class consisting of a state vector and methods to manipulate the state vector. For the base class, these are empty methods (accept for things common to all physical objects, such as mass). The state itself is implemented as a vector, and each type of physical object can treat this vector differently. For instance, the ParticlePhysicalObject can treat it as a 6-component vector where the first 3 are position and second 3 entries are velocity values. It also contains a vector of constant accelerations which can be used to add things such as gravity to the mix. Each physical object will contain its own GetStateDerivative vector which returns a pointer through the parameter to an array the same length of the state vector, but with each entry being the derivative of that entry in the state with respect to time. This way, timestepper doesn't need to know whether the PhysicalObject is a particle, a rigid body, or a deformable object, as long as the derivative entries from this function correspond to the same entries in its state, then TimeStepper can use the derivative information to do its thing without a care in the world.
For TimeStepper, I'm thinking about just maintaining a vector of PhysicalObject pointers which can be registered the the TimeStepper.
In the works also is a Collider with it's own strategy. I have found that the strategy pattern is translating very well to these physically based simulations.
TODO - Reread Witkin's course notes on rigid bodies.
Tuesday, May 24, 2011
Subscribe to:
Posts (Atom)