AminetAminet
Search:
84799 packages online
About
Recent
Browse
Search
Upload
Setup
Services

dev/basic/OptmRemap.lha

Mirror:Random
Showing: m68k-amigaos iconppc-amigaos iconppc-morphos iconi386-aros iconi386-amithlon iconppc-warpup iconppc-powerup icongeneric icon
No screenshot available
Short:Optimized palette re-mapping code
Author:Curt Esser
Uploader:Curt Esser <camge ix netcom com>
Type:dev/basic
Architecture:m68k-amigaos
Date:1998-02-18
Requires:BDGFX library (C) BadDolls Production
Download:dev/basic/OptmRemap.lha - View contents
Readme:dev/basic/OptmRemap.readme
Downloads:670

You can find this small (one command) library in Aminet/dev/basic
or at http://www.a2points.com/homepage/3698138

What it does: Remaps an iff picture to your screen's palette.  For
              the example, I have used the Workbench Screen, but
              it should work with any custom screen too.     
              
Limitations:  Might not work on on a GFX card - let me know!
              
Your Bit:     If you find any errors, or come up with any improvements
              please pass them along to me.

              Also, if you have any good examples on any Blitz related
              topics, please upload them here so others can use them!  


This is an updated version of the re-mapping example I uploaded before.

The day after my re-map code appeared, I recieved a letter from Xavier Nuel,
the author of the BDGFX library used for the colour mapping:

 Hi Curt !!!

 I've done some improvements to your good code :-)

 Why do you use the Remap command ? It's so slow...
 
 Bye , Xavier Nuel ( BadDolls )

So, I tried his altered version, and yes it did produce a noticable speed
improvement!  But it seemed a bit slower if the picture depth was less than
that of the target screen.  This was odd, I thought, so I did some speed
comparisons between the two versions.

As you can see, if the picture depth is less than that of the target screen,
the old method is much faster, but if it is equal or greater depth than the
point/plot method is a lot faster.

I have no explanation for this, but being a firm believer in the theory "If
it works, GO FOR IT!", I altered the code to include all three methods and
automatically switch to the fastest method.

Surprisingly, this adds very little to the size of the finished exec!


Results of remapping tests:

All test done on NTSC A1400T, WB 3.1, 2M chip  4M fast  RuntimeErrors OFF


128 colour WB:
                        2 bitmap -          1 bitmap -       2 bitmap
    Picture             ReMap Command       Point/Plot       Point/Plot

16 colour  399*403      216 ticks           1920 ticks       1988 ticks

256 col.   432*484      5403 ticks          2622 ticks       2946
                                            *BAD COLOURS*  

64 col.    320*200      420 ticks           944 ticks        1008 ticks




256 colour WB:

16 col.    399*403      245 ticks           2122 ticks       2123 ticks

256 col.   432*484      5995 ticks          2944 ticks       3194 ticks

64 col     320*200      475 ticks           1057 ticks       1102 ticks     

Readme created with ARC 2.4 - Copyright (c)1996-98 by Jens Weyer.


Contents of dev/basic/OptmRemap.lha
 PERMSSN    UID  GID    PACKED    SIZE  RATIO     CRC       STAMP          NAME
---------- ----------- ------- ------- ------ ---------- ------------ -------------
[generic]                 2557    6608  38.7% -lh5- aa8e Feb 15  1998 Optimized.remap.bb
[generic]                 1330    2766  48.1% -lh5- 1e7d Feb 17  1998 OptmRemap.readme
---------- ----------- ------- ------- ------ ---------- ------------ -------------
 Total         2 files    3887    9374  41.5%            Feb 17  1998
Page generated in 0.02 seconds
Aminet © 1992-2024 Urban Müller and the Aminet team. Aminet contact address: <aminetaminet net>