Attributes and colour inversion

Everything related to BASIC version 1.x (Oric 1 and Atmos) or HYPERBASIC (Telestrat).
Don't hesitate to give your small program samples, technical insights, or questions...
Antiriad2097
Flying Officer
Posts: 158
Joined: Tue May 09, 2006 9:42 pm
Location: Aberdeen, UK
Contact:

Attributes and colour inversion

Post by Antiriad2097 »

I'm working on a prototype in Basic to figure out the routines and display methods with a view to moving to assembly or C with the OSDK.

Please excuse the inaccuracies in the following images as I knocked them up very quickly in paint.net just for example, they're not a true reflection of the Oric display.

Am I correct in thinking that with the standard Oric colour attribute system, I have to give up an entire character width to a colour change?

I think that if I have a 'forground' tree on the left of the screen, its trunk colour will be retained and bleed into the next character square if I place a smaller background tree immediately to its right thus:
Image

In the above image, the tree in the background should have green at its top, but being within one character of the foreground tree its had the effect of assuming the colour attribute of the trunk to its left.

I think this is how the Oric display would work.

Reading this:
http://www.defence-force.org/download/c ... nglish.txt
I discover that magenta and green are inverse colours.

As the colour attribute is set by bit 7 and the inverse attribute is set by bit 8, can I flip the inversion bit on the character square containing my background tree top and still put pixel data into the character square to give the following result?

Image

Is this correct, or does flipping the inversion bit 8 also require a full character width as with changing the paper/ink colours?

If inversion works, I can simply set the main ink colour to magenta and flip the inversion bit on any area that requires green. This would make things much simpler, so it seems too easy.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

NOTE: The "Painting Tricks" forum in the Graphics section would have been a better choice :)

It's true that for any byte of the screen you have to choose between GRAPHICS or ATTRIBUTE. So yes when you change the color, the full 6 pixels of this byte are going to use the curent color of the paper.

The INVERT is a bit available on every single byte of the screen. So you can invert graphics, but you can also use invert when changing colors. The important thing to remember is that the invert bit inverts the 6 pixels. So if you have some pixels with the paper color they will have 7-paper as new color, and the ink pixels will have 7-ink as their new color.

If you keep the current "rectangular" shapes, you're not going to have an issue, but if you try to have rounded shapes, or some form of smooth scroller where your tree trunks will overlap on two bytes, the inversion will impact both the tree trunk part (that you said want to draw as INK) and the sky part (that used the CYAN paper color). If you use invert, both the ink and paper are going to be inverted, so yeah your CYAN will be displayed as RED.

Are you trying to display static pictures, or animated scrolling/parallax effects?
Antiriad2097
Flying Officer
Posts: 158
Joined: Tue May 09, 2006 9:42 pm
Location: Aberdeen, UK
Contact:

Post by Antiriad2097 »

Thanks Dbug. I considered the 'painting tricks' bit of the forum but that appeared to be for 'how to' rather than 'how do I?' so opted for this one instead. I'll know next time.

I hadn't thought about the background colour inverting too :oops:

I want to animate, which is why its posing such a problem.

I may sacrifice detail for colour, just having a block of green as per my mock ups instead of adding any real shape to the trees.

I might be able to work round it a little by changing colour attributes within the foreground tree trunk and inverting from that - with some juggling of colours the inversion could give me the correct ones.

I shall experiment further.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

You could also cheat with the perspective, and making sure that the base line of the foliage of the trees starts at the same position whatever the distance.
Antiriad2097
Flying Officer
Posts: 158
Joined: Tue May 09, 2006 9:42 pm
Location: Aberdeen, UK
Contact:

Post by Antiriad2097 »

Fudging the perspective like that won't work for what I want to do.

At the moment, I think I'll take a simpler route and have trunk colours on even lines and foliage colours on odd lines. It should do what I need quite well and even give me a bit more colour for other areas lower down.
Post Reply