| | Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Sine sprites in the sideborder. VSP garbage and more
Hello everyone. I'm working on my first C64 demo / intro. I managed to open the sideborder at the top and obviously I immediately put some X-sinus sprites there (I'm still trying to figure out how a DYSP works, right know i have opened lines with 0 and 8 sprites). I noticed that the positioning of the sprites on the X axis is a bit weird. Position 0 is slighty on the left border, but if you want to go all the way to the left you have to use X 500 or there about. My question is, is there some sinus maker or converter that would take care of this ? (so it goes from 0 to ~500 looking like smooth movement to the left). Another question, what is the good way of handling the 9th bit of X position ? What I do is generate a 256 words sinus with values 0 to 500 and use c++ program to split that into 2 256 bytes tables like
sin_1:
1,2,3,4,5,6,7,55,33,....
sin_2:
1,0,0,0,0,1,0,0,1.... where 1 means to set the bit and 0 to not do that.
My sprite 0 is bugging out in the right most border while other sprites display just fine. Why is that ? I've read somewhere that sprite 0 is evil, but could not find any details on why.
I also do VSP by turning on the screen at the right moment together with XSCROLL for smooth scrolling. I see few pixel lines of garbage just above the image, I cover that with the illegal screen mode, disable it at line 56. Is that a good idea ? Another thing about VSP is that it seems to move the whole screen down by one char on the scrolled side (makes sence I guess, as the part of the chars that are outside of the image are displayed on the next text line). So should I copy the 25 lines of graphics in each column when scrolling for seamless scroll or do people not do that ?
Here's a picture of what it looks right know. A big mess !
(PETSCII picture by Archmage as a placeholder. I can't find any pics in binary and that was the easiest to take out of a compiled prg) Hope you have the patience to help a lamer out.
https://i.imgur.com/byWFRsH.jpg[/url]
HughJass from Poland |
|
... 55 posts hidden. Click here to view all posts....
|
| | Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Darn, I didn't want to post here anymore till I realease the demo, but I came across a problem I can't solve, and it can't be too hard, I'm just missing something.... Can someone explain this garbage in FLD area ?
https://i.imgur.com/Y1VQX6D.mp4
I'm doing FLD on am unstable raster (by 0-3 cycles) but that shouldn't be a problem, eh? This is the same interrupt that changes from bitmap to char mode.
irq_line_209:
pha
txa
pha
tya
pha
!for inner, 0, 10{
nop
}
lda #$65
sta $d018
lda #$1b
sta $d011
ldy fld_counter
ldx fld_sin, y
-:
lda $d012
cmp $d012
beq *-3
clc
lda $d012
adc #1
and #7
ora #$18
sta $d011
dex
bne -
inc flc_counter
lda scroller_d016_counter
sta $d016
dec scroller_d016_counter
bne +
lda #7
sta scroller_d016_counter
+:
Thanks for your help guys! |
| | ChristopherJam
Registered: Aug 2004
Posts: 1409 |
Easiest way to hide the garbage is to just blank the area by setting an illegal mode such as ECM+bitmap, ie just ORA#$78 instead of #$18 in your FLD loop.
Then regardless of what your d018 value and last row of characters read, VIC-II will just display black pixels.
But as to where it's coming from in the first place.. maybe ADC 2 or 3 instead of just 1? You're currently repeatedly saying "do a badline on the next raster" then waiting for the beginning of the next raster to start working out the value to use to avoid the DMA you've just queued. It's due only a few cycles into the line you've waited for; suspect you're doing a badline on most lines at the moment rather than a traditional "gap between the char rows" FLD per se. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
yeah at fld badlines happen naturally when you stop the scrolling, no need to force em. |
| | Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Am I doing FPP effect here ? This is still the bugged FLD. If I had 8 copies of this charset with each starting a line below and if I'd swap between them on each line... or am I thinking about something else.
https://i.imgur.com/9c7fRBC.png
Anyway, I've fixed my FLD. The problem was that I wanted to do too much on the same line... change from bitmap to text, scroll it, calculate the d011... I rearanged some of the code and now it works fine. But I'm still curious about the effect in the picture above. |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
almost fpp... it is possible to repeat a char line like that, any nr of rows, you can repeat every 1st 4 row, every 1st 6 row, and every 1st 1 row is fpp... it doesnt even need cycle exact timing just a so-so. |
| | Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: almost fpp... it is possible to repeat a char line like that, any nr of rows, you can repeat every 1st 4 row, every 1st 6 row, and every 1st 1 row is fpp... it doesnt even need cycle exact timing just a so-so.
Alright, I'll try some FPP in the next part. Your chessboard in Soiled Legacy is done using FPP, right ? |
| | Oswald
Registered: Apr 2002
Posts: 5094 |
yep :) |
| | Golara
Account closed
Registered: Jan 2018
Posts: 212 |
I have a very strange thing going on... I'm trying to code an intro for the part where the sprite logos scroll from the left side of the screen one after another. This is done with 4 interrupts, on line 50, 100, 150, 200 with this code
intro_logo_1_x !byte 0
intro_logo_2_x !byte 0
intro_logo_3_x !byte 0
intro_logo_4_x !byte 0
intro_fld_counter !byte $ff
logo1_d010:
!byte 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!byte 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!byte 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
!byte 0,0,0,0,0,0,0,0,0,128,128,128,128,128,128,128
logo1_d015:
!byte 128,128,128,128,128,128,128,128,128,128,128,192,192,192,192,192
!byte 192,192,192,192,192,192,224,224,224,224,224,224,224,224,224,224
!byte 240,240,240,240,240,240,240,240,240,240,240,248,248,248,248,248
!byte 248,248,248,248,248,248,252,252,252,252,252,252,252,252,252,252
logo1_d000:
!byte 0,5,9,14,18,23,27,32,36,41,45,50,54,59,63,68
!byte 72,77,81,86,90,95,99,104,108,113,117,122,126,131,135,140
!byte 144,149,153,158,162,167,171,176,180,185,189,194,198,203,207,212
!byte 216,221,225,230,234,239,243,248,252,1,5,10,14,19,23,28
intro_1_irq:
inc $d020
pha
txa
pha
lda #01
!for inner, 0, 5{
sta $d029+inner
}
lda #$fc
sta $d01d
sta $d017
ldx #6
!for inner, 0, 5{
stx $4ffa + inner
inx
}
lda #52
sta $d005
sta $d007
sta $d009
sta $d00b
sta $d00d
sta $d00f
ldx intro_logo_1_x
lda logo1_d010, x
sta $d010
lda logo1_d015, x
sta $d015
lda logo1_d000, x
!for inner, 0, 4{
sta $d00e - (inner*2)
clc
sbc #47
}
sta $d00e - 10
cpx #63
beq +
;dec intro_fld_counter
inx
+:
stx intro_logo_1_x
lda #<intro_2_irq
sta KERNALIRQServiceRoutineLo
lda #>intro_2_irq
sta KERNALIRQServiceRoutineHi
lda #100
sta VIC2Raster
+MACROAckRasterIRQ_A
pla
tax
pla
dec $d020
rti
intro_2_irq:
inc $d020
pha
txa
pha
lda #02
!for inner, 0, 5{
sta $d029+inner
}
lda intro_logo_1_x
cmp #63
bne +
lda #$fc
sta $d01d
sta $d017
ldx #0
!for inner, 0, 5{
stx $4ffa + inner
inx
}
lda #102
sta $d005
sta $d007
sta $d009
sta $d00b
sta $d00d
sta $d00f
ldx intro_logo_2_x
lda logo1_d010, x
sta $d010
lda logo1_d015, x
sta $d015
lda logo1_d000, x
!for inner, 0, 4{
sta $d00e - (inner*2)
clc
sbc #47
}
sta $d00e - 10
cpx #63
beq +
dec intro_fld_counter
inx
+:
stx intro_logo_2_x
lda #<intro_3_irq
sta KERNALIRQServiceRoutineLo
lda #>intro_3_irq
sta KERNALIRQServiceRoutineHi
lda #150
sta VIC2Raster
+MACROAckRasterIRQ_A
pla
tax
pla
dec $d020
rti
intro_3_irq:
inc $d020
pha
txa
pha
lda #03
!for inner, 0, 5{
sta $d029+inner
}
lda intro_logo_2_x
cmp #63
bne +
lda #$fc
sta $d01d
sta $d017
ldx #12
!for inner, 0, 5{
stx $4ffa + inner
inx
}
lda #152
sta $d005
sta $d007
sta $d009
sta $d00b
sta $d00d
sta $d00f
ldx intro_logo_3_x
lda logo1_d010, x
sta $d010
lda logo1_d015, x
sta $d015
lda logo1_d000, x
!for inner, 0, 4{
sta $d00e - (inner*2)
clc
sbc #47
}
sta $d00e - 10
cpx #63
beq +
dec intro_fld_counter
inx
+:
stx intro_logo_3_x
lda #<intro_4_irq
sta KERNALIRQServiceRoutineLo
lda #>intro_4_irq
sta KERNALIRQServiceRoutineHi
lda #200
sta VIC2Raster
+MACROAckRasterIRQ_A
pla
tax
pla
dec $d020
rti
intro_4_irq:
inc $d020
pha
txa
pha
lda #05
!for inner, 0, 5{
sta $d029+inner
}
lda intro_logo_3_x
cmp #63
bne +
lda #$fc
sta $d01d
sta $d017
ldx #18
!for inner, 0, 5{
stx $4ffa + inner
inx
}
lda #202
sta $d005
sta $d007
sta $d009
sta $d00b
sta $d00d
sta $d00f
ldx intro_logo_4_x
lda logo1_d010, x
sta $d010
lda logo1_d015, x
sta $d015
lda logo1_d000, x
!for inner, 0, 4{
sta $d00e - (inner*2)
clc
sbc #47
}
sta $d00e - 10
cpx #63
beq +
dec intro_fld_counter
inx
+:
stx intro_logo_4_x
lda #<intro_1_irq
sta KERNALIRQServiceRoutineLo
lda #>intro_1_irq
sta KERNALIRQServiceRoutineHi
lda #50
sta VIC2Raster
+MACROAckRasterIRQ_A
pla
tax
pla
dec $d020
rti
And now look at what happens... the first logo is flickering, it looks like the d015 writes that happen at lines 100,150,200 have an affect on sprites on line 52... How is that possible ?
Another interesting thing is that the rasters seem to be stable (no flickering on the border colors) even though it's not a stable routine. Sure, the cpu i just executing a busy loop outside of the interrupt, but it should still be able to interrupt between the opcode sometimes (as it always did when I set up a simple raster interrupt)
https://i.imgur.com/jTBQxv8.png
(code like this will be converted to speedcode generator ofcourse later on) |
| | Mixer
Registered: Apr 2008
Posts: 452 |
lda logo1_d015, x
sta $d015
Perhaps that write takes place too late and it is already line 52. |
| | Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Mixer. I've tried putting sprites much lower than 2 lines and the effect is still the same |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next | |
