ZAD Adventure System - Progress

Show us what you're working on, (preferably with screenshots).
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

ZAD Adventure System - Progress

Post by PROSM »

Hello there,

I've been writing a graphical adventure system recently which aims to allow one to create games in the style of the old SCUMM adventure games (e.g. Maniac Mansion). It's called ZAD (ZX Adventure Designer) and can produce games which run on a ZX Spectrum with at least 48K of RAM.

So far, the bytecode interpreter has been fully implemented and debugged, along with both the base-level graphics functions and the redraw manager, the walking mode and the keyboard scanning routines. The items that are still yet to be implemented are the interactivity system (being able to select a verb and then position the cursor on the object to perform the action) and the tape system (reading and writing save-files to cassette). Hopefully, I should be able to get these done by the end of January at the earliest, or possibly mid-February.

All background images used in the game are compressed via Einar's wonderful ZX7 tool, without which this project wouldn't have been remotely feasible.

Below is a video, showing a test game which demonstrates the abilities of the engine at this point. I must mention that, while there are full message line capabilities in this build, they are not used in this demo.

[Media]https://youtu.be/WSmb9IVZZ9g[/media]
All software to-date
Working on something, as always.
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: ZAD Adventure System - Progress

Post by R-Tape »

This looks fantastic.

I'm not clear - is this a utility that runs on a spectrum or a PC?
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

R-Tape wrote: Wed Jan 17, 2018 11:15 pm This looks fantastic.

I'm not clear - is this a utility that runs on a spectrum or a PC?
The development kit is a set of utilities that runs on Windows (they could of course be ported to other OSes). In reality, there are only two utilities, both of which handle graphics conversion. All of the bytecode compilation is handled via a set of PASMO macros.
All software to-date
Working on something, as always.
User avatar
Morkin
Bugaboo
Posts: 3250
Joined: Mon Nov 13, 2017 8:50 am
Location: Bristol, UK

Re: ZAD Adventure System - Progress

Post by Morkin »

Looks cool..!

I like the main sprite's blinking animation.
My Speccy site: thirdharmoniser.com
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: ZAD Adventure System - Progress

Post by RMartins »

Nice work, keep us posted on the developments.
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: ZAD Adventure System - Progress

Post by Ralf »

Very interesting project! It would be great if you made it to the stage where creating actual games would be possible.

Remember that if you want other people to use it it must be friendly, bug free (mostly ;) ) and well documented. In the past
many people tried to make some engines that turned out unusable in the end.

Also the engine can't take too much memory. If it uses 30 of 40 available kilobytes of Spectrum 48 memory then it would be hard to make any more serious game with it.

How do you store backgrounds? As single, big, compressed pictures or are they built from tiles?

In the video it seems that you have sprite movement by 8 pixels(movement by character)? Are you going to stick to it or more presise movement by 1 or 2 pixels will be available too?

Generally as I said it's very interesting news. Don't forget to write some progress reports here! :)
User avatar
4thRock
Manic Miner
Posts: 415
Joined: Thu Nov 09, 2017 9:35 am
Location: Portugal

Re: ZAD Adventure System - Progress

Post by 4thRock »

A Windows program is great! :D
Spectrum based game creators are harder to use...

Looking forward to it!
I like the full color, 8x8 animation. Multicolour to sprites would be a nice addition.
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

Ralf wrote: Thu Jan 18, 2018 10:39 am Very interesting project! It would be great if you made it to the stage where creating actual games would be possible.

Remember that if you want other people to use it it must be friendly, bug free (mostly ;) ) and well documented. In the past
many people tried to make some engines that turned out unusable in the end.

Also the engine can't take too much memory. If it uses 30 of 40 available kilobytes of Spectrum 48 memory then it would be hard to make any more serious game with it.

How do you store backgrounds? As single, big, compressed pictures or are they built from tiles?

In the video it seems that you have sprite movement by 8 pixels(movement by character)? Are you going to stick to it or more presise movement by 1 or 2 pixels will be available too?

Generally as I said it's very interesting news. Don't forget to write some progress reports here! :)
Thank you for your kind words, Ralf. I certainly aim to get this engine to a usable state, as I intend to write a game or two myself with it. The graphics you see in the video are rough drafts of those to be used in my game. As for the manual, I have all of the technical documentation written, but before I release the engine to the public, I will also have to write a tutorial to help people become familiar with the engine. In addition to this, while PASMO is fairly good at compiling the bytecode via macros, I imagine that others would want a dedicated compiler to make things easier.

Memory isn't a big concern, and is extremely unlikely to ever be one. Although it's not definite right now, an estimated 30KB will be available for game data. According to my estimates, a typical in-game room will take some 400 to 800 bytes, so you'll be able to have an average of around 30 rooms, taking into account the extra memory eaten up by frames (the graphics for the movable objects). Of course, this varies depending on how much data each room uses.

The backgrounds are stored as tile maps which are compressed via ZX7. In fact, the way in which graphics are drawn to the screen is pretty much via an emulated character mode. This unfortunately prohibits me from making the movements of objects more precise than 8 pixels, and it also introduces a considerable overhead in drawing the graphics to the screen, but this is outweighed by the fact that it greatly reduces the amount of memory needed for the graphics data and screen buffers, since only 2 bytes (tile index and attribute) are needed for each character block. The off-screen buffer takes only 1KB of memory and the universal character set needs only 2KB to store all 256 characters.
4thRock wrote: Thu Jan 18, 2018 4:11 pm A Windows program is great! :D
Spectrum based game creators are harder to use...

Looking forward to it!
I like the full color, 8x8 animation. Multicolour to sprites would be a nice addition.
I agree that Spectrum-based creators are harder to work with. Really, in my case, it needs to be a set of Windows utilities due to the sheer amount of data to manipulate for such a game. In addition, ZX7 is needed for the compression of the graphics, so part of the development environment would have to run on a modern computer anyways.

I'm glad you like the full colour animation in my game, but unfortunately, multicolour would not be possible due to the amount of CPU time that it requires and also the amount of memory that storing such data would require (5 bytes per character for an 8x2 attribute layout).
All software to-date
Working on something, as always.
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: ZAD Adventure System - Progress

Post by Ralf »

Thanks for the explanations.

I suppose 8 pixel movement would force some "style" for the games. As sprite will move by 8 pixels, they can be colourful without too much colour clashing, just like in your example. And I suppose they can be BIG :) With 8 pixel movement big sprites move bettter, you don't feel that the movement is jerky.

So if I were to make some game with it, personally I would go after something similar graphically to Trap Door, Flunky, Benny Hill and other games by Don Priestley.

Anyway good luck with your project!
User avatar
R-Tape
Site Admin
Posts: 6353
Joined: Thu Nov 09, 2017 11:46 am

Re: ZAD Adventure System - Progress

Post by R-Tape »

Does this cyan blob have a name by the way? Tell me it's not Horace!
ArtOfWalls
Drutt
Posts: 1
Joined: Fri Jan 19, 2018 2:17 am

Re: ZAD Adventure System - Progress

Post by ArtOfWalls »

This looks great! I'm willing to see your progress.
The closest things I remember in Spectrum are "The Trap Door" and "Flunky". Funny games with great graphics. If your engine can make games to this level then it will be a success!
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

R-Tape wrote: Thu Jan 18, 2018 10:50 pm Does this cyan blob have a name by the way? Tell me it's not Horace!
It's Thomas Stakes. Surprisingly, it's very hard (for me at least) to come up with an infrequently used name for a game character. I must've tried fifty others in Google before settling on that one.
All software to-date
Working on something, as always.
Wall_Axe
Manic Miner
Posts: 491
Joined: Mon Nov 13, 2017 11:13 pm

Re: ZAD Adventure System - Progress

Post by Wall_Axe »

if the main character can be customized, he could look like Dan Dare from Dan Dare 3?
I dont think that game used masking
Image
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

Wall_Axe wrote: Fri Jan 19, 2018 8:52 pm if the main character can be customized, he could look like Dan Dare from Dan Dare 3?
I dont think that game used masking
Image
I'm not sure what you mean by customized. If you mean for games that you write yourself, then yes, all you would have to do is convert the Dan Dare 3 sprites into my 'FRAME' format and set up the walking animation pointers accordingly so that the software knows where to look for each direction. The player character shown in my video is set up in exactly the same manner. However, you may need to disable the blinking animations if your player sprites don't use them.

In regards to masking, the ZAD adventure system allows a basic form of masking via attributes, where character blocks of frames can either be entirely opaque, take on the PAPER colour of the background tile being covered or can be completely empty, so the background character is not overwritten at all.
All software to-date
Working on something, as always.
Wall_Axe
Manic Miner
Posts: 491
Joined: Mon Nov 13, 2017 11:13 pm

Re: ZAD Adventure System - Progress

Post by Wall_Axe »

oh good, so the main character can look cool then :)
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

ZAD Adventure System - Progress Update

Post by PROSM »

Just a quick update on the progress of the ZAD Adventure System: A cursor has been implemented, allowing the player to select objects on the screen. When objects are moused over, the object name is displayed. This uses the same key input code as the player movement routine, but of course uses it for a different purpose. The different interaction modes will call the cursor routines, and when the ENTER key is pressed while the cursor is hovering over an object, the object reference will be passed back to the interaction routine selected so that it can carry out the appropriate action.

A quick note on player input: the directional movement is controlled via keys 6 to 9 on the keyboard. This not only makes it easier to program, but also allows for Sinclair joystick support (if one desires to use it, that is).

Here's a screenshot which shows the current development build of the engine, with the cursor selected, hovering over the player character, Thomas Stakes:

Image

I'll probably make a further update in the next few days, when I have got the region selection working as well. To make things clear, objects are the movable items on screen, but regions are the areas of the background that can be interacted with. They are, as a consequence, static and unmovable.
All software to-date
Working on something, as always.
User avatar
Uto
Drutt
Posts: 24
Joined: Wed Nov 15, 2017 10:28 am

Re: ZAD Adventure System - Progress

Post by Uto »

Very interesting tool! Congratulations!

Would you consider supporting Kempston mouse to move that cursor? It can be used in a real Spectrum with the original mouse interface, and most modern clones as ZX-Uno and Spectrum Next support it. In the end you can move that cursor with keys or joystick if you want, but also with mouse in case there is one plugged in.

Technical specs here, is quite simple:
http://uto.speccy.org/zxunofaq_en.html#7100
http://uto.speccy.org
Follow me at @uto_dev
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

Uto wrote: Sun Jan 28, 2018 3:37 pm Very interesting tool! Congratulations!

Would you consider supporting Kempston mouse to move that cursor? It can be used in a real Spectrum with the original mouse interface, and most modern clones as ZX-Uno and Spectrum Next support it. In the end you can move that cursor with keys or joystick if you want, but also with mouse in case there is one plugged in.

Technical specs here, is quite simple:
http://uto.speccy.org/zxunofaq_en.html#7100
Sorry for my late reply, [mention]Uto[/mention]. I will support the Kempston mouse interface, but right now it is not the highest priority since the rest of the engine has yet to be completed. It is definitely on the cards, however, as it doesn't look too hard to implement a driver for mouse functionality. It may even be a better method of control when playing via an emulator.
All software to-date
Working on something, as always.
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

ZAD Adventure System - Huffman, Proportional Text and Compilers

Post by PROSM »

Hello again!

I apologize for the lack of recent updates, because the project was briefly put on hiatus in order to write my CSSCGC 2018 entry, a conversion of Plumbers Don't Wear Ties. I will return to writing this engine and the accompanying development utilities.

To start, I've been looking at text compression lately as the amount of space text takes up currently makes that including speech or text descriptions rather costly in terms of memory. At the moment, text is stored using my own custom character mapping in a 6-bit per character format, which means that there is only space in the character map for capital letters. However, Huffman text compression is a very good choice for this engine, since strings are actually embedded within the bytecode scripts themselves (with the exception being strings that are duplicated across numerous scripts; the later instances are instead just references to the first embedded version). Because the strings are stored like this, strewn across memory, Lempel-Ziv compression would not be very effective because the window would have to be extremely large to allow for the use of repeated phrases.

The cost of the Huffman tree in memory would be outweighed by the compression gains, as I estimate that the size of text can be halved by Huffman coding. In addition to this, the limit upon the character map size imposed by the current 6-bit format would allow one to use lowercase letters or even accented characters if needed.

However, I am having trouble implementing a Huffman compressor in Python, as I'm finding it hard to understand how the tree structure and the nodes could be implemented. I use Python as a test bed for my code, and then port it to C for the development utilities, so that I can make sure that my comprehension of a concept is rock-solid before I invest time into writing a C program.

Now, we move onto proportional text. I've decided to do away with the 64 column text display and instead use variable spacing for each character. This will reduce the length of messages that can be printed there, but it will make said messages easier to read.

Finally, the compiler. The rooms of the game are split into 'modules', which are all independent of each other. These modules will be assembled individually (with jump targets yet to be defined) and then the compiler will try to find the best fit, one which allows all modules to co-exist in memory and leave the largest amount of free contiguous memory possible. This is being written in Python so that I can get the core bits correct before I move them into C.

I am not sure whether to create a C-style programming language, or simply let the end-user program directly in the bytecode language. The latter would be simpler for me and would give the user more control over the system, but the former may be more approachable for novices. Please leave your opinion below, as I need to hear from potential users about what they would want.

Thank you for reading! Please leave any suggestions or comments you have.
All software to-date
Working on something, as always.
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: ZAD Adventure System - Progress

Post by Ralf »

I am not sure whether to create a C-style programming language, or simply let the end-user program directly in the bytecode language.
The easier it will be, the more users you will have. I understand that "easy for user"="harder for you" so you may want to find your compromise.

Personally I would go after Basic syntax, not C. Most people in Zx Spectrum world have experience with Basic but not necessarily C and may be afraid of all these brackets, not to mentions pointers ;)
To start, I've been looking at text compression lately
You can do it without compression if it's too much trouble. You can go down to 5 bits per letters: 32 combinations for 26 English letters. You can also use prefixes for some rare symbols (5 bits per prefix and next 5 bits for rare character which give you another 32 symbols). You can also have some logic like "after dot symbol there is always a capital letter" as start of new sentence. I have an unfinished game using such ideas so these are actually tricks that worked for me.
The rooms of the game are split into 'modules',
But don't foget to do some global variables. Actions in one location should be able to influence things in another location.

Good luck with your project! Don' forget to post here ;)
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

Ralf wrote: Thu Feb 15, 2018 8:41 pm
I am not sure whether to create a C-style programming language, or simply let the end-user program directly in the bytecode language.
The easier it will be, the more users you will have. I understand that "easy for user"="harder for you" so you may want to find your compromise.

Personally I would go after Basic syntax, not C. Most people in Zx Spectrum world have experience with Basic but not necessarily C and may be afraid of all these brackets, not to mentions pointers ;)
To start, I've been looking at text compression lately
You can do it without compression if it's too much trouble. You can go down to 5 bits per letters: 32 combinations for 26 English letters. You can also use prefixes for some rare symbols (5 bits per prefix and next 5 bits for rare character which give you another 32 symbols). You can also have some logic like "after dot symbol there is always a capital letter" as start of new sentence. I have an unfinished game using such ideas so these are actually tricks that worked for me.
The rooms of the game are split into 'modules',
But don't foget to do some global variables. Actions in one location should be able to influence things in another location.

Good luck with your project! Don' forget to post here ;)
A BASIC-style syntax should be easy to implement and also be easy to write for the user, but I'm not sure how to implement one of the ZAD system concepts in this style of programming.

To reduce the amount of time spent in the bytecode execution loop, there is a 'centre point'. This can be set anywhere in the code. The centre point is where bytecode execution begins from on each loop. This means that for an animation sequence, we can set the centre point to start executing the animation loop immediately from the beginning of a new execution loop, and when we're done, we can set the centre point back to the main logic loop for the entire room. I'm not entirely sure how I could implement that cleanly in a BASIC-style syntax. I suppose it could automatically centre at the start of each room module and then loops with their own centre points could be indented to make it clearer that they are separate.

In regards to the compression, I understand the concept of Huffman compression, but it's just trying to implement it. I'll keep picking away at it whilst I implement the other things.

Finally, in response to your note about global variables, the way that variables are allocated within the system technically makes them all global, but the way that the compiler will allocate them abstracts this from the end-user. Local variables are allocated upwards from $00 and global variables are allocated downwards from $5F. There are variables above $60 in the variable page, but these are given a dedicated purpose (object positions and their frame pointers, region information, system flags, etc.).
All software to-date
Working on something, as always.
Nomad
Manic Miner
Posts: 600
Joined: Thu Dec 28, 2017 12:38 pm

Re: ZAD Adventure System - Progress

Post by Nomad »

If I was that concerned about space and large amounts of text I would probably just go for tables of two byte tokens... per word.

65535 Token IDs then. The trick is you set space and other punctuation as its own token in the stream. Then you can have compound token groups in the stream and probably capture all of the English language. :lol:

I think that is a very rich vocabulary for English anyway.

http://www.slate.com/articles/life/the_ ... count.html

Well it depends what you want... I found this article interesting on the subject. Even with some crazy large number because this can do compounds you can capture the whole of the set of English words with a relatively small number of elements...

Also think that you can do cool stuff with this approach if its coded right... Make sure that you don't bake in the space in each token, have the space as its own distinct token. That way you can create compound words when encoding and save a lot of time and space in your definitions at the expense of a little speed.

: HE h e ;
: THE t he ;
: THEM the m ;

: AT a t ;
: TACK t a c k ;
: ATTACK at tack ;

But that would be pretty fancy you are on the verge of going phoneme route then - I always wondered what could be done if you associated graphics with phoneme instead of sounds in a limited target like the specy.

You would be looking at 44 tokens then for all the English sounds, associate that with a routine to do whatever - print a text chunk, make a sound, do some program effect. Everything can then be generated from combinations of the 44 tokens.
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

Nomad wrote: Fri Feb 16, 2018 12:19 am If I was that concerned about space and large amounts of text I would probably just go for tables of two byte tokens... per word.

65535 Token IDs then. The trick is you set space and other punctuation as its own token in the stream. Then you can have compound token groups in the stream and probably capture all of the English language. :lol:

I think that is a very rich vocabulary for English anyway.

http://www.slate.com/articles/life/the_ ... count.html

Well it depends what you want... I found this article interesting on the subject. Even with some crazy large number because this can do compounds you can capture the whole of the set of English words with a relatively small number of elements...

Also think that you can do cool stuff with this approach if its coded right... Make sure that you don't bake in the space in each token, have the space as its own distinct token. That way you can create compound words when encoding and save a lot of time and space in your definitions at the expense of a little speed.

: HE h e ;
: THE t he ;
: THEM the m ;

: AT a t ;
: TACK t a c k ;
: ATTACK at tack ;

But that would be pretty fancy you are on the verge of going phoneme route then - I always wondered what could be done if you associated graphics with phoneme instead of sounds in a limited target like the specy.

You would be looking at 44 tokens then for all the English sounds, associate that with a routine to do whatever - print a text chunk, make a sound, do some program effect. Everything can then be generated from combinations of the 44 tokens.
I like the idea, [mention]Nomad[/mention], but with phonemes, you are only able to spell the words phonetically, rather than how they are actually spelt, so it would be good for speech synthesis, but not for text displays. However, your idea about phonemes raises an interesting point, as you could instead use graphemes (how the phonemes are spelt). There are several more graphemes than phonemes since there are often several ways in which to spell them, but it should help the compression ratio significantly, as there are many three or four letter graphemes, which reduce down to a single token. This allows us to encode words like through as th r ough. With conventional ASCII, this word would take 7 bytes, but using the graphemes, it only takes 3 bytes, one for each grapheme token.

Coupled with Huffman compression, significant space savings could be made, as more frequent tokens will have shorter tokens, reducing the space taken even further.

Of course, this works only for English language games. For games in other languages, they could either define their own list of graphemes or they could just use a conventional alphabet character mapping and do away with the graphemes.
All software to-date
Working on something, as always.
User avatar
PROSM
Manic Miner
Posts: 472
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

PROSM wrote: Fri Feb 16, 2018 8:24 am I like the idea, @Nomad, but with phonemes, you are only able to spell the words phonetically, rather than how they are actually spelt, so it would be good for speech synthesis, but not for text displays. However, your idea about phonemes raises an interesting point, as you could instead use graphemes (how the phonemes are spelt). There are several more graphemes than phonemes since there are often several ways in which to spell them, but it should help the compression ratio significantly, as there are many three or four letter graphemes, which reduce down to a single token. This allows us to encode words like through as th r ough. With conventional ASCII, this word would take 7 bytes, but using the graphemes, it only takes 3 bytes, one for each grapheme token.

Coupled with Huffman compression, significant space savings could be made, as more frequent tokens will have shorter tokens, reducing the space taken even further.

Of course, this works only for English language games. For games in other languages, they could either define their own list of graphemes or they could just use a conventional alphabet character mapping and do away with the graphemes.
Well, I did some tests in Python and discovered that there are over 130 unique graphemes (at least from the list I used), so it would be impractical to both store them in memory and also use Huffman coding on them, since this works best when you have a limited character set. I think I'll stick to writing an implementation of Huffman coding, since the decompression tree can be really small. I've looked at this post on Battletoads' text compression, and the way they implement the decompression tree is really compact and fast as well.
All software to-date
Working on something, as always.
User avatar
djnzx48
Manic Miner
Posts: 729
Joined: Wed Dec 06, 2017 2:13 am
Location: New Zealand

Re: ZAD Adventure System - Progress

Post by djnzx48 »

I'd be interested to know the details of how you're planning to store the tree in memory, since I'm also considering using Huffman coding for in-game text in my own project. Storing the tree as a structure of nodes and pointers seems to me like it would use a lot of memory, but at least it would be very fast to decompress.

I remember reading somewhere that it was possible to store a tree going top to bottom, left to right, using 0 to represent a node and 1 followed by a symbol to represent a leaf. This would be a lot slower as you'd have to traverse most of the tree to decode a single symbol, but the tree itself would take up a lot less space - only 1 bit per node. Although maybe the stack space required to traverse the tree would outweigh the benefits in this case.

I also had the idea that if this method was used, it might be possible to change the text encoding scheme when compiling/assembling. Basically rather than using, for example, ASCII to encode the uncompressed text, you could arrange the characters in the order that they appear in the tree. So then instead of having to store the symbols in the tree itself, you could simply increment a counter as you traversed the tree and whatever value you stopped on would be the character's encoding. A side effect of this method would be that you wouldn't be able to use the table in the ROM for translating keypresses to characters, but this doesn't sound like it would be a major problem.
Post Reply