fast HAM8 conversion ?

[Thorham]

Originally Posted by meynaf

I've got so many versions that I probably mixed up things

I'm still using the very first version!

Originally Posted by meynaf

I thought to write it like that. But it makes the assumption that the difference will never overflow a signed byte, which is not the case because we're subtracting two unsigned bytes to get the diff as a signed value (before taking its absolute value).

EDIT: it *can* be done !
It may overflow a signed byte, but not an unsigned one.
So it must be written that way : (same but with bcc instead of bpl)
move.l d1,d0
sub.b (a6)+,d0
bcc.s .n0
neg.b d0

Thanks for it. I wouldn't have believed something could still be done !

You're welcome. It seems that bpl and bcc do the same here, as it looks like it works perfectly.

I've got a little question: What does the following code do?

;ce code sert reequilibrer les pixels en cas .......
moveq #2,d5
and.l d7,d5
add.l d5,d6 ;+2 sur rouge
moveq #1,d5
and.l d7,d5 ;+1 sur bleu
add.l d5,d4

I tried removing it, and it seems to make no difference.

Edit: I know, more or less, what it does now, the effect is only visible when scrolling. The ham fringing becomes much worse. However, I've spotted the mouse pointer influencing the colors! That means it's probably possible to use a sprite to get rid of the ham fringing when scrolling completely. And if thats the case, then the above code can be left out, which will make the frame count drop to 128!

[meynaf]

Originally Posted by Thorham

You're welcome. It seems that bpl and bcc do the same here, as it looks like it works perfectly.

They start to not do the same when the difference is too big.
For a quick example, imagine d1 is 00 and (a6)+ gives ff.
The difference will be 01 - but should be ff !
If you bpl, you'll keep 01. If you bcc, however, you'll do the neg and hopefully end up with ff.

Originally Posted by Thorham

I've got a little question: What does the following code do?

;ce code sert reequilibrer les pixels en cas .......
moveq #2,d5
and.l d7,d5
add.l d5,d6 ;+2 sur rouge
moveq #1,d5
and.l d7,d5 ;+1 sur bleu
add.l d5,d4

I've tried removing it, and it seems to make no difference.

It just takes cpu to do nothing

Errh, seriously, no. But it doesn't impact the rendering in itself.

Here is how it works :
My tests are made so that in case of identical error values blue will come first, then red, then green (reverse order of the normal ratio).
Saying that d7 is the pixel loop counter (so it goes backwards), and d6/d5 are the error values for resp. red and blue - which, important, have b1-0 to 00 because of 6-bit components -, in a row of identical pixels we'll get :
11 +1 both (-> green pixels are the default)
10 +1 red (-> blue pixels)
01 +1 blue (-> red pixels)
00 nothing (-> blue pixels)
And that will end up with GBRB patterns in rows of identical colors, thus avoiding those long erroneous lines.
I hope it's clear enough. I doubt it though...

To see it in action, apply the renderer to your 1024x768 image. Once the image is displayed, move your mouse to the right until the image can't scroll more to the right.
Do this with both the code active and disabled ; you can't miss it even with a bad display.

[meynaf]

Originally Posted by Thorham

Edit: I know, more or less, what it does now, the effect is only visible when scrolling. The ham fringing becomes much worse. However, I've spotted the mouse pointer influencing the colors! That means it's probably possible to use a sprite to get rid of the ham fringing when scrolling completely. And if thats the case, then the above code can be left out, which will make the frame count drop to 128!

I've never seen a sprite influencing ham display
Don't you have some sort of mouse pointer patch running and perturbating ?

[Thorham]

Originally Posted by meynaf

It just takes cpu to do nothing

Errh, seriously, no. But it doesn't impact the rendering in itself.

Here is how it works :
My tests are made so that in case of identical error values blue will come first, then red, then green (reverse order of the normal ratio).
Saying that d7 is the pixel loop counter (so it goes backwards), and d6/d5 are the error values for resp. red and blue - which, important, have b1-0 to 00 because of 6-bit components -, in a row of identical pixels we'll get :
11 +1 both (-> green pixels are the default)
10 +1 red (-> blue pixels)
01 +1 blue (-> red pixels)
00 nothing (-> blue pixels)
And that will end up with GBRB patterns in rows of identical colors, thus avoiding those long erroneous lines.
I hope it's clear enough. I doubt it though...

To see it in action, apply the renderer to your 1024x768 image. Once the image is displayed, move your mouse to the right until the image can't scroll more to the right.
Do this with both the code active and disabled ; you can't miss it even with a bad display.

It's crystal clear now! Have you also noticed how the mouse pointer can change colors on a ham screen? It may be possible to get rid of the ham fringing completely by using a sprite. Al you would have to do is set the color value of the sprite to what it's supposed to be on screen. Simply changing the color for each scan line. That way the GBRB code can be removed from the loop and you don't have to fix the scroll errors by writing to the bit planes, which means you don't have to save the original data. With a little bit of luck, this would actually work.

[meynaf]

Originally Posted by Thorham

It's crystal clear now! Have you also noticed how the mouse pointer can change colors on a ham screen? It may be possible to get rid of the ham fringing completely by using a sprite. Al you would have to do is set the color value of the sprite to what it's supposed to be on screen. Simply changing the color for each scan line. That way the GBRB code can be removed from the loop and you don't have to fix the scroll errors by writing to the bit planes, which means you don't have to save the original data. With a little bit of luck, this would actually work.

You'll still have to save the original data, else how the heck will you know what to display in the sprite
And I won't believe a sprite can change a ham display until I see it on my own screen.

[Thorham]

Yes, you would still need that, and it would cost a lot. I was just thinking about you mentioning the problem at the beginning of this thread. There must be some sort of way to fix it

You can see the sprite change the ham colors in the fringing parts of the screen. Easiest way to check it out, is to remove then gbrb code, make the screen fringe really bad, and move the pointer over the fringing parts. If it doesn't work for you, then maybe theres something wrong at my end. I checked it in winuea and it doesn't seem to work, maybe it's not emulated or my hardware is buggy! Still, it might just be a feature.

Edited: I've found a much clearer way of showing what I mean:

;ce code sert reequilibrer les pixels en cas .......
moveq #2,d5
and.l d7,d5
add.l d5,d6 ;+2 sur rouge
moveq #1,d5
and.l d7,d5 ;+1 sur bleu
add.l d5,d4

In this code, just add d7 to d6 and d4 directly. This will mess up the image, but move the mouse pointer around, and you should clearly see the effect.

I've seen this happen in some viewers, and I thought I'd mention it.

[meynaf]

Sadly I can't check that before this week-end (as usual ).

However, do you see the same thing when running my viewer ?
(you can do that by simply grabbing the ham image as iff and then display it with the "v" program)
Because if you still see that then your mouse pointer is not a sprite, as I remove it.

Alternatively you can spot the line zcall screen in ham8_test.s and add zcall mouseoff right after it, to do the same effect.

[Thorham]

Originally Posted by meynaf

Sadly I can't check that before this week-end (as usual ).

However, do you see the same thing when running my viewer ?
(you can do that by simply grabbing the ham image as iff and then display it with the "v" program)
Because if you still see that then your mouse pointer is not a sprite, as I remove it.

Alternatively you can spot the line zcall screen in ham8_test.s and add zcall mouseoff right after it, to do the same effect.

The mouse pointer gets turned off, as it's supposed to, it's definitively a sprite.

I got the address table working, and I must say there is no difference compared to my 64kb index table. I also checked the large address table, for 800x600 the nr of frames drops to 131. The table is still only 64kb, though.

[meynaf]

I've found a possible spot for optimization, but failed to achieve anything.

Here is the idea...

This :

move.l d4,a5
add.l d6,a5
add.l d5,d6
add.l d5,d4

can be rewritten like that :

add.l d5,d4
add.l d6,d5
add.l d6,d6
sub.l d5,d6
add.l d4,d6

There's a slight loss, it's not an optimization - but we're no longer using a5.

If we could do the same for that :

add.l d4,d4
move.l d5,a5
add.l d5,d5
add.l a5,d5

then we could keep a5 all long and remove the move to a5.

But it doesn't seem to be possible to rewrite this part without a mul (horror !), a memory access (give up !) or with swaps (still too slow).
Of course we have no spare regs.

The goal of those two blocks of code is to get 2r+3g, 2r+b, 3g+b in the 3 very same regs we had r, g and b value - in less than 10 simple instructions and without using another reg.

If you've got an idea...

[Thorham]

Cool, my miggy is ready to go, so I'll check it out.

Originally Posted by meynaf

But it doesn't seem to be possible to rewrite this part without a mul (horror !), a memory access (give up !) or with swaps (still too slow).

[StrategyGamer]

Originally Posted by meynaf

I've never seen a sprite influencing ham display

He is using a highly buggy piece of software called WinUAE.

[Graham Humphrey]

Shall I assume that was ironic?

[Thorham]

Originally Posted by StrategyGamer

He is using a highly buggy piece of software called WinUAE.

No, I'm not. This thread is about optimizing a ham rendering routine, and therefore I'm using my a1200. In fact, under winuae this doesn't seem to happen. It could be I have a hardware problem or a virus, but but that's pretty unlikely. I certainly hope it's not a problem, because then it's a feature!

[StrategyGamer]

Please place the example hampic in the zone and I will test it on my real A1200.

p.s. does the problem only happen in HAM8 or also in HAM6?

[DamienD]

Originally Posted by StrategyGamer

He is using a highly buggy piece of software called WinUAE.

Is that comment really necessary StrategyGamer???

Just because you don't use / like WinUAE doesn't give you the right to slag it off without reason... There are alot of members here who do use / love WinUAE and find it a very good / stable piece of software. I for one only use WinUAE!!!

Also, don't forget that the author visits EAB, is a very active / helpful member on these forums and to the Amiga community overall. Not sure if he's read your comments as yet but not very nice considering all the time / effort he puts into this project for free...

Software bashing on EAB is not allowed full stop. This goes for AmiKit, Classic WorkBench, AmigaSys, WinUAE or whatever. If you have nothing constructive or relevant to add the thread then it's probably best not to say anything at all... I mean, it's awesome for people to have different opinions and of course you are entitled to yours but as mentioned above, slagging something off without good reason isn't appropriate. Please try to be a bit more constructive with your future posts.

[StrategyGamer]

I wasn't bashing UAE. I was merely making a statement of fact.

[Graham Humphrey]

Originally Posted by StrategyGamer

I wasn't bashing UAE. I was merely making a statement of fact.

Maybe you would like to back that up with examples. Otherwise, behave yourself.

[DamienD]

Originally Posted by StrategyGamer

I wasn't bashing UAE. I was merely making a statement of fact.

How is that fact??? What's so buggy about UAE???

Anyway, I don't want to get into an argument about this. Your comments are completely off topic, do not belong in this thread and sure look like unsubstantiated software bashing to me... Please stay on topic.

[StrategyGamer]

Extensive documentation of numerous UAE bugs would be off topic in this thread. Behave yourself.

[DamienD]

Thorham has already said the following:

Originally Posted by Thorham

In fact, under winuae this doesn't seem to happen.

This totally disproves your argument in regards to this thread... so I will ask you again, please stop posting unrelated / unsubstantiated comments and stay on topic.