Programming, graphics, games, media, C++, Windows, Internet and more...
# Compiler Development - A Higher-Order Hardcore
Sat
31
Jan 2015
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 :)
# Global Game Jam 2015 - Our game: ComicsTale
Tue
27
Jan 2015
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 | #ggj #competitions #productions Share
# Review: Deleaker - A tool that finds resource leaks
Wed
14
Jan 2015
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 | #visual studio #tools #c++ Share
# Good Buy: ADATA DashDrive Elite UE700 128GB USB3.0
Tue
13
Jan 2015
When I was browsing online shop, I was shocked to see that the market of USB flash memory sticks ("pendrives") changed so much recently. I have many pendrives that I was given or won as a prize somewhere, mostly 2-8 GB. My biggest pendrive was 32 GB that I bought several years ago for a very occasional price, as for that time period. Now I can see that the most reasonable choice (for money that I want to spend on a pendrive) is 128 GB!
So I started searching for a model to buy. Sure pendrive is not so complex as a laptop or a car - it's just a small accessory, but anyway I wanted to make a good choice, so I decided to look for following criteria:
Finally I found this one and I bought it for myself, as well as for my family as Christmas present: ADATA DashDrive Elite UE700 128GB USB3.0.
I'm quite happy with it. Transfers that I actually measured by writing and then reading one big file from/to SSD disk are: 110 MB/s write, 181 MB/s read, which is enough to write a 2 GB file in just 18 seconds and read it in 11 seconds.
(This article is not sponsored. It's just my personal recommendation.)
Important Update 2015-06-04: I have two of these pendrives and after half year of using them (not very much - mostly for backup and moving files between computers, once every few days) they both started showing errors and losing files! So eventually I do not recomment this model!!!
Comments | #hardware #shopping Share
# Lectures on ETI, Gdańsk University of Technology
Thu
08
Jan 2015
Employees of Intel Technology Poland are visiting Gdańsk University of Technology, Faculty of Electronics, Telecommunications and Informatics (known as ETI). On Thursday - 8, 15, 22 January 2015, there will be lectures as part of "Computer Graphics" course. Time: 11:15 - 13:00, place: new ETI building, room NE AUD1L. It's a lecture for students of computer science, but anyone who is interested can come and listen.
Together with Piotr Kozioł, I will be presenting on January 22nd. Our presentation has title "Shaders and their compilation" and will cover:
During 2 hours we will cover lots of topics - basically all what happens to the shader after it's written in high level language and passed to graphics API - how it's processed by the driver and executed by the GPU.