Misc programming discussion (from pms).

[Thorham]

Originally Posted by meynaf

Well, why didn't I see it is something I still wonder

It can happen, but who cares, as long as it's solved. You know this already: I find that adding blank lines helps, because it's easier to miss things when your code doesn't contain those blanks. I may use them too often, but it seems you may not use them often enough. Just a thought

Originally Posted by meynaf

As I told you, color pickers give different results only for choices that are difficult to make, and these usually matter less on HAM.

Yeah, if it's going to matter, then only if your color picker is close to perfect, and that's not easy to do.

Originally Posted by meynaf

Well, I won't say it can't be improved, but what I think is that it can't be done without slowing it down. This is a challenge you might wish to take

It's a challenge for sure Anyway, I do know a way to improve your quality renderer, but at the cost of speed, unfortunately. In case you want to know: Use super highres instead of normal highres, and write two ham pixels instead of one. The first ham pixel is the one with the largest delta, and the second pixel is the one with the second largest delta. The disadvantage is obviously that you have to c2p twice the amount of data (in the renderer you also have to write twice the amount of data, but this part doesn't matter much, because fastmem writes are quite fast).

I haven't tested this, but if it is a lot better, then it might be nice as an option (especially for '060 users).

Originally Posted by meynaf

Even if you wanted to blame me, you wouldn't need to do it. I did it enough myself

What for? For one small, easy to miss bug? Of course, I believe software doesn't have to contain bugs, but to err is human, and getting rid of every last bug is not easy (although still possible).

[Thorham]

To add something to the super highres idea: You can do one of three things per pixel:

1) Write two ham pixels.
2) Write ham pixel, then palette pixel.
3) Write palette pixel, then ham pixel.

Might be interesting as a quality enhancing feature.

Also, you might want to try other weights then 2xRed, 3xGreen and 1xBlue. I've had some good results with 3xRed, 4xGreen and 2xBlue. Those weights take only a few extra cycles, but they increase the color quality. That green thing I told you about is reduced by those new weights (it's not caused by that bug), so it may be worth looking into.

On a side note: Have you tried rendering without a palette? Now I know that this reduces the quality (duh ), but it's great for experimentation, because you get to see the errors pretty clearly. That said, most parts of most of the images I've tried still look very good without palette usage, and it makes me wonder what's really the best way to calculate when the error becomes too big.

Edit:

I've rendered the difference between a palette less ham image and the original 24 bit image, and the difference is quite interesting. It makes it really easy to see where the errors will be in the ham image. I've tried using this in my quick renderer, and for some images the quality is a little better than your quality renderer (really, I haven't made a mistake this time ). In most cases it's still not as good, however Damn, this is difficult, and frustrating

[meynaf]

Originally Posted by Thorham

It can happen, but who cares, as long as it's solved. You know this already: I find that adding blank lines helps, because it's easier to miss things when your code doesn't contain those blanks. I may use them too often, but it seems you may not use them often enough. Just a thought

I don't think adding blank lines would have shown me that bug...

Originally Posted by Thorham

Yeah, if it's going to matter, then only if your color picker is close to perfect, and that's not easy to do.

When the error level is low, then the color picker is perfect. Else nothing will be.

Originally Posted by Thorham

It's a challenge for sure Anyway, I do know a way to improve your quality renderer, but at the cost of speed, unfortunately. In case you want to know: Use super highres instead of normal highres, and write two ham pixels instead of one. The first ham pixel is the one with the largest delta, and the second pixel is the one with the second largest delta. The disadvantage is obviously that you have to c2p twice the amount of data (in the renderer you also have to write twice the amount of data, but this part doesn't matter much, because fastmem writes are quite fast).

I haven't tested this, but if it is a lot better, then it might be nice as an option (especially for '060 users).

I thought about this long ago, and made tests with FastJpeg. Unfortunately it ended up giving something not stunningly better - but only stunningly slower.

Now perhaps you need to know that '060 boards have even poorer chipmem timings than '030, and that displaying 8-bit SHRES leaves you with no free chip memory cycle at all (unless you're in the borders).

Originally Posted by Thorham

What for? For one small, easy to miss bug? Of course, I believe software doesn't have to contain bugs, but to err is human, and getting rid of every last bug is not easy (although still possible).

Yes, for that small, easy to miss, but rather old, bug.

Originally Posted by Thorham

To add something to the super highres idea: You can do one of three things per pixel:

1) Write two ham pixels.
2) Write ham pixel, then palette pixel.
3) Write palette pixel, then ham pixel.

Might be interesting as a quality enhancing feature.

Why don't you test things before you suggest them ?

Originally Posted by Thorham

Also, you might want to try other weights then 2xRed, 3xGreen and 1xBlue. I've had some good results with 3xRed, 4xGreen and 2xBlue. Those weights take only a few extra cycles, but they increase the color quality. That green thing I told you about is reduced by those new weights (it's not caused by that bug), so it may be worth looking into.

Beware of particular cases which render better with some method !

I chose the 3/2/1 ratio because it was used in the IJG jpeg library (see its jquant2.c). A "better" one would use non-integer values and 4/3/2 is certainly not better for the general case.

Originally Posted by Thorham

On a side note: Have you tried rendering without a palette? Now I know that this reduces the quality (duh ), but it's great for experimentation, because you get to see the errors pretty clearly. That said, most parts of most of the images I've tried still look very good without palette usage, and it makes me wonder what's really the best way to calculate when the error becomes too big.

Yes, I did. This shows a nice row of green pixels at the left of the image (often at other parts, too).
While debugging, I also tried to put ONLY palette pixels. Ugly, of course, but not always as bad as expected.

Originally Posted by Thorham

Edit:

I've rendered the difference between a palette less ham image and the original 24 bit image, and the difference is quite interesting. It makes it really easy to see where the errors will be in the ham image. I've tried using this in my quick renderer, and for some images the quality is a little better than your quality renderer (really, I haven't made a mistake this time ). In most cases it's still not as good, however Damn, this is difficult, and frustrating

Doesn't this requires a full pre-scan of the image, that is, just too much time ?

[Thorham]

Originally Posted by meynaf

When the error level is low, then the color picker is perfect. Else nothing will be.

Yes, but a better color picker will yield better results for larger errors. It still seems as if this could be advantagous.

Originally Posted by meynaf

I thought about this long ago, and made tests with FastJpeg. Unfortunately it ended up giving something not stunningly better - but only stunningly slower.

Well, so much for that idea then

Originally Posted by meynaf

Now perhaps you need to know that '060 boards have even poorer chipmem timings than '030, and that displaying 8-bit SHRES leaves you with no free chip memory cycle at all (unless you're in the borders).

Didn't know about those chipmem timings, but if the quality doesn't get much better, than it's not important anyway.

Originally Posted by meynaf

Yes, for that small, easy to miss, but rather old, bug.

Don't be so hard on yourself, man, it happens.

Originally Posted by meynaf

Why don't you test things before you suggest them ?

Yeah, good idea

Originally Posted by meynaf

Beware of particular cases which render better with some method !

Yeah, all too true.

Originally Posted by meynaf

I chose the 3/2/1 ratio because it was used in the IJG jpeg library (see its jquant2.c). A "better" one would use non-integer values and 4/3/2 is certainly not better for the general case.

Is better perhaps more like 29.9xRed, 58.7xGreen and 11.4xBlue? Basically, 2/3/1 renders with more detail and lower color quality, while 3/4/2 renders with a little less detail and more color quality. 3/4/2 is certainly generally usable, but it depends on ones preferences.

Originally Posted by meynaf

Yes, I did. This shows a nice row of green pixels at the left of the image (often at other parts, too).
While debugging, I also tried to put ONLY palette pixels. Ugly, of course, but not always as bad as expected.

Can be quite revealing, but I just can't seem to figure a better way to compensate for those damned errors

Originally Posted by meynaf

Doesn't this requires a full pre-scan of the image, that is, just too much time ?

No, it doesn't. The moment you know which component to write, you know that the delta for that component becomes zero. In other words, if you're going to write blue as a ham pixel, you know that the new deltas are simply the red and green deltas. The problem is therefore not speed, but I still haven't been able to use this information to render better ham images

Update:

I've come up with an interesting idea. Why not make a table for the palette/rgb deltas? Sure, you can only really make a table for 12 bit color (make one for 18 bit color and the table becomes way too large), but, you might be able to correct the errors (using fixed error correction already helps). I've been experimenting with this, and the table works, now all I need to do is correct the errors properly (those errors simply come from the fact that the assumed input pixel always uses only four bits per component).

If this can be gotten to work properly, then you don't have to calculate two sets of deltas anymore, just one, and that should save a whole bunch of cycles (if the error correction can be made cheap enough without sacrificing quality in any way). Further gain may be obtained from using peterk's table idea with weighted deltas (haven't gotten this to work yet).

However, the extra table will use up memory. My current version has V assemble to around 60 KB. Of course I'm doing Don Adan's lea thing again (which is a good idea, and if I can't get rid of it, too bad, I'm fresh out of registers. You'd think 15 free registers would be enough, but noooooo ), and my color lookup table currently isn't compressed like yours (I'm trying different palettes, with different color picking methods so there's no point in compressing the table yet), so those 60 Kbs will get a lot less.

One last thing: In your quality renderer, can't you change one of the auto increment palette color reads (sub.b (a6)+,dx) to non auto increment? You then just have to add an addq to the palette writing part.

[meynaf]

Originally Posted by Thorham

Yes, but a better color picker will yield better results for larger errors. It still seems as if this could be advantagous.

Pixels with large errors will rarely be palette pixels, so this is less important than it looks (didn't I already say something like that ?).

Originally Posted by Thorham

Is better perhaps more like 29.9xRed, 58.7xGreen and 11.4xBlue? Basically, 2/3/1 renders with more detail and lower color quality, while 3/4/2 renders with a little less detail and more color quality. 3/4/2 is certainly generally usable, but it depends on ones preferences.

2/3/1 is the closest approximation, and it's quicker to compute than 3/4/2.

Originally Posted by Thorham

Can be quite revealing, but I just can't seem to figure a better way to compensate for those damned errors

There is little you can do. I even tried some sort of dithering, but it ended up showing ugly artifacts and I dropped the idea (which was too slow anyway).

Originally Posted by Thorham

No, it doesn't. The moment you know which component to write, you know that the delta for that component becomes zero. In other words, if you're going to write blue as a ham pixel, you know that the new deltas are simply the red and green deltas. The problem is therefore not speed, but I still haven't been able to use this information to render better ham images

You can only use this data to choose the palette, and this requires a pre-scan of the image.

Originally Posted by Thorham

Update:

I've come up with an interesting idea. Why not make a table for the palette/rgb deltas? Sure, you can only really make a table for 12 bit color (make one for 18 bit color and the table becomes way too large), but, you might be able to correct the errors (using fixed error correction already helps). I've been experimenting with this, and the table works, now all I need to do is correct the errors properly (those errors simply come from the fact that the assumed input pixel always uses only four bits per component).

If this can be gotten to work properly, then you don't have to calculate two sets of deltas anymore, just one, and that should save a whole bunch of cycles (if the error correction can be made cheap enough without sacrificing quality in any way). Further gain may be obtained from using peterk's table idea with weighted deltas (haven't gotten this to work yet).

However, the extra table will use up memory. My current version has V assemble to around 60 KB. Of course I'm doing Don Adan's lea thing again (which is a good idea, and if I can't get rid of it, too bad, I'm fresh out of registers. You'd think 15 free registers would be enough, but noooooo ), and my color lookup table currently isn't compressed like yours (I'm trying different palettes, with different color picking methods so there's no point in compressing the table yet), so those 60 Kbs will get a lot less.

I find it funny to see you stumble on several ideas I've had before... but alas I found out this one couldn't be done without sacrificing quality or using a 18-bit table. You could be luckier than I was, but I doubt.

Originally Posted by Thorham

One last thing: In your quality renderer, can't you change one of the auto increment palette color reads (sub.b (a6)+,dx) to non auto increment? You then just have to add an addq to the palette writing part.

Auto-increment has same speed as non auto increment.

[Thorham]

I'm picking up the old discussion again right where I seemed to have left off.

Originally Posted by meynaf

It does some weird CPU tests, and gives binary result accordingly to what it found. It's small so you can disassemble it if you're curious

Sure, I can disassemble it, but can't you say what it does exactly?

Originally Posted by meynaf

To err is human, you know.

Absolutely. But that just means bugs happen, not that they can't all be removed (that's difficult, but not impossible).

Originally Posted by meynaf

You don't know if it's good prior to testing it

Yep, you sure do have to test monitors before shelling out the cash.

Originally Posted by meynaf

I don't think so, even though I didn't look in detail.

Then I can't get more DM II info, sorry.

Originally Posted by meynaf

For most of it, the compiler is to blame.

Ah, so they didn't write it in assembler, eh? I wonder why not?

Originally Posted by meynaf

Just finish it then

Only when the dungeon is finished. I don't want to have to start over each time you add things

Originally Posted by meynaf

Boring business software doesn't require any fancy graphics chipset nor does it need an amazing cpu architecture, so it's certainly no surprise peecees are the way they are.

Originally Posted by meynaf

Then take the sources, and...

I've been thinking about it, but it's a lot of work, so I don't know...

Originally Posted by meynaf

I won't do a prefs window with only ONE pref, and a config file would disallow changing it on the fly while editing.

If there are no other prefs, then that would indeed be pointless. Perhaps you could add an icon that allows toggling the option on/off? Or you could press a key to toggle it.

Originally Posted by meynaf

Maybe not so hard. But I use conditional assembly, too. And some kind of formulas in parameters.

Okay, that's clear.

Originally Posted by meynaf

I have higher needs than that. Macros are essential when you have some puzzles requiring several specific actuators per cell.

Good point, but it still doesn't seem unsolvable. I'm still trying to come up with something good, but doing so without making compromises is perhaps a little more difficult than I thought (things are usually a little harder than I initially anticipate).

Originally Posted by meynaf

But Csbwin wouldn't support my dungeons. Besides, its extensions are made IMO in a pretty dirty way.

Well, that sucks then Perhaps it really is time for someone to do a much better Amiga/peecee version from scratch (yes, for both platforms, and both 100% compatible with each other).

Originally Posted by meynaf

I like this kind of report. Please tell me more whenever you can.

Haven't played for a while now (my Amiga is still dead as you know).

Originally Posted by meynaf

Well, I have to make some testing of graphics.library/BestModeIDA(). For now I've never used it.

Have you managed to get something useful working now?

Originally Posted by meynaf

Pixels with large errors will rarely be palette pixels, so this is less important than it looks (didn't I already say something like that ?).

Yep, you sure did However, I still think that when everything works as well as it could possibly get that you'd get better results on average, it's just a hunch, though, and your explanation makes sense.

Originally Posted by meynaf

2/3/1 is the closest approximation, and it's quicker to compute than 3/4/2.

Okay, I've looked at the jpeg source code you told me about. Those 2/3/1 weights are an approximation of the NTSC gray scale formula. I don't see how gray scale weights are the best for HAM rendering (they're probably not). Perhaps you can show me some images where this does actually matter.

From the jpeg source:

* The 2/3/1 scale factors used here correspond loosely to the relative
* weights of the colors in the NTSC grayscale equation.

Originally Posted by meynaf

There is little you can do. I even tried some sort of dithering, but it ended up showing ugly artifacts and I dropped the idea (which was too slow anyway).

Yeah, dithering would make things too slow, good dithering isn't cheap.

Originally Posted by meynaf

You can only use this data to choose the palette, and this requires a pre-scan of the image.

Perhaps that's all you can use it for, I certainly don't have any definitive answers.

Originally Posted by meynaf

I find it funny to see you stumble on several ideas I've had before...

How typical...

Originally Posted by meynaf

but alas I found out this one couldn't be done without sacrificing quality or using a 18-bit table. You could be luckier than I was, but I doubt.

You know whats bothering me the most? I keep getting very close to your renderer's quality level, but there's always something wrong with the rendering. It's really frustrating (it's better than that quick renderer I was doing, but it's not good enough).

Originally Posted by meynaf

Auto-increment has same speed as non auto increment.

I thought it was a little slower. How strange...

meynaf, you can save 100+ cycles per scan line by starting each line with a palette write. Doesn't help much, I know, but because this probably happens anyway it's still something

To everyone who reads this thread:

Does anyone have any good ideas to do fast, quality ham rendering? PeterK already provided a nice speed optimization, now a nice quality boost without much speed loss is needed.

Any help and suggestions are appreciated

[meynaf]

Originally Posted by Thorham

Sure, I can disassemble it, but can't you say what it does exactly?

It just tests weird cases where different cpus will behave differently. Also contains a few pitfalls for emulators.

Originally Posted by Thorham

Absolutely. But that just means bugs happen, not that they can't all be removed (that's difficult, but not impossible).

Yes, but you never know if all of them have been removed !

Originally Posted by Thorham

Ah, so they didn't write it in assembler, eh? I wonder why not?

Most code in the world isn't written in assembler. You could ask their writers why they didn't use asm

Originally Posted by Thorham

Only when the dungeon is finished. I don't want to have to start over each time you add things

This is taking as granted that you can actually finish it and I believe you can't

Originally Posted by Thorham

Boring business software doesn't require any fancy graphics chipset nor does it need an amazing cpu architecture, so it's certainly no surprise peecees are the way they are.

The surprise is that everything else died...

Originally Posted by Thorham

I've been thinking about it, but it's a lot of work, so I don't know...

Yes, I know it's some work...

Originally Posted by Thorham

If there are no other prefs, then that would indeed be pointless. Perhaps you could add an icon that allows toggling the option on/off? Or you could press a key to toggle it.

Yes, this is a good idea. I'll see how I can do it (probably with a key).

Originally Posted by Thorham

Good point, but it still doesn't seem unsolvable. I'm still trying to come up with something good, but doing so without making compromises is perhaps a little more difficult than I thought (things are usually a little harder than I initially anticipate).

Yes, things are harder than your initial evaluation. Good think you know it

Originally Posted by Thorham

Well, that sucks then Perhaps it really is time for someone to do a much better Amiga/peecee version from scratch (yes, for both platforms, and both 100% compatible with each other).

I'm afraid that if you don't do it, no-one will.
But original dungeon format can work with both my code and csbwin.

Originally Posted by Thorham

Haven't played for a while now (my Amiga is still dead as you know).

Didn't you order a new one ?

Originally Posted by Thorham

Have you managed to get something useful working now?

No. I fact I haven't tried yet

Originally Posted by Thorham

Yep, you sure did However, I still think that when everything works as well as it could possibly get that you'd get better results on average, it's just a hunch, though, and your explanation makes sense.

This could still raise the quality, but probably not worth the extra cycles (there will be some, right ?).

Originally Posted by Thorham

Okay, I've looked at the jpeg source code you told me about. Those 2/3/1 weights are an approximation of the NTSC gray scale formula. I don't see how gray scale weights are the best for HAM rendering (they're probably not). Perhaps you can show me some images where this does actually matter.

From the jpeg source:

* The 2/3/1 scale factors used here correspond loosely to the relative
* weights of the colors in the NTSC grayscale equation.

Grey scale computation is about visual lightness, that is, visual sensitivity of the eye. I don't need a picture to show you this, just play with RGB sliders in a paint program and you'll see.

Originally Posted by Thorham

You know whats bothering me the most? I keep getting very close to your renderer's quality level, but there's always something wrong with the rendering. It's really frustrating (it's better than that quick renderer I was doing, but it's not good enough).

Yes, I understand it can be frustrating.

Originally Posted by Thorham

I thought it was a little slower. How strange...

This was true for 68000 (I think).

Originally Posted by Thorham

meynaf, you can save 100+ cycles per scan line by starting each line with a palette write. Doesn't help much, I know, but because this probably happens anyway it's still something

Even the leftmost pixel can be much better with ham pixels.

[Thorham]

Originally Posted by meynaf

It just tests weird cases where different cpus will behave differently. Also contains a few pitfalls for emulators.

What kind of weird cases?

Originally Posted by meynaf

Yes, but you never know if all of them have been removed !

Depends on how you debug your program. It's only really a problem for situations where there are many cases to check. If you only have a limited set of cases for each routine, then you can be certain all bugs can be removed.

Originally Posted by meynaf

Most code in the world isn't written in assembler. You could ask their writers why they didn't use asm

That's true enough, and I think we all know the reason

Originally Posted by meynaf

This is taking as granted that you can actually finish it and I believe you can't

Isn't it supposed to be a normal dungeon? I can understand why you would think this for my solo nightmare dungeon attempt, but a normal dungeon?

Originally Posted by meynaf

The surprise is that everything else died...

Other platforms probably just screwed up, that's all, really.

Originally Posted by meynaf

Yes, I know it's some work...

Some eh? Okay, the engine isn't too hard, not even when you take in account CSBWin and RTC. But then you basically have your own unique engine (which is actually a good thing), and you'd need some sort of dungeon converter, and that's the problem.

Originally Posted by meynaf

Yes, this is a good idea. I'll see how I can do it (probably with a key).

But don't make it a key combo

Originally Posted by meynaf

Yes, things are harder than your initial evaluation. Good think you know it

Back in the day a friend of mine once made me aware of this.

Originally Posted by meynaf

I'm afraid that if you don't do it, no-one will.

I'm afraid so, too.

Originally Posted by meynaf

But original dungeon format can work with both my code and csbwin.

True, but people still want to have more editing features than the original format allows. It's the different formats that are the problem here.

Originally Posted by meynaf

Didn't you order a new one ?

No, I didn't

Originally Posted by meynaf

No. I fact I haven't tried yet

It's the right way to do it, because all users with custom planar screen setups will get best fit.

Originally Posted by meynaf

This could still raise the quality, but probably not worth the extra cycles (there will be some, right ?).

There wouldn't be extra cycles because it's part of the color picker table. Only calculating the table will be slower, and maybe you would need a different compression method for the table.

Originally Posted by meynaf

Grey scale computation is about visual lightness, that is, visual sensitivity of the eye. I don't need a picture to show you this, just play with RGB sliders in a paint program and you'll see.

But using gray means you mostly select for detail and sacrifice color quality while you want to preserve both as much as possible. I'm not saying 3/4/2 is best for this, but it's better at preserving color quality than 2/3/1 while there doesn't seem to be much detail loss. Perhaps you should try it.

Originally Posted by meynaf

Yes, I understand it can be frustrating.

Originally Posted by meynaf

This was true for 68000 (I think).

Thought I read it in the docs for some reason.

Originally Posted by meynaf

Even the leftmost pixel can be much better with ham pixels.

True, but if you set a color with the copper, you would get the best match, and it would save those few cycles

[meynaf]

Originally Posted by Thorham

What kind of weird cases?

Well, for an example, what do you get in the CCR after a divide by zero ?

Originally Posted by Thorham

Depends on how you debug your program. It's only really a problem for situations where there are many cases to check. If you only have a limited set of cases for each routine, then you can be certain all bugs can be removed.

Apart for a hello world, you'll never find the case. Else there are always many cases to check.

Originally Posted by Thorham

Isn't it supposed to be a normal dungeon? I can understand why you would think this for my solo nightmare dungeon attempt, but a normal dungeon?

This isn't "normal" dungeon. This is "less difficult", which doesn't mean "easy". In other words, instead of being killed very early, you can get far in it, but still not finish it (I think).
Anyway I'm not about to touch it soon, so you can start it without worrying.

Originally Posted by Thorham

Some eh? Okay, the engine isn't too hard, not even when you take in account CSBWin and RTC. But then you basically have your own unique engine (which is actually a good thing), and you'd need some sort of dungeon converter, and that's the problem.

If your only fear is the dungeon converter, I will do it !
(But, of course, you must make the engine first...)

Originally Posted by Thorham

But don't make it a key combo

Well, now you can press savagely on * key to activate the repeat mode you asked for (note this isn't a key combo ).

As a bonus, you have a "MOD" indication shown whenever the file has been modified and not saved (things like that were badly missing).

Archive has been updated but this time it is on my site :
meynaf.free.fr/tmp/dm-tools.lzx
English version is provided so you will not have to re-translate it

Side note : I now remember another reason why I initially chose to do otherwise - to avoid blinking things due to constant display refresh as long as a button is pressed...
But don't worry about this, it won't happen.

Originally Posted by Thorham

Back in the day a friend of mine once made me aware of this.

First law of computing : things are always tougher than expected (and take longer, and cost more...).

Originally Posted by Thorham

True, but people still want to have more editing features than the original format allows. It's the different formats that are the problem here.

Sorry. Dungeons aren't standardized

Originally Posted by Thorham

No, I didn't

Will you, one day ?

Originally Posted by Thorham

It's the right way to do it, because all users with custom planar screen setups will get best fit.

Here you take as granted it will really give the best fit. But it isn't the case. In fact it is taking more risk.

I only have PAL monitor driver, yet my first few tests (yes I've finally made some ) have shown cases where the suggested mode isn't the wished one (suggested one is logical, ok, but it's not what I wanted).
For example, imagine you want a lowres screen that's larger than the view. Well, you simply can not do that with this method, which makes V's switches lowres and highres useless, and, even worse, prevent one of the OS bug workaround to work !

And is it really worth ? Mode promotion for dblpal works "as is", and very few monitors support highgfx - which means very few users, too.

Originally Posted by Thorham

There wouldn't be extra cycles because it's part of the color picker table. Only calculating the table will be slower, and maybe you would need a different compression method for the table.

I think it's better to remain consistent. If you have a better visually, but computationnally non-obvious color, it might end up never chosen because the renderer sees a high error level for it and outputs a ham pixel instead.
Do you see what I mean ?

Originally Posted by Thorham

But using gray means you mostly select for detail and sacrifice color quality while you want to preserve both as much as possible. I'm not saying 3/4/2 is best for this, but it's better at preserving color quality than 2/3/1 while there doesn't seem to be much detail loss. Perhaps you should try it.

The eye is more sensitive to details than to colors.

Anyway I've tried it, and I didn't see better colors at all. In fact what I saw was awful color details in frontiers between areas with very different colors (sometimes with rows of obviously wrong green or blue pixels).
If you think I've made it wrong or checked "special case" images, then give me your code and images.
But for me there is nothing better with this method. No, it's NOT better at preserving colors, in fact it's even worse. The errors are especially visible on texts.

Originally Posted by Thorham

Thought I read it in the docs for some reason.

Strange, looking in the manual I see this isn't even true for 68000...
If you read it in the docs, what did you read and where ?

Originally Posted by Thorham

True, but if you set a color with the copper, you would get the best match, and it would save those few cycles

And the time you take to setup your copper list will eat the cycles (chipmem writes...), not to mention it's not easy as we're in an Intuition screen, and that it would totally prevent correct screen grabbing. All that, for just a few cycles and a minimalistic quality gain. Please think twice

[Thorham]

Originally Posted by meynaf

Well, for an example, what do you get in the CCR after a divide by zero ?

Shouldn't you get the same result on all cpus?

Originally Posted by meynaf

Apart for a hello world, you'll never find the case. Else there are always many cases to check.

That's not the case. Here's an example. In my old kernel I have a simple memory allocation system. Now look at the FreeMem cases:

- A freed block connects to the start of another mem block.
- A freed block connects to the end of another mem block.
- A freed block connects to the start and the end of two other mem blocks.
- A freed block doesn't connect to any other mem blocks.

After that the memory has to be added to the FreeMemList:

- Two entries are merged into one (freed block connects to two other blocks).
- One entry is changed (freed block connects to one other block).
- A new entry has to be added (freed block doesn't connect to other blocks).

This last case has a few cases of it's own:

- The new entry can just be added because there is room in the list.
- The new entry can't be added yet because the list is full, the list can be expanded.
- The new entry can't be added yet because the list is full, the list can't be expanded (out of memory). Now safety list space is used to allow the list to be expanded anyway.

As you can see the number of cases is very limited, and this is for real code, not theoretical code.

Originally Posted by meynaf

This isn't "normal" dungeon. This is "less difficult", which doesn't mean "easy". In other words, instead of being killed very early, you can get far in it, but still not finish it (I think).
Anyway I'm not about to touch it soon, so you can start it without worrying.

Ah, I see, I just thought it was a normal dungeon. I'll check it out again.

Originally Posted by meynaf

If your only fear is the dungeon converter, I will do it !
(But, of course, you must make the engine first...)

I'll think about it.

Originally Posted by meynaf

Well, now you can press savagely on * key to activate the repeat mode you asked for (note this isn't a key combo ).

As a bonus, you have a "MOD" indication shown whenever the file has been modified and not saved (things like that were badly missing).

Archive has been updated but this time it is on my site :
meynaf.free.fr/tmp/dm-tools.lzx
English version is provided so you will not have to re-translate it

Cool, thanks

Originally Posted by meynaf

First law of computing : things are always tougher than expected (and take longer, and cost more...).

How true

Originally Posted by meynaf

Sorry. Dungeons aren't standardized

Nope, and it's a damned shame

Originally Posted by meynaf

Will you, one day ?

It's only because I'm strapped for cash right now. I've been made a good offer on the board, but I have to wait a little longer to get the money.

Originally Posted by meynaf

Here you take as granted it will really give the best fit. But it isn't the case. In fact it is taking more risk.

Really?

Originally Posted by meynaf

I only have PAL monitor driver, yet my first few tests (yes I've finally made some ) have shown cases where the suggested mode isn't the wished one (suggested one is logical, ok, but it's not what I wanted).
For example, imagine you want a lowres screen that's larger than the view. Well, you simply can not do that with this method, which makes V's switches lowres and highres useless, and, even worse, prevent one of the OS bug workaround to work !

Then some sort of method must be thought up for this work more properly.

Originally Posted by meynaf

And is it really worth ? Mode promotion for dblpal works "as is", and very few monitors support highgfx - which means very few users, too.

It is for people who use highgfx

Originally Posted by meynaf

I think it's better to remain consistent. If you have a better visually, but computationnally non-obvious color, it might end up never chosen because the renderer sees a high error level for it and outputs a ham pixel instead.
Do you see what I mean ?

Yes, I do

Originally Posted by meynaf

The eye is more sensitive to details than to colors.

Yes, I know this. A good example of when this is very obvious is when you look at things at very low light levels (night vision): You see in black and white or only get a very vague impression of color.

Originally Posted by meynaf

Anyway I've tried it, and I didn't see better colors at all. In fact what I saw was awful color details in frontiers between areas with very different colors (sometimes with rows of obviously wrong green or blue pixels).
If you think I've made it wrong or checked "special case" images, then give me your code and images.
But for me there is nothing better with this method. No, it's NOT better at preserving colors, in fact it's even worse. The errors are especially visible on texts.

Could you show me the text render please? Anyway, I think you've made a mistake in your code, because I've checked this with your renderer as well. What I've done is use an older version (with the bug corrected) because it's simpler to modify. Here it is:

; transforme 1 ligne r,g,b en ham8 (chunky)
; a0=srcbuf, a1=dest, d7=nb pixels

 ifnd round
round equ 0
 endc
 ifnd quick
quick equ 0
 endc

 ifd halve
 ifne halve
 fail				; scaling not supported in this version
 endc
 endc

 mc68030


 ifeq quick
; méthode normale

; d0 = tmp
; d1-d3 = set 1
; d4-d6 = set 2
; d7 = boucle
; a0 = src
; a1 = dest
; a2-a4 = save d1-d3
; a5 = table
; a6 = palette
ze_renderham8
 suba.l a2,a2			; an regs +rapides que pile
 suba.l a3,a3			; (ceci est le pixel précédent)
 suba.l a4,a4			; (1er à gauche = couleur 0, donc noir)

 ifeq round				; round=0 ou scale=1
 moveq #0,d1			; high reste à 0 tout le long
 moveq #0,d2
 moveq #0,d3
 endc

 move.l #zv_h8tab,a5
 subq.w #1,d7			; dbf + rapide que subq/bcc
.loop

 ifne round
 moveq #2,d1
 moveq #2,d2
 moveq #2,d3
 add.b (a0)+,d1
 subx.b d4,d4			; 00 si ok, FF si ça dépasse
 or.b d4,d1				; inchangé si ok, FF si ça dépasse
 add.b (a0)+,d2
 subx.b d4,d4
 or.b d4,d2
 add.b (a0)+,d3
 subx.b d4,d4
 or.b d4,d3
 else					; round=0
; pas d'arrondi, on coupe juste
 move.b (a0)+,d1
 move.b (a0)+,d2
 move.b (a0)+,d3
 endc

 moveq #-4,d4			; fc
 and.b d4,d1
 and.b d4,d2
 and.b d4,d3

 move.l d1,d4			; rrrr....
 lsl.l #4,d4			; rrrr....0000
 move.b d2,d4			; rrrrvvvv....
 lsl.l #4,d4			; rrrrvvvv....0000
 move.b d3,d4			; rrrrvvvvbbbb....
 lsr.l #4,d4			; rrrrvvvvbbbb
 move.l (a5,d4.l*4),a6

 move.l d1,d0
 sub.b (a6)+,d0
 bcc.s .n0
 neg.b d0
.n0
 move.l d2,d5
 sub.b (a6)+,d5
 bcc.s .n1
 neg.b d5
.n1

 move.l d3,d6
 sub.b (a6)+,d6
 bcc.s .n2
 neg.b d6
.n2
	move.l	d0,d4	;Save Red.
	add.l	d5,d0	;Red+Green.
	add.l	d5,d0	;Red+2xGreen.
	add.l	d6,d0	;Red+2xGreen+Blue.
	add.l	d0,d0	;2xRed+4xGreen+2xBlue.
	add.l	d4,d0	;3xRed+4xGreen+2xBlue.

; add.l d5,d0			; r+v
; add.l d0,d0			; (r+v)*2 = 2r+2v
; add.l d5,d0			; 2r+3v
; add.l d6,d0			; 2r+3v+1b

 move.l d1,d4
 sub.l a2,d4
 bpl.s .n3
 neg.l d4
.n3
; add.l d4,d4			; r *2

	move.l	d4,d5	;3xRed.
	add.l	d4,d4
	add.l	d5,d4

 move.l d2,d5
 sub.l a3,d5
 bpl.s .n4
 neg.l d5
.n4
; move.l d5,d6
; add.l d5,d5
; add.l d6,d5			; v *3

	lsl.l	#2,d5	;4xGreen.

 move.l d3,d6
 sub.l a4,d6
 bpl.s .n5
 neg.l d6
.n5						; b *1
	add.l	d6,d6	;2xBlue

 add.l d4,d5			; d4=r d5=r+v d6=b
 add.l d6,d4			; r+b r+v b
 add.l d6,d6			; r+b r+v 2b
 add.l d5,d6			; r+b r+v 2b+r+v
 beq.s .vbrb			; all together = 0 -> gbrb
 sub.l d4,d6			; r+b r+v v+b

; d6=r d5=b d4=v d0=f
 cmp.l d4,d6
 bls.s .br
 cmp.l d4,d5
 bls.s .bx
 cmp.l d4,d0
 bls.s .fi
.ve
 move.l d2,a3
 addq.b #3,d2
 move.b d2,(a1)+
 dbf d7,.loop
 rts
.br
 cmp.l d6,d5
 bls.s .bx
 cmp.l d6,d0
 bls.s .fi
.ro
 move.l d1,a2
 addq.b #2,d1
 move.b d1,(a1)+
 dbf d7,.loop
 rts
.bx
 cmp.l d5,d0
 bls.s .fi
.bl
 move.l d3,a4
 addq.b #1,d3
 move.b d3,(a1)+
 dbf d7,.loop
 rts
.fi
 move.b (a6),(a1)+
 move.b -(a6),d3
 move.b -(a6),d2
 move.b -(a6),d1
 move.l d1,a2
 move.l d2,a3
 move.l d3,a4
 dbf d7,.loop
 rts
.vbrb
 btst #0,d7				; 0,2 -> b
 beq.s .bl
 btst #1,d7				; 1 -> r
 beq.s .ro
 bra.s .ve				; 3 -> v	(3210->vbrb)

; initialisation de la table
ze_ham8init
 lea zv_h8tab,a1
 lea zv_zz1(pc),a2
 lea zv_zz2(pc),a3
 lea 4096*4(a1),a4
 moveq #0,d2
.re1
 move.b (a3)+,d3
 moveq #15,d4
 and.b d3,d4			; d4=low
 lsr.b #4,d3			; d3=high
 bra.s .euh
.re2
 tst.b d4
 bmi.s .re1
 move.b d4,d3
 st d4
.euh
 move.b (a2)+,d2		; valeur à poser
 bclr #7,d2
 beq.s .n7
 addi.b #$20,d3
.n7
 bclr #6,d2
 beq.s .n6
 addi.b #$10,d3
.n6
 lea zv_pal32,a6
 add.b d2,d2			; max 63 -> max 126
 add.b d2,d2			; -> max 254
 add.l d2,a6
.re3
 move.l a6,(a1)+
 subq.b #1,d3			; comme dbf, mais high(d3) pas modifié
 bcc.s .re3
 cmpa.l a4,a1
 blo.s .re2
; suite : palette modifiée
 lea zv_h8pal(pc),a0
 lea zv_pal32,a1
 moveq #0,d7
.loop
 move.b (a0)+,(a1)+
 move.b (a0)+,(a1)+
 move.b (a0)+,(a1)+
 move.b d7,(a1)+
 addq.b #4,d7
 bne.s .loop
 rts


; données pour la table
zv_zz1 incbin scrconv/zz1.dat
zv_zz2 incbin scrconv/zz2.dat
 even

; palette
zv_h8pal			; ma palette pour ham
 include scrconv/pal.i

; la méthode est rapide, par contre on dépense 16k de ram (pas énorme qd même)
 bss
zv_pal32 ds.l 64		; palette 4-bytes (4e=index*4)
zv_h8tab ds.l 4096	; indique index couleur +proche pour chaque 12-bit rvb
 code			; pour que l'appelant s'y retrouve


 else
; méthode rapide à palette fixe

ze_renderham8
 suba.l a2,a2			; an regs +rapides que pile
 suba.l a3,a3			; (ceci est le pixel précédent)
 suba.l a4,a4			; (1er à gauche = couleur 0, donc noir)
 moveq #0,d1			; high reste à 0 tout le long
 moveq #0,d2
 moveq #0,d3
.loop
 move.b (a0)+,d1
 move.b (a0)+,d2
 move.b (a0)+,d3
; diff d'avec pixel fixe (and c0 sur 3 composantes -> 64 cols)
 moveq #$3f,d0
 and.l d1,d0
 moveq #$3f,d5
 and.l d2,d5
 moveq #$3f,d6
 and.l d3,d6
 add.l d5,d0			; r+v
 add.l d0,d0			; (r+v)*2 = 2r+2v
 add.l d5,d0			; 2r+3v
 add.l d6,d0			; 2r+3v+1b
; trouver l'erreur sur chaque composante, d'avec le précédent
 move.l d1,d4
 sub.l a2,d4			; sur un 030, .l + rapide que .w pour An
 bpl.s .n3			; (not taken : 4, taken : 6)
 neg.l d4			; val abs de la diff
.n3
 move.l d2,d5
 sub.l a3,d5
 bpl.s .n4
 neg.l d5
.n4
 move.l d3,d6
 sub.l a4,d6
 bpl.s .n5
 neg.l d6
.n5
; pondérer les valeurs pour comparaisons
; ça se complique un peu parce qu'on n'a plus que d4-d6/a5 de libre
 add.l d4,d4			; rouge *2
 move.l d5,a5
 add.l d5,d5
 add.l a5,d5			; vert *3 (et bleu *1)

; pour chaque composante, additionner l'erreur sur les deux autres
; je fais d6=d5+d6, a5=d4+d6 et d4=d4+d5
 move.l d4,a5
 add.l d6,a5			; vert
 add.l d5,d6			; rouge (plus besoin de d6)
 add.l d5,d4			; bleu (plus besoin de d4-d5)

; prendre la solution qui a l'erreur la + faible
; (depuis d0=fixe, a5=rouge, d6=vert, d4=bleu)
 cmp.l a5,d6			; 3 cmp avec vert
 bls.s .br
 cmp.l a5,d4
 bls.s .bx
 cmp.l a5,d0
 bls.s .fi
; fallthru : .ve
 moveq #-4,d0			; fc
 and.l d0,d2
 move.l d2,a3
 addq.b #3,d2
 move.b d2,(a1)+
 subq.w #1,d7
 bne .loop
 rts
.br				; choix bleu/rouge
 cmp.l d6,d4
 bls.s .bx
 cmp.l d6,d0
 bls.s .fi
; fallthru : .ro
 moveq #-4,d0			; fc
 and.l d0,d1
 move.l d1,a2
 addq.b #2,d1
 move.b d1,(a1)+
 subq.w #1,d7
 bne .loop
 rts
.bx
 cmp.l d4,d0
 bls.s .fi
; fallthru : .bl
 moveq #-4,d0			; fc
 and.l d0,d3
 move.l d3,a4
 addq.b #1,d3
 move.b d3,(a1)+
 subq.w #1,d7
 bne .loop
 rts
.fi				; fixe, c'est le cas le +rare
 moveq #-$40,d0			; c0
 and.b d0,d1
 and.b d0,d2
 and.b d0,d3
 move.l d1,a2			; pixel précédent
 move.l d2,a3
 move.l d3,a4
 lsr.b #2,d2
 lsr.b #4,d3
 or.b d2,d1
 or.b d3,d1
 move.b d1,(a1)+
 subq.w #1,d7
 bne .loop
ze_ham8init			; pas besoin
 rts

; palette, arrondie à 3*2 bits rvb
zv_h8pal
 dc.b $00,$00,$00
 dc.b $00,$00,$40
 dc.b $00,$00,$80
 dc.b $00,$00,$c0
 dc.b $00,$40,$00
 dc.b $00,$40,$40
 dc.b $00,$40,$80
 dc.b $00,$40,$c0
 dc.b $00,$80,$00
 dc.b $00,$80,$40
 dc.b $00,$80,$80
 dc.b $00,$80,$c0
 dc.b $00,$c0,$00
 dc.b $00,$c0,$40
 dc.b $00,$c0,$80
 dc.b $00,$c0,$c0
 dc.b $40,$00,$00
 dc.b $40,$00,$40
 dc.b $40,$00,$80
 dc.b $40,$00,$c0
 dc.b $40,$40,$00
 dc.b $40,$40,$40
 dc.b $40,$40,$80
 dc.b $40,$40,$c0
 dc.b $40,$80,$00
 dc.b $40,$80,$40
 dc.b $40,$80,$80
 dc.b $40,$80,$c0
 dc.b $40,$c0,$00
 dc.b $40,$c0,$40
 dc.b $40,$c0,$80
 dc.b $40,$c0,$c0
 dc.b $80,$00,$00
 dc.b $80,$00,$40
 dc.b $80,$00,$80
 dc.b $80,$00,$c0
 dc.b $80,$40,$00
 dc.b $80,$40,$40
 dc.b $80,$40,$80
 dc.b $80,$40,$c0
 dc.b $80,$80,$00
 dc.b $80,$80,$40
 dc.b $80,$80,$80
 dc.b $80,$80,$c0
 dc.b $80,$c0,$00
 dc.b $80,$c0,$40
 dc.b $80,$c0,$80
 dc.b $80,$c0,$c0
 dc.b $c0,$00,$00
 dc.b $c0,$00,$40
 dc.b $c0,$00,$80
 dc.b $c0,$00,$c0
 dc.b $c0,$40,$00
 dc.b $c0,$40,$40
 dc.b $c0,$40,$80
 dc.b $c0,$40,$c0
 dc.b $c0,$80,$00
 dc.b $c0,$80,$40
 dc.b $c0,$80,$80
 dc.b $c0,$80,$c0
 dc.b $c0,$c0,$00
 dc.b $c0,$c0,$40
 dc.b $c0,$c0,$80
 dc.b $c0,$c0,$c0
 endc

This versions program flow is simpler than your current, more optimized version (this one still contains the quick rendering code, but that's not used here). This modification should render images, including text (I've tried this) properly. Really, changing weights from 2/3/1 to 3/4/2 shouldn't cause such big differences in quality. Also, even my quick renderer (with 3/4/2) renders text properly (almost as good as your quality renderer), so if you get a steep drop in quality, then you probably made a mistake somewhere (which is easy seeing how much more complex your current version is than the previous version).

Actually, the original and the 3/4/2 version produce very similar results (I've had better results with my quick renderer, probably because I use a different, also non even, palette). The differences are most visible with the 4096 color image I showed you (the original).

I think I'm going to leave fast, good rendering alone for a little while, and try my hand at setting 64 colors per four scan lines, and use that as a palette. Don't know how to do it yet, but if done properly it should provide a great quality boost (my quick renderer produces better results with an image specific palette already) at the cost of speed (but that doesn't matter. I want an Aga HamLab like program that cares only about quality).

Originally Posted by meynaf

Strange, looking in the manual I see this isn't even true for 68000...
If you read it in the docs, what did you read and where ?

I probably just miss read it

Originally Posted by meynaf

And the time you take to setup your copper list will eat the cycles (chipmem writes...), not to mention it's not easy as we're in an Intuition screen, and that it would totally prevent correct screen grabbing. All that, for just a few cycles and a minimalistic quality gain. Please think twice

All too true, I was just trying to be a smart ass

[meynaf]

Originally Posted by Thorham

Shouldn't you get the same result on all cpus?

When you divide by zero, there is no result

Originally Posted by Thorham

That's not the case. Here's an example. In my old kernel I have a simple memory allocation system. Now look at the FreeMem cases:

- A freed block connects to the start of another mem block.
- A freed block connects to the end of another mem block.
- A freed block connects to the start and the end of two other mem blocks.
- A freed block doesn't connect to any other mem blocks.

After that the memory has to be added to the FreeMemList:

- Two entries are merged into one (freed block connects to two other blocks).
- One entry is changed (freed block connects to one other block).
- A new entry has to be added (freed block doesn't connect to other blocks).

This last case has a few cases of it's own:

- The new entry can just be added because there is room in the list.
- The new entry can't be added yet because the list is full, the list can be expanded.
- The new entry can't be added yet because the list is full, the list can't be expanded (out of memory). Now safety list space is used to allow the list to be expanded anyway.

As you can see the number of cases is very limited, and this is for real code, not theoretical code.

The number of cases you could think of was very limited, which isn't the real number of cases, so far not. You could still crash if the size of a block is 0, or if it is odd, for example. Or perhaps you're reading an uninitialized value somewhere, which worked anyway (by accident) in your "complete" tests. You never know what you've missed (else you wouldn't have missed it !).

Originally Posted by Thorham

Ah, I see, I just thought it was a normal dungeon. I'll check it out again.

So, can you finish it ?

Originally Posted by Thorham

Nope, and it's a damned shame

Surely, but it's (too often) the price for new features.

Originally Posted by Thorham

It's only because I'm strapped for cash right now. I've been made a good offer on the board, but I have to wait a little longer to get the money.

You appear to be waiting for quite a long time already

Originally Posted by Thorham

Really?

Really.

Originally Posted by Thorham

Then some sort of method must be thought up for this work more properly.

But as long as you can't check everyone's configuration, this is taking more risk, as I said.

Originally Posted by Thorham

It is for people who use highgfx

That's very few people

Originally Posted by Thorham

Yes, I know this. A good example of when this is very obvious is when you look at things at very low light levels (night vision): You see in black and white or only get a very vague impression of color.

And you knew it. No excuse

Originally Posted by Thorham

Could you show me the text render please? Anyway, I think you've made a mistake in your code, because I've checked this with your renderer as well. What I've done is use an older version (with the bug corrected) because it's simpler to modify. Here it is:
(...)
This versions program flow is simpler than your current, more optimized version (this one still contains the quick rendering code, but that's not used here). This modification should render images, including text (I've tried this) properly. Really, changing weights from 2/3/1 to 3/4/2 shouldn't cause such big differences in quality. Also, even my quick renderer (with 3/4/2) renders text properly (almost as good as your quality renderer), so if you get a steep drop in quality, then you probably made a mistake somewhere (which is easy seeing how much more complex your current version is than the previous version).

Whether this gives a steep drop in quality or not is irrelevant, as long as it doesn't give any improvement at all. Prove there are good cases, then we'll see for the bad ones.

Originally Posted by Thorham

Actually, the original and the 3/4/2 version produce very similar results (I've had better results with my quick renderer, probably because I use a different, also non even, palette). The differences are most visible with the 4096 color image I showed you (the original).

If results are similar, then it's probably not worth the extra cycles, right ?

Originally Posted by Thorham

I think I'm going to leave fast, good rendering alone for a little while, and try my hand at setting 64 colors per four scan lines, and use that as a palette. Don't know how to do it yet, but if done properly it should provide a great quality boost (my quick renderer produces better results with an image specific palette already) at the cost of speed (but that doesn't matter. I want an Aga HamLab like program that cares only about quality).

For my part I'll wait for the Natami to come out, and adapt my viewer for it. I don't think I'll touch the HAM any more.

[Thorham]

Originally Posted by meynaf

When you divide by zero, there is no result

No result, or an undefined result?

Originally Posted by meynaf

The number of cases you could think of was very limited, which isn't the real number of cases, so far not. You could still crash if the size of a block is 0, or if it is odd, for example. Or perhaps you're reading an uninitialized value somewhere, which worked anyway (by accident) in your "complete" tests. You never know what you've missed (else you wouldn't have missed it !).

It is the real number of cases. The size of a block can't be zero, because the allocation routine won't allocate zero length blocks. The routine can probably handle uneven block sizes, but it doesn't matter, because the allocation routines rounds all sizes up to the nearest multiple of eight. I've also checked all code paths that initialize the values, and all values that have to be set are always set. And besides, the routines don't produce the proper results with unitialized values. As a human, you can't guarantee 100% perfection, but it's still extremely unlikely that there's a bug in that code.

Originally Posted by meynaf

So, can you finish it ?

Haven't started a serious session yet.

Originally Posted by meynaf

Surely, but it's (too often) the price for new features.

Sad but true. It would've been a big help if at least everything was documented properly, but you can hardly blame people for not doing this.

Originally Posted by meynaf

You appear to be waiting for quite a long time already

Yeah, and I'm not happy about it. I'm between jobs at the moment, so I'm seriously low on cash for extras.

Originally Posted by meynaf

But as long as you can't check everyone's configuration, this is taking more risk, as I said.

Perhaps, there might still be a good method that works everywhere.

Originally Posted by meynaf

That's very few people

That's true.

Originally Posted by meynaf

Whether this gives a steep drop in quality or not is irrelevant, as long as it doesn't give any improvement at all. Prove there are good cases, then we'll see for the bad ones.

It is relevant if that steep drop was caused by a mistake, but it doesn't really matter, because...

Originally Posted by meynaf

If results are similar, then it's probably not worth the extra cycles, right ?

... in your render routine those two different weights don't make much of a difference. They matter more in my quick render routine and when you render without a palette. Probably the only way to really improve things is to do all these things:

1) Use a better algorithm to determine whether or not to write a palette pixel, and this will probably end up a lot slower.
2) Use a better color picker table (I somehow doubt that your table is 100% perfect for small errors, but my table isn't exactly perfect, either).
3) Use a better base palette (but which colors to pick?).

Although there's not an inch of doubt in my mind that things can be done better for fast rendering, right now I have no idea how to do it Tis a strange beasty that HAM it is

Originally Posted by meynaf

For my part I'll wait for the Natami to come out, and adapt my viewer for it. I don't think I'll touch the HAM any more.

Although Natami would be ridiculously cool, I'm only interested in it's original Amiga features, I don't care about things like 24 bit color, because I already have that on my peecee and don't need a Natami for that. One of the appealing aspects of the AGA chipset is trying to squeeze the most out of it.

[meynaf]

Originally Posted by Thorham

No result, or an undefined result?

Both

Originally Posted by Thorham

It is the real number of cases. The size of a block can't be zero, because the allocation routine won't allocate zero length blocks. The routine can probably handle uneven block sizes, but it doesn't matter, because the allocation routines rounds all sizes up to the nearest multiple of eight. I've also checked all code paths that initialize the values, and all values that have to be set are always set. And besides, the routines don't produce the proper results with unitialized values. As a human, you can't guarantee 100% perfection, but it's still extremely unlikely that there's a bug in that code.

Yes, it's unlikely, but not guaranteed. That's what I was saying.

Originally Posted by Thorham

Haven't started a serious session yet.

So, question is : when ?

Originally Posted by Thorham

Sad but true. It would've been a big help if at least everything was documented properly, but you can hardly blame people for not doing this.

Originally Posted by Thorham

Yeah, and I'm not happy about it. I'm between jobs at the moment, so I'm seriously low on cash for extras.

But this isn't an extra, is it ?

Originally Posted by Thorham

Perhaps, there might still be a good method that works everywhere.

If so, I don't know it.

Originally Posted by Thorham

It is relevant if that steep drop was caused by a mistake, but it doesn't really matter, because...

... in your render routine those two different weights don't make much of a difference. They matter more in my quick render routine and when you render without a palette.

One could say it doesn't matter because it's not better in any way

Originally Posted by Thorham

Probably the only way to really improve things is to do all these things:

1) Use a better algorithm to determine whether or not to write a palette pixel, and this will probably end up a lot slower.

This is more general than just a choice of palette pixel or not. It can be palette, red, green, or blue.

Originally Posted by Thorham

2) Use a better color picker table (I somehow doubt that your table is 100% perfect for small errors, but my table isn't exactly perfect, either).

It IS perfect for small errors, because colors in it are too different for any confusion in this area.
If you find a counter-example, tell me. It means that one color has nothing to do in here and can be replaced by another one !

Originally Posted by Thorham

3) Use a better base palette (but which colors to pick?).

Adapting the colors to the picture requires scanning it beforehand - and a damn smart method to do so, which I can't think of.

Originally Posted by Thorham

Although there's not an inch of doubt in my mind that things can be done better for fast rendering, right now I have no idea how to do it Tis a strange beasty that HAM it is

Strange. There is barely an inch of doubt in my mind that things can't (significantly) be done better at that speed

Originally Posted by Thorham

Although Natami would be ridiculously cool, I'm only interested in it's original Amiga features, I don't care about things like 24 bit color, because I already have that on my peecee and don't need a Natami for that. One of the appealing aspects of the AGA chipset is trying to squeeze the most out of it.

I'd still prefer true 24 bits

[Thorham]

Originally Posted by meynaf

Both

Well, you're supposed to use the trap anyway.

Originally Posted by meynaf

Yes, it's unlikely, but not guaranteed. That's what I was saying.

Okay, but depending on the routine in question, it can certainly be possible to know and test all cases. Your HAM renderer is a good example of where this is a lot more problematic, because it's a visually oriented routine, even though there aren't that many cases. The small bug doesn't seem to do much, until you correct it (you have to see it, after all, what are the right output values?), while in those system routines you already know what the output has to be. What I'm saying is that for those kinds of routines everything is much more defined.

Originally Posted by meynaf

So, question is : when ?

I'll try it on the newest WinUae beta today. The current version is much faster than the previous version on my old peecee (the version I was using is barely usable here), so there is a very good chance the game will run at the right speed. If so, I can start playing it before getting my A1200 mobo replacement.

Originally Posted by meynaf

But this isn't an extra, is it ?

Actually, when you're low on cash it is. Things like food and bills have to come first. Those things aren't a problem, but after that there's just not much left. Anyway, I can pay for the thing at the end of this month. I had a debt to pay off, and last month was the last term, so I have a little more extra money now.

Originally Posted by meynaf

If so, I don't know it.

Me neither (haven't given it any thought).

Originally Posted by meynaf

One could say it doesn't matter because it's not better in any way

It does matter, because you're trying something in the wrong way, and end up thinking it doesn't work for the wrong reason. That said, it's surprising that in your renderer it doesn't make much of a difference, while it does in mine.

Originally Posted by meynaf

This is more general than just a choice of palette pixel or not. It can be palette, red, green, or blue.

True, but it's part of it.

Originally Posted by meynaf

It IS perfect for small errors, because colors in it are too different for any confusion in this area.

Perhaps you're right, but I'm still going to check this (can't really hurt to try, can it?).

Originally Posted by meynaf

If you find a counter-example, tell me. It means that one color has nothing to do in here and can be replaced by another one !

I'll tell you for sure

Originally Posted by meynaf

Adapting the colors to the picture requires scanning it beforehand - and a damn smart method to do so, which I can't think of.

You don't need a really smart method. You already get better results by simply making a 64 color version of an image and then using that palette as a HAM base palette. Probably not an optimal solution, but it's already an improvement.

However, there is a better way. Now, this is by no means a complete idea, but it's a start:

When rendering a HAM image without a palette, you'll notice that many areas of the image look the way they're supposed to look, right? For those areas you don't need the palette, because the errors are very small. Basically, the color choosing algorithm limits choosing colors from the areas with larger errors, and it can then for those small areas test different color setups to determine which one will yield the smallest error. Of course, this isn't going to be very fast, but it should still be better than just using the 64 colors that best match the image generally. This method becomes especially useful if you set 64 colors per four scan lines.

You can start by limiting your color choices to the medium to large error areas, and just use a normal color selection algorithm on those areas, where you just ignore the low error areas. Because you don't have to do anything for those areas, you'll also speed up the routine.

This idea probably needs some refining, but it does seem like a good basis for a slower, higher quality rendering routine (especially when used with palette slicing).

By the way, can't you use a similar technique for determining when you really don't need to check the base palette in your renderer? For low error areas you don't need the palette anyway, so calculating the palette index and the deltas shouldn't really be necessary, should it? Could save a bunch of cycles. I think I'll implement this in my quick render routine. It's easy to add palette checking to that routine anyway.

Originally Posted by meynaf

Strange. There is barely an inch of doubt in my mind that things can't (significantly) be done better at that speed

Hmm, I don't know. There's always the chance that someone, somewhere, will invent a better method then what you came up with. But I must admit that it's mainly because of this reason that I think it can be improved.

Originally Posted by meynaf

I'd still prefer true 24 bits

Then buy a peecee, and you'll have all the 24bit you'll ever need No, seriously, where is the fun in that?

[meynaf]

Originally Posted by Thorham

Well, you're supposed to use the trap anyway.

Yes, but I find instructive to know the "undocumented" behaviour.

Originally Posted by Thorham

Okay, but depending on the routine in question, it can certainly be possible to know and test all cases. Your HAM renderer is a good example of where this is a lot more problematic, because it's a visually oriented routine, even though there aren't that many cases. The small bug doesn't seem to do much, until you correct it (you have to see it, after all, what are the right output values?), while in those system routines you already know what the output has to be. What I'm saying is that for those kinds of routines everything is much more defined.

Yes, but you can't think of everything that can happen in a program, even though it's less likely you've missed something on "easy" routines.

Originally Posted by Thorham

I'll try it on the newest WinUae beta today. The current version is much faster than the previous version on my old peecee (the version I was using is barely usable here), so there is a very good chance the game will run at the right speed. If so, I can start playing it before getting my A1200 mobo replacement.

Seeing that the post is a few days old now, I guess you tried ?

Originally Posted by Thorham

Actually, when you're low on cash it is. Things like food and bills have to come first. Those things aren't a problem, but after that there's just not much left. Anyway, I can pay for the thing at the end of this month. I had a debt to pay off, and last month was the last term, so I have a little more extra money now.

No, no, no. The miggy is an absolute necessity, over food

Originally Posted by Thorham

It does matter, because you're trying something in the wrong way, and end up thinking it doesn't work for the wrong reason. That said, it's surprising that in your renderer it doesn't make much of a difference, while it does in mine.

In theory it shouldn't make much of a difference even in your version.
Have you weighted your threshold to update it for 3/4/2 ? 2/3/1 leads to a total of 6, so if you didn't, you'll get a different result because 3/4/2 gives 33% bigger error values (hence you need a 33% bigger threshold).

Originally Posted by Thorham

True, but it's part of it.

Not really. There isn't a choice of palette vs ham. There are 4 types of pixels, of which 3 are computed together because it's easier - and quicker - this way.

Originally Posted by Thorham

Perhaps you're right, but I'm still going to check this (can't really hurt to try, can it?).

I'll tell you for sure

Yes, check it and tell me. But I don't think you will find something

Originally Posted by Thorham

You don't need a really smart method. You already get better results by simply making a 64 color version of an image and then using that palette as a HAM base palette. Probably not an optimal solution, but it's already an improvement.

However, there is a better way. Now, this is by no means a complete idea, but it's a start:

When rendering a HAM image without a palette, you'll notice that many areas of the image look the way they're supposed to look, right? For those areas you don't need the palette, because the errors are very small. Basically, the color choosing algorithm limits choosing colors from the areas with larger errors, and it can then for those small areas test different color setups to determine which one will yield the smallest error. Of course, this isn't going to be very fast, but it should still be better than just using the 64 colors that best match the image generally. This method becomes especially useful if you set 64 colors per four scan lines.

You can start by limiting your color choices to the medium to large error areas, and just use a normal color selection algorithm on those areas, where you just ignore the low error areas. Because you don't have to do anything for those areas, you'll also speed up the routine.

This idea probably needs some refining, but it does seem like a good basis for a slower, higher quality rendering routine (especially when used with palette slicing).

This looks interesting. Now let's see if you're able to draw some working code out of it

Originally Posted by Thorham

By the way, can't you use a similar technique for determining when you really don't need to check the base palette in your renderer? For low error areas you don't need the palette anyway, so calculating the palette index and the deltas shouldn't really be necessary, should it? Could save a bunch of cycles. I think I'll implement this in my quick render routine. It's easy to add palette checking to that routine anyway.

You're never sure a fixed pixel won't do better than the HAM one, unless you get an error value of zero. And in this case, the palette computation part is already skipped !

Originally Posted by Thorham

Hmm, I don't know. There's always the chance that someone, somewhere, will invent a better method then what you came up with. But I must admit that it's mainly because of this reason that I think it can be improved.

If so, this "someone, somewhere", has to tell me what he did

Originally Posted by Thorham

Then buy a peecee, and you'll have all the 24bit you'll ever need No, seriously, where is the fun in that?

Well, where's the fun in having AGA when you already had ECS ?

[Thorham]

Originally Posted by meynaf

Yes, but I find instructive to know the "undocumented" behaviour.

It's certainly interesting.

Originally Posted by meynaf

Yes, but you can't think of everything that can happen in a program, even though it's less likely you've missed something on "easy" routines.

Not necessarily easy, but straight forward and very predictable behavior. Routines like that are easy to get in a state where it's highly unlikely that there's a bug left.

Originally Posted by meynaf

Seeing that the post is a few days old now, I guess you tried ?

Yes, and it wasn't a lot of fun. The good news is that my new Pentium 3 runs WinUae better than my old one. The old ones main problem was the dying CPU fan, which caused breaks in the program execution when the load became high (it would start spinning faster, then you'd get the break, and then it would slow down again and this recently become worse). Which means I can start playing properly

Originally Posted by meynaf

No, no, no. The miggy is an absolute necessity, over food

Hahaha Actually, I'm getting my money this week, and I'm sending the money over for the mobo on the same day, so it's a done deal

Originally Posted by meynaf

In theory it shouldn't make much of a difference even in your version.

Well, it does. It's probably because my quick renderer sacrifices quality for speed.

Originally Posted by meynaf

Have you weighted your threshold to update it for 3/4/2 ? 2/3/1 leads to a total of 6, so if you didn't, you'll get a different result because 3/4/2 gives 33% bigger error values (hence you need a 33% bigger threshold).

Yes, I have. The base threshold is 64, so that simply has to be multiplied by the sum of all the weights.

Originally Posted by meynaf

Not really. There isn't a choice of palette vs ham. There are 4 types of pixels, of which 3 are computed together because it's easier - and quicker - this way.

Still doesn't mean that there isn't a better way to choose palette pixels. One thing is that your color picker is based on 12 bit color, which it of course has to, or the table would become too large. But I might be wrong

Originally Posted by meynaf

This looks interesting. Now let's see if you're able to draw some working code out of it

That shouldn't be to difficult. I'm probably going to do this in the weekend. I still have my new peecee to setup properly. I want to completely wipe my 160 gig hd, but it's filled with stuff that needs sorting out. A lot of it can be tossed, and some of it has to be backed up. It's going to take a while... It would be much better if I could just buy a new drive, but that's going to have to wait.

Originally Posted by meynaf

You're never sure a fixed pixel won't do better than the HAM one, unless you get an error value of zero. And in this case, the palette computation part is already skipped !

The problem here is perhaps that the error computation isn't optimal. The palette values will often not yield an error of zero, either, and low ham pixel errors are proabably completely invisible. Perhaps not interesting as a speed optimization in your renderer, but if it works, it will save a lot of cycles in the method I proposed for slower, better rendering, because you don't have to check the whole palette for each pixel in the image, so it's essential I use this if it works properly.

Originally Posted by meynaf

If so, this "someone, somewhere", has to tell me what he did

Hey, I'm just saying, that you can never be a 100% certain

Originally Posted by meynaf

Well, where's the fun in having AGA when you already had ECS ?

Good point, but for me HAM8 is the perfect balance between quality and having to puch things to get the best resaults. ECS HAM only works in lowres, and the bit depth is a little too low. Also, HAM6 and HAM8 are mostly the same, and a good HAM8 algorithm will probably work perfectly fine with HAM6.

Edit:

I'll most certainly be getting back into this HAM rendering business. My old monitor had become quite dark and when I tried my HAM diff program on my new monitor, it showed a whole world which was previously invisible Perhaps now that I can see what I'm doing, I can crack quality fast rendering (or maybe not ).

[meynaf]

Originally Posted by Thorham

Not necessarily easy, but straight forward and very predictable behavior. Routines like that are easy to get in a state where it's highly unlikely that there's a bug left.

You think that... and one day you find a bug in that "perfect" routine.

Originally Posted by Thorham

Yes, and it wasn't a lot of fun. The good news is that my new Pentium 3 runs WinUae better than my old one. The old ones main problem was the dying CPU fan, which caused breaks in the program execution when the load became high (it would start spinning faster, then you'd get the break, and then it would slow down again and this recently become worse). Which means I can start playing properly

Ok, so from this I understand that you got your a$$ kicked in the second dungeon too. Good news

Originally Posted by Thorham

Hahaha Actually, I'm getting my money this week, and I'm sending the money over for the mobo on the same day, so it's a done deal

So when will you receive it ? Next week ?

Originally Posted by Thorham

Well, it does. It's probably because my quick renderer sacrifices quality for speed.

Yes, I have. The base threshold is 64, so that simply has to be multiplied by the sum of all the weights.

Still mysterious... but I guess we can live without knowing.

Originally Posted by Thorham

Still doesn't mean that there isn't a better way to choose palette pixels. One thing is that your color picker is based on 12 bit color, which it of course has to, or the table would become too large. But I might be wrong

It's already large enough, right. More precision wouldn't bring much quality, though.

Originally Posted by Thorham

That shouldn't be to difficult. I'm probably going to do this in the weekend. I still have my new peecee to setup properly. I want to completely wipe my 160 gig hd, but it's filled with stuff that needs sorting out. A lot of it can be tossed, and some of it has to be backed up. It's going to take a while... It would be much better if I could just buy a new drive, but that's going to have to wait.

Why not just getting a new drive and copying everything on it ?

Originally Posted by Thorham

The problem here is perhaps that the error computation isn't optimal. The palette values will often not yield an error of zero, either, and low ham pixel errors are proabably completely invisible. Perhaps not interesting as a speed optimization in your renderer, but if it works, it will save a lot of cycles in the method I proposed for slower, better rendering, because you don't have to check the whole palette for each pixel in the image, so it's essential I use this if it works properly.

It all depends of the kind of image you're seeing. On some images you won't have two identical pixels, while on others it can be up to 50%.

Originally Posted by Thorham

Hey, I'm just saying, that you can never be a 100% certain

As there isn't much researching in the field, it's likely I can sleep a big while before this happens

Originally Posted by Thorham

Good point, but for me HAM8 is the perfect balance between quality and having to puch things to get the best resaults. ECS HAM only works in lowres, and the bit depth is a little too low. Also, HAM6 and HAM8 are mostly the same, and a good HAM8 algorithm will probably work perfectly fine with HAM6.

Don't tell me you don't want anything over AGA just because of the HAM8 ???

Originally Posted by Thorham

Edit:

I'll most certainly be getting back into this HAM rendering business. My old monitor had become quite dark and when I tried my HAM diff program on my new monitor, it showed a whole world which was previously invisible Perhaps now that I can see what I'm doing, I can crack quality fast rendering (or maybe not ).

Dark side of monitors isn't fun. When I was using the TV I just stopped coding - but it was good to play DM1 and I played my difficult dungeon 'til the end !

[Thorham]

Originally Posted by meynaf

You think that... and one day you find a bug in that "perfect" routine.

Hey now, I said unlikely, not 100% certain, there's a difference. But you must admit that certain routines are easy to break down into smaller, completely testable chunks. While this still doesn't give you 100% certainty, it does reduce the chance that you'll miss bugs a lot, and that's the point.

Originally Posted by meynaf

Ok, so from this I understand that you got your a$$ kicked in the second dungeon too. Good news

Well, ass kicked... wait... I'll continue my exploits in your Dungeon Master thread

Originally Posted by meynaf

So when will you receive it ? Next week ?

I've sent my bank the transfer details, but it's by mail (yeah, quite old fashioned ), so it will take about a week or so for the money to arrive, and then it'll probably take another week for the mobo to arrive. Three weeks maximum Which is fine with me, because WinUae runs better on my 'new' peecee, so I can certainly make do with it.

Originally Posted by meynaf

Still mysterious... but I guess we can live without knowing.

Yes, quite weird, but I'm going to coninue with this stuff as of today. I had taken a break from HAM rendering, because I over did it 'a little', and ran out of ideas, but I'm refreshed now

Originally Posted by meynaf

It's already large enough, right. More precision wouldn't bring much quality, though.

Probably not.

Originally Posted by meynaf

Why not just getting a new drive and copying everything on it ?

Yes, I bought one anyway (500 giga bytes). Basically I had to pay 100 Euros every month to pay off a debt, but now that I don't have to anymore, I can spend the money as I see fit, which means I can pay for the A1200 mobo and a new hard drive

Originally Posted by meynaf

It all depends of the kind of image you're seeing. On some images you won't have two identical pixels, while on others it can be up to 50%.

I'm not sure I understand what you mean, please explain.

Originally Posted by meynaf

As there isn't much researching in the field, it's likely I can sleep a big while before this happens

That's true, after all, there isn't really a use for this other than rendering to HAM hardware. On possible use might be for image compression. Render a HAM10 image, then interpolate all the gun colors that don't change, and calculate the difference with the original and see how well it compresses. I wonder if anyone has tried this...

Originally Posted by meynaf

Don't tell me you don't want anything over AGA just because of the HAM8 ???

No, I can't say I do. If I want 24 bit I'll just use my peecee. Part of the fun is trying to get the most out of limited hardware, and HAM8 is great for this. Basically it's challenging, while 24 bit frame buffers offer no such challenge.

Edit:

My ideal setup is two A1200s, one with an '030 and one with an '060, where the '030 would get the most usage. For me no 24 bit cards, no power peecee and no 16 bit audio (if I want all that, I'll just use my peecee)

Originally Posted by meynaf

Dark side of monitors isn't fun. When I was using the TV I just stopped coding - but it was good to play DM1 and I played my difficult dungeon 'til the end !

Was it really that unreadable? What editor, font and resolution do you use?

[meynaf]

Originally Posted by Thorham

Hey now, I said unlikely, not 100% certain, there's a difference. But you must admit that certain routines are easy to break down into smaller, completely testable chunks. While this still doesn't give you 100% certainty, it does reduce the chance that you'll miss bugs a lot, and that's the point.

I didn't say it wouldn't reduce the chance, I said it wouldn't reach 100%, so at the end we agree here.

Originally Posted by Thorham

Well, ass kicked... wait... I'll continue my exploits in your Dungeon Master thread

I've sent my bank the transfer details, but it's by mail (yeah, quite old fashioned ), so it will take about a week or so for the money to arrive, and then it'll probably take another week for the mobo to arrive. Three weeks maximum Which is fine with me, because WinUae runs better on my 'new' peecee, so I can certainly make do with it.

Your ability to continue is all that counts. I want to see how far you can get.

Originally Posted by Thorham

Yes, quite weird, but I'm going to coninue with this stuff as of today. I had taken a break from HAM rendering, because I over did it 'a little', and ran out of ideas, but I'm refreshed now

Ok, I guess you will tell of any idea you have.

Originally Posted by Thorham

Yes, I bought one anyway (500 giga bytes). Basically I had to pay 100 Euros every month to pay off a debt, but now that I don't have to anymore, I can spend the money as I see fit, which means I can pay for the A1200 mobo and a new hard drive

So you finally paid your old gambling debts

Originally Posted by Thorham

I'm not sure I understand what you mean, please explain.

What I mean is that speed opts for rows of identical pixels gain nothing on some images, but gain a lot on others. You will never know if you will, or not, often have error values of zero.

Originally Posted by Thorham

That's true, after all, there isn't really a use for this other than rendering to HAM hardware. On possible use might be for image compression. Render a HAM10 image, then interpolate all the gun colors that don't change, and calculate the difference with the original and see how well it compresses. I wonder if anyone has tried this...

You can't hope more than reducing 24 bits to 10, which already isn't extremely efficient by itself.

Originally Posted by Thorham

No, I can't say I do. If I want 24 bit I'll just use my peecee. Part of the fun is trying to get the most out of limited hardware, and HAM8 is great for this. Basically it's challenging, while 24 bit frame buffers offer no such challenge.

Edit:

My ideal setup is two A1200s, one with an '030 and one with an '060, where the '030 would get the most usage. For me no 24 bit cards, no power peecee and no 16 bit audio (if I want all that, I'll just use my peecee)

I think I'll pass on this kind of challenges in the future... I want a new environment in which to code like I actually do, but allowing more. There are many other challenges to be met then, e.g. porting games.

Originally Posted by Thorham

Was it really that unreadable? What editor, font and resolution do you use?

Not unreadable but less clear, even with regular topaz 8 on 640x256.

[Thorham]

Originally Posted by meynaf

I didn't say it wouldn't reduce the chance, I said it wouldn't reach 100%, so at the end we agree here.

Yes, but it does get a little philosophical there, as in 'nothing is certain'. I don't like thinking like that, because I'm not sure I agree with that. But for software, even if 100% bug free is possible (which I still like to believe), it's certainly not easy.

Originally Posted by meynaf

Your ability to continue is all that counts. I want to see how far you can get.

To me it also counts that I'm going to have an Amiga again Anyway, like I said, I'll keep you informed in your DM thread.

Originally Posted by meynaf

Ok, I guess you will tell of any idea you have.

I must admit that I haven't tried much, because there are quite a few things to try, actually. One thing is certainly a big relief, and that's that there's no more fixed palette. That's such a limitation for getting optimal results (simply impossible with a fixed palette).

Originally Posted by meynaf

So you finally paid your old gambling debts

Nope, something whit the rent. Where I live they won't kick you out immediately if you can't pay for a few months, but they will still want the money

Originally Posted by meynaf

What I mean is that speed opts for rows of identical pixels gain nothing on some images, but gain a lot on others. You will never know if you will, or not, often have error values of zero.

True, but for many images, most of the image is going to look good with just HAM pixels, so for most images this speed optimization will work.

Originally Posted by meynaf

You can't hope more than reducing 24 bits to 10, which already isn't extremely efficient by itself.

True, but it might help in beating PNGs lossless compression, which might be interesting for the novelty value.

Originally Posted by meynaf

I think I'll pass on this kind of challenges in the future... I want a new environment in which to code like I actually do, but allowing more.

Can't say I'm too fond of expaning the AGA capabilities; those constraints are half of the fun to me.

A good example is the good old Paula (this is from when my Amiga still worked). I always thought that calibration didn't do much, until I was playing back some Playstation 2 music using WinAmp. This music is 48 Khz, and WinAmp was playing it back at 44 Khz (after messing around with the settings), and it sounded noisy, and guess what? I've been using WinAmp to downsample music to 24 Khz, and WinAmp uses fast and cheap routines to downsample!

When I tried Sox (has slow, high quality down sampling) to down sample that Playstation music to 44 Khz it sounded just fine. So I tried down sampling something to 28 Khz with Sox, played it back on my Amiga (streaming over the network ), and it sounded fantastic Much better than that awful WinAmp down sampling routine, and there was quite a difference between calibrated and uncalibrated as well.

Clearly the Amiga hardware can be pushed quite a bit if you do it right, and expanding it will take all of that away

Originally Posted by meynaf

There are many other challenges to be met then, e.g. porting games.

Yes, but the closer you get to todays capabilities, the easier it becomes to just run a game on the games original platform. Part of the charm of making a good Starcraft port, for example, is that it runs on AGA+68k. Something like Natami can handle that easily, and it's new hardware, so why not just run it on a peecee?

Originally Posted by meynaf

Not unreadable but less clear, even with regular topaz 8 on 640x256.

Okay, but I'd still like to know which editor you use (just curious).