| |
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....
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
doublesin would be even better ( add up some sines) |
| |
Digger
Registered: Mar 2005
Posts: 437 |
how many sprites are you squeezing into the bottom border? 6? :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I'd say no more than five. $d017 stretch takes at least 8* cycles and opening the border takes at least another 8*. That leaves 47 cycles of which quite a few are consumed by the VICII. So to move 5 sprites we need 5 x LDA#/STA$ (6 cycles), another 30 cycles:
8+8+30 == 46 which according to victimer might work.
* = this assumes having registers preset (for example X=0 and Y=8) for quick $d016/$d017 writes, and unrolled code.
I could very well be wrong though. Haven't done any sprite tech-tech stuff for a long while. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
Quote: I'd say no more than five. $d017 stretch takes at least 8* cycles and opening the border takes at least another 8*. That leaves 47 cycles of which quite a few are consumed by the VICII. So to move 5 sprites we need 5 x LDA#/STA$ (6 cycles), another 30 cycles:
8+8+30 == 46 which according to victimer might work.
* = this assumes having registers preset (for example X=0 and Y=8) for quick $d016/$d017 writes, and unrolled code.
I could very well be wrong though. Haven't done any sprite tech-tech stuff for a long while.
I'm doing 6 sprites. I have 4 cycles left too (after opening the second line of border). I don't update all the sprite registers on the same line, but it works fine as you can see, although I had to fiddle around with the order of instructions until I got rid of the bugs. The SS is not supposed to flash, I just don't update the colors for it yet, althought I have plenty of time for that, I just forgot. In this screen you see couple of posts above I have free raster time from about line 56 to line 250, so I can do some other cool stuff too. I don't know what to do next right know though. I'm also thinking if I should make it a tiny demo in this intro like format (where only the middle of the screen changes with some new pictures or some other effect), or to do a multi prg press-space-to-continue kind of demo. I definitely don't know how to do stuff like one-der or dawnfall in onefile yet. |
| |
Golara
Account closed
Registered: Jan 2018
Posts: 212 |
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. |
| |
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: 5094 |
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: 5094 |
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 |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 - Next |
