z2

I agree. Take me to the spicy page.
It is currently Thu Jun 21, 2018 3:58 pm

All times are UTC




Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2

What do you think about ZZT for the TI-89?
1. I'd play it. 80%  80%  [ 4 ]
2. Better to write it for a cellphone. 0%  0%  [ 0 ]
3. Great idea. I'll help! 0%  0%  [ 0 ]
4. Terrible idea. Why do people keep trying to revive ZZT? 0%  0%  [ 0 ]
5. Get a life. 20%  20%  [ 1 ]
Total votes : 5
Author Message
PostPosted: Tue Oct 04, 2011 3:16 pm 
Offline
fgsdfs
User avatar

Joined: Wed Mar 12, 2003 5:44 pm
Posts: 2432
Location: :noitacoL
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*


Top
 Profile  
 
PostPosted: Wed Oct 05, 2011 3:50 pm 
Offline
Level 17 Accordion Thief
User avatar

Joined: Fri Sep 12, 2003 1:41 am
Posts: 1423
Location: Edmonds, WA
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).


Top
 Profile  
 
PostPosted: Wed Oct 05, 2011 6:31 pm 
Offline
the Gargoyle.
User avatar

Joined: Tue Jul 25, 2006 10:02 am
Posts: 602
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.


Top
 Profile  
 
PostPosted: Tue Oct 18, 2011 5:50 am 
Offline
the Gargoyle.
User avatar

Joined: Tue Jul 25, 2006 10:02 am
Posts: 602
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group