Re: A82: is everybody dead?
[Prev][Next][Index][Thread]
Re: A82: is everybody dead?
Am I right to assume that the full SQRXZ will feature vertical scrolling;
I've only played the current 82 version and as far as I can remember it
scrolls horizontally and only allows limited "backtracking"? If not then
it makes on-the-fly decompression as simple as having a table of offsets
into your data, representing the start of each screen, as well as a
buffer to store the single screen into before scrolling into it. If you
are allowing vertical scrolling, then I'd probably use a similar approach,
but encode the data in terms of "wider-than-screen" rows of background
tiles, with appropriate pointers again. As for your level-in-level idea,
I'm thinking it's gonna be a pain in the butt to to compress (and
decompress) that efficiently using the pcx method, since it depends on
lots of repeated data which is likely to "spill" over into other screens
(ignore this sentence if what I'm saying makes no sense, I've only got a
vague memory of how pcx encoding works... and I might even be thinking
about PIC anyway :) ). Personally, and I'm talking with limited
compression experience here, I'd go for a technique that combines LZW-type
grouping of characters with a Huffman approach to representing these
strings, with of course an appropriately sorted table precalculated.
Anyway, I hope at least some of this helps, and I'd appreciate being set
straight if anything I've said doesn't quite make sense (I'm only just
experimenting with these things as I work on my 8 way scrolling
platform game.)
Jeremy Wazny
On Wed, 13 Jan 1999, Thomas J. Hruska wrote:
>
> 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 ;)
>
>
References: