OpenEuphoria

Re: Platform Game Optimisation (oops)

• Posted by Jeffrey Fielding <JJProg at CYBERBURY.NET> Dec 12, 1999
• 464 views

I made a mistake, and canceled my message, but I'm not sure whether it was sent
or not. Anyway, here is the corrected message:
I've noticed that sequence subscripting is rather slow, and usually adding
parenthesis help speed-up the program a bit.
I'll look at the rest of the program when I have some more time.
--
-- CODE!
--
procedure M_UpdateScreen(integer scrnx, integer scrny)
  integer posx, scrnx320
  sequence temp, temp2
  scrnx320 = scrnx+320
  for i = 1 to length(lvl_layout) do
    posx = lvl_layout[i][G_POSX]
    if posx >= scrnx and posx < scrnx320 then
      temp2 = lvl_layout[i]
      temp = lvl_graphics[temp2[G_TILE]]
      gfx_add(2, temp[G_IDNUM], temp[G_SIZX],
          temp[G_SIZY], (temp2[G_POSX] * 16) - scrnx,
          (temp2[G_POSY] * 16) - scrny,
          207)
    end if
  end for
end procedure
--
-- END CODE!
--

Jeffrey Fielding
JJProg at cyberbury.net
http://members.tripod.com/~JJProg


EUPHORIA at LISTSERV.MUOHIO.EDU wrote:

> 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.