Nic01
16th September 2002 02:17 UTC
Resolution Display Problem
I think it just me, but the resolution display for the horizontal size only display numbers which are multiples of 4... It seem to treat multiple resolutions that are displayed at the same number similiarly (The preset doesn't restart when it happens). This makes a resolution with a center dot ("Center" like in 5x5 screen, the center is (3,3) when all of screen is treated positive) impossible (Or difficult to do... or just needs patience... I dunno). Anyone else with the same problem?
P.S. : The vertical size resizes properly...
P.P.S. : This problem was found while fiddling with that Custom Filter APE while exploring Cellular Automata-like patterns...
Edit : Just tested a little more - Happens on all skins I have and occurs when resizing in the right border too (I always resize from left)
UnConeD
17th September 2002 01:52 UTC
(warning: complicated explanation follows :))
32-bit image
The AVS image is stored as a long string of pixels in the RGB0 format. Each pixel is a 32-bit number of the form RRGGBB00, where RR GG BB are 3 8-bit numbers representing the 3 color channels. The wasted byte is used to make sure every pixel fits in 32-bit and is aligned at 32-bits:
24-bit color:
R1 G1 B1 R2 | G2 B2 R3 G3 | B3 R4 G4 B4 | ...
32-bit color:
R1 G1 B1 00 | R2 G2 B2 00 | R3 G3 B3 00 | ...
The x86 processor is a 32-bit processor... this means it works on 32-bits at a time and fetches blocks of 32-bits (4 bytes). Using 32-bit is much more efficient in terms of speed, than 24-bit (pixels are not aligned) or 16-bit (color channels are not split in bytes).
The image is stored horizontally, then vertically, top-left to bottom-right.
Width is a multiple of 4
An important factor here is MMX. MMX instructions perform one operation on multiple sets of data. For example, add 8 pairs of bytes together in one instruction. More specifically, MMX registers are 64-bit wide, so it operates on 64-bits at the same time.
Because we use 32-bit color, we can fit 2 pixels in 64-bits. So it would be handy if the image has an even width, because this allows us to optimize our algorithms to process 2 pixels at a time without having to worry about uneven ends.
AVS goes further and aligns every row of pixels on 4 bytes. I believe this has something to do with the Pentium's cache. You see, when memory access is required, the processor doesn't just read the desired data, it also reads the data that is situated close to the one requested, and stores this in a piece of fast memory called the cache. So if you're working your way through the image and you read pixel #1, the processor will also fetch pixel #2 and #3. So when you arrive at pixel #2, it's already sitting there in the cache rather than having to be fetched from slo-mo main memory.
I can't give you an exact reason why they chose 4 bytes though, but it's really for the good :)
Computers generally like powers of 2 because they use a binary system. People generally like powers of 10 because we use a decimal system. That's why cars generally have round prices (save for that irritating habit of always taking (price - 1 cent) to make it seem less).
If you're interested in the architecture of processors, I recommend reading "The Art of Assembly Language Programming" by Randall Hyde. It's a book about programming the x86 architecture, but the book is so broad (especially the beginning chapters) that you'll learn a lot more than just assembly.
The AVS window itself can have any dimensions though, it'll just calculate 1-3 columns of extra pixels that are not shown.