| |
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 |
Quote: Can you do VSP and FLD at the same time ? Both effects work for me individually, but I can't do both at the same time. I have a big square on the left going left and right. Am I accidentally doing FLI or something ? Can't be, as i'm doing the FLD the slow but sure way of reading the current line and setting Yscroll to something different.
same code moves the whole screen without vsp. I do vsp at line 47 and fld at 56
EDIT. I've fixed that, the code for enabling illegal screen mode to cover VSP garbage was causing the problem.
Ok I got the vsp+fld working reasonably well (although very slow, it's all lousy test code now) and I blank the bytes that go beyond the screen to make it look like it doesn't wrap and that gave me an idea to try to make the image scroll into the border on both sides... Although I don't see it being possible with the logo and music taking away all my top and bottom raster time. SO. I'll try to make that effect in the other part and for this i'll come up with something else, but still kooool |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
looks like d011 write is horizontally on wrong cycle and you have accidental fli (lt red checkers) |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: looks like d011 write is horizontally on wrong cycle and you have accidental fli (lt red checkers)
Yeah man. I sorted it out and it works fine. A different question... and sorry for just throwing it into this single thread but I don't know if making several threads would be better. And this is mostly because durrinf the weekday I'm like 2 hours a day at home and I'm just constantly thinking about trying something out but I have no time lol.
About line crunch. I understand it's about "undoing" a bad line which forces Vic to draw another text line right away and because of that the screen is shorter and it will wrap around putting that line at the bottom. Cause that 25 times and you scroller the entire screen. There's 25 lines of these 1st pixel lines of each row, so it's usually covered with the illegal screen mode (rocketry has a full screen but that's out of question for me)
I'm just thinking... if you always cover the 25 pixel lines with black pixels but crunch only let's say 5 lines, some of the scrolled image will be covered too, right ? and the sprite pointers will be drawn as chars too ? How do people work around it ? or is that normal and you can't do anything about it ?
Is there a way to load a file before address $0801? Or do I have to copy my stuff to the lower memory if I want to use it ?
I noticed that the background colour under the side borders of while displaying bitmap is different on every line (the colour of the most right pixel ?) Is there a way to change that other than making the picture have the desired colour as the last pixel on the line (if it even comes from the bitmap colour) |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
I'm not the best person to answere these, but here are my educated guesses:
linecrunch: use fld to keep the area 25 lines high. never used linecrunch to scroll picture, so take this with a grain of salt..
load before $0801: the kernal (built in) load routine doesnt stop you from loading anywhere, however sideffects of sta to various locations might, also if you load to screen mem, the basic ready prompt printing after load will ruin your day :) similar applies to custom load routines. you can load anywhere, but nothing saves you from the possible bad side effects of overwriting memory :)
"I noticed that the background colour under the side borders of while displaying bitmap is different on every line "
this might be the hires bitmap thing I only heard of, one of the colors of the 2 possible per char of the rightmost char will be used as "sideborder" color if you remove the sideborder. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Yeah I know you're the speedcode and math kind of guy, but you still know way more about the Vic than me at this point... FLD. I didn't think about it, although I don't think it would solve the problem, because say you do one line crunch. That would make the lines 2-25 on top and line 1 on the bottom, but if I do 18 lines of fld to show the second line as the first visible (at pixel line 25) the bottom line will go beyond the screen... Hmm But I'm just guessing I'll try to allocate some time tomorrow to check it. With char based pictures it wouldn't be such a big problem perhaps because you can copy the graphics around, but bitmap is too big. Unless maybe I split copying over say 4 frames and scroll by 2 pixels per frame max, but that's not cool it has to go all over haha |
| |
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: 1378 |
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: 5017 |
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: 5017 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
