| |
Mixer
Registered: Apr 2008
Posts: 422 |
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. |
|
... 7 posts hidden. Click here to view all posts....
|
| |
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: 422 |
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: 3132 |
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: 422 |
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: 421 |
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: 3132 |
mixer: seems correct in x64 and x64sc (2.4)
dggr: I don't know |
| |
Mixer
Registered: Apr 2008
Posts: 422 |
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 |
| Previous - 1 | 2 - Next |
