Programming, graphics, games, media, C++, Windows, Internet and more...
All blog entries, ordered from most recent. Entry count: 1198.
Pages: 
1 ... 46 47 48 49 50 ... 150 
# Data-Oriented Design - Links and Thoughts
Thu
06
Jan 2011
In April 2008 I've written an essay "Fanatyzm obiektowy" (in Polish, it means "Object-Oriented Fanaticism"). I've always believed there is something wrong with object-oriented programming, that it simply doesn't meet its own objectives and so following it blindly as an ideology not only a programming language mechanics has many pitfalls. Now I'm glad that recently a concept of "Data-Oriented Design" (DOD) emerged and gained popularity among game developers. Here is my try to aggregate all important information on this subject that can be found on the Internet:
Slides:
Blog entries:
Other:
If you know any other good readings on this subject, please leave a comment. I'll update my list.
As far as I can see, focusing more on data instead of objects gives a number of benefits for the code:
Of course DOD doesn't exist in the void. It's related to many other concepts and you can find many good sources of knowledge about each one. Some of them are:
Comments | #software engineering #c++ Share
# My Talk about OOP on Polygon Group - Slides
Thu
06
Jan 2011
Here are slides from my today presentation - "Pułapki programowania obiektowego" (in Polish): PDF, PPTX.
Comments | #teaching #events Share
# Generating LIB File for DLL Library
Tue
04
Jan 2011
I've been recently trying to use libVLC - functionality of great, codec-less VLC media player enclosed in form of DLL library. By the way I've came across a great article: GenerateLibFromDll and now I know how to generate LIB file for any DLL library! Here is detailed description of the problem:
When you have a DLL library you want to use in your C++ code, you may do it dynamically by using LoadLibrary and GetProcAddress functions from WinAPI, but it's more convenient to do it statically. But it's not enough to just #include signatures of library functions and use them in your project. You also need to link with some LIB file, even if the file is not a real static library with compiled code, but only a few-kilobyte-long list of imported functions. I believe that's just another flaw of C++ language, because other languages like for example C# don't need this even when importing functions from native DLL libraries.
If you have some SDK prepared for Visual C++ or compile the library by yourself, you also get the LIB file next to DLL. But if you have only the library, that article shows following steps to generate matching LIB:
1. From Start menu run "Visual Studio Command Prompt".
2. Execute command:
dumpbin /exports DLL_FILE.dll > DEF_FILE.def
This command prints some information about given DLL library in textual form to its standard output. We redirect it to a text file with DEF extension. But to make it real DEF file, we need to edit it.
3. Open DEF_FILE.def in some text editor and edit it to contain only the names of exported functions in form of:
EXPORTS
function_1_name
function_2_name
function_3_name
...
4. From the Visual Studio Command Prompt, execute another command:
lib /def:DEF_FILE.def /out:LIB_FILE.lib /machine:x86
And there you have it! The so much required LIB file generated from DLL library. You only need signatures of these functions with proper parameters and return values declared in some H header file and you can successfully use your DLL by linking with LIB file created by yourself :)
Comments | #visual studio #c++ #windows #winapi Share
# My Talk about OOP on Polygon Group
Mon
03
Jan 2011
This Wednesday on the Polygon scientific group I'll give a talk titled "Pułapki programowania obiektowego" ("Pitfalls of Object-Oriented Programming" - but that's just a translation, not to be confused with great English article with same title). It will be a polemics with the recent Veldrin's presentation on design patterns and also another expression of my interest in the topic of DOD (Data-Oriented Design). I'll post more on this subject soon, including slides from my presentation.
Comments | #teaching #events Share
# Origami: Platonic Solids?
Sun
02
Jan 2011
Here are all solids I managed to assemble from origami Sonobe module that look like regular polyhedra. I know 4 of them and I wonder if there are some more possible? Are there somehow related to the concept of platonic solid?
# Different Ways of Processing Data
Tue
14
Dec 2010
Much is being said about UX these days, while not so much about the art and science of designing good API so libraries can communicate successfully with their users, that is other programmers. I'm interested in the latter for some time and today I'd like to explore the topic of how some data, whether objects or a raw sequence of bytes, can be processed, loaded and saved. I will clarify what I mean in just a moment. I believe the ways to do it can be grouped into several categories, from simplest but most limited way to the most flexible, efficient but difficult to use.
1. The simplest possible interface for loading (or saving) some data is to pass a string with path to file. That's the way we load DLL libraries in WinAPI. Unfortunately it limits the programmer to load object only from physical files, not from other places like memory pointer, where source data could be placed e.g. after decompression or downloading from network.
HMODULE WINAPI LoadLibrary(__in LPCTSTR lpFileName);
2. Solution to this problem is an API that allows loading data from either file or memory. Some example can be texture loading in D3DX (extension to DirectX), where separate functions are available that take either path to a disk file (LPCTSTR pSrcFile), pointer to a buffer in memory (LPCVOID pSrcData, UINT SrcDataSize) or Windows resource identifier (HMODULE hSrcModule, LPCTSTR pSrcResource).
HRESULT D3DXCreateTextureFromFile(
__in LPDIRECT3DDEVICE9 pDevice,
__in LPCTSTR pSrcFile,
__out LPDIRECT3DTEXTURE9 *ppTexture);
HRESULT D3DXCreateTextureFromFileInMemory(
__in LPDIRECT3DDEVICE9 pDevice,
__in LPCVOID pSrcData,
__in UINT SrcDataSize,
__out LPDIRECT3DTEXTURE9 *ppTexture);
HRESULT D3DXCreateTextureFromResource(
__in LPDIRECT3DDEVICE9 pDevice,
__in HMODULE hSrcModule,
__in LPCTSTR pSrcResource,
__out LPDIRECT3DTEXTURE9 *ppTexture);
Another possible approach is to utilize single function and interpret given pointer as either string with file path or a direct memory buffer, depending on some flags. That's the way you can load sound samples in FMOD library:
FMOD_RESULT System::createSound(
const char * name_or_data,
FMOD_MODE mode,
FMOD_CREATESOUNDEXINFO * exinfo,
FMOD::Sound ** sound
);
Where name_or_data is "Name of the file or URL to open, or a pointer to a preloaded sound memory block if FMOD_OPENMEMORY/FMOD_OPENMEMORY_POINT is used."
3. That's more flexible, but sometimes an object is so big that it's not efficient or even possible to load/uncompress/download its full contents into memory before creating a real resource or do some processing. What's needed is an interface to process smaller chunks of data at time. One of ways to do it is defining an interface with callbacks that the library will call to query for additional piece of data. Then we can implement this interface to read data from any source we wish, whether simple disk file, compressed archive or a network socket. When we want to load an object, we call appropriate function passing pointer to our implementation of the interface. During this call our code is called back and asked to read data. For example, that's the way we can load sounds in Audiere library. The interface for reading data is:
class File : public RefCounted {
public:
ADR_METHOD(int) read(void* buffer, int size) = 0;
ADR_METHOD(bool) seek(int position, SeekMode mode) = 0;
ADR_METHOD(int) tell() = 0;
};
4. A step futher towards more flexibility and generality is the concept of streams, like from Java, C# or Delphi. These object-oriented languages define in their standard libraries an abstract base class for input (for reading data) and output stream (for writing data) that can be implemented in many possible ways. For example, Java's InputStream class defines methods:
void close()
int read()
int read(byte[] b)
int read(byte[] b, int off, int len)
void reset()
long skip(long n)
Many derived classes are provided. Some of them read/write data from real sources like file or network connection, while others process data (for example compress, encrypt) and pass them to another stream. This way a chain of responsibilities can be created where we write data to a stream that compresses them and pass them to another stream, which encrypts them and passes them to the one that does buffering and finally write the data to the stream that saves it to a file. It's my favourite approach right now, although it has a drawback - an overhead for virtual method calls in each stream for each piece of data read or written. This inefficiency can be minimized by controlling granularity - processing a buffer of reasonable size at time, never byte-after-byte.
5. Finally, there is the most direct, low-level approach which is also most flexible and efficient, but at the same time very difficult to use properly. I'm talking about a single function that takes pointers to input and output buffers, as well as some structure containing current state and processes a piece of data. It consumes some/all data from input buffer (by advancing some pointer or counter) and produces new data to the output buffer. There are no callbacks. The interface is neither "push" (where we write data) or "pull" (where we read data), but both at time. That's the way zlib compression library works (which I complained about here, in Polish), as well as LZMA SDK (which I described here).
typedef struct z_stream_s {
Bytef *next_in; /* next input byte */
uInt avail_in; /* number of bytes available at next_in */
uLong total_in; /* total nb of input bytes read so far */
Bytef *next_out; /* next output byte should be put there */
uInt avail_out; /* remaining free space at next_out */
uLong total_out; /* total nb of bytes output so far */
char *msg; /* last error message, NULL if no error */
struct internal_state FAR *state; /* not visible by applications */
//...
} z_stream;
ZEXTERN int ZEXPORT deflate OF((z_streamp strm, int flush));
Comments | #software engineering #c++ Share
# My Implementation of Diff Algorithm
Tue
16
Nov 2010
Algorithm for comparing two sequences of some data is very useful. For example, version control systems like SVN or Git use it to highlight differences between two versions of a text file. But what if you need to code such algorithm from scratch? Today it was my task and it turned out to be not so simple, so I want to share my sample implementation in C++ which I came up with based on some readings from the Internet and my previous experiences with calculating Levenshtein distance.
What we need to compare is sometimes just lines of text files that are equal or not, but I needed something more complex, so let's say an item is defined as follows:
struct Item
{
unsigned ID;
const char *Text;
};
For items from opposite sides to be comparable they must have same ID values. Text may be different, but I'd prefer to match items with same Text (treated as NULL-terminated string) or at least same Text length.
Here are sample data:
const Item items1[] = {
{ 1, "Foo" },
{ 1, "Foo" },
{ 2, "Bar" },
{ 4, "Foobar" },
};
const Item items2[] = {
{ 1, "Foo" },
{ 1, "Firefox" },
{ 1, "Another one" },
{ 2, "Boo" },
{ 5, "Last one" },
};
const unsigned count1 = _countof(items1);
const unsigned count2 = _countof(items2);
The final result may look like this:
1 Foo <-> 1 Foo
-- <-> 1 Firefox
1 Foo <-> 1 Another one
2 Bar <-> 2 Boo
4 Foobar <-> --
-- <-> 5 Last one
# C++ in Game Programming - Slides
Thu
04
Nov 2010
Here are slides from my yesterday lecture "C++ in Game Programming" (in Polish):
C++ w programowaniu gier.pdf
C++ w programowaniu gier.pptx
Comments are welcome. I consider this an attempt before writing something bigger of this kind that I hope to submit as a paper to one of Polish game developers conferences next year, like IGK.