Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
 Welcome to our latest new user hardy_1974 ! (Registered 2018-03-16) You are not logged in 
CSDb User Forums

Forums > C64 Coding > Dynamic Character Set
2018-03-13 06:48

Registered: Mar 2010
Posts: 6
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.

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.

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.

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.

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.
... 7 posts hidden. Click here to view all posts....
2018-03-14 03:49

Registered: Oct 2010
Posts: 135
I thought of something like this many years ago, for a very real purpose: 9600 baud scrolling 80 column terminal. You can't use too much time at once because you need to read the incoming bits in real-time.
2018-03-15 05:21
Martin Piper

Registered: Nov 2007
Posts: 378
Flying Shark does this IIRC.
2018-03-15 10:55

Registered: Sep 2002
Posts: 81
Quote: I thought of something like this many years ago, for a very real purpose: 9600 baud scrolling 80 column terminal. You can't use too much time at once because you need to read the incoming bits in real-time.

The Diskmag Relax featured a fullscreen proportional font upscroller. I think it was also done with charsets like this.
2018-03-16 02:55

Registered: Dec 2001
Posts: 935
Oswald aka MicroPenis' technique would seriously limit the number of sprite frames you could have in a bank. Almost as much as my work in progress FLI game, so I would not recommend that, unless you think it's easier to dynamically allocate them all the time. :)
2018-03-16 09:27

Registered: Aug 2004
Posts: 751
Hybrid TBH/μPenis approach: two charsets for upper/lower screen, for up to 512 definitions at once \O/

(of course, scrolling vertically would be.. interesting.. Perhaps keep the split lines static relative to the map, so they scroll with the screen? Would be useful artwise as you could ensure style changes aligned with charset changes)
2018-03-16 09:32

Registered: Aug 2004
Posts: 751

I assume you mean 65 new chars for diagonals? (40+25). You could split the load across screens by usually staying 8-15 pixels ahead on horizontal movement, and deferring the vertical edge by a frame whenever both vertical and horizontal edges are crossed.

I'm wondering if it would be worth dividing the map into regions that used 8 bit indices internally, to avoid all the 16 bit index use in the management routines. Each region would have its own mapping table, and count table for number of onscreen occurrences of each id.

Not much to be gained from large area splits compared to just changing charset when you get to a new area, but perhaps the regions could be (eg) per 16x16 character megatile, or two regions alternating for odd/even rows of chars on the map?
2018-03-16 10:39

Registered: Jul 2007
Posts: 328
With a static map, much of this work can be done offline. For instance, you could have 128 globally defined chars, and any number of "logical" chars that are mapped to the remaining 128 "physical" chars.

The map editor should perform the mapping, and ensure that it is always possible to assign the same physical char to any given logical char. That is, if two logical chars can ever appear simultaneously on the screen (at some scroll offset), they must be mapped to different physical chars. This turns into a large constraint problem that can be simplified if the map is divided into sub-areas. The map editor would also emit tables/code to update the font when a new sub-area scrolls into view.
2018-03-16 11:01

Registered: Oct 2010
Posts: 135
I remembered how I made my full screen no-cpu scroller.

Each charset covers 6 rows, so there's 4 of them. The memory areas are split with 4 rasters. The screens shows 0-239 in order. There's 6 predefined screen mems. Each one shows the chars scrolled one more up.

Scrolling has 6 phases, where you change the screen mem pointer and move the rasters up one row. The new row comes from the first charset, and you have to plot into charset definitions. That's 320 bytes to write.

At 9600 baud, I think there's several chars you can plot per frame, so update in chunks which is a bit more efficient.

You can go even beyond this if you don't mind some flicker; you can use two banks and have each 4x8 area with it's own colour to support ANSI screen codes.

Blank spaces can use one of the remaining 6 chars definitions then you only need to write that char into the row of screen mem, so each line of update doesn't have to plot a full row into the charset definitions.
2018-03-16 14:41

Registered: Aug 2004
Posts: 751
Quoting lft
The map editor should perform the mapping, and ensure that it is always possible to assign the same physical char to any given logical char.

That would certainly cut down the runtime significantly, but it's also a somewhat less flexible system. It's easy enough to synthesise a case that fails to satisfy that constraint that TBH's system would nonetheless be fine with (eg include the first 256 logical chars on one screen, have a second screen that includes char 257 and the first 128 chars, and a third screen that includes char 257 and the second 128 chars).

No idea whether that would be an issue in practice, mind :)
2018-03-16 14:45

Registered: Aug 2004
Posts: 751
Nice work, Repose.

You could save a few KB by using linecrunch to scroll up a row or five, but then you'd still need the first few rows of another screen to switch to at some raster line or other if you wanted to maintain the 'zero cpu' constraint.
Previous - 1 | 2 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Users Online
Guests online: 44
Top Demos
1 Uncensored  (9.7)
2 Edge of Disgrace  (9.7)
3 C64 48Khz HiFi Digi ..  (9.7)
4 SSDPCM2 V3 - 16khz  (9.6)
5 Coma Light 13  (9.6)
6 The Shores of Reflec..  (9.6)
7 Comaland 100%  (9.6)
8 Lunatico  (9.6)
9 Incoherent Nightmare  (9.5)
10 Wonderland XII  (9.5)
Top onefile Demos
1 Pandemoniac Part 2 o..  (9.5)
2 Dawnfall V1.1  (9.5)
3 Synthesis  (9.5)
4 Treu Love [reu]  (9.5)
5 Daah, Those Acid Pil..  (9.5)
6 Dawnfall  (9.4)
7 Merry Xmas 2017  (9.4)
8 FMX Music Demo  (9.4)
9 Hardware Accelerated..  (9.3)
10 One-Der  (9.2)
Top Groups
1 Oxyron  (9.4)
2 Booze Design  (9.4)
3 Censor Design  (9.3)
4 Arsenic  (9.3)
5 Crest  (9.3)
Top NTSC-Fixers
1 Pudwerx  (9.8)
2 Horizon  (9.7)
3 The Shadow  (9.7)
4 Stormbringer  (9.6)
5 Fungus  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2018
Page generated in: 0.24 sec.