Showing posts with label development. Show all posts
Showing posts with label development. Show all posts
Nov 28, 2012
One more exceptional blog
This guy articles are just awesome. I must read them all! As in introduction I personally recommend to read a this one.
Apr 14, 2012
Digger.NET in development, part 4
This post could also be named: "Why is it a good habit to search for and read the docs" or "Why is it a good habit to comment your code".
The base source code of a Digger Remastered is a C Windows application which uses DirectX for graphics output. Due to the source evolution nature of this game (at least I think so), which was a DOS application before, variables naming is somewhat... short. No camel case also. And almost no comments in source code. I've downloaded latest source code for Windows as my starting point. I thought it will not be very hard to understand the code of this, rather simple, game. I've deciphered some part of a high level game code, but then I've approached a graphics code. This is the place there I have stuck a big time. Can you guess what this code does?
As you can see, all variables here, except for i are global. Also complicates things, you know. This was also frustrating because I didn't actually need most of the graphics code, which uses pixel-by-pixel drawing since I use real bitmap sprites for drawing. But because this code also tightly coupled (related) with other game logiŃ (collision detection for example) I need to understand it too.
Not so long ago, I've decided to look for another sources on the site, Java in particular, in hope it will help to understand the graphics code. However, the Java sources were useless, but I've also downloaded (for some unknown reason) old windows sources and voila, I've found some text files inside the zip! The description I found inside was invaluable:
void putis(void)
Redraw background images
quite unexpected from a name though, hmm. Considering there are tens of different obscure functions and global variables, and deciphering one of them can take hours, this file gonna save me big time (pun here!).
Strange thing though is, why not add this single line as a comment in source code file, just there it belongs, not in a big separate text file. Why? Why?! Why?!!
The base source code of a Digger Remastered is a C Windows application which uses DirectX for graphics output. Due to the source evolution nature of this game (at least I think so), which was a DOS application before, variables naming is somewhat... short. No camel case also. And almost no comments in source code. I've downloaded latest source code for Windows as my starting point. I thought it will not be very hard to understand the code of this, rather simple, game. I've deciphered some part of a high level game code, but then I've approached a graphics code. This is the place there I have stuck a big time. Can you guess what this code does?
void putis(void)
{
int i;
for (i=0;i<SPRITES;i++)
if (sprrdrwf[i])
gputi(sprx[i],spry[i],sprmov[i],sprwid[i],sprhei[i]);
}As you can see, all variables here, except for i are global. Also complicates things, you know. This was also frustrating because I didn't actually need most of the graphics code, which uses pixel-by-pixel drawing since I use real bitmap sprites for drawing. But because this code also tightly coupled (related) with other game logiŃ (collision detection for example) I need to understand it too.
Not so long ago, I've decided to look for another sources on the site, Java in particular, in hope it will help to understand the graphics code. However, the Java sources were useless, but I've also downloaded (for some unknown reason) old windows sources and voila, I've found some text files inside the zip! The description I found inside was invaluable:
void putis(void)
Redraw background images
quite unexpected from a name though, hmm. Considering there are tens of different obscure functions and global variables, and deciphering one of them can take hours, this file gonna save me big time (pun here!).
Strange thing though is, why not add this single line as a comment in source code file, just there it belongs, not in a big separate text file. Why? Why?! Why?!!
Apr 12, 2012
Why you should reinvent the wheel
Below, I will talk about game development specifically, but I think this can be applied to any type of development.
The main theme I want to concentrate on is: if you personally experienced problems which some "wheel" solves, then you will use it better and with more satisfaction.
Consider arrays for example. Do you remember very first time you really understand concept of arrays? Usually this is very close to the beginning of language study. But despite that, usefulness of arrays is immediately obvious. You dont need tens of variables to store multiple values, and of course cycle processing of this values is much easier, to say the least.
Now remember user defined functions. They also come early, but not so early as arrays. Functions benefits is not so obvious until your programs go beyond some 100 lines.
And then, pointers. Double linked-lists. Queue. Stack. All of that strange useless magic. Then classes arrived and OOP with that strange inheritance thing. Why do you need to block access to a structure field? Some of us were forced to all this stuff at university or college. But as time goes you begin to understand why all this exist.
There is, however, a different side of this. Many starting game developers, as I can see, for example, at gamedev.stackexchange.com tend to use heavily some rather complex frameworks for games. The problem is that unless you will create game without usage of some frameworks, unless you didn't try to solve problems which arise with you own hands, you can't quite understand even basic logic that stands behind framework, and can't use it effectively.
You don't use classes from the start. You don't use pointers and complex data structures from the start. Not even functions. You use variables and arrays. Then your code grows, you understand concept of a function. And so on, you use more advanced features, then you face problem and understand how that feature helps to solve it. Before that time, your usage of it would be wrong and unefficient. Similarly enough you don't start game development by creating WoW clone, you are making Tetris clone.
Of course there are exceptions. You don't write XNA youself. You don't write standard C library. But this are well built, long time tested, basic functionality tools from a major brand. They can be considered a part of a language. You don't write image manipulation library, it's not the core kwnoledge that drives your game. But you write your game editor, your game core and physics engine. Even if you fail, your experience will be invaluable.
The main theme I want to concentrate on is: if you personally experienced problems which some "wheel" solves, then you will use it better and with more satisfaction.
Consider arrays for example. Do you remember very first time you really understand concept of arrays? Usually this is very close to the beginning of language study. But despite that, usefulness of arrays is immediately obvious. You dont need tens of variables to store multiple values, and of course cycle processing of this values is much easier, to say the least.
Now remember user defined functions. They also come early, but not so early as arrays. Functions benefits is not so obvious until your programs go beyond some 100 lines.
And then, pointers. Double linked-lists. Queue. Stack. All of that strange useless magic. Then classes arrived and OOP with that strange inheritance thing. Why do you need to block access to a structure field? Some of us were forced to all this stuff at university or college. But as time goes you begin to understand why all this exist.
There is, however, a different side of this. Many starting game developers, as I can see, for example, at gamedev.stackexchange.com tend to use heavily some rather complex frameworks for games. The problem is that unless you will create game without usage of some frameworks, unless you didn't try to solve problems which arise with you own hands, you can't quite understand even basic logic that stands behind framework, and can't use it effectively.
You don't use classes from the start. You don't use pointers and complex data structures from the start. Not even functions. You use variables and arrays. Then your code grows, you understand concept of a function. And so on, you use more advanced features, then you face problem and understand how that feature helps to solve it. Before that time, your usage of it would be wrong and unefficient. Similarly enough you don't start game development by creating WoW clone, you are making Tetris clone.
Of course there are exceptions. You don't write XNA youself. You don't write standard C library. But this are well built, long time tested, basic functionality tools from a major brand. They can be considered a part of a language. You don't write image manipulation library, it's not the core kwnoledge that drives your game. But you write your game editor, your game core and physics engine. Even if you fail, your experience will be invaluable.
Aug 15, 2011
Documentation XML auto-comments
Actually I was quite sceptical about auto-commenters which stubs some text into your thriple-slash '///' Documentation XML comments. But after using AtomineerUtils and GhostDoc for some time I must admit: if you are serious about your code quality any of this kind of tools is a must. It saves a lot of time. I was suprised if not impressed about how much actually can tool get from variable name and produce adequate comment. You can even leave it as it is, though it will be absolutely useless, but it's absolutely much easier to fix this predefined comment then to write one from a scratch.
For a most of us C#/VB.NET users, I would recommend GhostDoc, but there are some unique features in AtomineerUtils which you can try out. If you are C/C++ coder then AtomineerUtils is the only solution you have, and you're lucky because it's also extremely good.
For a most of us C#/VB.NET users, I would recommend GhostDoc, but there are some unique features in AtomineerUtils which you can try out. If you are C/C++ coder then AtomineerUtils is the only solution you have, and you're lucky because it's also extremely good.
Aug 8, 2011
Complexities of C/C++ development in modern world
I have not worked with C for a very long time, until recently, then I started DiggerC project. Working with .NET all last years I've took for granted it's all the benefits this architecture gives you. Going back to pure C is like a fresh shower. I'm talking not just about manual memory management, it's least significant part. The most significant thing, that I realized almost immediately — you are almost alone with a C Standard library and a WinAPI. There is just no convenient mechanism for creating reusable libraries in C. At best you can find something like this, but no more. The other part is code manipulation. The .NET 1.0 based Visual Studio .NET (i.e. 7.0) C# projects had same, or better "IntelliSense" support than you have now in Visual Studio 2010 for C. No refactor, comment or almost any other basic coding support feature, you name it — it's not there.
Subscribe to:
Posts (Atom)