OpenEuphoria

Re: Platform Game Optimisation

• Posted by Roderick Jackson <rjackson at CSIWEB.COM> Dec 13, 1999
• 478 views

Well, let's see here. Keeping the structure of the code
generally the same, you can still do quite a bit of
'tightening' to it, for speed optimization:

--
-- CODE!
--
procedure M_UpdateScreen(integer scrnx, integer scrny)
  integer g_posx
  sequence temp_lvl_layout, temp_lvl_graphics

  for i = 1 to length(lvl_layout) do
    temp_lvl_layout = lvl_layout[i]  -- reduces number of index accesses
    g_posx = temp_lvl_layout[G_POSX] -- reduce those accesses even more!
    if (g_posx >= scrnx) and (g_posx < (scrnx + 320)) then
      temp_lvl_graphics = lvl_graphics[temp_lvl_layout[G_TILE]] -- ditto...
      gfx_add(2, temp_lvl_graphics[G_IDNUM], temp_lvl_graphics[G_SIZX],
          temp_lvl_graphics[G_SIZY], g_posx * 16 - scrnx,
          temp_lvl_layout[G_POSY] * 16 - scrny,
          207)
    end if
  end for
end procedure
--
-- END CODE!
--

Hope this helps,


Rod Jackson

----------
From:   Peter Millan[SMTP:robotnik at OPTUSNET.COM.AU]
Sent:   Sunday, December 12, 1999 4:05 PM
To:     EUPHORIA at LISTSERV.MUOHIO.EDU
Subject:        Platform Game Optimisation

Hello all.

I am currently writing a platform game based on Sonic the Hedgehog (which
is
legal as long as I don't sell it, blah blah). But I'm sure part of my code
could be optimised a hell of a lot more.

The level's graphical layout is stored in a sequence, lvl_layout. It stores
an id number, and it's x and y position in the level. {{id, x, y}, {...}}
etc.
The mem_id number corresponds to the position in the lvl_graphics sequence
that contains the location of that graphic in memory, and it's x and y
dimensions.

Now, depending on the viewpoint of the screen, the program will draw the
graphics
into a memory buffer, which is then mem_copy'd onto the screen. The buffer
is 576
by 456 pixels, the screen resolution being 320x200. What you'll see on the
screen
is copied from the middle of this buffer - that way, when the screen
scrolls, you
can still draw the graphics that start off the screen.

If you still understand what I'm going on about, this is the code used to
draw:

--
-- CODE!
--
procedure M_UpdateScreen(integer scrnx, integer scrny)
  integer
    d

  for i = 1 to length(lvl_layout) do
    if lvl_layout[i][G_POSX] >= scrnx and lvl_layout[i][G_POSX] < scrnx +
320 then
      d = lvl_layout[i][G_TILE]
      gfx_add(2, lvl_graphics[d][G_IDNUM], lvl_graphics[d][G_SIZX],
          lvl_graphics[d][G_SIZY], lvl_layout[i][G_POSX] * 16 - scrnx,
          lvl_layout[i][G_POSY] * 16 - scrny,
          207)
    end if
  end for
end procedure
--
-- END CODE!
--

Of course, I'm not doing bounds checking in the y direction, but you should
have
the general idea on the way I'm approaching it. I'd love to hear
suggestions on
how you'd improve it.

If you want to see the whole game so far, to better understand the code,
etc., get
it from www2.50megs.com/sonic/sth_mt/. It's only 71K.

Thanks for taking your time to help me.
Peter Millan.