English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. AMOS

 
 
Thread Tools
Old 22 November 2018, 23:28   #1
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 350
rotating & colouring Icons on the fly?

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?

Last edited by volvo_0ne; 22 November 2018 at 23:36.
volvo_0ne is offline  
Old 23 November 2018, 15:25   #2
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 44
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)
adrazar is offline  
Old 26 November 2018, 22:47   #3
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 350
Quote:
Originally Posted by adrazar View Post
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

Last edited by volvo_0ne; 27 November 2018 at 01:12.
volvo_0ne is offline  
Old 27 November 2018, 20:30   #4
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 44
Quote:
Originally Posted by volvo_0ne View Post
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.
adrazar is offline  
Old 27 November 2018, 22:24   #5
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 350
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 is offline  
Old 12 December 2018, 22:03   #6
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 350
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 is offline  
Old 12 January 2019, 02:21   #7
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 350
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.
volvo_0ne is offline  
Old 28 January 2019, 23:11   #8
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 44
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:
Code:
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:
Code:
'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.
Attached Files
File Type: zip rotate.zip (443 Bytes, 10 views)
adrazar is offline  
Old 12 February 2019, 22:48   #9
volvo_0ne
Registered User

 
Join Date: Mar 2015
Location: Sheffield UK
Posts: 350
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
volvo_0ne is offline  
Old 14 February 2019, 22:20   #10
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 44
Quote:
Originally Posted by volvo_0ne View Post
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.

Quote:
Originally Posted by volvo_0ne View Post
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:
Code:
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 is offline  
Old 15 February 2019, 04:41   #11
adrazar
Registered User

 
Join Date: Feb 2017
Location: Oslo
Posts: 44
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:
Code:
%00000000           %00000000
 11111111            00000001
 00000000  / 128  =  11111110
 11111111            00000001
(the last seven digits are discarded by the division).
adrazar is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Demo name? - Talking fish/human faces in tank & rotating Coke can Higgy request.Demos 0 08 May 2017 10:54
OS 3.5 icons on 3.1 & WHDLoad hangs when displaying icons PoulpSquad support.WinUAE 22 14 September 2012 01:57
FIXED: Venus The Fly Trap (TRAP #0) & NOVBRMOVE INFO Retro-Nerd project.Killergorilla's WHD packs 10 02 November 2007 00:42
educational/puzzle game involving colouring a robot/knight tricky Looking for a game name ? 0 20 November 2004 00:17
Fly Harder & F1 floppy versions turk182 request.Old Rare Games 6 11 November 2001 01:27

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 02:52.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.07075 seconds with 15 queries