20 March 2011, 13:58 | #1 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,839
|
HAM8 screen question.
Hi,
I've been playing around with the OS to open a HAM8 screen. So far so good, except for the fact that the OS opens a HAM8 screen with the HAM mode bits in the upper two bitplanes (refers to the chunky buffer: The mode bits are now always the upper two bits of a chunky pixel). Thinking it would solve the problem, I simply allocated my own screen memory, and rearranged the bitplanes so that the mode bits should be in the first two bits of a chunky pixel. But this doesn't work. Could it be the c2p I'm using (improper usage)? It's one of Kalms' c2p, the 1x1 8bit c2p for the '030, or am I doing something else wrong? Any help is appreciated |
20 March 2011, 14:08 | #2 |
Registered User
Join Date: Jan 2002
Location: Germany
Posts: 7,026
|
That's how HAM works. The upper two bits define the mode. Either bits 7 and 6 for HAM8 or bits 5 and 4 for HAM6. The remaining bits define either the new red or green or blue value or the palette entry, if both mode bits are 0.
|
20 March 2011, 14:11 | #3 |
Registered User
Join Date: Mar 2008
Location: Poland
Posts: 159
|
That's only true for HAM6. In HAM8 mode two LSBs define the mode.
|
20 March 2011, 14:16 | #4 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,839
|
Thanks for the replies
Solved the problem already, though. The c2p operates on contiguous chipmem. Because I rearranged the bitplanes, and obtained the address of the first plane from the bitmap structure (which is screen+10240*2, instead of screen), the two upper bitplanes were written after the displayed data while the first two bitplanes were left empty Silly mistake, isn't it Sorry for wasting peoples time with this |
21 March 2011, 17:57 | #5 | |
AMOS Extensions Developer
Join Date: Jun 2007
Location: near Cambridge, UK
Age: 44
Posts: 1,924
|
Quote:
I spent the last 2 weeks trying to debug my end credits routine, thinking it was buggy. It turned out the ASCII art that is part of the end credits used characters > 126, but my credits routine only works with characters < 126! The ASCII art thing wasn't obvious as character 173 looks like character 45 when viewed in my favourite text editor. It wasn't until I used a binary/hex/decimal/text editor that it became obvious when viewing the file in decimal mode. Regards, Lonewolf10 |
|
29 March 2011, 04:20 | #6 | |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,416
|
Quote:
I had a play around with HAM8 C2P myself but couldn't get it to do much but generate some radom colors, might try it again one of these days. |
|
29 March 2011, 17:56 | #7 | ||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,839
|
Quote:
Quote:
Basically it worked properly, but the Ham8 mode bits were placed in the upper two bitplanes, and I wanted them to be the lower two bitplanes (so that you can simply and+or the mode bits into a chunky pixel), which didn't work, because I was pointing the c2p routine to the wrong address (bitplane 2 as the start instead of bitplane 0). |
||
30 March 2011, 00:46 | #8 |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,416
|
So you're coding in 'C' I assume?
Would you mind sharing your code here, I had some issues opening a HAM8 screen, setting the palette etc. Thanx. |
30 March 2011, 18:38 | #9 | |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,839
|
Nope, pure assembler, which sadly requires writing a proper framework (which I've been working on for a while know, because my previous one was both crappy and limited).
Quote:
Actually, seeing how you've made an OS friendly port of DOTT, you're already opening a screen and setting the palette, etc, and although I don't mind sharing code, I would like to know why (opening a HAM8 screen simply requires changing one parameter in the openscreen taglist, and you simply set the first 64 colors instead of 256 for 8bpp). |
|
31 March 2011, 00:09 | #10 | |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,416
|
Quote:
Thanks but assembler doesn't help me (I'm more a C++ kind of guy ). Yep I figured out how to open a HAM8 screen but could get it to display properly using Kalms Ham8 C2P functions. I wasn't sure how I should be updating the palette to display HAM8 and if I was using the C2P in the right way. When I get the time and the energy I might give it another go. The other problem that I had was that I didn't have a real Amiga to try my code on, only WINUAE. |
|
31 March 2011, 18:40 | #11 | |||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,839
|
Quote:
Quote:
Quote:
Not a problem for HAM8+OS code at all |
|||
01 April 2011, 01:08 | #12 | |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,416
|
Quote:
Why do you only need to set 64 colors, HAM8 can display thousands? HAM8 supports 64 colors per pixel so the question becomes how to you set the palette for the entire image that you want to display (eg 320x200 chunky pixels = 64000). From the readme text of the HAM8 C2P: Code:
Converters which read in standard 15/16/32bpp graphics formats, and output 555 or 666 ham8 graphics. As an example say that I've got a 320x200 16 bit chunky buffer (16bit RGB 565 format) and I want to display it. From the readme files it looks like you need to use 'c2p_2rgb565_4rgb555h8_040.s' and pass in the 16 bit chunky buffer which would output to a 1280x200 WB screen. It would be great to output 320x200 16bit colors to a 320x200 WB screen but that's not how HAM works is it? Last edited by NovaCoder; 01 April 2011 at 13:21. |
|
01 April 2011, 17:10 | #13 | |||||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,839
|
Quote:
Quote:
1) Set pixel to palette. 2) Hold red+green, modify blue. 3) Hold red+blue, modify green. 4) Hold green+blue, modify red. Quote:
Quote:
Quote:
HAM c2p: 3x1 pixels, almost exact color matches. Normal c2p: 1x1 pixels, approximations (quality depends on the way in which the true color image is analyzed). If this is unclear, feel free to ask more questions |
|||||
01 April 2011, 23:24 | #14 |
Registered User
Join Date: Jan 2011
Location: France
Age: 52
Posts: 507
|
HAM8 = Hold And Modify, 8 bits per pixel.
It means that it takes the existing pixel to it's left (or the color from palette entry 0 if it's a left-border pixel) and then holds it's color and just modify one of the 3 rgb components. Wich one of the 3 rgb components it does modify depends on the 2 high-end bits (bit 6 and 7, starting with 0). So in fact a ham8 pixel has 2 command bits that specifies wich rgb component it modifies and 6 value bits that tells us what that rgb components new value will be. if the command bits are 0 it will not modify one of the rgb components, but instead it will put one of the real palette colors that the ham8 mode has. command bit values: 00: the 6 lower bits will be the palette color entry from the 64 base ham8 colors. 01: the 6 lower bits will tell us what the new BLUE component will be (keeping red and green from previous left pixel) 10: the 6 lower bits will tell us what the new RED component will be (keeping blue and green from previous left pixel) 11: the 6 lower bits will tell us what the new GREEN component will be (keeping blue and red from previous left pixel) Exemple: If you read a pixel in your HAM8 screen with the ReadPixel function from the graphics library, and you get back a value of 191 then you just need to transform the value into binary and you obtain: 191 --> 1011 1111 You take the 2 high bits wich are 10, what means this pixel changes the red component, and the value of the new red component will be 11 1111 what is 63. Now you could say, but Amiga do code the rgb color components on 8 bits, but ham8 only can modify the colors from 0 to 63 (6 bits). In fact the 6 bits are taken like the uper 6 bits from a 8 bits RGB component, so you can just multiply the valor by 4, and you obtain 63X4 = 252. Of course with your only one ReadPixel command you won't be able to know what the complete color of that pixel actualy is, you will have to check the previous left pixel, and the one left from this one, and so on, till you fall either on the left border pixel, or on a base palette pixel, or till you have seen all 3 rgb valors. Sorry, i feel my explanation lacks a bit of proper english |
02 April 2011, 05:59 | #15 | |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,416
|
Quote:
As you say, the 4x C2P routines will give you something very close to the original image. What about performance, I assume 1x1 pixel is much quicker (as there less pixels to write)? So your loop has to reset the 64 color palette for each pixel it writes does it? How does WB know that each 64 color palette is associated with each pixel (or pixels). I though SetRGB32() did it for the entire screen? |
|
02 April 2011, 07:47 | #16 | |||
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,839
|
Quote:
Quote:
Quote:
Any more questions? Feel free to ask'm here |
|||
02 April 2011, 09:18 | #17 | |
Registered User
Join Date: Jan 2011
Location: France
Age: 52
Posts: 507
|
Quote:
But me too sometimes i'm just to lazy to read some "longer" posts from someone else and to try to understand it , i think i explained it rather well finnaly |
|
03 April 2011, 03:32 | #18 | ||
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,416
|
Quote:
Yep did see that and yes, it was a good explanation....thanx. Quote:
I would like to pass in: 1) 300x200 16 bit (565) pointer (chunky buffer in) 2) 300x200 8 bit pointer (chunky buffer out) 3) Palette pointer for the 64 entries (for later use by LoadRGB32 in my code) What do you think? It would be better if the width and height could be specified (parameters). Would such a routine be fast enough for real-time usage BTW? Last edited by NovaCoder; 03 April 2011 at 04:46. Reason: Back to back posts merged. Use multi-quote. |
||
03 April 2011, 10:43 | #19 | |
Registered User
Join Date: Jan 2011
Location: France
Age: 52
Posts: 507
|
Quote:
You probably meant: 2) 300x200 8 bit planar pointer that points on first top left edge of first bitplane (?) If you really meant what you wrote then it probably takes to much time for real-time, because you will need affter this some c2p routine that converts your 8 bit chunky to real Amiga screen datas. |
|
03 April 2011, 11:14 | #20 |
Registered User
Join Date: Sep 2007
Location: Melbourne/Australia
Posts: 4,416
|
Hiya,
Yep I know that I'd need to use a C2P routine after this call (probably the same 1x 8bit routine that Thorham is using for his code). |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
HAM8 C2P Hacking | NovaCoder | Coders. General | 2 | 25 March 2010 10:37 |
Workbench screen question. | Thorham | Coders. General | 10 | 31 August 2008 19:31 |
Problem making ham8 icons. | Thorham | support.Apps | 0 | 12 March 2008 22:30 |
fast HAM8 conversion ? | meynaf | Coders. General | 237 | 23 February 2008 08:58 |
Multiple HAM8 pictures? | killergorilla | support.Other | 4 | 15 February 2007 14:41 |
|
|