zzt for graphing calculator

Discuss how totally awesome Bang! is here.

Moderator: Terryn

What do you think about ZZT for the TI-89?

1. I'd play it.
5
83%
2. Better to write it for a cellphone.
0
No votes
3. Great idea. I'll help!
0
No votes
4. Terrible idea. Why do people keep trying to revive ZZT?
0
No votes
5. Get a life.
1
17%
 
Total votes: 6

User avatar
Commodore
fgsdfs
Posts: 2459
Joined: Wed Mar 12, 2003 5:44 pm
Location: :noitacoL
Contact:

Re: zzt for graphing calculator

Post by Commodore »

Tokenizing is what would be done. I've been thinking the best way would be a cross-platform editor. Getting the heft of a modern processor behind compression save a lot of time. Simplifies juggling chunks of memory around too, they'd all be compressed and linked when compiled.
*POW* *CLANK* *PING*

User avatar
Quantum P.
Level 17 Accordion Thief
Posts: 1427
Joined: Fri Sep 12, 2003 1:41 am
Location: Edmonds, WA
Contact:

Re: zzt for graphing calculator

Post by Quantum P. »

Tokenization would be an easy first step. It wouldn't help text, but it would cut way down on the code.

You might want to do some kind of hybrid setup, where boards are RLE-encoded, ZZT-OOP is tokenized, and text is pre-compressed using an LZ algorithm. Terrain can be modified and labels can be zapped (you want a small, simple compressor), but text doesn't change (you can have a big complicated compressor with a small decompressor).

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: zzt for graphing calculator

Post by Saxxon »

Quantum P. wrote:Tokenization would be an easy first step. It wouldn't help text, but it would cut way down on the code.

You might want to do some kind of hybrid setup, where boards are RLE-encoded, ZZT-OOP is tokenized, and text is pre-compressed using an LZ algorithm. Terrain can be modified and labels can be zapped (you want a small, simple compressor), but text doesn't change (you can have a big complicated compressor with a small decompressor).
Labels could even be sortened. In fact you could probably even tokenize those too and give a specific offset. Store all the text in one big block outside of the code and reference it with offsets too.

User avatar
Saxxon
the Gargoyle.
Posts: 608
Joined: Tue Jul 25, 2006 10:02 am
Contact:

Re: zzt for graphing calculator

Post by Saxxon »

given a 40x25 grid (for the c64), you got 1000 bytes. This causes an issue if speed is a concern since indexed mode only works up to 256 bytes.

If you want to account for a side bar for stats you could instead use a size of 32x25. That would make things easy since it is a power of two (page would be Row>>3, index would be Row<<5 OR Column). And if you didn't mind odd placement of data on pages, you could even have one row per page, and have the first 32 bytes be ID, second 32 bytes be color, and the other 192 for whatever other use. Maybe object data. Since you'd be using 25 pages you would want 6 objects/page at least. At 22 bytes of data you'd be using 132 bytes of the page and still be sitting on 60 more. You'd use self modifying code to dump the page into whatever instructions you were using for reading object data.

Not including game state and code, you'd be looking at 1900h bytes of memory on the board and objects alone. Which really, is not much. If dropped on a disk that uses standard kernal routines, the load time wouldn't even be noticeable (but we'd want to have a fastloader in case someone is using a breadbox!) Game state would have to be saved to disk as the game was played, unless we dedicated half the disk to the current game being played. Given what cutting down on text in the code would do for us if it was compiled, we would be looking at a serious reduction in the amount of space the game takes anyway, so this is actually pretty reasonable.

We'd probably do away with the BASIC ROM. That would leave us a good chunk of memory. We'd definitely be able to support more than one board. We could even put the game's main code under the Kernal rom and throw in a low memory routine that would swap it in and out for when save and load are needed. Since only one of them is needed at a time, this would be trivial (assuming Kernal doesn't write to the memory underneath, I don't know it well)

Getting the standard 8x14 font down to 8x8 wouldn't be terribly hard and, how convenient, there are also 256 characters on the c64 :)

Probably getting ahead of myself here. But it does seem like a really fun idea.

Post Reply