Twitter

Pinboard Bookmarks

Blog Tags

Recommended Productions

Ball-B

Simple 3D game developed in Unity during Global Game Jam 2014.

Play Online

Date: 2014-01-26

Download:
Ball_B_Windows.zip (8.78 MB)
Ball_B_Source.zip (20.49 MB)

Octovirus

Simple 2D game developed during Global Game Jam 2013, for Windows.

Date: 2013-01-27

Download:
Octovirus.zip (6.1 MB)

FX Batch Compiler 1.1

This Windows application supports compilation of FX effect files and HLSL shader files using fxc command line compiler included in DirectX SDK. You can compile many files at time or one file with different settings.

Features:

  • Write compilation scripts in a simple language by specifying parameters for fxc.exe.
  • Compile multiple shaders at time.
  • Compile only shaders that need rebuild checked by file modification time.
  • Review success or failure, warning and error count and compiler output for every task.
  • Compile single HLSL source file with different parameters and preprocessor macros.

Date: 2011-02-09

Download:
FxBatchCompiler_1-1.exe
FxBatchCompiler-1.1-bin.zip
FxBatchCompiler-1.1-src.zip

Block Wizard

My first Flash game. Coded with FlashDevelop in ActionScript 3.

Date: 2010-04-06

CommonLib 9.0

Universal library for C++, created especially with game programmers in mind. Includes: math module (vectors, matrices, quaternions, planes, rich set of collision functions and more), string operations, conversions, smart pointers, configuration files handling, date and time module, exception class hierarchy for error handling, file system handling, stream class hierarchy, FreeList - free memory allocator, complex logger, profiler, library for threading and synchronization, tokenizer, wrappers for compression with zlib.

Language: C++. Platforms: Windows and Linux. License: GNU LGPL. Optional support for Unicode. Optional integration with D3DX. Documentation made with Doxygen.

Date: 2009-12-16

Download:
CommonLib_9_0.zip (4.92 MB)

Aqua Fish 2

Game for children - clone of PacMan. Player swims as a fish and collects points, as well as special items. Player also have to run away from enemies or destroy them. 60 maps in 6 different titlesets. Low hardware requirements. See also YouTube videos: [1], [2]. Game was published by Play Publishing company.

GameDev Calc

Calculator for game programmers. Basic data unit is a vector of 1-4 floating point numbers, which can be treated as (x,y,z,w) vector or (r,g,b,a) color. Next to basic calculations like addition, multiplication or sinus, vector operations are also available, e.g. vector normalization, conversion between degrees and radians, color conversion between RGB and HSB, finding linear an quadratic function coefficients and much more. Instead of entering single number, here you can see all the history of your calculations in form of stack and all operations are performed on that stack. Data can be entered and retrieved in different formats, like "D3DXVECTOR4(0.0f, 0.5f, 0.752f, 1.0f)" or "0xFF0080C0". Platform: Windows. Language: C#. License: GNU GPL.

Download:
GameDevCalc_1-0.zip (53.06 KB)
GameDevCalc_1-0_src.zip (50.73 KB)

Blog

21:12
Mon
27
Apr 2015

Watch out for reduced precision normalize/length in OpenGL ES

GLSL language for OpenGL ES introduces concept of precision. You can annotate variable declaration (both float and int/uint) with a precision qualifier: highp, mediump or lowp, like:

mediump float a = 3.0;

You can also specify default precision qualifier by using precision statement. Language specification defines minimum required range and precision for each precision qualifier.

  • highp basically means normal, single-precision, 32-bit float (IEEE 754), as we know it from CPU programming.
  • mediump is said to have have range of at least -2^14 ... 2^14 and relative precision 2^-10, so it can be, for example, implemented using a 16-bit, half-precision float.
  • lowp is said to have range at least -2 ... 2 and absolute precision 2^-8, so basically it can be stored as a 10-bit, fixed-point number.

GPU vendors are free to use more precise data types, or even full 32-bit float for all of them. What exact precision is used depends on specific GPU and maybe even operating system or graphics driver version. Using smaller data types can occupy less memory, calculate faster and consume less battery power. But it comes at the price of reduced precision and range of these numbers. Tom Olson wrote interesting articles about this: "Benchmarking floating-point precision in mobile GPUs": Part I, Part II, Part III.

In this post I'd like to warn you against a specific problem related to it - usage of length(), normalize() and distance() functions. Using smaller data types not only limits precision in terms of number of significant digits, but also available range (over which the value will saturate to -INF/+INF). For mediump, this range is defined as +/-2^14, which is only 16384.

This may still look like a lot, but let's remember that calculating vector length involves intermediate value that it sum of squares of this components. This can grow very big before a square root is applied. For example, for 3D vector:

length(a) = sqrt(a.x*a.x + a.y*a.y + a.z*a.z)

If you do this operation on a mediump vector, the term a.x*a.x + a.y*a.y + a.z*a.z can exceed maximum value for vector as small as (74.0, 74.0, 74.0). It can be very dangerous if you do something like this in your fragment shader:

precision mediump float;
uniform vec3 light_pos;
...
void main()
{
    ...
    vec3 dir_to_light = normalize(pos - light_pos);
    // Calculate your lighting and so on...

You might ask: Why isn't this intermediate value stored in high precision before taking its square root to avoid this overflow problem? Obviously it could be, as precision in any place of the shader is free to be higher than the minimum allowed in that place, so some GPU vendors can do it this way, but you shouldn't rely on this. GLSL specification clearly says that the shader is free to use same, reduced precision for intermediate values.

The precision used to internally evaluate an operation, and the precision qualification subsequently associated with any resulting intermediate values, must be at least as high as the highest precision qualification of the operands consumed by the operation.

Conclusion is: When you write shaders for OpenGL ES, watch out for operations that involve calculating vector length (or dot product) like length(), normalize(), distance(), use highp precision for vectors involved and remember that what works on one GPU due to using precision higher than minimum required, may not work on another GPU and it’s still an application issue.

Comments (1) | Tags: math opengl | Author: Adam Sawicki | Share

20:28
Fri
03
Apr 2015

My visuals on Headrush party in Protokultura, Gdańsk

Next Saturday, 2015-04-11, you can see my music visualizations on Headrush party in Protokultura club in Gdańsk. There will be 3 scenes with various genres of electronic dance music, and the club is big and very good, so I'm sure it will be great party. My visuals will be shown on psytrance scene. Unfortunately I can't be there myself, but I'm sure my friends Wooffer and Brain Massage will handle setup of this system very well. Some random screenshots:

Comments (0) | Tags: events music psytrance | Author: Adam Sawicki | Share

18:10
Thu
12
Mar 2015

Funny quotes from Twitter

Today I reviewed all the tweets that I have in favorites and made a list of most funny (and sometimes quite serious) quotes that I could find there. They are mostly about C++, games and graphics programming. Enjoy :)

If Tetris has taught me anything, it's that errors pile up and accomplishments disappear.
Reproducibility is collaborating with people you don't know, including yourself next week (@philipbstark at #dsesummit)
QA Engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders a sfdeljknesv.
Sony totally missed the opportunity to call their phones Talkman.

Read full entry > | Comments (1) | Tags: humor | Author: Adam Sawicki | Share

23:20
Tue
03
Mar 2015

IGK 2015 Conference

On 10-12 April 2015 the 12th edition of IGK gamedev conference is taking place in Siedlce, Poland (see also topic on forum.warsztat.gd). Registration is now open.

I will be there, giving a lecture "On the other side of graphics API. How does graphics driver and chip look like?" (It will be in Polish. Actual title: "Po drugiej stronie API graficznego. Czyli jak wygląda sterownik i układ graficzny?")

Abstract: A programmer developing games or other applications that utilize GPU uses one of API-s for 3D graphics (e.g. DirectX, OpenGL) or GPGPU (e.g. OpenCL). With examples based on the Intel products, the lecture shows what is on the other side of that API: characteristics and components of graphics driver (especially shader compiler), architecture of a GPU and its instruction set.

Comments (0) | Tags: intel igk events | Author: Adam Sawicki | Share

22:06
Fri
06
Feb 2015

Psychill Evening Vol 2 with my visuals

On Friday, 13 February 2015 I'd like to invite you for second edition of Psychill Evening party in Paszcza Lwa club in Gdańsk, Poland. Once again the music will be "Psychill, Psybient, Downtempo, Psydub and Ambient", so basically more calm genres of electronic music. Once again I will be doing visuals on this party. See also my blog entry and video below from first edition.

I'm now working on my software to prepare some new stuff. Some random screenshots:

Of course this is a blog about programming, not about art or parties, so in the next posts I will explain some of the technical details behind this program.

Comments (2) | Tags: vj psytrance music events | Author: Adam Sawicki | Share

18:14
Sat
31
Jan 2015

Compiler Development - A Higher-Order Hardcore

Of various kinds of programs that a programmer can work with, I think that developing compilers is particularly difficult. Here is why:

If your job is to just work with data (e.g. in Excel), all that can be wrong is just the data.

If you are a programmer, you write programs. Programs generally translate some input data to some output data. So if the output is wrong, you examine the input and if you are convinced that the input is correct, there is probably some bug in your program.

If you develop a compiler, things get even more complicated. Then you write a program (compiler) that will take source code of another program as input and produce compiled program as output. That program will process some data. So if the output of that program is wrong, its input data may be wrong, its source code may have a bug or, if you are convinced that they are both correct, there is probably some bug in the compiler. So there are more “degrees of freedom” here. You examine what’s wrong in the output data, then you look at compiled program to find a bug and finally you examine the compiler to understand why it generated that program.

It’s not always that simple to even determine which part has a bug. Even if your change in the compiler causes program to produce invalid output, sometimes it may be a bug in the source code. For example, the program may rely on some undefined behavior (like use of uninitialized variable), so any change in the compiler can produce different output, while the compiler is still correct.

When learning functional programming, you must understand how to operate on higher-order functions - functions that operate on functions. I can see an analogy here. So if you even consider working in compiler development, better think twice whether you are ready for such higher-order, hardcore level of debugging :)

Comments (4) | Tags: compilers | Author: Adam Sawicki | Share

20:12
Tue
27
Jan 2015

Global Game Jam 2015 - Our game: ComicsTale

Last weekend a big event took place - Global Game Jam. As every year, thousands of people around the world had fun while making a game in 48 hours. I was in a jam site 3City Game Jam (link to site at globalgamejam.org) in Gdańsk, Poland, organized in Olivia Business Center by Playsoft Games. With 163 registered jammes, it was one of the biggest in the world (actually 24th out of 518 sites)!

Theme this year was a question: "What do we do now?" so we came up with an idea for a game that looks like a comics, where player has to choose where to click. Our team was:

Developers: Leonardo Kasperavičius, Adam Sawicki
2d artist: Ryszard Niedzielski
Game designer & producing: Frederic Raducki

And here is our game: ComicsTale (source code on GitHub). It is made in Unity (as most of the games), with 2D graphics and with mobile platforms in mind. In the voting on 3City Game Jam, we took 4th place out of around 36.


comicstales_win.zip - Windows Binary
comictales.apk - Android Binary
comictales_mac.zip - Mac Binary

It was fun to make game in a weekend. People were nice, atmosphere was great and there was free pizza! I recommend participating in Global Game Jam to anyone interested in game development. It's much more interesting than coding alone at home and submitting games to some virtual, online competitions.

Comments (3) | Tags: productions competitions ggj | Author: Adam Sawicki | Share

23:57
Wed
14
Jan 2015

Review: Deleaker - A tool that finds resource leaks

Deleaker is a tool for programmers that finds resource leaks in C++ programs. It's commercial, with free trial and unconditional 30 day money back. Here is my review of this tool. I've tested version 3.0.27.0.

Deleaker is installed as a plugin for Visual Studio, any version from 2005 to 2013. It also works with Visual Studio Community 2013, as this new free version also supports plugins. There is also standalone Deleaker application (see below).

The purpose of this tool is to augment debugging of native C++ programs with the ability to list all resources that are allocated at the moment (heap memory, virtual memory, OLE memory, GDI objects, USER objects, handles) and so to detect resource leaks. Here is how it works:

The interface is very simple - it can be learned in just few minutes. You can build your program and start debugging it by hitting F5, Deleaker is enabled automatically. Now just open dedicated panel (menu Deleaker > Deleaker Window) and there press "Take snapshot" button. You don't even have to pause execution, but of course the button works as well when your program is paused at a breakpoint. After few seconds, the panel is populated with a list of currently allocated resources, with the place from which it was allocated shown in first column.

After selecting one, bottom panel displays full call stack. Clicking in this call stacks navigates to the place in the source code where the allocation is specified. Finally, after program exit, the list is filled with resources that were not freed - these are actual leaks!

You can filter the list by module (EXE or DLL file that made the call) and by resource type (memory, GDI objects etc.). There is also a column with size of the resource and "Hit Count" - number of resources that were allocated by that particular place in the code (e.g. inside a loop) and stay allocated at the moment.

"Show full stack" button is a nice feature. Clicking it displays full call stack, while by default, the stack is stripped from entries that don't come from your code, but from system libraries. For example, above my function with the actual allocation instruction, there is MSVCR120D.dll!operator new, then there is MSVCR120D.dll!malloc etc... until ntdll.dll!RtlAllocateHeap. It's good that the program can ignore such call stack entries. It also entirely ignores allocations made by system modules outside of your code.

Unfortunately it does this only by identifying module that the function comes from and not it's name, so it cannot ignore templates, like these from STL containers. Maybe ignoring functions by name specified as wildcard or regular expression would help, e.g. "std::*" or "std\:\:.+" - just like Visual Studio debugger can step over specified functions, as I described in How to Make Visual Studio Debugger not Step Into STL.

You can press "Take snapshot" multiple times and save the snapshots for later view. (They are just numbered, you cannot give them names.) By the way, Deleaker captures F5 key, so even when during debugging session, if the focus is in Deleaker panel, this button doesn't resume your program, but instead refreshes the list of allocations (takes new snapshot). You can also select two snapshots and compare them. Then you see only resources that were allocated in the right snapshot and not in the left, which can indicate a leak that happened during some time of the program execution.

Besides heap memory allocations, the tool can also detect other types of resources, like GDI objects. Unfortunately not all interesting types of resources are covered. For example, an opened file of type FILE* f = fopen(...) is shown as normal memory allocation and opened file of type HANDLE f = CreateFile(...) is not shown at all, but I guess it must be due to some system internals.

I didn't find a single leak in my main home project, so I created a dedicated, simple program to test if it can really find leaks. I also checked that it works with programs compiled in Release configuration as well.

Aside from being a Visual Studio plugin, Deleaker can also work as standalone Windows application.

Overall, I like the program. If its price is not a problem for you or your company, I think it can be very useful in improving quality of developed software. I especially like the fact that it's so easy to learn and use.

Comments (1) | Tags: c++ tools visual studio | Author: Adam Sawicki | Share

Older entries >

STAT NO AD [Stat] [Admin] [STAT NO AD] [pub] [Mirror] Copyright © 2004-2015 Adam Sawicki
Copyright © 2004-2015 Adam Sawicki