HAM8 screen question.

[Thorham]

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

[thomas]

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.

[yaqube]

Originally Posted by thomas

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.

That's only true for HAM6. In HAM8 mode two LSBs define the mode.

[Thorham]

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

[Lonewolf10]

Originally Posted by Thorham

Silly mistake, isn't it Sorry for wasting peoples time with this

I have made plenty of silly mistakes.

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

[NovaCoder]

Originally Posted by Thorham

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

You are using the actual HAM8 C2P routines aren't you?

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.

[Thorham]

Originally Posted by Lonewolf10

I have made plenty of silly mistakes.

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!

Yep, that's a beauty right there

Originally Posted by NovaCoder

You are using the actual HAM8 C2P routines aren't you?

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.

No, I'm actually using normal 1x1 8 bit per pixel c2p; seems Kalms' Ham8 c2p also does true color to Ham8 conversion, which I don't need (don't need real time).

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).

[NovaCoder]

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.

[Thorham]

Originally Posted by NovaCoder

So you're coding in 'C' I assume?

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).

Originally Posted by NovaCoder

Would you mind sharing your code here, I had some issues opening a HAM8 screen, setting the palette etc.

I have some (supposedly) properly behaving test code which I can share, but it's in assembler, of course. However, I got that to work just by reading the RKM (elowar's doc site) and examining some (asm) include files and autodocs (NDK 3.1), so it shouldn't (isn't) too difficult to get to work.

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).

[NovaCoder]

Originally Posted by Thorham

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).

Hiya,

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.

[Thorham]

Originally Posted by NovaCoder

Thanks but assembler doesn't help me (I'm more a C++ kind of guy ).

Yeah, read that on UtilityBase yesterday

Originally Posted by NovaCoder

Yep I figured out how to open a HAM8 screen but could get it to display properly using Kalms Ham8 C2P functions.

If you want normal 1x1 pixel HAM8, and not 3x1, you must use normal 8 bit per pixel c2p, not HAM8 c2p! Those HAM8 c2p routines convert to 3x1 pixel format.

Originally Posted by NovaCoder

I wasn't sure how I should be updating the palette to display HAM8.

Like I said, just set colors 0 to 63 with LoadRGB32, that's it

Originally Posted by NovaCoder

The other problem that I had was that I didn't have a real Amiga to try my code on, only WINUAE.

Not a problem for HAM8+OS code at all

[NovaCoder]

Originally Posted by Thorham

Yeah, read that on UtilityBase yesterday
If you want normal 1x1 pixel HAM8, and not 3x1, you must use normal 8 bit per pixel c2p, not HAM8 c2p! Those HAM8 c2p routines convert to 3x1 pixel format.
Like I said, just set colors 0 to 63 with LoadRGB32, that's it
Not a problem for HAM8+OS code at all

Why would you'd use the normal 8bit per pixel C2P with HAM8....that's very strange

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:

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?

[Thorham]

Originally Posted by NovaCoder

Why would you'd use the normal 8bit per pixel C2P with HAM8....that's very strange

It's needed for getting normal 1x1 pixel resolution (HAM8 is just an 8 bits per pixel mode).

Originally Posted by NovaCoder

Why do you only need to set 64 colors, HAM8 can display thousands?

Remember that HAM pixels have four modes:

1) Set pixel to palette.
2) Hold red+green, modify blue.
3) Hold red+blue, modify green.
4) Hold green+blue, modify red.

Originally Posted by NovaCoder

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).

You can't, you can only set the 64 normal palette colors. Rendering an image in HAM requires analyzing the image, so that you can determine which of the above mentioned pixel modes best represents a true color pixel, or by using three pixels to represent one true color pixel.

Originally Posted by NovaCoder

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.

These HAM c2p routines render a true color pixel by using three HAM pixels to represent one true color image. When you want to use that analyzing method to use only single pixels, you need a normal 8 bit per pixel c2p, not HAM.

Originally Posted by NovaCoder

It would be great to output 320x200 16bit colors to a 320x200 WB screen but that's not how HAM works is it?

If you use the analyzing method, you get an approximation of this in the same resolution, while if you use those HAM c2p routines, you get 16 bits per pixel at one third of the resolution.

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

[Lord Riton]

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

[NovaCoder]

Originally Posted by Thorham

It's needed for getting normal 1x1 pixel resolution (HAM8 is just an 8 bits per pixel mode).
Remember that HAM pixels have four modes:

1) Set pixel to palette.
2) Hold red+green, modify blue.
3) Hold red+blue, modify green.
4) Hold green+blue, modify red.
You can't, you can only set the 64 normal palette colors. Rendering an image in HAM requires analyzing the image, so that you can determine which of the above mentioned pixel modes best represents a true color pixel, or by using three pixels to represent one true color pixel.
These HAM c2p routines render a true color pixel by using three HAM pixels to represent one true color image. When you want to use that analyzing method to use only single pixels, you need a normal 8 bit per pixel c2p, not HAM.
If you use the analyzing method, you get an approximation of this in the same resolution, while if you use those HAM c2p routines, you get 16 bits per pixel at one third of the resolution.

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

Ok that makes sense. So how good does 1x1 pixel HAM8 look for a 16 bit image when the image has not be generated to be 'HAM friendly'?

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?

[Thorham]

Originally Posted by NovaCoder

So how good does 1x1 pixel HAM8 look for a 16 bit image when the image has not be generated to be 'HAM friendly'?

What do you mean with HAM friendly picture?

Originally Posted by NovaCoder

What about performance, I assume 1x1 pixel is much quicker (as there less pixels to write)?

No, it's not. HAM8 c2p does c2p conversion and it renders the image. This is much faster than calculating which of those four modes best suits a pixel.

Originally Posted by NovaCoder

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?

No, you don't reset the palette for each pixel, if that was possible, you could just set each pixel to a specific value and you wouldn't need HAM at all. The palette is only set once with LoadRGB32 and that's it. Note that a typical 3x1 HAM8 renderer doesn't need the palette at all (you set red, then green, then blue), while for 1x1 you can get some serious HAM fringing if you don't use a palette.

Any more questions? Feel free to ask'm here

[Lord Riton]

Originally Posted by NovaCoder

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?

Is my previous post invisible to you ?

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

[NovaCoder]

Originally Posted by Lord Riton

Is my previous post invisible to you ?

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

Hiya,

Yep did see that and yes, it was a good explanation....thanx.

Originally Posted by Thorham

What do you mean with HAM friendly picture?
No, it's not. HAM8 c2p does c2p conversion and it renders the image. This is much faster than calculating which of those four modes best suits a pixel.
No, you don't reset the palette for each pixel, if that was possible, you could just set each pixel to a specific value and you wouldn't need HAM at all. The palette is only set once with LoadRGB32 and that's it. Note that a typical 3x1 HAM8 renderer doesn't need the palette at all (you set red, then green, then blue), while for 1x1 you can get some serious HAM fringing if you don't use a palette.

Any more questions? Feel free to ask'm here

Ok sounds interesting, could you knock my up an assembler routine to do the conversion so I can give the 1x C2P method I try.

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?

[Lord Riton]

Originally Posted by NovaCoder

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?

I don't understand why you want also a chunky buffer for the output , that would mean you would need another routine affter that one to convert your 8 bit chunky (that would be ham8 chunky) to planar (bitplanes).
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.

[NovaCoder]

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).