Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
  You are not logged in - nap
Foundry 255b   [2019]

Foundry 255b Released by :
ChristopherJam

Release Date :
8 August 2019

Type :
C64 1K Intro

Released At :
The 256b Sprite Font Compo

Achievements :
C64 1K Intro Competition at The 256b Sprite Font Compo :  #2

User rating:**********  9.6/10 (29 votes)   See votestatistics
**********  10/10 (8 votes) - Public votes only.

Credits :
Code .... ChristopherJam
Graphics .... ChristopherJam

Download :
http://csdb.dk/getinternalfile.php/187035/foundry255b cjam.prg (downloads: 179)
http://csdb.dk/getinternalfile.php/188789/foundry_src.zip (downloads: 37)

Look for downloads on external sites:
 Pokefinder.org


Production Info
Submitted by ChristopherJam on 29 September 2019
Some notes on the rendering process:


Before rendering commences, a loop decunches the pattern definition into a 252 byte fill pattern buffer. Each pattern definition byte uses bits three and four to specify the colour for the even pixels, and bits one and two to specify the XOR of the even and odd pixels.

The fill pattern is reflected, and only 19px high, so only 10 bytes are required to define it.



The first pass in rendering each letter is to render a 2x4 MCM pixel splat at each location marked with an 'o' in the original font definition.

At conversion time the potential splat locations are classified into those used by eight or more letters, and those used by seven or fewer letters. Any letters that only use common splat points are defined with 16 flags to select from the common spalt points, the remainder use 24 flags.

The splats are performed by first writing $83 to four pixels in the zero page framebuffer for each splat point (at (x,y), (x+1,y), (x,y+2) and (x+1,y+2)), then a nominal second pass ORs each row in the frame buffer with its predecessor.

Just before the second pass there are a few pixel copies that round up to three of the corners of letters like O, C, D etc (I ran out of space for rounding the bottom right, but it's darker and hence less noticeable).

The loop at "pl" combines what used to be passes two through five, all now rolled into a single loop

The third pass does the shadow - it sets bit zero in each pixel if that bit is set in either the pixel above or the pixel to the left.
sbuf[x,y] = sbuf[x,y] | (sbuf[x-1,y]&1) | (sbuf[x,y-1]&1))

The fourth pass does the highlight, ORing in light grey from right and down, mid grey from the diagonal:
sbuf[x,y] = sbuf[x,y] | (sbuf[x,y+1]&3) | (sbuf[x+1,y]&3) | (sbuf[x+1,y+1]&2)

At this stage, the frame buffer contins $83 for any pixels covered by the splats, and 0x for anything that should contain a shadow or highlight pixel.

The fifth pass replaces any pixels with bit 7 set with pixels from the pattern fill buffer.

The final stage copies pixels from the frame buffer to the sprite definition, using a pair of ones shifted through "fourloop' as flags to trigger a memory write for every four pixels read.



Some additional space saving measures.

The splatting is performed by using zero page indexed store instructions. This addressing mode wraps, to always write to zero page even if X+addr>255. We take advantage of this by hunting for a magic number that can be added to all of the splat locations (themselves just 8 bit indices into the render buffer) with the property that "as many as possible values for the pattern location can then be found within the first 16 elements of the list."

If the pattern is stored in bits 1..4 instead of the more obvious 0..3, then "as many as possible" turns out to be "all of them," which is nice.

That number is then added to the splat locations and subtracted from the base address for the splat STAs, and the splat location table reordered to move the 10 pattern definition bytes to the front, saving 10 bytes off the executable size. Note that the four bits of the pattern definition bytes are don't-cares, which does help a bit.

The $11 value used to trigger writes in the final stage is just stored in the loop initialiser for the pattern fill.

The letters that only use 16 splat points are all moved to the front, so a simple decrement/bpl serves to select the flag count for the next letter.

The first byte of the bitstream that defines the letters is used as the bitbuffer for the most recent byte read from the stream.

The renderer just keeps running until the bitstream reader crosses the page boundary at the end of page nine; I don't use the charcount that I forgot to delete.
Search CSDb
Advanced
Navigate
Prev - Random - Next
Detailed Info
· Summaries
· User Comments (18)
· Production Notes (1)
Fun Stuff
· Goofs (3)
· Hidden Parts
· Trivia
Forum
· Discuss this release
Sponsored links
Support CSDb
Help keep CSDb running:



Funding status:




About this site:
CSDb (Commodore 64 Scene Database) is a website which goal is to gather as much information and material about the scene around the commodore 64 computer - the worlds most popular home computer throughout time. Here you can find almost anything which was ever made for the commodore 64, and more is being added every day. As this website is scene related, you can mostly find demos, music and graphics made by the people who made the scene (the sceners), but you can also find a lot of the old classic games here. Try out the search box in the top right corner, or check out the CSDb main page for the latest additions.
Home - Disclaimer
Copyright © No Name 2001-2022
Page generated in: 0.085 sec.