| |
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 |
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
"is there some sinus maker or converter that would take care of this ? "
no. you have to write your own.
"what is the good way of handling the 9th bit of X position ?"
handle sprite x pos as a 16bit number.
"My sprite 0 is bugging out in the right most border while other sprites display just fine. Why is that ?"
iirc because sprite gfx is being read exactly at that pos where you display it.
"I cover that with the illegal screen mode, disable it at line 56. Is that a good idea ? "
yes
"So should I copy the 25 lines of graphics in each column when scrolling for seamless scroll or do people not do that ?"
yes |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
But if I just use 16bit numbers I also need a 16 bit counter or ? Cuz right know I have just one counter and i use it to read from two tables
ldx sin_counter
lda sin_1, x
sta $d000
lda sin_2, x
beq skip_9th_bit
lda $d01d
ora #$01
sta $d01d
skip_9th_bit:
inc sin_counter
.... |
| |
Trash
Registered: Jan 2002
Posts: 122 |
X-positions in sideborder work like this:
position 0 is right of the the left-most position, between 0 and -248 (the position just one pixel to the left of 0) there is a gap of 8 pixels that essentially just hides your sprite.
I usually for simplicity use two sin-curves and a look up table for calculating sprites x-position.
According to how a DYSP work, they can work in any number of ways, I recommend using the easiest variant to start with: load the value 63 in dc04 and start a clock at the right moment, use $dc04 to know how many cycles you need to waste... |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
What you see in the first post is result of about 40 hours of coding, I didn't try anything with CIA yet. I was reading about cycle tables and how to calculate that... I'm trying to understand that first.
Well I have another question now. Right know I open about 10 lines of 0 sprites and then 21 with 8 sprites (with 7 sprites the timing is the same, but at least i don't have that bug). I'm just using macros like this (for ACME)
!macro MSideBorder8sprites{
dec sideborder_color_counter
sta $d021
nop
nop
nop
ldx sideborder_color_counter
lda colors, x
nop
nop
nop
nop
nop
dec $d016
inc $d016
}
!macro MSideBorder0sprites{
sta $d021
ldx sideborder_color_counter
lda colors, x
inc sideborder_color_counter
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
bit $88
nop
nop
nop
dec $d016
inc $d016
}
and call it like that
_stable:
lda #$c8
sta $d016
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
bit $ea
nop
;inc $d021
nop
nop
nop
dec $d016
inc $d016
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder0sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
+MSideBorder8sprites
lda #$00
sta $d021
dec sideborder_color_counter
dec sideborder_color_counter
dec sideborder_color_counter
dec sideborder_color_counter
As you can see I also do some scrolling rasterbars. For the lines with 0 sprites it looks great, the color changes way back to the left (you can barely see it with debug borders in VICE) but on the lines with 8 sprites it changes somewhere in the middle of the screen, so I have this 1 pixel high split... Is there a way to fix it or should i just go for a full blown raster split. |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Try changing the border color between dec $d016 and inc $d016.
You have between cycles 56 and 17 next line to do the border opening and other stuff. The sprite data fetching happens during those cycles too and take away many of those cycles from cpu, so not all timings are possible. |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
Quote: But if I just use 16bit numbers I also need a 16 bit counter or ? Cuz right know I have just one counter and i use it to read from two tables
ldx sin_counter
lda sin_1, x
sta $d000
lda sin_2, x
beq skip_9th_bit
lda $d01d
ora #$01
sta $d01d
skip_9th_bit:
inc sin_counter
....
I think you want $d010 instead of $d01d. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
the way it works its that the video chip stops the cpu to read sprite gfx data, with all 8 sprites on the cpu is stopped on the sideborder completely, you can only change color mid screen.
google for "vic article c64" for details.
sprite x pos, for just demo usage your table approach is fine. also you are mixing things up, 16 bit numbers can be stored in tables that have only 255 entries, you dont need 16 bit table pointer automatically. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: the way it works its that the video chip stops the cpu to read sprite gfx data, with all 8 sprites on the cpu is stopped on the sideborder completely, you can only change color mid screen.
google for "vic article c64" for details.
sprite x pos, for just demo usage your table approach is fine. also you are mixing things up, 16 bit numbers can be stored in tables that have only 255 entries, you dont need 16 bit table pointer automatically.
Yes you're right, I was just typing from memory and got the wrong HW register address.
I thought about 16bit counter because then you have to read every second byte, but just now i realised that i could still only increment the index by 1 and do a left shift to multiply the number by 2 to read the next byte. Well now I'll just have to figure out these left side border positions so I can convert my sinuses.
Mixer: Why would I change the border color if the border is open on that line ? Did you mean the background color ? I did that and it did help, the color change is more to the right, but still visible. I kinda figured out the sprite fetching is happening at the right border and continues to the next line, I guess I'll have to do a raster split then for it to look good.
https://i.imgur.com/Ji9ju5s.jpg[/url] |
| |
Mixer
Registered: Apr 2008
Posts: 452 |
Yes, background color. My bad. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
I always wondered how people find these VIC tricks, they seem very specific and hard to come by by accident, but I think I just accidentaly started stretching my sprites.... At line 250 I disable the bottom border, set the sprite position to 255 and calculate their X from the sinus, call the music (which takes a bunch of lines) and then set the sprites Y to 10 for the top border. That worked fine, but I thought I'll make the sprites at the bottom expanded in Y on the bottom and normal on the top. I disable Y expansion after the music and because the ammount of raster the music takes is kinda random i started stretching sprites on my bottom border lol.
That made me want to do a proper sprite stretching, I'm just thinking how to go about it... This is what I came up with, tell me if it's a good approach.
I'd need let's say 40 lines of stable raster, on each line i'd read from a 40 elements table in which i decide if I should do the stretching or not. Now I'm thinking how to fill up such a table... Let's say a sinus with values from 0 to 3, whatever the number I read i put as many 1s into the table.... HMMM
Btw. How far can i put a sprite on the lower border before it starts to appear on the top ? It seems like there's some position on which I see the sprite both on top and bottom border, really weird ! |
... 55 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
