Page 3 of 6

Re: CC65 to DSK

Posted: Tue Dec 25, 2018 3:23 pm
by 8bit-Dude
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???

Re: CC65 to DSK

Posted: Tue Dec 25, 2018 5:02 pm
by iss
See Chart 11 at bottom of the page.

Re: CC65 to DSK

Posted: Wed Dec 26, 2018 1:46 am
by 8bit-Dude
Thanks!

Re: CC65 to DSK

Posted: Wed Dec 26, 2018 11:18 am
by Dbug
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.

Re: CC65 to DSK

Posted: Wed Dec 26, 2018 2:30 pm
by 8bit-Dude
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?)

Re: CC65 to DSK

Posted: Wed Dec 26, 2018 7:33 pm
by Dbug
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

Posted: Thu Dec 27, 2018 6:14 am
by 8bit-Dude
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. :-)

Re: CC65 to DSK

Posted: Thu Dec 27, 2018 12:57 pm
by ibisum
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 .. ;)

Re: CC65 to DSK

Posted: Thu Dec 27, 2018 2:59 pm
by Dbug
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

Posted: Fri Dec 28, 2018 4:37 am
by 8bit-Dude
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.

Re: CC65 to DSK

Posted: Thu Apr 18, 2019 10:56 am
by 8bit-Dude
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! :D

Re: CC65 to DSK

Posted: Thu Apr 18, 2019 11:06 am
by Dbug
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?

Re: CC65 to DSK

Posted: Fri Apr 19, 2019 2:58 am
by 8bit-Dude
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... :D

Re: CC65 to DSK

Posted: Fri Apr 19, 2019 6:23 am
by Symoon
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! ;)

Re: CC65 to DSK

Posted: Fri Apr 19, 2019 8:58 am
by Dbug
Looking better already :)