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
 
... 55 posts hidden. Click here to view all posts....
 
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 !
2018-01-23 12:38
Mixer

Registered: Apr 2008
Posts: 422
Answer to all of your current and future VIC questions :) VIC Article [english]
2018-01-23 15:41
TWW

Registered: Jul 2009
Posts: 541
I used this to generate the horizontal sine-values:


    .var sinus = 0

SinusXLo:
    .for (var i = 0 ; i < 256 ; i++) {
        .eval sinus = RadiusX - 7 + RadiusX*sin(toRadians(i*360/256))
        .if (sinus < 0) .eval sinus = sinus - 9
        .byte sinus
    }

SinusXHi:
    .for (var i = 0 ; i < 256 ; i++) {
        .eval sinus = RadiusX - 7 + RadiusX*sin(toRadians(i*360/256))
        .if (sinus < 0) .eval sinus = 256
        .byte >sinus
    }


2018-01-23 16:04
JackAsser

Registered: Jun 2002
Posts: 1989
This is all there is to it. When you really understand this chart it will explain almost everything: https://www.linusakesson.net/programming/vic-timing/victiming.p..
2018-01-23 20:13
Oswald

Registered: Apr 2002
Posts: 5017
sprite stretching is very easy, just turn on/off y stretch bit on each line. horizontal timing is doesnt matter except the 1 cycle where it results in another trick called sprite crunch.
2018-01-24 10:32
Golara
Account closed

Registered: Jan 2018
Posts: 212
Aha, that's really great. I must have missunderstand the article on sprite stretching, I thought it was cycle accurate and sprite crunching is the same trick but in a different cycle. I made a simple loop of various lenghts like this:

	ldx .xPosCounter
	lda sprite_stretch, x
	adc #10
	tay
	lda #$ff
l1:	
	inc $d021
	sta $d017
	eor #$ff
	sta $d017
	dec $d021
	dey
	bne l1


And it seems like I do a sprite crunch at some frames, can you confirt that it is in fact sprite crunch ? My sprites appear twice.



I also decided to do a logo instead of DYSP for now, it's made out of 6 sprites. I swing it from 0 to 255 and set the 9th bit at the correct position, or so I think... It blinks sometimes, do you see anything I do wrong ?

	lda #$00
	sta $d020
	sta $d021
	sta $d010 ; 9th X bit
	
	ldx .xPosCounter
	lda sprite_border_sin_1, x
	cmp #230
	bcc skip5
	tay
	lda #%01111100
	sta $d010
	tya
skip5:
	cmp #230-24
	bcc skip4
	tay
	lda #%00111100
	sta $d010
	tya
	jmp skip1
skip4:
	cmp #230-24-24
	bcc skip3
	tay
	lda #%00011100
	sta $d010
	tya
	jmp skip1
skip3:
	cmp #230-24-24-24
	bcc skip2
	tay
	lda #%00001100
	sta $d010
	tya
	jmp skip1
skip2:
	cmp #230-24-24-24
	bcc skip1
	tay
	lda #%00000100
	sta $d010
	tya
skip1:
	clc
	sta $d00e
	adc #24
	sta $d00c
	adc #24
	sta $d00a
	adc #24
	sta $d008
	adc #24
	sta $d006
	adc #24
	sta $d004


I'll try to make it the last question.
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
Mike
Didi/Laxity
Grue/Extend
www.gb64.com
MCM/ONSLAUGHT
Boogaloo/Horizon
goto80/HT
Case/Padua
Flavioweb/🇮🇹HF..
Guests online: 88
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 The Ghost  (9.6)
9 Wonderland XIV  (9.6)
10 Bromance  (9.6)
Top onefile Demos
1 It's More Fun to Com..  (9.8)
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 Coders
1 Axis  (9.8)
2 Graham  (9.8)
3 Lft  (9.8)
4 Crossbow  (9.8)
5 HCL  (9.8)

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