<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Get Info: #60fps</title>
    <description>Posts tagged “60fps” — Blog of independent game and app developer Matt Sephton. Featuring vintage Macintosh, game development, digital artwork, Japanese esoterica, video game reviews, hacks and tips, and much more.</description>
    <link>https://blog.gingerbeardman.com/tag/60fps/</link>
    <atom:link href="https://blog.gingerbeardman.com/tag/60fps/index.xml" rel="self" type="application/rss+xml"/>
    <pubDate>Wed, 01 Jul 2026 16:09:47 +0000</pubDate>
    <lastBuildDate>Wed, 01 Jul 2026 16:09:47 +0000</lastBuildDate>
    <generator>Jekyll v4.4.1</generator>

    
      
        <item>
          <title>Daily Driver: One Shade of Grey?</title>
          <description>&lt;p&gt;Since I am targeting 60fps one of the things I can do is flash a black sprite every other frame to get a shade of grey. Yes! Grey on a black and white screen.&lt;/p&gt;

&lt;p&gt;It only works at high frame rates (note: 50fps isn’t high enough!) because the screen is &lt;em&gt;so damned good&lt;/em&gt; that flashing at a slower rate simply looks like… an image flashing. The effects is also visible on device for the same reason.&lt;/p&gt;

&lt;p&gt;So I’m not sure I’ll use it, as all other shadows are dithered and flashing them all will hit the frame rate. But it was fun to try! One for another game, perhaps?&lt;/p&gt;

&lt;blockquote&gt;
  &lt;p&gt;I believe this technique was used on other systems with limited colours, such as Game Boy and Palm (to get 4 shades), certain Commodore 64 games (eg. Creatures 2) did it to get never-before-seen colours, and of course old arcade and video games often did exactly my trick to get their semi-opaque shadows.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;&lt;img src=&quot;https://cdn.gingerbeardman.com/images/posts/daily-driver-one-shade-grey.jpg&quot; alt=&quot;JPG&quot; /&gt;&lt;/p&gt;
</description>
          <author>by Matt Sephton</author>
          <pubDate>Wed, 19 Aug 2020 00:00:00 +0000</pubDate>
          <link>https://blog.gingerbeardman.com/2020/08/19/one-shade-of-grey/</link>
          <guid isPermaLink="true">https://blog.gingerbeardman.com/2020/08/19/one-shade-of-grey/</guid>
        </item>
      
    
      
        <item>
          <title>Daily Driver: High Frame Rates are Best Frame Rates</title>
          <description>&lt;p&gt;Over the course of development I’d been unhappy with the game running at 30fps, as it did not feel responsive enough. I’m a big believer that if a gamer features fast action gameplay and requires quick reactions then higher frame rates and lower response time are what is needed.&lt;/p&gt;

&lt;p&gt;Over the lifetime of the project I had beeb experimenting with running the game at a higher frame rate, as the maximum frame rate supported by Playdate SDK is 50fps. When I wrote my physics I did so in a way that it was not tied to one specific frame rate. Actually, it’s more correct to say that it is tied to the highest frame rate of 50fps but is done so in a way that it can be adapted to any frame rate.&lt;/p&gt;

&lt;p&gt;Anyway, after a round of optimisations and general improvements to the way I did both the skid marks (draw direct to background image rather as sprites) and sound effects (not attaching the whole sound engine to each object!) my game was running at max frame rate.&lt;/p&gt;

&lt;p&gt;So, I decided to see how high the game would run if I removed the frame limiter (which the SDK allows) and to my surprise my hame was running between 60 and 75fps. At this point I had the crazy idea of running my game at 60fps, because… why not? I wrote my own simple frame limiter (which would be more precise if the SDK allowed finer grained time reporting) and now the game runs faster and smoother than games should on Playdate.&lt;/p&gt;

&lt;p&gt;One interesting thing I noticed was that if I used my frame limiter code to limit the game to 50fps, I actually had a bunch more time, ~3ms, to do stuff per frame update than if I used the SDK frame limiter! I can only assume that every frame update the SDK frame limiter is doing something I am not doing.&lt;/p&gt;

&lt;p&gt;So, writing my own frame limiter clawed back some time from the SDK and also allowed me to go harder, better, faster, stronger. Double win!&lt;/p&gt;
</description>
          <author>by Matt Sephton</author>
          <pubDate>Tue, 14 Jul 2020 00:00:00 +0000</pubDate>
          <link>https://blog.gingerbeardman.com/2020/07/14/high-frame-rates/</link>
          <guid isPermaLink="true">https://blog.gingerbeardman.com/2020/07/14/high-frame-rates/</guid>
        </item>
      
    

  </channel>
</rss>
