<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <link href="https://marekfiser.com/feed.xml" rel="self" type="application/atom+xml"/>
  <link href="https://marekfiser.com/" rel="alternate" type="text/html" hreflang="en"/>
  <updated>2026-08-16T00:00:00Z</updated>
  <id>https://marekfiser.com/</id>
  <title type="html">Marek&apos;s blog</title>
  <subtitle>Marek&apos;s blog about game dev, computer graphics, programming, and fractals!</subtitle>
  <author>
    <name>Marek Fiser</name>
    <email>blog@marekfiser.com</email>
  </author>
  <entry xml:lang="en">
    <title type="html">Double-double: 31 digits of precision without leaving the FPU</title>
    <link href="https://marekfiser.com/blog/double-double-arithmetic" rel="alternate" type="text/html"/>
    <published>2026-08-16T00:00:00Z</published>
    <updated>2026-08-16T00:00:00Z</updated>
    <id>https://marekfiser.com/blog/double-double-arithmetic</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="blog"/>
    <category term="C#"/>
    <category term="Performance"/>
    <category term="Fractals"/>
    <summary>If you ever need more precision than what 15 decimal digits of the double format can offer, and arbitrary-precision arithmetic is too slow, too heavy, or simply not available, there is a neat trick: glue two doubles together and treat them as one number. This gives you ~31 decimal digits for roughly 9x the cost of a plain double in a real kernel (4-12x per isolated operation). With no heap allocation and no dependencies, this lands it almost exactly halfway between a double and an arbitrary-precision library perf-wise. This post explains the error-free transformations that make it work, measures it against MPFR, and shows where the trick runs out of steam.</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">Unity&apos;s Mono problem: Why your C# code runs slower than it should</title>
    <link href="https://marekfiser.com/blog/mono-vs-dot-net-in-unity" rel="alternate" type="text/html"/>
    <published>2025-12-27T00:00:00Z</published>
    <updated>2025-12-27T00:00:00Z</updated>
    <id>https://marekfiser.com/blog/mono-vs-dot-net-in-unity</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="blog"/>
    <category term="Unity (engine)"/>
    <category term="C#"/>
    <category term="Performance"/>
    <summary>Execution of C# code in Unity&apos;s Mono runtime is slow by today&apos;s standards, much slower than you might expect! Our game runs 2-3x faster on modern .NET compared to Unity&apos;s Mono, and in a few small benchmarks I measured speedups of up to 15x. I&apos;ve spent some time investigating what&apos;s going on and in this article I will present my findings and why everyone should want Unity&apos;s .NET modernization to become production-ready as soon as possible.</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">IOException: Success</title>
    <link href="https://marekfiser.com/blog/io-exception-success" rel="alternate" type="text/html"/>
    <published>2024-12-29T00:00:00Z</published>
    <updated>2024-12-29T00:00:00Z</updated>
    <id>https://marekfiser.com/blog/io-exception-success</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="blog"/>
    <category term="C#"/>
    <summary>Some time ago, I encountered and resolved a truly bizarre issue: certain players were unable to save their game due to an IOException with the error message &quot;Success&quot;. To this day, I still receive inquiries from fellow devs about how to address this problem. This article documents the issue and provides a reference for the workaround.</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">Is 16.7 million colors enough?</title>
    <link href="https://marekfiser.com/blog/is-16m-colors-enough" rel="alternate" type="text/html"/>
    <published>2015-01-05T00:00:00Z</published>
    <updated>2015-01-05T00:00:00Z</updated>
    <id>https://marekfiser.com/blog/is-16m-colors-enough</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="blog"/>
    <category term="Computer graphics"/>
    <category term="Fractals"/>
    <summary>Majority of our devices today can display 16.7 million colors. This may sound as a lot but sometimes human eye can notice a difference between two neighboring colors. I have encountered this problem while creating some fractal images. The solution to the limitation is usage of dithering. This article describes the problem and presents a simple solution.</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">Mausr - Marek&apos;s Unicode Symbols Recognizer</title>
    <link href="https://marekfiser.com/projects/mausr-mareks-unicode-symbols-recognizer" rel="alternate" type="text/html"/>
    <published>2014-12-21T00:00:00Z</published>
    <updated>2014-12-21T00:00:00Z</updated>
    <id>https://marekfiser.com/projects/mausr-mareks-unicode-symbols-recognizer</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="projects"/>
    <category term="Machine learning"/>
    <category term="C#"/>
    <category term="ASP.NET"/>
    <summary>Mausr is a library and web interface that performs unicode symbols recognition from hand drawn input using simple neural network. The symbol recognition library is written from scratch without any ML library and it implements back-propagation learning algorithm as well as basic non-linear optimization algorithms such as gradient descent and iRprop.</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">Internship at NVIDIA 2014</title>
    <link href="https://marekfiser.com/blog/internship-at-NVIDIA-2014" rel="alternate" type="text/html"/>
    <published>2014-09-15T00:00:00Z</published>
    <updated>2014-09-15T00:00:00Z</updated>
    <id>https://marekfiser.com/blog/internship-at-NVIDIA-2014</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="blog"/>
    <category term="Internship"/>
    <summary>I spent summer of 2014 as an intern at the NVIDIA. That was quite different experience than the last year in the Google. This article describes all the aspects of being an intern in the Silicon Valley including tips how to prepare for such adventure. A big part of the summer was a road trip from Indiana to California and back and I will talk about it as well. After I returned everybody keep asking me: What is better, NVIDIA or Google? You can find out my personal opinion in the post!</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">Mamex - Marek&apos;s Mandelbrot explorer</title>
    <link href="https://marekfiser.com/projects/mamex-mareks-mandelbrot-explorer" rel="alternate" type="text/html"/>
    <published>2014-08-04T00:00:00Z</published>
    <updated>2014-08-04T00:00:00Z</updated>
    <id>https://marekfiser.com/projects/mamex-mareks-mandelbrot-explorer</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="projects"/>
    <category term="Fractals"/>
    <category term="C#"/>
    <category term="C++ CLI"/>
    <category term="Computer graphics"/>
    <summary>Mamex is a Mandelbrot set rendering library written in C# and supports arbitrary precision (provided by GMP) for infinite zoom. The explorer can visualize Mandelbrot and Julia sets and has many additional features such as interactive color gradient editor, projections support, and batch rendering. Custom anti-aliasing algorithm, sharpening, and color dithering algorithms yields beautiful results.</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">Internship at Google 2013</title>
    <link href="https://marekfiser.com/blog/internship-at-Google-2013" rel="alternate" type="text/html"/>
    <published>2013-09-18T00:00:00Z</published>
    <updated>2013-09-18T00:00:00Z</updated>
    <id>https://marekfiser.com/blog/internship-at-Google-2013</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="blog"/>
    <category term="Internship"/>
    <summary>In the summer of 2013 I had an opportunity to be a part of the Google for whole 14 weeks. This article tells the whole story starting from the application process describing all my great experience. I was interning at Google Headquarters in sunny California and I was member of Google Research team. This article is accompanied with around 100 images from Google campus and surrounding areas.</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">Realtime visualization of 3D vector fields using CUDA</title>
    <link href="https://marekfiser.com/projects/realtime-visualization-of-3D-vector-fields-using-CUDA" rel="alternate" type="text/html"/>
    <published>2013-04-21T00:00:00Z</published>
    <updated>2013-04-21T00:00:00Z</updated>
    <id>https://marekfiser.com/projects/realtime-visualization-of-3D-vector-fields-using-CUDA</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="projects"/>
    <category term="C++"/>
    <category term="CUDA"/>
    <category term="OpenGL"/>
    <category term="Computer graphics"/>
    <summary>This project demonstrates visualization techniques like glyphs, stream lines, stream tubes, and stream surfaces, all done in real time. The key is RK4 integrator implemented using CUDA that is uses very fast texture lookup functions to access a vector field. This article contains more than 100 images and figures, commented code snippets, and source code available for download.</summary>
  </entry>
  <entry xml:lang="en">
    <title type="html">Conway&apos;s Game of Life on GPU using CUDA</title>
    <link href="https://marekfiser.com/projects/conways-game-of-life-on-gpu-using-cuda" rel="alternate" type="text/html"/>
    <published>2013-03-17T00:00:00Z</published>
    <updated>2013-03-17T00:00:00Z</updated>
    <id>https://marekfiser.com/projects/conways-game-of-life-on-gpu-using-cuda</id>
    <author>
      <name>Marek Fiser</name>
      <email>blog@marekfiser.com</email>
    </author>
    <category term="projects"/>
    <category term="CUDA"/>
    <category term="C++"/>
    <category term="OpenGL"/>
    <category term="Simulation"/>
    <summary>This project compares performance of CPU and GPU in evaluation of famous Conway&apos;s Game of Life. The performance was tested on three different implementations. The most sophisticated version of the algorithm on GPU stores data in one bit-per-cell array and leads to speed-up of 480x compared to serial CPU algorithm. The best implementation for CPU turned out to be lookup-table approach leading to 60x speedups over serial CPU. The report contains detailed explanation of used algorithms, measurements, and code of whole project for download.</summary>
  </entry>
</feed>
