Re: A82: is everybody dead?


[Prev][Next][Index][Thread]

Re: A82: is everybody dead?




At 02:47 PM 1/10/99 EST, you wrote:
>where is everyone?  doesn't anybody need any help?  Nothing to discuss about
>your projects?  SOMEBODY please get some sort of conversation going.  You
>can't tell me that 75 people have nothing to talk about.
>
>~Adamman

Yup...I'm dead :)

Okay, I have to tell everyone where I am with SQRXZ 82...yes, it is still
being developed.  As I was going to activate the final bit of source, I
realized one thing...it wasn't programmer friendly.  To even add a single
bit of code for enemies to be smarter was going to be a nightmare.  So, I
decided to rewrite the whole game from scratch (well, not totally, but it
came close).  I am now to where I may need to again rewrite sections to
shrink code size...say something like 4K will be reduced if I can come up
with the right idea.  My original plan was to expand a complete level into
a temporary 5K level storage space.  Now I realize that I can use an extra
database in conjunction with 9 screens worth of expanded data to reduce the
storage space.  This means level data will have to be extracted on-the-fly
but will allow for virtually unlimited level sizes.

The only problem is figuring out how to do this.  The best idea I have so
far is to use my PCX-like extractor and somehow do the same thing with it
as I have done with pretty much the rest of my game:  Make the level
integrated with itself and the game.  It isn't integrated in the permanent
sense, but integrated meaning there is code that is executed after level
loading and possibly even use multi-level section pointers (hard to
explain...kind of like pointer->pointer->pointer->...->actual data for the
compressed section of level.  It decreases code size and usually speeds up
the code a bit).  However, the problem lies with the fact that I want to
also be able to include _entire_ levels inside of a level at any point,
like so (psuedo-level [sp?] format):

Level1:
SSSSSSS
SSL   S
SS    S
SS    S
SS    S
SSSSSSS

Level2:
SSSS
SL S
S  S
SSSS

Level3:
SS
SS

S = Screen
L = Level link

Level in "string" format (no separate lines and spaces):

Level1:
SSSSSSSSSLSSSSSSSSSSSSSSSSS

Level2:
SSSSSLSSSSSSS

Level3:
SSSS

This is a great idea...except one thing, I can't implement it.  The idea is
only to have one entry for the level pointer for the insert.  A problem
arises since the game won't know how to determine when the player hits the
linked level.  I thought about individual screen links (which I can already
do...but each one counts as a screen...limiting level size), but that isn't
what I want.  I also don't want something like:

SSSSSSS
SSSL  S
SSSR  S
SSSR  S
SSSSSSS

R = Reference to a level link

"String" format:  SSSSSSSSSSLSSSSRSSSSRSSSSSSSS

I want it in memory EXACTLY the way I showed it previously.  I have an
idea, though, but it doesn't totally satisfy me.  It requires the use of a
screen row table (for speed) and a header for each screen telling how many
bytes to the next screen.  If the header byte equals 0, then I can assume
that the next screen is either a level link or a reference.  However, I
still do not have a solution for keeping track of enemies inside level
links...especially those levels that are multi-linked together.  I have
*everything* else with multi-link capabilities (enemies, objects, main
character(s), _and_ pattern databases).  Just need to do the same thing
with the levels.

As to the inactive enemies, I have an idea as well...but as before it is
not good enough.  I can use a database and store what I am storing now
(enemy graphic #, position in level), but also add what level (and screen
#) the enemy is on.  This idea requires 2 databases:  Enemy storage and
screens visited.  Since memory is limited, sections of both databases will
be purged as the distance between the main character increases.  Can anyone
think of something faster?

Thanks for any help...it is very much appreciated.  (Especially for someone
who just died and came back to life ;)



Follow-Ups: References: