ZAD Adventure System - Progress

Show us what you're working on, (preferably with screenshots).
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: ZAD Adventure System - Progress

Post by RMartins »

PROSM wrote: Fri Feb 16, 2018 8:24 am ...
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.
...
graphemes is a good way to make your tree shorter, by using a graphene per node, instead of a character per node, so do use graphemes.

But I would suggest a different approach for the tree, given the premiss of a lot of text, but not that many distinct words in the text.

I would build the tree (or set of trees, or sequences) in a different way.
I would define the leaf of a tree (or start of a sequence) as the beginning of a word, that is constructed, by following the nodes up to the root.
So you will have many roots, for example, one would be all words that end in "th". You only populate the words you actually use in your texts of course.

So to encode a text, you would keep a sequence of word IDs (how you encode this is up to you, to get maximum compression, or minimum use of bits). But given that words that end in the same grapheme will probably improve the space locality of the data, you can use relative distances, with variable bit sizes for length if needed, to link a node to it's parent node.

When decoding, you just grab the first word ID (typically the address of the left node that corresponds to that word), and you crawl up it's three, until you get to it's root, hence producing the required word, by concatenating the node contents while traversing it up.

Add a space and grab the next word ID, and repeat, until your text is done.

The largest data part, will surely be the multitude of word trees, but then adding extra text, should cost very little, at most 2 bytes per word, no matter how long the word is. And if you compress these sequence of IDs you can have a very compact and fast text decompression.

You can make optimizations for plurals, like "tree" and "trees", so that you don't have to create a new tree node sequence just to get a plural of a word.

You can take this idea, one level further, by building sequences of sentences (commonly used Sequences of word IDs ), if you find there are enough that repeat, to justify another structure for it.

I hope I managed to make it clear.

NOTE: you should optimize for the data size, in this case, and not code size, since data size will overwhelm any code size needed for this.

TIP: you code use a single bit, similar to some UTF encodings, to encode if the next byte is part of the current grapheme (0) or not(1). when this bit changes (to 1), the next char, will have the start of the relative position of the parent node. which can again be variable bit encoded, to minimize size.
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

RMartins wrote: Mon Feb 26, 2018 9:05 pm graphemes is a good way to make your tree shorter, by using a graphene per node, instead of a character per node, so do use graphemes.

But I would suggest a different approach for the tree, given the premiss of a lot of text, but not that many distinct words in the text.

I would build the tree (or set of trees, or sequences) in a different way.
I would define the leaf of a tree (or start of a sequence) as the beginning of a word, that is constructed, by following the nodes up to the root.
So you will have many roots, for example, one would be all words that end in "th". You only populate the words you actually use in your texts of course.

So to encode a text, you would keep a sequence of word IDs (how you encode this is up to you, to get maximum compression, or minimum use of bits). But given that words that end in the same grapheme will probably improve the space locality of the data, you can use relative distances, with variable bit sizes for length if needed, to link a node to it's parent node.

When decoding, you just grab the first word ID (typically the address of the left node that corresponds to that word), and you crawl up it's three, until you get to it's root, hence producing the required word, by concatenating the node contents while traversing it up.

Add a space and grab the next word ID, and repeat, until your text is done.

The largest data part, will surely be the multitude of word trees, but then adding extra text, should cost very little, at most 2 bytes per word, no matter how long the word is. And if you compress these sequence of IDs you can have a very compact and fast text decompression.

You can make optimizations for plurals, like "tree" and "trees", so that you don't have to create a new tree node sequence just to get a plural of a word.

You can take this idea, one level further, by building sequences of sentences (commonly used Sequences of word IDs ), if you find there are enough that repeat, to justify another structure for it.

I hope I managed to make it clear.

NOTE: you should optimize for the data size, in this case, and not code size, since data size will overwhelm any code size needed for this.

TIP: you code use a single bit, similar to some UTF encodings, to encode if the next byte is part of the current grapheme (0) or not(1). when this bit changes (to 1), the next char, will have the start of the relative position of the parent node. which can again be variable bit encoded, to minimize size.
I apologize for my late reply to your comment, [mention]RMartins[/mention]. I'm slightly confused by your tree explanation. I don't quite understand how a tree with many leaves and roots would be built and connected. The word ID concept is easy to follow, but I can't see how your tree would be constructed. Could you perhaps give an example of such a tree, please?
All software to-date
Working on something, as always.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: ZAD Adventure System - Progress

Post by RMartins »

PROSM wrote: Mon Mar 05, 2018 8:07 pm ...

I apologize for my late reply to your comment, @RMartins. I'm slightly confused by your tree explanation. I don't quite understand how a tree with many leaves and roots would be built and connected. The word ID concept is easy to follow, but I can't see how your tree would be constructed. Could you perhaps give an example of such a tree, please?
It's not a single tree, but a tree for each set of words that end with the same grapheme.
And it's not a tree in the sense that you do not start at the root, so you do not even need to know or have a list of all the roots, at least not at runtime.

Each branch from root to a specific leaf will define a complete word.
We traverse the tree in reverse, from leaf to root, since the words end at root.

Let's grab 2 words from the text above "traverse" and "reverse".
They both end with the same grapheme "se", so lets decompose these.

Code: Select all

"tra"-"ver"-"se"
"re"-"ver"-"se"
We can clearly see that they share more than one graphene in sequence "ver"-"se".
So let's build a tree in reverse (using ASCII art).

Code: Select all

"tra" +\
         +- "ver" -+- "se"
"re" +/
"se" is the root node of this tree, but we will always refer to it's elements, by starting from a leave.
Take into account, we can start at something that does not look like a leaf, but it's actually a word within a word, like "verse" above, so we may start at that.

You can look at this not a like a tree, but a group of sequences, that share the ending parts of the sequence, to avoid any confusion with any concepts of tree you might already have set your mind to.

So you will have many of these groups of sequences.

Hope it helped.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: ZAD Adventure System - Progress

Post by RMartins »

To simplify the main idea, if instead of graphemes, we would use single letters on each node, we would in fact have exactly 26 trees, since a word can only end in one of the 26 letters of the alphabet (not counting upper/lower case).
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

RMartins wrote: Tue Mar 06, 2018 2:00 pm ...
It's not a single tree, but a tree for each set of words that end with the same grapheme.
And it's not a tree in the sense that you do not start at the root, so you do not even need to know or have a list of all the roots, at least not at runtime.

Each branch from root to a specific leaf will define a complete word.
We traverse the tree in reverse, from leaf to root, since the words end at root.

Let's grab 2 words from the text above "traverse" and "reverse".
They both end with the same grapheme "se", so lets decompose these.

Code: Select all

"tra"-"ver"-"se"
"re"-"ver"-"se"
We can clearly see that they share more than one graphene in sequence "ver"-"se".
So let's build a tree in reverse (using ASCII art).

Code: Select all

"tra" +\
         +- "ver" -+- "se"
"re" +/
"se" is the root node of this tree, but we will always refer to it's elements, by starting from a leave.
Take into account, we can start at something that does not look like a leaf, but it's actually a word within a word, like "verse" above, so we may start at that.

You can look at this not a like a tree, but a group of sequences, that share the ending parts of the sequence, to avoid any confusion with any concepts of tree you might already have set your mind to.

So you will have many of these groups of sequences.

Hope it helped.
I can see how it would work now. I'll try to get something like that implemented in the next week or so, just to see how big of a space saving could be made using it. It looks like it would shrink the text down by quite a bit. Thank you very much!
All software to-date
Working on something, as always.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: ZAD Adventure System - Progress

Post by RMartins »

PROSM wrote: Tue Mar 06, 2018 5:18 pm ...
I can see how it would work now. I'll try to get something like that implemented in the next week or so, just to see how big of a space saving could be made using it. It looks like it would shrink the text down by quite a bit. Thank you very much!
Great.

Size gain will depend on the following vectors:
- Amount of distinct words in the game vocabulary (smaller vocabulary equals better ratio)
- Amount of text content in the game (larger text content equals better ratio)

Given a specific set of vocabulary, you can optimize the amount of bits required on each reference, either for words, or for grapheme addresses.
But that's for phase 2 :ugeek:

You can also optimize by merging graphemes of a tree that are never used in the text alone.
Example: if after constructing all the trees (group sequences), we end up with 2 graphemes in sequence like the ones required for "verse" (i.e. "ver", "se") with no other sibling for the node "ver", this means, there is no other word that links to "se" grapheme, so in this case we could merge "ver" and "se" as a single grapheme.
NOTE: this is only possible if each grapheme is "instanced" in each tree, and not referenced from a reference table.

If there are a lot of graphemes that repeat a lot in the many distinct words, it might be better for a node to have reference to a grapheme in a grapheme reference table, if that saves space.
You can also have an hybrid approach, where small graphemes, like 2 letters only are not very likely to improve size, by using a reference, and instead add them inline in the node. You only need a single bit for this.

Something like a C struct

Code: Select all

typedef struct TNODE_T
{
   TNode_TRef parent;
   Grapheme_T grapheme;
} TNode_T
For example, Grapheme_T can use a bit stream or sequence of bytes, where first bit will defined if it's inlined or referenced, for example.

A text, is a sequence of TNode_TRef's
Avoid using char sized (8 bits) info, if you do not need to, since you can gain a lot of space, if for example, you only need 12 bits to keep a word in a sentence.

Additionally, you can use dynamically sized references, (for example, similar to how UTF-8 encoding works), since this will allow you to use less bits for words that are used often, like "the", "a", etc...

But all these are optimizations, after you get the basic idea working.
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

ZAD Adventure System - Back to work!

Post by PROSM »

Well, my GCSE exams have been completed, so now I can go back and complete the ZAD system over the long holiday. Hurrah!
Spoiler
Now, for a start, the ZX Adventure Designer program is being written in C++ with wxWidgets, in order to make it compatible across various operating systems. The ZX7 compressor will be included in the program for automatic compression of background images and other data. Many thanks to [mention]Einar Saukas[/mention] for his kind permission in letting me use his ZX7 tool in my program.

In terms of the adventure system itself, there still remain some user interface routines to implement, along with the save and load functions. By the end of it, the user should have around 31KB to work with.

I am looking to try and implement AY music support on the 128K machines. It will just play modules from the extra memory banks of the 128K on every frame interrupt. I realize that many people will probably desire this functionality (after seeing the popularity of AGD Musicizer), so I am deciding to have it built right into the designer program.

I apologize for my several months silence, I'll try to keep updates more regular, as I should be able to now given that I no longer have exams to revise for.
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 »

Waiting for updates!
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

ZAD Adventure System - Tape functions

Post by PROSM »

I've spent the past day or so getting the tape functions to work correctly, and I have succeeded. The video below is a demonstration of the tape functions in action. Please excuse the graphical artifacts; my video card's memory is beginning to fail. The card will be replaced soon, so this problem should be fixed for the next video.

[media]https://www.youtube.com/watch?v=o7nbpImfzHk[/media]

I was encountering an interesting bug whilst fiddling with the tape routines, which I would like to explain in the hope that someone else may find it useful. To start, ZAD games use the standard ROM routines for loading and saving data on tape. This is very convenient, but also comes with a few problems of its own - one must preserve the BASIC system area, the IY register and the HL' register. The ZAD system does this at startup, saving the IY and HL' registers into a temporary space in RAM when it sets up interrupt mode 2 for checking the keyboard. When tape functions are required, it restores the IY and HL' registers and switches back to interrupt mode 1 briefly, for calling the ROM tape routines.

The ROM routines usually return to the caller, either indicating success (carry flag set) or failure (carry flag reset). However, if the user hits the BREAK key, thus interrupting the routine, then instead the ROM executes RST 8, which jumps to the error handler. Normally this would invoke the BASIC system, thus exiting the game and probably crashing the Spectrum as well. To counteract this, the variable ERR-SP (at $5C3D), which usually points back to BASIC, is instead redirected to a memory address containing a pointer into a ZAD routine, which lets the game intercept the BREAK and handle the cancellation from there.

However, due to my misunderstanding of how the ROM error handler works, the address in ERR-SP is loaded into the stack pointer and pushes a register pair onto the stack before executing a RET to enter the ZAD cancel routine, thus trashing the IY temporary variable (which is directly before the error handler pointer in memory). As a result, when the user performs a tape operation again and holds the BREAK key, the game freezes rather than cancelling as normal.

The problem was solved by adding a two byte buffer zone between the IY temporary variable and the error handler pointer, and restoring the stack pointer to the top of the stack ($5DFF) immediately after entering the cancel routine. I suppose I should have seen the problem from miles away, considering the naming of the variable, ERR-SP, but sometimes these things can slip by unnoticed.

I am now currently working on the inventory listing function and getting a basic framework for the wxWidgets program going. I hope to post my next progress update in a couple of days.
All software to-date
Working on something, as always.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: ZAD Adventure System - Tape functions

Post by Ast A. Moore »

PROSM wrote: Tue Jun 19, 2018 6:04 pm ZAD games use the standard ROM routines for loading and saving data on tape.
In that case, you don’t need to deselect all the tape loading options in Fuse. I you lead them active, it’ll save your data almost instantaneously, and will create a standard TAP/TZX file. (Note, that you’ll need to close it and open a new one, or Fuse will keep appending data blocks to the same file.)
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Tape functions

Post by PROSM »

Ast A. Moore wrote: Tue Jun 19, 2018 7:04 pm In that case, you don’t need to deselect all the tape loading options in Fuse. I you lead them active, it’ll save your data almost instantaneously, and will create a standard TAP/TZX file. (Note, that you’ll need to close it and open a new one, or Fuse will keep appending data blocks to the same file.)
I don't usually disable them, I just turned them off on the video for demonstration purposes, in order to make the saving and loading operations more obvious.
All software to-date
Working on something, as always.
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: ZAD Adventure System - Tape functions

Post by Ast A. Moore »

PROSM wrote: Tue Jun 19, 2018 7:28 pm
Ast A. Moore wrote: Tue Jun 19, 2018 7:04 pm In that case, you don’t need to deselect all the tape loading options in Fuse. I you lead them active, it’ll save your data almost instantaneously, and will create a standard TAP/TZX file. (Note, that you’ll need to close it and open a new one, or Fuse will keep appending data blocks to the same file.)
I don't usually disable them, I just turned them off on the video for demonstration purposes, in order to make the saving and loading operations more obvious.
Got it. Fair enough. No problem, then. ;)
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

ZAD Adventure System - Byte-shaving

Post by PROSM »

Whilst working on the editor program, I decided to rewrite part of the display code used by ZAD, specifically the region drawing code. This can draw any arbitrary region of the work-space buffer to its corresponding place onscreen. It was my original intention to have only the altered regions of the screen redrawn in order to save on the processing time required to update the screen. However, to test the system functionality quickly, I used a full-screen draw instead, intending to write the selective drawing code later.

To my surprise, the full-screen draw itself was sufficiently fast for the purposes of my game engine, so I decided to redraw the entire display on every game cycle to simplify the code. The region drawing code was still handling this full-screen draw as an arbitrary region, however, which slowed it down somewhat, as it was having to add a line offset of zero to the work-space pointer and the screen pointers at the end of each line.

I have now rewritten the region drawing code to instead do only a full-screen draw, without any of the offset adding or start address calculation. This has sped it up somewhat, since it no longer needs to check as many conditions or perform offset calculations for different sized regions.

This rewritten routine has also opened up 32 variable slots in the register map, which were previously used for storing the old positions for objects (which would have been used for the selective drawing code). This means that an extra 32 variable slots are available for use in your game's logic scripts, giving a grand total of 128 variable slots available for use (the other 128 are reserved for internal ZAD use).

I do enjoy rewriting old routines; I find that planning them on paper is the best way to accomplish this, since I can clarify my register allocation and the algorithm itself before I begin to write the code.

I hope to write another progress update soon. See you later! :D
All software to-date
Working on something, as always.
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

"Postie's Peril" - Demo

Post by PROSM »

This project is not dead. Quite the contrary in fact, as I would like to show you a demo of the first game being written with the engine, "Postie's Peril":

[media]https://youtu.be/RE-Ctp0DezU[/media]

It's all well and good seeing the game, but why not trying it as well? The video above only shows a bit of the demo, so to get the full demo as a TAP file, click on the link below.

https://www.dropbox.com/s/8kc69arkjyhco ... o.tap?dl=0

The controls are as follows:
  • 6 - left
  • 7 - right
  • 8 - down
  • 9 - up
  • Enter - select
  • To access verbs, simply push the key for the letter highlighted in white (e.g. A for Apply to, E for Examine. Then you can position the cursor over an object and press Enter to perform the action.
Please do let me know what you think of this demo with a reply, I'd be very grateful if you did.
Last edited by PROSM on Sun Dec 09, 2018 10:09 pm, edited 1 time in total.
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 »

Love it—this is something special. The control mechanism takes a bit of getting used to, but the instructions are all very clear. Please finish it!
User avatar
Ivanzx
Manic Miner
Posts: 736
Joined: Tue Nov 14, 2017 9:51 am

Re: ZAD Adventure System - Progress

Post by Ivanzx »

Looking excellent! One of the very few things the Spectrum did not achieve so far, and it looks like you will do it :)
Ralf
Rick Dangerous
Posts: 2279
Joined: Mon Nov 13, 2017 11:59 am
Location: Poland

Re: ZAD Adventure System - Progress

Post by Ralf »

Looks nice!
And feels a bit similar to early Lucas games like Maniac Mansion or Zak McKraken. Spectrum never had this kind of games, unlike let's say C64. So at last this is going to change, I guess :)
User avatar
druellan
Dynamite Dan
Posts: 1466
Joined: Tue Apr 03, 2018 7:19 pm

Re: ZAD Adventure System - Progress

Post by druellan »

Love it!

Testing it quickly, one small suggestion I can make is to leave the inventory item position when you close the list. This way, when you can't use an item because you are not close enough or any other reason, you don't need to search the inventory again for the item.
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

R-Tape wrote: Sun Dec 09, 2018 9:45 pm Love it—this is something special. The control mechanism takes a bit of getting used to, but the instructions are all very clear. Please finish it!
Thanks, R-Tape! The controls are a bit fiddly at first, but they do get easier to handle with time. An inlay will be included with the full game, with all the instructions, but I'm glad you found my post had enough info to get you going.
Ivanzx wrote: Sun Dec 09, 2018 10:05 pm Looking excellent! One of the very few things the Spectrum did not achieve so far, and it looks like you will do it :)
Thanks, Ivan! I've always felt the Spectrum was missing a point-and-click adventure; the main sticking point seemed to be how to do the graphics in the small memory (this was a major theme of the "Monkey Island on Spectrum" thread at WoS).
Ralf wrote: Mon Dec 10, 2018 9:43 am Looks nice!
And feels a bit similar to early Lucas games like Maniac Mansion or Zak McKraken. Spectrum never had this kind of games, unlike let's say C64. So at last this is going to change, I guess :)
Many thanks, Ralf! :D
druellan wrote: Mon Dec 10, 2018 4:47 pm Love it!

Testing it quickly, one small suggestion I can make is to leave the inventory item position when you close the list. This way, when you can't use an item because you are not close enough or any other reason, you don't need to search the inventory again for the item.
Thanks for the suggestion, druellan! I've implemented this functionality now (however, the list position resets when items are transferred in or out of the inventory).
All software to-date
Working on something, as always.
User avatar
oblo
Drutt
Posts: 31
Joined: Mon Dec 10, 2018 9:24 pm

Re: ZAD Adventure System - Progress

Post by oblo »

This is awesome! Just tried the PostedPeril Demo and with something like this, a lot of dreamed-games can come true :D
BTW, did you considered to use a mouse driver like this or this?
Cheers.
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

oblo wrote: Mon Dec 10, 2018 10:28 pm This is awesome! Just tried the PostedPeril Demo and with something like this, a lot of dreamed-games can come true :D
BTW, did you considered to use a mouse driver like this or this?
Thanks [mention]oblo[/mention] for your kind comment! In regards to a mouse driver, I may implement one. I'm trying to avoid touching the engine code now, so that I can focus on the game itself, but if I can get it working quickly enough, then there will be Kempston mouse support.
All software to-date
Working on something, as always.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: ZAD Adventure System - Progress

Post by RMartins »

This has gone a long way. from the initial screens. 8-)

Hoping to see this finished in the near future. :geek:
User avatar
Kweepa
Manic Miner
Posts: 311
Joined: Sat Feb 03, 2018 6:14 pm
Location: Albuquerque, New Mexico

Re: ZAD Adventure System - Progress

Post by Kweepa »

I agree.
Looking forward to writing a game with this - I'll probably write a Reality-On-The-Norm game (an old Adventure Game Studio group project).
But only if the movement controls are customizable to ZXKM. :)

So we can start work, what are the maximum main character sprite dimensions?
Here's Mika Huy, reporter for the Realizer, reduced to 40px high:
Image
User avatar
PROSM
Manic Miner
Posts: 473
Joined: Fri Nov 17, 2017 7:18 pm
Location: Sunderland, England
Contact:

Re: ZAD Adventure System - Progress

Post by PROSM »

Kweepa wrote: Thu Mar 07, 2019 12:08 am I agree.
Looking forward to writing a game with this - I'll probably write a Reality-On-The-Norm game (an old Adventure Game Studio group project).
But only if the movement controls are customizable to ZXKM. :)

So we can start work, what are the maximum main character sprite dimensions?
Here's Mika Huy, reporter for the Realizer, reduced to 40px high:
Image
The maximum dimensions for any frame is 32x16 characters (so 256x128 characters). Of course, this is if memory will permit, as the amount of memory a frame will take can be calculated using the formula m = 2wh + 2, where w is the width and h is the height.

Your graphics might not work too well, though, as the game display is an emulated character mode. This means that all of the backgrounds and frames are built up of tiles from a universal character-set (of 255 characters, with one reserved for blank). This measure is necessary in order to reduce the memory used by graphics. Those three sprites above would make up 30 characters in the set, or about 12%. You may want to reconsider redesigning the graphics, perhaps making them bigger so that they can be designed around the character block limits.
All software to-date
Working on something, as always.
User avatar
Kweepa
Manic Miner
Posts: 311
Joined: Sat Feb 03, 2018 6:14 pm
Location: Albuquerque, New Mexico

Re: ZAD Adventure System - Progress

Post by Kweepa »

Ah yes, I see. I'd be willing to use up half my character set to realize the main character! :)
(Any progress on the engine?)
Post Reply