| |
Mixer
Registered: Apr 2008
Posts: 427 |
Release id #112767 : Starfield
I have a question for vic specialists:
A similar raster routine is used in the starball and starfield effects I just posted.
Between the cycle 56 and 17 on the next line the routine opens borders and changes the sprite x position and sprite data pointer, the rest of the cycles of each line are used for reading tables opening up/low borders and sprite y position changes when needed.
There is a little bug at the right of center, where sometimes sprite disappears on the line, however it is ok the next line, at some lines and some times they do not disappear at all.
The motion and pointer data is correct. I believe it has something to do with the sprite fetching mechanism. I dont think it is a d010 bug either, if it was it would flash the sprite on the left border. The effect uses sprite number 8 (d00e/d00f). The same with the starball routine, which is almost the same.
I spent quality time with the vic article to try to figure that out, but never did. Any ideas? With that information the raster routine could be perfected or stated that it is as good as I can make it. |
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Interesting!
Would it be possible to clean your routine up untill you only have the described problem?
I mean, create a routine where you move sprite 8 about at exactly the buggy cycle and show us what happens. |
| |
Hein
Registered: Apr 2004
Posts: 933 |
Quote:I dont think it is a d010 bug either, if it was it would flash the sprite on the left border.
Or in the right border maybe far outside the screen?? (d00e=255 and d010=%10000000)
Not that I checked the routine, tho. |
| |
Mixer
Registered: Apr 2008
Posts: 427 |
http://www.sid.fi/~mixer/sounds/startest.prg
There is a little debug program, it pretty much explains how the effect works.
f5 and f7 scroll the stars, i.e. ,x index to table which then contains the table x value and another with hi bit d010 values.
f1 selects between offset patterns for each line.
- 0 to 255
- random value from 0 to 255
- a sin curve.
f3 rotates color, makes no difference here.
As you may see. The pattern 0 to 255 produces a diagonal line - with no gaps. All follow the same X, no sprite disappears.
Sin curve pattern shows a gap in one position - where did the sprite go? it is not on that line. Vice debug shows it nowhere.
Random pattern however shows sprites disappearing from lines here and there.
I've considered that something goes wrong with the X position calculation
(lda scroll adc offset tax table,x) clc makes no difference, it would simply jump a position - not disappear the sprite.
|
| |
Mace
Registered: May 2002
Posts: 1799 |
I put Vice VIC-settings on 'debug' and changed screen colour to blue, just to make things clearer.
It shows no sprites at the far end of the screen, so somehow the one line just disappears into nothingness.
What I notice is that the hidden line only appears at a certain X position (which one?!) and only when the line beneath it is further to the right.
Can't think what is happening, though.
Could it be that the pointer is set to the wrong sprite? |
| |
Digger
Registered: Mar 2005
Posts: 422 |
Interesting stuff, how does this behave on a real machine? Have you any cycles left to add another sprite? :) |
| |
Mr. SID
Registered: Jan 2003
Posts: 424 |
To clear up the mystery, there's no bug in your code, just a bug in VICE as it seems. x64 shows the missing line, x64sc and a real C64 are fine. Go figure...
|
| |
Mixer
Registered: Apr 2008
Posts: 427 |
Editing 3fff also to 01(lda 01 ->08df in code) helped to count 11 chars from right border on that line. Which puts it right to the 9th x bit, d010 line.(28 chars from left border)
Also in random data there seems to be a case that the missing line has x larger than the previous line and also d010 changes. So, why only upwards causes trouble?
I'll make a test pattern for that.
|
| |
Mace
Registered: May 2002
Posts: 1799 |
When the line is straight, vertically, I notice that the top line is a bit to the left compared to the rest of the bar.
When you scroll this left, at a certain point, you see that the 2nd line disappears at a certain point.
This perhaps makes it easier to find what happens, as you know which position is the disappearing line. |
| |
Mixer
Registered: Apr 2008
Posts: 427 |
Mr Sid, good, I was confused as I got various comments on it bugging.
Anyway, one for the vice team then. |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Maybe that will get them to release a new version. |
| |
iAN CooG
Registered: May 2002
Posts: 3142 |
if it works in x64sc and doesn't in x64, don't expect viceteam to fix it soon, x64 is going to be put aside in next versions of vice, sooner or later x64sc will become the default.
ps: vice 2.4 is going to be released this weekend, be prepared =) |
| |
Mixer
Registered: Apr 2008
Posts: 427 |
Great :)
Here is the errata routine:
http://www.sid.fi/~mixer/sounds/startest2.prg
There is new - stripe pattern with 1 pixel x difference each other line. Scroll that on top of the hi bit d010 change and magic.
If it is fixed elsewhere, then I'm happy.
|
| |
Mace
Registered: May 2002
Posts: 1799 |
Hoxs64 v1.0.7.4 runs your routine just fine, without the missing line. |
| |
Digger
Registered: Mar 2005
Posts: 422 |
On my x64 (Vice 2.3) I can see $3fff is also offset by 1 pixel in some lines. Weird.
@iAN CooG: do you know if there's any chance for the 256x256px 8bit grayscale live memory map monitor? :)
|
| |
iAN CooG
Registered: May 2002
Posts: 3142 |
mixer: seems correct in x64 and x64sc (2.4)
dggr: I don't know |
| |
Mixer
Registered: Apr 2008
Posts: 427 |
1 pixel 3fff offset is likely to be a d016 result. Optimized raster routine uses partly same data for spritepointers and d016 for border opening/closing.
It seems all this has been due to older x64:s used for running the demo.
|
| |
Clarence
Registered: Mar 2004
Posts: 119 |
Mixer, for such routines use real hw to test, and ignore emulator behaviour. It took me some effort too to figure
out a similar timing (flawless on real hw):
Unicorn, the Collectors Edition |
