[CSDb] - User Forums - Dynamic Character Set

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Dynamic Character Set

2018-03-13 05:48

TBH

Registered: Mar 2010
Posts: 21

Dynamic Character Set

For some years I've been curious about the potential for dynamic character set definitions in scrolling games. It's not a new idea and there are many limited implementations (Bounder, Katakis, Hawkeye, Golden Axe, etc).

But, so far I haven't seen a transition-less scrolling game that was not limited to 256 char definitions. My idea is to treat the viewable screen as two edges - one incoming, one outgoing.

The incoming edge is 16-bit to hold the character definition indices. I'll call these Tiles.
The outgoing edge is 8-bit to hold the outgoing indices of the character definitions.
A section of char IDs can be set static so that Tile IDs fall straight through to the screen instead of undergoing transformation.

LIMITATIONS
1) No more than the number of characters allocated to use by the routine can appear on screen. If all 256 chars are set to be dynamic, then the screen cannot display more characters than that. Maps have to be designed with that in mind.
2) CPU Cycles.
Assuming a 75-byte edge (for diagonals), it's likely no more than 10 new char definitions will be introduced in one hit. YMMV.
No new chars takes about 2500 cycles. 10 new chars about 4500 cycles.
It's a lot, but my prototype code isn't optimised.

TECHNIQUE
Incoming Edge
1) Copy the incoming Tile indices to the Incoming Edge table. For example, if scrolling to the left, these images will appear in the rightmost column.
2) Check each Tile index to see if it is currently assigned a Char ID.
2A) If so, increment the char's counter of onscreen-occurrence and push the Char ID onto the screen or a buffer.
2B) If not, assign an unused character and copy the Tile image to the char's definition.

Outgoing Edge
1) Copy the outgoing char indices to the outgoing Edge table. These are the chars that are scrolling off the screen.
2) Use the char as an index to the table holding the counter for its onscreen occurrences and decrement that value. If there no further occurrences of that char onscreen then place it back into the pool of unused char Ids and mark the corresponding Tile ID as having no associated char.

OTHER USES
This could also work for regions of a non-scrolling screen. For example, a Bard's Tale style RPG where lots of character images need to be plotted and animated. For any region of the screen that needs to use dynamic chars applied, just "swipe" the origin of the edges down each row of that region.

BACK TO REALITY
Anyway, I wrote a prototype routine which works as expected, but that CPU hit is probably why no game seems to have adopted a similar approach.

... 20 posts hidden. Click here to view all posts....

2018-03-18 03:51

ChristopherJam

Registered: Aug 2004
Posts: 1409

Quote: You can linecrunch but what happens when you've scrolled a whole screen?

The idea was to combine linecrunch with your six screens method - so after you linecrunch by five rows, the amount of crunch is reset back to zero again.

2018-03-19 04:57

TBH

Registered: Mar 2010
Posts: 21

Some interesting points have been made that illustrate quite well the various trade-offs between CPU time and memory space for when resources are limited.

I like Oswald's suggestion for a bitmap-like characters display. It's appealing for reasons of convenience and speed:
a) No restriction on the number of unique visible char definitions.
and
b) Hard scroll is fast because it can be done with a CPU index register used as both loop counter and character value, instead of the more common technique of shifting arbitrary character values around screen memory.

But it is not so appealing when memory is sparse since it uses the same amount as a bitmap screen; at least 9K in one video bank unless you split that across two or more.

@ChristopherJam re "I assume you mean 65 new chars for diagonals?"
Yes, 65. Addition was never my strong point. Neither is programming, I suspect.

The various ideas about using regions and generating the char map optimally is something I investigated earlier:

It seemed that for a uni/bi-directional scroller, it would be easy to have character redefinitions flagged only on the incoming rows or columns when necessary. So, a char map designed to never have more than the allowed definitions visible could be used. The actual dynamic redefinitions would be stored in a separate lookup table which would redefine a char when a new definition was incoming on a column (or row). IOW, only the differences would be stored and handled.

But as I see it, only a uni/bi-directional scrolling map can guarantee (in a reasonable amount of memory) that the char map will match such an only-if-a-redefinition-is-needed lookup table. In such a case the lookup table is a one-dimensional array (for a bi-directional scroller it is reflected for the opposite direction).

But a multi-directional scroller would require a potentially massive two-dimensional table that handled four directions separately in relation to the previous XY coordinate (effectively an Acyclic Graph)- which is why I resorted to handling individual characters as described in my prototype routine.

For multidirectional scrolling, the idea by lft and others about regionalising the map elements is a nice one. But, wouldn't the map's variety be reduced due to potential conflict between char definitions occurring in all directions (greater areas of overlap), not just left/right or up/down? However, an extra onscreen charset would help with that, as mentioned. I can imagine it working well with, say, a top-down RPG like Times Of Lore with different geographical regions with clearly defined graphical differences - you are walking in a pine forest, then slowly emerge into farmland, then a few screens later enter a city.

Anyway, the above is just a bundle of thoughts this conversation thread has inspired so far. At least I now have a clearer idea of what other options are available for the things I'm attempting.

Previous - 1 | 2 | 3 - Next

Refresh

Subscribe to this thread: