<?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 arithmetic: 31 digits of precision from two doubles</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, 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. With no heap allocation and no dependencies, this puts it perf-wise almost exactly halfway between a double and an arbitrary-precision library. This post explains how the format works and the math behind it. It also benchmarks the type against __float128 and 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>The majority of our devices today can display 16.7 million colors. This may sound like a lot but sometimes the 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 the 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 a simple neural network. The symbol recognition library is written from scratch without any ML library and it implements a 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 the summer of 2014 as an intern at NVIDIA. That was a quite different experience than the last year in Google. This article describes all the aspects of being an intern in Silicon Valley including tips how to prepare for such an 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 keeps 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 an interactive color gradient editor, projections support, and batch rendering. Custom anti-aliasing algorithm, sharpening, and color dithering algorithms yield 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 Google for a 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 a member of the 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 an RK4 integrator implemented using CUDA that 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 a speed-up of 480x compared to the serial CPU algorithm. The best implementation for CPU turned out to be a lookup-table approach leading to 60x speedups over serial CPU. The report contains a detailed explanation of used algorithms, measurements, and code of the whole project for download.</summary>
  </entry>
</feed>
