Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > Sine sprites in the sideborder. VSP garbage and more
2018-01-22 11:35
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
2018-01-22 12:17
Oswald

Registered: Apr 2002
Posts: 5017
"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
2018-01-22 12:30
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
....
2018-01-22 12:52
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...
2018-01-22 13:02
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.
2018-01-22 13:34
Mixer

Registered: Apr 2008
Posts: 422
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.
2018-01-22 13:34
Mr. SID

Registered: Jan 2003
Posts: 421
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.
2018-01-22 13:39
Oswald

Registered: Apr 2002
Posts: 5017
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.
2018-01-22 14:15
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]
2018-01-22 15:44
Mixer

Registered: Apr 2008
Posts: 422
Yes, background color. My bad.
2018-01-23 11:05
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
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
Advanced
Users Online
Guests online: 124
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Bromance  (9.6)
10 Memento Mori  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 Rainbow Connection  (9.5)
6 TRSAC, Gabber & Pebe..  (9.5)
7 Onscreen 5k  (9.5)
8 Wafer Demo  (9.5)
9 Dawnfall V1.1  (9.5)
10 Quadrants  (9.5)
Top Groups
1 Oxyron  (9.3)
2 Nostalgia  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Diskmag Editors
1 Jazzcat  (9.4)
2 Magic  (9.4)
3 hedning  (9.2)
4 Newscopy  (9.1)
5 Elwix  (9.1)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.044 sec.