[CSDb] - User Forums - Event id #2846 : The 256b sprite font compo

You are not logged in - nap

CSDb User Forums

Forums > CSDb Entries > Event id #2846 : The 256b sprite font compo

2019-07-22 00:58

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Event id #2846 : The 256b sprite font compo

<Post edited by moderator on 22/7-2019 11:21>

* The object of the competition is to generate a sprite-font, in 256 bytes or less code.
* The code should be placed at $0900 and up, but no further than $09ff and must end with an RTS.
* The sprites should be placed at $2000-$2fff, so sprite number $80-$bf.
* 64 sprites are viewed, but it is up to the coder to decide how many he want to generate, but to be considered a font, at least the letters A-Z should be present and readable.
* For the other sprites, you can of course generate the appropriate numbers/punctuation characters, or spaceships or whatever, or not generate them at all and spend all your bytes on doing fancier A-Z, it's up to you to decide what will impress the voters most! :)
* Since the code to actually view the sprites would take quite some space, and the competition should not be about that optimizing the viewer code (or who can do the coolest looking viewer) I will provide the code that displays the 64 sprites on screen, it will occupy $0801-$08ff, and will perform a JSR to $0900 where your font generation code should be.
* The viewer has a number of tweakable parameters that are placed on $0810-$0814:
$0810 - $00=Sprites should be singlecolor. $ff=Sprites should be multicolor
$0811 - Bakground and border color.
$0812 - Sprite base color ($d027-$d02e will be set to this)
$0813 - Sprite multicolor1 ($d025 will be set to this)
$0814 - Sprite multicolor2 ($d026 will be set to this)
Simply change these bytes directly in the viewer code (if you compile it) or in the final binary if you use that, they should not be set from you generator code, as this is also not something that should steal your precious space.
* The generator code may *not* depend on A,X,Y holding specific startup values, or memory being initialized to something specific (you may for example not pull data from the viewer code and use etc.).
* The generator code may use ZP and stack (remember that your code is a subroutine that is being called though, so don't destroy the return address!)
* The generator may use memory up to $3fff
* Max three entries per coder
* The deadline for the compo is two months from now, 2019-09-22 at 23:59:59 CET
* Then follows a voting period of two weeks, a snapshot of the CSDb votes at 2019-10-06 at 23:59:59 CET will be the final result. (modedit: fixed date)
* No prizes except eternal glory.

Here's the viewer code for Kick Assembler usage, with a place to put your generator code at the end:
.pc =$0801 "Basic Starter"
:BasicUpstart($0820)

.pc=$0810 "Constants"
multicol:
.byte $00
bgcol:
.byte $06
sprcol:
.byte $0e
sprmcol1:
.byte $00
sprmcol2:
.byte $00

.pc = $0820 "Code"
sei
lda multicol
sta $d01c
lda bgcol
sta $d020
sta $d021
lda sprmcol1
sta $d025
lda sprmcol2
sta $d026
lda sprcol
ldx #$07
!loop:
sta $d027,x
dex
bpl !loop-
ldx #$00
lda #$20
!loop:
sta $0400,x
sta $0500,x
sta $0600,x
sta $0700,x
inx
bne !loop-
lda #$ff
sta $d015
lda #$80
sta $d010
ldx #$07
ldy #$00
lda #$18+44
!loop:
sta $d000,y
clc
adc #29
iny
iny
dex
bpl !loop-
jsr generatefont
lda #$35
sta $01
mainloop:
lda #$2f
sta ycoord
lda #$80
sta spridx
yloop:
lda ycoord
!wait:
cmp $d012
bne !wait-
clc
adc #4
ldx #$07
ldy #$00
!loop:
sta $d001,y
iny
iny
dex
bpl !loop-
ldx #$00
ldy spridx
!loop:
tya
sta $07f8,x
iny
inx
cpx #8
bne !loop-
clc
lda spridx
adc #8
sta spridx
lda ycoord
adc #25
sta ycoord
cmp #$2f+8*25
bne yloop
jmp mainloop

ycoord:
.byte 0
spridx:
.byte 0

.pc=$0900 "Font generation code"
generatefont:
rts

Yes, code is neither pretty nor optimal, but that's not the point here, the pretty code should be written by YOU! :D

If you prefer some other assembler, here's the prebuilt binary for the $0801-$08ff portion:
sprite_font_view_base.prg

Here are some simple examples I've done to prove that it actually works:
Sprites using ROM font scaled to 3x3 pixel size. $0810 params set to : $00,$06,$0e,$00,$00
example1.prg

Exact same font but with multicolor params set (works this way as well!) $0810 params set to : $ff,$0b,$0c,$0f,$0f
example2.prg

2019-07-22 01:05

Shadow
Account closed

Registered: Apr 2002
Posts: 355

A CSDb-related question - what type of release should the entries be set as? "C64 1k intro" perhaps?
Because even if the competing code is less than 256b, the final result .prg with the included viewer will be upwards of 512 byte big.

2019-07-22 10:28

Rex

Registered: Sep 2011
Posts: 14

There is a typo in your voting period end date. It ends before the compo deadline.

2019-07-22 11:10

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Quote: There is a typo in your voting period end date. It ends before the compo deadline.

AH crap! Yes, it's supposed to be 2019-10-06 of course. Unfortunately I can't edit it now.

2019-07-22 11:19

iAN CooG

Registered: May 2002
Posts: 3204

Quote: AH crap! Yes, it's supposed to be 2019-10-06 of course. Unfortunately I can't edit it now.

I changed it for you to 6 october

2019-07-23 06:59

ChristopherJam

Registered: Aug 2004
Posts: 1409

Can we still assume that interrupts are already disabled?

(as per comment #13 from Proposal - The sprite font compo!)

I just noticed that Geir's entry starts by disabling CIA interrupts, and was wondering if other ROM based entries can safely skip that step.

2019-07-23 11:38

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Quote: Can we still assume that interrupts are already disabled?

(as per comment #13 from Proposal - The sprite font compo!)

I just noticed that Geir's entry starts by disabling CIA interrupts, and was wondering if other ROM based entries can safely skip that step.

Yes, that was my intention, seems like I forgot to copy that text over to the official rules.

2019-07-23 19:46

Rudi

Registered: May 2010
Posts: 126

So, the generator code should be less than or equal to 256b, but not the final .prg (or whatever format you use), since you're providing the viewer code?

2019-07-23 23:47

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Quote: So, the generator code should be less than or equal to 256b, but not the final .prg (or whatever format you use), since you're providing the viewer code?

That is correct:
"The end result PRG should not be a 256 byte binary, instead it's the 257 bytes (for viewer code + load address) PLUS your code, so the ending .PRG file may be as big as 513 bytes." this was my summary of it posted in the discussion thread, unfortunately I forgot to copy it into the event description.

2019-07-24 00:27

Rudi

Registered: May 2010
Posts: 126