Programming, graphics, games, media, C++, Windows, Internet and more...
All blog entries, ordered from most recent. Entry count: 1198.
Pages: 
1 ... 61 62 63 64 65 ... 150 
# Disadventages of Nested Classes and Anonymous Namespaces
Fri
28
Aug 2009
Some of techniques I have been using to arrange my C++ code were anonymous namespaces and nested classes. I liked them till I've discovered their big disadventage - they are not compatible with forward declarations. Here is an example. Let's say we have two classes - Problematic and Second - and we want to place them in separate HPP+CPP files, while Second will use Problematic. The obvious solution is to define them like this:
////// Problematic.hpp
class Problematic
{
};
////// Second.hpp
#include "Problematic.hpp"
class Second
{
Problematic *obj;
void CreateObj();
};
We all know that the fewer inclues the better (especially we should avoid including headers in other headers), so it's good to only declare Problematic class in Second header and include its definition in CPP file. We can do it as Problematic class is used in the Second header only by pointer (references are also OK) and not by value.
////// Second.hpp
class Problematic;
class Second
{
Problematic *obj; // Here class declaration is enough
void CreateObj();
};
////// Second.cpp
#include "Second.hpp"
#include "Problematic.hpp" // Included here, not in HPP
void Second::CreateObj()
{
obj = new Problematic(); // Here full class definition must be known
}
# Reflect and Refract Functions
Mon
24
Aug 2009
Every game developer must have some knowledge about maths and especially geometry. Math library for game developers always contains structures like vector, matrix and functions like vector normalization or matrix inversion. But high level shader languages, designed to do geometrical computations, have many more interesting intrinsic functions. Some of more complex ones are reflect and refract, which calculate vector reflection and refraction in relation to the normal of a surface. How to implement them in C++?
Reflection works according the simple rule that "angle of incidence equals angle of reflection". Although there are no angles in the formula - all the necessary work is done by dot product.
void Reflect(VEC3 &out, const VEC3 &incidentVec, const VEC3 &normal)
{
out = incidentVec - 2.f * Dot(incidentVec, normal) * normal;
}
For reflect function, the formula is given in th HLSL documentation, but for refract function it is not. It took me some time to find the implementation, but finally I've found it in the GLSL Specification (thanks KriS!). So here is the code converted to C++. Eta is the refraction index (e.g. 1.5f).
inline void Refract(
VEC3 &out, const VEC3 &incidentVec, const VEC3 &normal, float eta)
{
float N_dot_I = Dot(normal, incidentVec);
float k = 1.f - eta * eta * (1.f - N_dot_I * N_dot_I);
if (k < 0.f)
out = VEC3(0.f, 0.f, 0.f);
else
out = eta * incidentVec - (eta * N_dot_I + sqrtf(k)) * normal;
}
These functions are part of my library: CommonLib.
Comments | #rendering #math Share
# About the Guy Who Made Love
Sat
22
Aug 2009
Today I want to talk a bit about what's the dream of almost every passionate game developer. It seems very hard or almost impossible to achieve, but younger amateurs still hope that they will manage to do it someday. Of course I'm talking about making a 3D MMO game.
As it turned out for me today (thanks for the link KriS!), it actually IS possible. I'm talking about the game called Love written entirely by one person - Eskil Steenberg. He have coded all the software from modeling tools through network protocol and renderer until game mechanics. To see it working I recommend watching these videos. The game is powered by his engine called Quel Solaar, which is actually available for download.
I must admit I haven't been impressed so much for a long time. I suppose the amount of time and passion that had to be put into this code is enormous. Graphical style and gameplay, as well as the user interface of his tools are very unusual and surprising. And all of this is made by one guy...
I recommend watching his lecture from this year's Assembly party titled Developing the technology behind "Love". You can see many technical details and if you don't want to watch the entire one hour video, at least watch the beginning (where he talks about his "smarter way of doing things") and the ending (where he expresses his thoughts about the value of good tools).
BTW it's also nice to watch new videos from GC 2009 of the CryEngine 3. "What you see is what you play" and instant asset update (including textures) - that's how good game editor should look like :)
Comments | #software engineering #networking #web #rendering #games #events #engine #demoscene #philosophy #tools Share
# Beautiful Wallpapers on Flickr
Fri
21
Aug 2009
Yesterday I've found Flickr profile of Reciprocity - Alan Jaras - a research scientist and microscopist playing with photography of caustics and other light effects. Of course it's all the matter of taste, but for me his photos are really amazing. They look so abstract and so natural at the same time. Just look at the galleries Taming Light, Bending Light and Twisting Light. I think it wouldn't be easy to procedurally generate such images. Also check out his Favourites for more unusual images.
Comments | #graphics #web Share
# Source Code and Ray Tracer
Wed
19
Aug 2009
As some of you are interested in seeing source code of my 2D Software Renderer, I'll fullfill this request, although I don't think there is anything special about this code. Here is the file: SoftRender01.zip and here is a brief description of this project:
BTW, I've started coding a raytracer. Of course the first primitive I support is a sphere and first effects I've coded are shadows and reflections. Ray tracing is not magic. It's just like "foreach pixel, foreach object, render", while rasterization is the opposite: "foreach object, foreach pixel, render". But It's quite fascinating that raytracer suppors directly some of effects that require special preprocessing in standard rasterization (like preparing shadow map and enviromental map in case of my effects).
Comments | #productions #rendering #algorithms Share
# My 2D Software Renderer
Tue
18
Aug 2009
I've been recently working on rendering 2D primitives in pure software, without any hardware acceleration. Sure It's about foundations of computer graphics, but I did it just for fun. External libraries I've used are DevIL to read bitmap files (like TGA) and FreeType to read and render font files (like TTF). I compose graphics in my software renderer to my "surface" in RAM and finally present it on the window with SetDIBitsToDevice function. As you can see I've managed to reach real-time performance, despite I haven't done any advanced optimizations like MMX, SSE or multithreading.
My renderer supports drawing rectangles, lines, polygons, circles, ellipses, triangles, blitting bitmaps, as well as scissor test (clipping to rect), alpha test and alpha blending. Here is how the renderer interface looks like:
Comments | #rendering #productions Share
# My Way of Implementing Streams #3
Mon
17
Aug 2009
I've decribed my way of implementing base classes for binary data streams in my recent posts. This time I want to show some of my specific stream classes. The main one is of course FileStream, which gives access to disk files. If opens file in the constructor (throws exception if opening fails) and of course closes it in the destructor.
class FileStream : public SeekableStream
{
public:
FileStream(const std::string &FileName, FILE_MODE FileMode, bool Lock = true);
...
I use standard C functions on Linux (fopen, fclose, fread, fwrite) and WinAPI functions on Windows (CreateFile, CloseHandle, ReadFile, WriteFile). These two API are very different. WinAPI gives much more flexibility, because using CreateFile you can choose separately whether you want write and/or read access, whether to protect file from opening by another application, whether clear the file or access existing data, whether create new file or fail if it doesn't exist etc. But still I've decided to define my FILE_MODE enum in the C-like style (where you pass mode as string like "wb", "rb+" etc.) together with comments explaining details of each mode.
enum FILE_MODE
{
// write: yes, read: no, initial pos: 0
// not exists: create, exists: clear
FM_WRITE,
// write: yes, read: yes, initial pos: 0
// not exists: create, exists: clear
FM_WRITE_PLUS,
// write: no, read: yes, initial pos: 0
// not exists: error, exists: open
FM_READ,
// write: yes, read: yes, initial pos: 0
// not exists: error, exists: open
FM_READ_PLUS,
// write: yes, read: no, initial pos: end
// not exists: create, exists: open
FM_APPEND,
// write: yes, read: yes, initial pos: end
// not exists: create, exists: open
FM_APPEND_PLUS,
};
There is one issue in the Linux implementation though. Documentation says that seeking doesn't work when file is opened in "a" or "a+" mode. WinAPI doesn't have such problems :)
# Reg__ @ Twitter
Sun
16
Aug 2009
I've created Twitter account - http://twitter.com/Reg__. I don't know what will I write there yet but you cannot blame me for joining this popular social networking portal if I find profiles of people like Maciej Sinilo or Josh Petrie there.