CC65 to DSK
Re: CC65 to DSK
I am unclear about something regarding attributes.
0-31 means attribute change
64-127 means INK pixel setting
192-255 means INVERTED INK pixel setting
What do 32-63 and 128-191 represent???
0-31 means attribute change
64-127 means INK pixel setting
192-255 means INVERTED INK pixel setting
What do 32-63 and 128-191 represent???
Re: CC65 to DSK
See Chart 11 at bottom of the page.
Re: CC65 to DSK
Thanks!
Re: CC65 to DSK
I find it easier to think in term of bit mask:
bit 7 = video inverse
bit 6 = indicates if the bottom 6 bits are bitmaps(0) or attributes (1)
It's not totally correct, because technically the values between 32 and 63 are not quite really attributes, they are displayable but with the bit 5 set which makes them of limite use, but twilighte did use these for his collision detection routines.
bit 7 = video inverse
bit 6 = indicates if the bottom 6 bits are bitmaps(0) or attributes (1)
It's not totally correct, because technically the values between 32 and 63 are not quite really attributes, they are displayable but with the bit 5 set which makes them of limite use, but twilighte did use these for his collision detection routines.
Re: CC65 to DSK
Thanks for this tip Dbug. I was confused about these values between 32 and 63, and 160-191.
Seems that they just repeat other patterns available in the ranges 64-127, and 192-255.
The idea of exploiting bit 6=0 and 5=1 for sprite collision is interesting though, I will make a note of this.
By the way, setting INK/PAPER with bit 7 set to 0 or 1 should have a similar outcome right?
(only difference is whether background for that group of 6 pixels is shown inverted of not, right?)
Seems that they just repeat other patterns available in the ranges 64-127, and 192-255.
The idea of exploiting bit 6=0 and 5=1 for sprite collision is interesting though, I will make a note of this.
By the way, setting INK/PAPER with bit 7 set to 0 or 1 should have a similar outcome right?
(only difference is whether background for that group of 6 pixels is shown inverted of not, right?)
Re: CC65 to DSK
Correct, the inverse bit does not have any impact on the way the attribute is handle. All it does is to change the way colors for this block of 6 pixel is handled, so when setting any attribute you can use that to choose between displaying 6 pixels of paper color or 6 pixels of inverted paper color
Re: CC65 to DSK
As you predicted, SAM mode has PAPER changes all over the place, which makes it hard to keep the race track black.
So for now I will focus on using mode -f2, which has no PAPER variations.
I managed to get a simple sprite animation, with attributes before and after each sprite used to set/reset the INK.
It's a close vote for which display system is hardest to use... DHR on Apple//e, or HIRES on Atmos.
So for now I will focus on using mode -f2, which has no PAPER variations.
I managed to get a simple sprite animation, with attributes before and after each sprite used to set/reset the INK.
It's a close vote for which display system is hardest to use... DHR on Apple//e, or HIRES on Atmos.
- Attachments
-
- viewer.dsk
- (131.5 KiB) Downloaded 400 times
- ibisum
- Wing Commander
- Posts: 1652
- Joined: Fri Apr 03, 2009 8:56 am
- Location: Vienna, Austria
- Contact:
Re: CC65 to DSK
Looks pretty good to this old Oric fans eyes .. but I wonder if you wouldn't get better results if you used AIC for the sprites themselves - looks like right now you're drawing new attributes with each sprite and getting the attribute clash, but if you were to use the AIC bit on the sprites, perhaps you could minimise the clash even further .. akin to the technique that Twilighte used in Pulsoids .. if I recall correctly he was able to get much smoother colour-changes around the sprites in that game by cleverly using the inverse bits to get different colour combinations for various game objects.
https://www.oric.org/software/pulsoids-1515.html
(In case you hadn't seen it already)
Anyway, viewer.dsk is certainly very tantalising - its going to be amazing to see the finished product on Oric when it happens. It already sets the expectations for a top-down racing game pretty high, and looks to be a new contender for the most colourful of such games on Oric already ..
https://www.oric.org/software/pulsoids-1515.html
(In case you hadn't seen it already)
Anyway, viewer.dsk is certainly very tantalising - its going to be amazing to see the finished product on Oric when it happens. It already sets the expectations for a top-down racing game pretty high, and looks to be a new contender for the most colourful of such games on Oric already ..
Re: CC65 to DSK
AIC is unfortunately difficult to use for things that move horizontally since the inverse bit only works on aligned blocs of 6 pixels.
Re: CC65 to DSK
AIC would make things complicated unless I move vertically in steps of 2 and horizontally in steps of 6... But even then the sprites will not look "sharp" (because of interlacing of different colours).
I would like to get the above demo working with SAM's mode, but the random PAPER/INK changes make this challenging (gotta figure out what was the last ink/paper change, and set the trailing attribute accordingly, which takes time to compute and thus slows down sprite redrawing).
Anyhow, I will next spend a little more time working on the Arduino "Ethernet/Joystick" module project.
I would like to get the above demo working with SAM's mode, but the random PAPER/INK changes make this challenging (gotta figure out what was the last ink/paper change, and set the trailing attribute accordingly, which takes time to compute and thus slows down sprite redrawing).
Anyhow, I will next spend a little more time working on the Arduino "Ethernet/Joystick" module project.
Re: CC65 to DSK
It took a bit of effort and thinking, but I finally got the demo working with AIC mode.
To reach this goal, I generated a custom GIMP paletter (with 19 colors) and a python script (~90 lines of code) that will convert the 19 colors image to AIC pixels.
I will include the palette and python converter in my next release of 8bit-Unity!
To reach this goal, I generated a custom GIMP paletter (with 19 colors) and a python script (~90 lines of code) that will convert the 19 colors image to AIC pixels.
I will include the palette and python converter in my next release of 8bit-Unity!
- Attachments
-
- viewer.dsk
- (131.5 KiB) Downloaded 363 times
Re: CC65 to DSK
Thats a visually interesting result.
Do you think in the final version you will be able to reduce (or suppress) the flickering around the cars?
Do you think in the final version you will be able to reduce (or suppress) the flickering around the cars?
Re: CC65 to DSK
I managed to reduce attribute clash by applying sprite INK only every two scanlines. I feel that the result is not bad, not bad at all!
I might leave it at that for now, and concentrate on getting the rest working...
I might leave it at that for now, and concentrate on getting the rest working...
- Attachments
-
- viewer.dsk
- (131.5 KiB) Downloaded 342 times
Re: CC65 to DSK
That's very nice!
Only question is the effect of the color attibute clash when cars will be close to each other?
I always have admiration for games authors that decide to work in colors on Oric. Alistair Way's Grand Prix kept the cars monochrom!
Only question is the effect of the color attibute clash when cars will be close to each other?
I always have admiration for games authors that decide to work in colors on Oric. Alistair Way's Grand Prix kept the cars monochrom!
Re: CC65 to DSK
Looking better already