rotating & colouring Icons on the fly?

[volvo_0ne]

Is there a way to rotate and/or re colour icons on the fly?

For instance I'm thinking of an arcade/adventure with lots of rooms, but the doorways are different colours and in different directions .

so I have to have 4 definitions for each doorway(UDLR), then open/closed, then 6 different possible colours for each.

This adds up to at least 16k of icons, The bloody map is a fraction of that!!!

I know I could just use the same colour for all of them but that would detract from the colourful nature of the project.

btw the Icons are only 2 colour and are only 16px X 16px, however the palette is 16 colours

Any ideas guys?

[adrazar]

The command Rev() can do 180°-rotations. Hence it's possible to have all four orientations with only two images; one facing U/D and one facing L/R.
There's no command that rotates images 90° on the fly. I believe one reason for this is that it would have been too slow to be very useful.

I have a neat idea for the colours, although it puts some constraints on the palette.
The point is that if you paste an icon with one bitplane in a screen with four bitplanes, only the first of these bitplanes is modified. However, the other three bitplanes are still used for determining the colour of the door. This means you can change those to any value you want (using Bar) before pasting the icon; this will change the colour of the door.

If you use Bar with Ink 6 for instance, the door will be displayed with colour 6 and 7 when you paste it.
(Generally: Ink 2*N => door gets colour 2*N and 2*N+1)

[volvo_0ne]

Originally Posted by adrazar

The command Rev() can do 180°-rotations. Hence it's possible to have all four orientations with only two images; one facing U/D and one facing L/R.
There's no command that rotates images 90° on the fly. I believe one reason for this is that it would have been too slow to be very useful.

I have a neat idea for the colours, although it puts some constraints on the palette.
The point is that if you paste an icon with one bitplane in a screen with four bitplanes, only the first of these bitplanes is modified. However, the other three bitplanes are still used for determining the colour of the door. This means you can change those to any value you want (using Bar) before pasting the icon; this will change the colour of the door.

If you use Bar with Ink 6 for instance, the door will be displayed with colour 6 and 7 when you paste it.
(Generally: Ink 2*N => door gets colour 2*N and 2*N+1)

Thanks for that, it made me wonder if I could do all that in one routine, and I found a workable (if slow) solution.

I pasted the "UP" icon to a small backscreen, then rotated it and picked it up again as another icon, Although this takes 3 vbls (one when compiled) it is quick enough for what I'm doing, as the doors are only drawn once per room change and there are never more than four.
The added advantage is the doors can be any colour I like as I re colour them when they are re-plotted.

Once again thanks

V1

[adrazar]

Originally Posted by volvo_0ne

Thanks for that, it made me wonder if I could do all that in one routine, and I found a workable (if slow) solution.

I pasted the "UP" icon to a small backscreen, then rotated it and picked it up again as another icon, Although this takes 3 vbls (one when compiled) it is quick enough for what I'm doing, as the doors are only drawn once per room change and there are never more than four.
The added advantage is the doors can be any colour I like as I re colour them when they are re-plotted.

Once again thanks

V1

Clever thinking! If you are going to do either a manual rotation or a colour change anyway, you can actually do both without spending any additional time.

I notice you must be using 16 colours (four bitplanes) for the icons as you say you can choose the colours freely when you rotate.
This seems like a terrible waste of memory for icons that use only two colours; surely one bitplane must be sufficient when the goal is to be stingy with the bytes
You can mix icons of any colour depth (i.e. number of bitplanes) in a single icon bank. To create icons with just one bitplane, simply grab them from a screen with two colours.

[volvo_0ne]

The memory overhead isn't all that crucial, but 16k seemed very excessive for all the door definitions, I've got it down to 898 bytes now

Also as the routine is configurable, I may (with the help of your Icon size code Thanks again!) be able to use it with the other icons in the game thus saving loads more memory unless drawing speed of the room data is compromised.

I am indeed using a 16 colour palette and if this idea works out, I'll probably do as you suggest re grabbing from a 2 colour screen.

Thanks for your help
V1

[volvo_0ne]

Update......
I created a routine for re-colouring the main icons so that I only need 1 copy of each icon (instead of one for each colour).
The speed is quite good but not instant for a redraw from memory (typically 6vbl's to recolour & draw 37 Icons to X,Y position)
However that equates to a saving of 21324 of memory, which I think is a good tradeoff

[volvo_0ne]

Now I need a faster "rotate" of a 16*16 block which only manipulates 1 plane, but it must be a pure rotate (rather than the built in rev command)

I'm sure this must be possible as I would only be manipulating one plane so peek +poke would do it asymetrically (I hope)....

looking into it now.

[adrazar]

The book "Hacker's Delight" presents a rather clever method for transposing "bit-matrices" of size 8x8 bits. Bit matrix transposition can be used for 90-degree rotations too if combined with a vertical reflection, so here's how they did it:

Original       Step 1        Step 2        Step 3

abcdefgh      aickemgo      aiqyemuC      aiqyGOW5
ijklmnop      bjdlfnhp      bjrzfnvD      bjrzHPX6
qrstuvwx      qysAuCwE      cksAgowE      cksAIQY7
yzABCDEF  ->  rztBvDxF  ->  dltBhpxF  ->  dltBJRZ8
GHIJKLMN      GOIQKSMU      GOW5KS19      emuCKS19
OPQRSTUV      HPJRLTNV      HPX6LT20      fnvDLT20
WXYZ1234      W5Y7193!      IQY7MU3!      gowEMU3!
567890!@      X6Z8204@      JRZ8NV4@      hpxFNV4@

All three steps can be done approximately the same way and with only a few intstructions. For instance step 1 can be done this way:

'UPPERHALF/LOWERHALF contains the first/last 32 bits of the bit matrix
T=(UPPERHALF/128 xor UPPERHALF) and %101010100000000010101010
UPPERHALF=UPPERHALF xor T xor (T*128)
T=(LOWERHALF/128 xor LOWERHALF) and %101010100000000010101010
LOWERHALF=LOWERHALF xor T xor (T*128)

You can try to make an implementation of this idea yourself, however I took the liberty of making my own version in assembly (my first assembly program ever! wooho ). I attached the executable if you'd like to try it in a machine code procedure, but beware: it doesn't test if the input is valid so you will have to take care of that yourself.
It takes one argument which should be either Sprite Base(N) or Icon Base(N) where N is the number of the image you want to rotate. It rotates the first bit plane 90 degrees clockwise and leaves the others as they were.

[volvo_0ne]

Whoa, that is WAY over my head.

I don't even know what to do with the downloaded zip file :-O

Thanks for your help though

[adrazar]

Originally Posted by volvo_0ne

Whoa, that is WAY over my head.

I didn't really explain anything so that's probably mostly my fault..
I'll now do the reasonable thing and add the missing explanation : Note first that each letter represents a bit in an 8x8 bitmap. In each step of the process some of the letters are swapped, where the moved letters are marked in red. After step 3 you see that the letters that first went left to right now go from top to bottom.

The operations with UPPERHALF and LOWERHALF should just be verified on paper, I guess. They are 32-bit numbers, where UPPERHALF contains the first four rows of the 8x8 bitmap and LOWERHALF the last four rows.

Originally Posted by volvo_0ne

I don't even know what to do with the downloaded zip file :-O

This is easier to explain Type the following in the editor:

Procedure ROTATE[ADR]
End Proc

and select the menu option Editor > Procedures > Insert Program.
When the machine code procedure has been installed it seems to be stuck in the program however. If this bothers you it might be a better idea to use the alternative method provided by the Pload/Call instructions because that has no such side effects.

[adrazar]

Um, forgot to clarify the perhaps greatest source of confusion: the formulas for UPPERHALF and LOWERHALF will not make sense unless the computations are done in binary representation. Division by 128 on binary numbers is a simple shift to the right by seven positions. Example:

%00000000           %00000000
 11111111            00000001
 00000000  / 128  =  11111110
 11111111            00000001

(the last seven digits are discarded by the division).