Problems in inverse

The Oric video chip is not an easy beast to master, so any trick or method that allows to achieve nice visual results is welcome. Don't hesitate to comment (nicely) other people tricks and pictures :)
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Problems in inverse

Post by Twilighte »

Take the example that a screen byte is 110110 and the required mask is 110011
For normal video (not inversed) the result is simple.

we AND the mask against the screen resulting in 110010

in code this would be

Code: Select all

        LDA ScreenByte
        AND Mask
However if the screen byte is inversed then all bits we take as 1 will appear as 0.
So whilst 110110 AND 110011 will be 110010 it will appear as 001101 which is clearly wrong.
So we deal with inversed screen separately to invert the bits before masking.

So we invert 110110 to get 001001 then mask with 110011 to get 000001 then invert again
to get 111110 which appears on the screen as 000001 which is correct.

In code this is

Code: Select all

        LDA ScreenByte
        BMI ScreenIsInverse
        AND Mask
        ...
ScreenIsInverse
        EOR #63
        AND Mask
        ...
Furthermore (oh yes) we then need to ORA with the bitmap graphic.

Trawling back through the above for normal video graphics we take the screen byte 110110
and AND with 110011 to get 110010 then OR with the sprite byte of 001100 to get 111110

And this is where things get tricky. Once we start dealing with inverse on inverse then
some may argue we should just replace the screen inverse byte, rather than attempt to merge
them.

If the inverse is in order to attain white on blue and the sprite byte is 000000
then the virtual black will look ok.
However (using AIC mode (split line technique)) we may be using inverse to attain white on red.
and a background of red is too bright and looks wrong.
Placing a contingency around which alternate line we are working on would then be the answer but
at what cpu cost?

Like...

Code: Select all

        LDA ScreenByte
        BMI ScreenIsInverse
        AND Mask
SendDirect
        ...
ScreenIsInverse
        BIT AltLineFlag
        BVS SendDirect
        EOR #63
        AND Mask
        ...
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

This is a very interesting question indeed. I have been lately reading about how 2D tiled games were done on the speccy and other platforms and this is one of the constraints I found if these games were targetted to the Oric.

As I have not done any tests I cannot tell about how this extra CPU cost could influence in a game such as this, but I bet that it will be noticeable.

Usually you want to draw all the graphics as quickly as possible, and, as this is one of the core routines, every CPU cycle counts (moreover if you want to move a lot of sprites quickly).

So for what I understood, if you are using the AIC mode (which is the only way to produce nice colored graphics on the Oric), you have to be very careful about how you mix graphics, which has an extra cost, at least the BMI and EORs.

For what you write I understood that things get worse if the sprite itself uses the inverse bit trick, so you need the extra code you wrote at the bottom of your post?

So we are at a discouraging deadlock here. I wonder (so I ask) if it could be a good idea (in some cases) to make things simpler. Imagine your sprite does not use inverse bits, but your background does.

Could it be possible to simply remove the inverse bit of the scan whenever you are masking a sprite there? There will be some kind of clash, of course, but I wonder if it would be tollerable. When you use monochrome mode in Stormlord, graphics look still nice, so would it look very bad if a scan's inverse bit is removed this way?

If this is doable, the speed of the code would increase a lot, as you can use a mask for the sprite with the inverse bit set to 0, so that the code becomes again the simple lda screenbyte/and mask/ora graphic.

Do you think this could work without looking horrible?

On a side note, now that we are talking about this, I have quite a rough idea about how to store things in memory to speed up the process of drawing tiles and sprites over them, but I have many doubts about this particularly routine as well as the fact that our tiles would be 6 pixel wide, instead of 8, which means either reduced graphics (if we are to version another game, that is) or updating more tiles, which would be slower.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

If the tiles are 6x6, the advantage is that 40*6=240, so you can access all the bytes of a whole line of tile using one single absolute screen address, this gives room for quite a lot of opportunities for optimisations :)
User avatar
Twilighte
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK
Contact:

Post by Twilighte »

Dbug wrote:If the tiles are 6x6, the advantage is that 40*6=240, so you can access all the bytes of a whole line of tile using one single absolute screen address, this gives room for quite a lot of opportunities for optimisations :)
Yes, i have used this a few times in the past. Cannot recall examples tho.
User avatar
Dbug
Site Admin
Posts: 4437
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Post by Dbug »

Twilighte wrote:
Dbug wrote:If the tiles are 6x6, the advantage is that 40*6=240, so you can access all the bytes of a whole line of tile using one single absolute screen address, this gives room for quite a lot of opportunities for optimisations :)
Yes, i have used this a few times in the past. Cannot recall examples tho.
I know that I did it for scrolling the small text in the Assembly 2002 intro invitation :)
User avatar
Chema
Game master
Posts: 3013
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Post by Chema »

And it is one of the reasons why fonts 6 pixels (7 also?) high are so efficient.

Anyway the problem is still there. Of course a 6x6 tile would be the easiest, fastest and more logical solution, but again, if converting a game, sprites should be reduced in size, or else more tiles would be used, which means more redrawing... :/

But we are getting a bit off-topic here, and my question is sill there. Would the method I suggested for mixing when inverse video be valid?
Post Reply