Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I've worked on Java mobile games... The best way to avoid GC'ing objects (which in turn <em>shall</em> trigger the GC at one point or another and <em>shall</em> kill your game's perfs) is simply to avoid creating them in your main game loop in the first place.</p> <p>There's no "clean" way to deal with this and I'll first give an example...</p> <p>Typically you have, say, 4 balls on screen at (50,25), (70,32), (16,18), (98,73). Well, here's your abstraction (simplified for the sake of this example):</p> <pre><code>n = 4; int[] { 50, 25, 70, 32, 16, 18, 98, 73 } </code></pre> <p>You "pop" the 2nd ball which disappears, your int[] becomes:</p> <pre><code>n = 3 int[] { 50, 25, 98, 73, 16, 18, 98, 73 } </code></pre> <p>(notice how we don't even care about "cleaning" the 4th ball (98,73), we simply keep track of the number of balls we have left).</p> <p>Manual tracking of objects, sadly. This how it's done on most current well-performing Java games that are out on mobile devices.</p> <p>Now for strings, here's what I'd do:</p> <ul> <li>at game initialization, predraw using <em>drawText(...)</em> <em>only once</em> the numbers 0 to 9 that you save in a <code>BufferedImage[10]</code> array.</li> <li>at game initialization, predraw once <em>"Your score is: "</em></li> <li>if the <em>"Your score is: "</em> really needs to be redrawn (because, say, it's transparent), then redraw it from your pre-stored <code>BufferedImage</code></li> <li>loop to compute the digits of the score and add, after the <em>"Your score is: "</em>, every digit manually one by one (by copying each the time the corresponding digit (0 to 9) from your <code>BufferedImage[10]</code> where you pre-stored them.</li> </ul> <p>This gives you best of both world: you get the reuse the <em>drawtext(...)</em> font and you created exactly zero objects during your main loop (because you <em>also</em> dodged the call to <em>drawtext(...)</em> which itself <em>may</em> very well be crappily generating, well, needless crap).</p> <p>Another "benefit" of this <em>"zero object creation draw score"</em> is that careful image caching and reuse for the fonts is not really <em>"manual object allocation/deallocation"</em>, it's really just careful caching.</p> <p>It's not "clean", it's not "good practice" but that's how it's done in top-notch mobile games (like, say, Uniwar).</p> <p>And it's fast. Darn fast. Faster than <em>anything</em> involving the creation of object.</p> <p><em>P.S: Actually if you carefully look at a few mobile games, you'll notice that often fonts are actually not system/Java fonts but pixel-perfect fonts made specifically for each game (here I just gave you an example of how to cache system/Java font but obviously you could also cache/reuse a pixel-perfect/bitmapped font).</em></p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload