1. 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.
2. Re: Platform Game Optimisation
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
temp = lvl_graphics[lvl_layout[i][G_TILE]]
temp2 = lvl_graphics[i]
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.
3. Re: Platform Game Optimisation
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.
