Misc programming discussion (from pms).

[meynaf]

Originally Posted by Thorham

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.

I won't like to go into endless theoretical discussion, so enough for me

Originally Posted by Thorham

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.

Ok. Please let me know how many skeletons I need to add in the dungeons (and where) to take your presence into account

Originally Posted by Thorham

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

Well, make it work and you'll see if it's such a big relief or not...

Originally Posted by Thorham

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

You won't make me believe that
(notice the smiley)

Originally Posted by Thorham

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.

It will work, and get very slightly lower quality for very slightly higher speed. Nothing interesting to me.
Applied to your "maximum quality" renderer, it'll lower the quality. Not by much, but it will and this is perhaps not truly acceptable.

Originally Posted by Thorham

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

But PNG has never been a good reference in that aspect. Just take the file as BMP, compress it with good general purpose cruncher and it's already beaten.

Originally Posted by Thorham

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

Constraints are fun only when you can overcome them. But when they make your project to fail or be very limited, the fun is gone. Natami's frontiers will need to be pushed too, it's just that they're further.

Originally Posted by Thorham

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?

Why not run on a peecee : because it's a peecee. The charm on AGA+68k will be gone when you'll discover your game won't run at an acceptable speed.

Originally Posted by Thorham

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

Try to guess it

[Thorham]

Originally Posted by meynaf

I won't like to go into endless theoretical discussion, so enough for me

That's fine with me

Originally Posted by meynaf

Ok. Please let me know how many skeletons I need to add in the dungeons (and where) to take your presence into account

Okay, I will.

Originally Posted by meynaf

Well, make it work and you'll see if it's such a big relief or not...

Still haven't worked on it much. I've been busy with my Freebasic gui project, and some other things that needed attention. Anyway, once I get back to it, all I really need is a median cut algorithm that's commonly used for color reduction. However, I'll still try it in Freebasic first, because it's much easier to try things like this in a higher level language, so this is still going to take some time before getting something working on the Amiga

Originally Posted by meynaf

You won't make me believe that
(notice the smiley)

It's the truth. That organization isn't privately owned (apparently), and also, with a few months I mean two, and I don't think they're even allowed to kick you out at that point. Don't know the details, but it sure helped when I was in a pinch.

Originally Posted by meynaf

It will work, and get very slightly lower quality for very slightly higher speed. Nothing interesting to me.

Very slightly higher speed? I don't think so. With out this idea you have to check 64 colors for every pixel, that's quite slow. With my idea you can reduce that to less than ten percent of the pixels (or even less). It'll end up much faster.

Remember that you have to calculate the color distance for 64 colors. Assuming that can be done properly in, say, ten cycles, you'll already get 640 cycles for just one pixel, therefore not having to check 90 percent of the pixels will save heaps of cpu time.

Originally Posted by meynaf

Applied to your "maximum quality" renderer, it'll lower the quality. Not by much, but it will and this is perhaps not truly acceptable.

Because it's going to have a big impact on the routines speed, I'm making it an option if it does reduce the quality.

Originally Posted by meynaf

But PNG has never been a good reference in that aspect. Just take the file as BMP, compress it with good general purpose cruncher and it's already beaten.

Really? Then why did the PNG designers come up with their whole encoding scheme?

Originally Posted by meynaf

Constraints are fun only when you can overcome them. But when they make your project to fail or be very limited, the fun is gone. Natami's frontiers will need to be pushed too, it's just that they're further.

Of course, but that just means you have to make an informed decision about what you're going to port over.

Originally Posted by meynaf

Why not run on a peecee : because it's a peecee. The charm on AGA+68k will be gone when you'll discover your game won't run at an acceptable speed.

Not a problem for me. If it can't run properly on AGA+68K I'll just run it on the peecee.

Originally Posted by meynaf

Try to guess it

I'll start with an obvious one: CygnusEd.

[meynaf]

Originally Posted by Thorham

Still haven't worked on it much. I've been busy with my Freebasic gui project, and some other things that needed attention. Anyway, once I get back to it, all I really need is a median cut algorithm that's commonly used for color reduction. However, I'll still try it in Freebasic first, because it's much easier to try things like this in a higher level language, so this is still going to take some time before getting something working on the Amiga

I'd say that if you haven't worked on something, you needn't post anything about it...

Originally Posted by Thorham

It's the truth. That organization isn't privately owned (apparently), and also, with a few months I mean two, and I don't think they're even allowed to kick you out at that point. Don't know the details, but it sure helped when I was in a pinch.

Nah. I still don't believe that
(perhaps one day you'll understand that I'm not serious here)

Originally Posted by Thorham

Very slightly higher speed? I don't think so. With out this idea you have to check 64 colors for every pixel, that's quite slow. With my idea you can reduce that to less than ten percent of the pixels (or even less). It'll end up much faster.

Remember that you have to calculate the color distance for 64 colors. Assuming that can be done properly in, say, ten cycles, you'll already get 640 cycles for just one pixel, therefore not having to check 90 percent of the pixels will save heaps of cpu time.

Yes, very slightly higher speed - but that's for my renderer, not yours (I ought to have specified it ).
For yours it will accelerate more, but it will lower your quality.
That's why I see it as uninteresting : it's not acceptable for either method.

Originally Posted by Thorham

Because it's going to have a big impact on the routines speed, I'm making it an option if it does reduce the quality.

Trust me, it will. Isn't what you want MAXIMUM quality ?

But there is another possibility.
Every 24-bit combination has only one best match in the palette but you can't make a table with that ; however, nothing prevents you from building a table from 12-bit out of these 24, which contain all candidates to be checked. There will not be many, this way you can perhaps get the real best match with only 3-4 color comparisons at maximum (and in many cases there will be only one).

Originally Posted by Thorham

Really? Then why did the PNG designers come up with their whole encoding scheme?

They tried to be smart ass

Originally Posted by Thorham

Of course, but that just means you have to make an informed decision about what you're going to port over.

Not a problem for me. If it can't run properly on AGA+68K I'll just run it on the peecee.

If there's nothing wrong with the pc for you, you don't need to port anything - just use the pc and you don't need a miggy either.

Originally Posted by Thorham

I'll start with an obvious one: CygnusEd.

Missed ! Try again

[Thorham]

Originally Posted by meynaf

I'd say that if you haven't worked on something, you needn't post anything about it...

Okay, I'll shut up about it

Originally Posted by meynaf

Nah. I still don't believe that
(perhaps one day you'll understand that I'm not serious here)

But it's the truth, I tell you, the truth

Originally Posted by meynaf

Yes, very slightly higher speed - but that's for my renderer, not yours (I ought to have specified it ).

Yes, for yours it won't matter much.

Originally Posted by meynaf

For yours it will accelerate more, but it will lower your quality.
That's why I see it as uninteresting : it's not acceptable for either method.

While I still haven't gotten around to testing this, I have been sporadically playing with it, and there might be a small problem that will cause a drop in quality. For some of the 'not so high' errors you can still get a better palette match, and this palette color will improve rendering of the next few pixels right after it. However, for very low errors this doesn't seem to hold true. I'll need to run more tests to see if that's the case. Still, it's a pity, because many times this will work like a charm

Originally Posted by meynaf

Trust me, it will. Isn't what you want MAXIMUM quality ?

Yes, I do want maximum quality. However, if this option is implemented properly, you'll still get great quality and it's much faster than maximum quality (which might become a novelty feature in a way if the 'fast mode' is good enough).

Originally Posted by meynaf

But there is another possibility.
Every 24-bit combination has only one best match in the palette but you can't make a table with that ; however, nothing prevents you from building a table from 12-bit out of these 24, which contain all candidates to be checked. There will not be many, this way you can perhaps get the real best match with only 3-4 color comparisons at maximum (and in many cases there will be only one).

Interesting, although I'm not entirely sure what you mean. I'll try to figure it out

Originally Posted by meynaf

They tried to be smart ass

They did, didn't they? I mean, is there any point at all to the scheme they used (no wonder I kept procrastinating)?

Originally Posted by meynaf

If there's nothing wrong with the pc for you, you don't need to port anything - just use the pc and you don't need a miggy either.

While there's nothing wrong with peecees to me, Amigas are fun, and peecees are boring

Originally Posted by meynaf

Missed ! Try again

Ed No, seriously, I don't have a clue.

[meynaf]

Originally Posted by Thorham

But it's the truth, I tell you, the truth

Yeah, sure.

Originally Posted by Thorham

While I still haven't gotten around to testing this, I have been sporadically playing with it, and there might be a small problem that will cause a drop in quality. For some of the 'not so high' errors you can still get a better palette match, and this palette color will improve rendering of the next few pixels right after it. However, for very low errors this doesn't seem to hold true. I'll need to run more tests to see if that's the case. Still, it's a pity, because many times this will work like a charm

I told you it would lower your quality

Originally Posted by Thorham

Yes, I do want maximum quality. However, if this option is implemented properly, you'll still get great quality and it's much faster than maximum quality (which might become a novelty feature in a way if the 'fast mode' is good enough).

You don't need this option to be reasonably fast.

Originally Posted by Thorham

Interesting, although I'm not entirely sure what you mean. I'll try to figure it out

I just mean having a list in the table, instead of a single item. Most of the colors are just too far away to be reasonable candidates, right ?

Originally Posted by Thorham

They did, didn't they? I mean, is there any point at all to the scheme they used (no wonder I kept procrastinating)?

The point is that deflate compression was so poor that they had to do something about it. I see no other reason. Now it's "less poor", but it still ain't good

Originally Posted by Thorham

While there's nothing wrong with peecees to me, Amigas are fun, and peecees are boring

So, for you, what makes Amigas fun, and what makes peecees boring ?

Originally Posted by Thorham

Ed No, seriously, I don't have a clue.

Aarghh ! Ed.
But why do people keep using that one when they had something much better on their HD from day one ?

[Thorham]

Originally Posted by meynaf

I told you it would lower your quality

Depends on the size of the error thresh hold. For low values such as four, things look promising. Make it too high, and it goes bad quickly. Still, there's quite some cpu time to save.

Originally Posted by meynaf

You don't need this option to be reasonably fast.

True if your table idea works.

Originally Posted by meynaf

I just mean having a list in the table, instead of a single item. Most of the colors are just too far away to be reasonable candidates, right ?

Haha, I still don't get it Perhaps I should try a bit harder to figure it out

Originally Posted by meynaf

The point is that deflate compression was so poor that they had to do something about it. I see no other reason. Now it's "less poor", but it still ain't good

Yeah, why they would go for a dictionary based compressor is already beyond me.

Originally Posted by meynaf

So, for you, what makes Amigas fun, and what makes peecees boring ?

It's mostly just the way it feels, although there's also the part where on the Amiga things are harder to get to work and be fast, and that's fun

Originally Posted by meynaf

Aarghh ! Ed.
But why do people keep using that one when they had something much better on their HD from day one ?

People actually use that editor? Really? What ever for Emacs is indeed better, although I never use it. Do you?

[meynaf]

Originally Posted by Thorham

Depends on the size of the error thresh hold. For low values such as four, things look promising. Make it too high, and it goes bad quickly. Still, there's quite some cpu time to save.

You shouldn't make such a compromise if what you want is absolute quality. If something's gonna take too long, just use a smarter algorithm.

Originally Posted by Thorham

True if your table idea works.

Haha, I still don't get it Perhaps I should try a bit harder to figure it out

Actual table gives closest match from 12-bit color. Instead of doing this, it could give the list of all potential color candidates. If implemented correctly, it will work. But how do you plan on finding the "best" color match
anyway ?

Originally Posted by Thorham

Yeah, why they would go for a dictionary based compressor is already beyond me.

What else could they have used ?

Originally Posted by Thorham

People actually use that editor? Really? What ever for Emacs is indeed better, although I never use it. Do you?

You don't have "Emacs". You have MicroEmacs (MEmacs), and this is exactly what I use and nobody else does. Not easy to learn, but efficient once you know it - and light enough for my needs.

[Thorham]

Originally Posted by meynaf

You shouldn't make such a compromise if what you want is absolute quality.

It depends. If it's not possible to make a fast highest quality render, then an optional compromise is interesting if it is both a lot faster and still quite good quality. If not, there's no point. Either way, it's only ever going to be an option, and it's not going to be the default setting.

Originally Posted by meynaf

If something's gonna take too long, just use a smarter algorithm.

That's true, but it has to be possible to make a fast algorithm, it might be that the good algorithms are all going to be somewhat slow.

Originally Posted by meynaf

Actual table gives closest match from 12-bit color. Instead of doing this, it could give the list of all potential color candidates. If implemented correctly, it will work.

I think it's starting to finally sink in here Sounds interesting, perhaps I can get it to work.

Originally Posted by meynaf

But how do you plan on finding the "best" color match
anyway ?

I'll start by using a simple quadratic color distance, and if that doesn't produce nice results I'll try an alternative I've found on the net. The only important things are that it produces good results and that it can be done with a table. Especially the table is important because of the multiplications.

Originally Posted by meynaf

What else could they have used ?

Perhaps an entropy coder? I don't really know, but it seems that a dictionary based compressor is better at compressing other things than graphics, or sound for that matter.

Originally Posted by meynaf

You don't have "Emacs". You have MicroEmacs (MEmacs),

It's still an Emacs derivative

Originally Posted by meynaf

and this is exactly what I use and nobody else does.

I personally prefer FrexxEd.

Originally Posted by meynaf

Not easy to learn, but efficient once you know it - and light enough for my needs.

I'll check it out

[meynaf]

Originally Posted by Thorham

It depends. If it's not possible to make a fast highest quality render, then an optional compromise is interesting if it is both a lot faster and still quite good quality. If not, there's no point. Either way, it's only ever going to be an option, and it's not going to be the default setting.

That's true, but it has to be possible to make a fast algorithm, it might be that the good algorithms are all going to be somewhat slow.

For best quality there is little choice, or you'll end up with something not much better than quick version.
This is because even the highest possible quality will be only marginally better than the normal quick one ; effect can be very visible but not stunning.

Originally Posted by Thorham

I think it's starting to finally sink in here Sounds interesting, perhaps I can get it to work.

This is how I would have done it anyway.

Originally Posted by Thorham

I'll start by using a simple quadratic color distance, and if that doesn't produce nice results I'll try an alternative I've found on the net. The only important things are that it produces good results and that it can be done with a table. Especially the table is important because of the multiplications.

Colorspace conversion can certainly be done with a table : this is how YCbCr conversion is done in my jpeg.s.

Originally Posted by Thorham

Perhaps an entropy coder? I don't really know, but it seems that a dictionary based compressor is better at compressing other things than graphics, or sound for that matter.

Entropy coder = lossy compression (or so I think).
Something relatively good at compressing graphics is Burrows-Wheeler algorithm (block sorting), although it ain't a specialized one. But it's probably too slow for that use (at least it was when PNG was designed). The situation is even worse in that aspect for statistical (PPM) encoders.

[Thorham]

Originally Posted by meynaf

For best quality there is little choice, or you'll end up with something not much better than quick version.

For the absolute maximum there's probably no choice. I've casually run some more tests, and low error values can be skipped without many problems, if any.

Originally Posted by meynaf

This is because even the highest possible quality will be only marginally better than the normal quick one ; effect can be very visible but not stunning.

No, there's nothing marginal about it. Even with 64 colors picked for an image you already get a big improvement. Setting 16 colors per scan line will indeed be a lot better than any fast method can be. It's all in the fringing. With quick renderers you'll always have the problem of using a static palette, and this creates fringing errors. Using an image specific palette already reduces this a lot, and setting colors on a per scan line basis will almost completely remove fringing errors when done properly.

Originally Posted by meynaf

This is how I would have done it anyway.

I'll probably try to come up with some working code for this in the weekend. although I can't say I'm very motivated to write the whole thing

Originally Posted by meynaf

Colorspace conversion can certainly be done with a table : this is how YCbCr conversion is done in my jpeg.s.

The algorithm I found is actually RGB based, and seems to give good results, so I'll probably just use that to get something working for now.

Originally Posted by meynaf

Entropy coder = lossy compression (or so I think).

Huffman encoding is an entropy coder. They're lossless

Originally Posted by meynaf

Something relatively good at compressing graphics is Burrows-Wheeler algorithm (block sorting), although it ain't a specialized one. But it's probably too slow for that use (at least it was when PNG was designed). The situation is even worse in that aspect for statistical (PPM) encoders.

Well, it's too late to change it now

[meynaf]

Originally Posted by Thorham

For the absolute maximum there's probably no choice. I've casually run some more tests, and low error values can be skipped without many problems, if any.

Isn't your target absolute maximum ?

Originally Posted by Thorham

No, there's nothing marginal about it. Even with 64 colors picked for an image you already get a big improvement. Setting 16 colors per scan line will indeed be a lot better than any fast method can be. It's all in the fringing. With quick renderers you'll always have the problem of using a static palette, and this creates fringing errors. Using an image specific palette already reduces this a lot, and setting colors on a per scan line basis will almost completely remove fringing errors when done properly.

I need to see it to believe it.

Originally Posted by Thorham

I'll probably try to come up with some working code for this in the weekend. although I can't say I'm very motivated to write the whole thing

Not motivated to write code, eh ?

Originally Posted by Thorham

The algorithm I found is actually RGB based, and seems to give good results, so I'll probably just use that to get something working for now.

Seems good idea.

Originally Posted by Thorham

Huffman encoding is an entropy coder. They're lossless

So what did you mean by "Perhaps an entropy coder" ?

Originally Posted by Thorham

Well, it's too late to change it now

Right, because even though format allows different methods (only one being used "for now"), adding more would break all existing decoders.

Anyway I am not into image processing now.
Among many projects I have, current one is a little game.
Do you remember that tile map thingy we talked about here ?
I've extended it :
meynaf.free.fr/tmp/tilemap.lzx
Now map data is outside of the code, as should be.
You just type map filename after the command, and see what this little 5kb executable can do.
"tilemap-th.map" is something you've already seen, just to show you there is no regression
"minigame.map" is a bigger map, where you must find the "exit" tile.
I'm really in need of more gfx to "decorate" places you can see here...

[Thorham]

Originally Posted by meynaf

Isn't your target absolute maximum ?

Yes, it is, but I like options that are still very good, but much faster. Anyway, those options don't have priority over maximum quality.

Originally Posted by meynaf

I need to see it to believe it.

You will, just not now

Originally Posted by meynaf

Not motivated to write code, eh ?

No, not really. I've been stuck with just a peecee for too long. On the plus side: My A1200 mobo has arrived Perhaps that will help me get motivated again.

Edit: Picked up the board, and it works perfectly. I'm a happy customer now

Originally Posted by meynaf

Seems good idea.

It probably is. Only if a non RGB based algorithm produces better results and the RGB to other color space conversion can be done fast will I try another algorithm.

Originally Posted by meynaf

So what did you mean by "Perhaps an entropy coder" ?

It might offer better compression for images than a dictionary based compressor.

Originally Posted by meynaf

Right, because even though format allows different methods (only one being used "for now"), adding more would break all existing decoders.

Pretty useless, isn't it?

Originally Posted by meynaf

Anyway I am not into image processing now.
Among many projects I have, current one is a little game.
Do you remember that tile map thingy we talked about here ?
I've extended it :
meynaf.free.fr/tmp/tilemap.lzx
Now map data is outside of the code, as should be.
You just type map filename after the command, and see what this little 5kb executable can do.
"tilemap-th.map" is something you've already seen, just to show you there is no regression
"minigame.map" is a bigger map, where you must find the "exit" tile.
I'm really in need of more gfx to "decorate" places you can see here...

Very nice, would be cool to see a full game You're right about the graphics, these can certainly be extended.

[meynaf]

Originally Posted by Thorham

Yes, it is, but I like options that are still very good, but much faster. Anyway, those options don't have priority over maximum quality.

This makes sense. So how's maximum quality going ?

Originally Posted by Thorham

You will, just not now

No, not really. I've been stuck with just a peecee for too long. On the plus side: My A1200 mobo has arrived Perhaps that will help me get motivated again.

Time will tell...

Originally Posted by Thorham

It might offer better compression for images than a dictionary based compressor.

But, man, deflate is huffman and you said huffman was entropy coder.

Originally Posted by Thorham

Pretty useless, isn't it?

Indeed.

Originally Posted by Thorham

Very nice, would be cool to see a full game

Well, this is some sort of a full game, because you now have a goal - finding the exit. But, of course, it's a very basic one

For new stuff, my way here is an iterative one. So, what is next simple step to add now ?

Originally Posted by Thorham

You're right about the graphics, these can certainly be extended.

They're either ripped/converted (e.g. character) or drawn by myself (e.g. brick wall). Place holder gfx they are...

But you can edit the IFF if you want
(note that some of the gfx here is not used)

[Thorham]

Originally Posted by meynaf

This makes sense. So how's maximum quality going ?

Originally Posted by meynaf

Time will tell...

As you probably expected, I haven't done a damned thing, because I really can't seem to become motivated right now. I need a small break from programming.

Originally Posted by meynaf

But, man, deflate is huffman and you said huffman was entropy coder.

Deflate is a combination of a dictionary coder and Huffman encoding. As you know, it finds repeating patterns in data, and replaces further repetitions with pointers to those patterns. It then uses Huffman encoding to get better compression ratios than just dictionary coding.

Huffman encoding can also be used by itself. Power Packer does this, for example, and this may be better for images, perhaps in combination with some simple encoding scheme. Images often don't have many repeating patterns, if I'm not mistaken, and if that's true, then a dictionary coder simply isn't the most suitable. Those are much better for things such as text.

Originally Posted by meynaf

Well, this is some sort of a full game, because you now have a goal - finding the exit. But, of course, it's a very basic one

Quite basic. I tried it, but at the moment it's rather too basic, although I'm not talking about the place holder graphics, those just aren't very important.

Originally Posted by meynaf

For new stuff, my way here is an iterative one. So, what is next simple step to add now ?

Usable objects, such as keys and locks, for starters?

I would advise you to take combat in consideration, too. Weren't you going to make it turn based? If so, then you'll probably like the way Fire Emblem implements combat. That game, however, doesn't contain any exploration, which is a bit of a pity. If you want to know what this plays like, I can download Shining Force with a fast Sega Master System emulator for you (it's more than fast enough on 50mhz '030), however, you won't be able to save your progress (as far as I know, perhaps I didn't try evrything), probably due to incompatibilty issues. Also, Shining Forces interface isn't as nice as Fire Enblems.

Originally Posted by meynaf

They're either ripped/converted (e.g. character) or drawn by myself (e.g. brick wall). Place holder gfx they are...

That's fine, they don't have to be pretty

Originally Posted by meynaf

But you can edit the IFF if you want
(note that some of the gfx here is not used)

Perhaps if I can get some good graphics (not as easy as I used to think )

That said, NetHack (I think) has a nice and simple indoor tile set, which I've shown you already. There are plenty of tiles that can be used directly as place holder graphics. Might be useful for now.

[meynaf]

Originally Posted by Thorham

As you probably expected, I haven't done a damned thing, because I really can't seem to become motivated right now. I need a small break from programming.

How on earth do you need some break from something you weren't actually doing before ?

Originally Posted by Thorham

Deflate is a combination of a dictionary coder and Huffman encoding. As you know, it finds repeating patterns in data, and replaces further repetitions with pointers to those patterns. It then uses Huffman encoding to get better compression ratios than just dictionary coding.

You know, most encoders more or less do that.

Originally Posted by Thorham

Huffman encoding can also be used by itself. Power Packer does this, for example, and this may be better for images, perhaps in combination with some simple encoding scheme. Images often don't have many repeating patterns, if I'm not mistaken, and if that's true, then a dictionary coder simply isn't the most suitable. Those are much better for things such as text.

Power Packer is just one of the worst compressor in the world, and it's certainly not using Huffman. Even lame deflate beats the crap out of it.
Please check your infos before talking.

Originally Posted by Thorham

Quite basic. I tried it, but at the moment it's rather too basic, although I'm not talking about the place holder graphics, those just aren't very important.

If it's too basic, tell what's missing. It's just exploration game, which obviously you didn't play to the end.

Originally Posted by Thorham

Usable objects, such as keys and locks, for starters?

This isn't simple step, as it requires inventory handling.

Originally Posted by Thorham

I would advise you to take combat in consideration, too. Weren't you going to make it turn based? If so, then you'll probably like the way Fire Emblem implements combat. That game, however, doesn't contain any exploration, which is a bit of a pity. If you want to know what this plays like, I can download Shining Force with a fast Sega Master System emulator for you (it's more than fast enough on 50mhz '030), however, you won't be able to save your progress (as far as I know, perhaps I didn't try evrything), probably due to incompatibilty issues. Also, Shining Forces interface isn't as nice as Fire Enblems.

No need to do that, simple screen grab and explanation will do.
But combat can easily be done graphically by just adding more units in the view. It's actual combat rules that make it more complex.

Originally Posted by Thorham

That's fine, they don't have to be pretty

They sure don't, even though outdoor gfx (ripped from freeciv) aren't that ugly.

Originally Posted by Thorham

Perhaps if I can get some good graphics (not as easy as I used to think )

You can replace them and try them directly, no need to submit to me.
Of course, if you have cute gfx to decorate a particular room, add them and i'll update the map accordingly.

Originally Posted by Thorham

That said, NetHack (I think) has a nice and simple indoor tile set, which I've shown you already. There are plenty of tiles that can be used directly as place holder graphics. Might be useful for now.

If you look attentively enough, you'll see that some nethack gfx are already used.

[Thorham]

Originally Posted by meynaf

How on earth do you need some break from something you weren't actually doing before ?

I was, I've been doing some work on the peecee.

Originally Posted by meynaf

You know, most encoders more or less do that.

Things like Zip, Rar, Lha and Lzx most certainly do that.

Originally Posted by meynaf

Power Packer is just one of the worst compressor in the world, and it's certainly not using Huffman.

How do you know it's not Huffman?

Originally Posted by meynaf

Even lame deflate beats the crap out of it.

That's because deflate uses a combination of dictionary coding and entropy coding, while PowerPacker only uses entropy coding as far as I know.

Originally Posted by meynaf

Please check your infos before talking.

I've read something about compression in the Dutch magazine Amiga Magazine. Unless my memory is wrong, PowerPacker most certainly uses Huffman coding. However, I could be wrong

Originally Posted by meynaf

If it's too basic, tell what's missing. It's just exploration game, which obviously you didn't play to the end.

No, I haven't It needs items, monsters and puzzles

Originally Posted by meynaf

This isn't simple step, as it requires inventory handling.

Shouldn't be too hard.

Originally Posted by meynaf

No need to do that, simple screen grab and explanation will do.

Okay, I'll see if I can find some good ones, if not, I'll make some good ones.

Originally Posted by meynaf

But combat can easily be done graphically by just adding more units in the view. It's actual combat rules that make it more complex.

And you need a reasonable AI, or it will be too easy to win.

Originally Posted by meynaf

They sure don't, even though outdoor gfx (ripped from freeciv) aren't that ugly.

Are those Freeciv graphics really suitable for a game like this?

[meynaf]

Originally Posted by Thorham

I was, I've been doing some work on the peecee.

For me this doesn't count as "programming"

Originally Posted by Thorham

Things like Zip, Rar, Lha and Lzx most certainly do that.

Yes.

Originally Posted by Thorham

How do you know it's not Huffman?

You can recrunch it later with another, better packer, and still gain something significant. Some strings are visible in the stream. And its decrunch routine is simple enough to give this indication anyway.

Originally Posted by Thorham

That's because deflate uses a combination of dictionary coding and entropy coding, while PowerPacker only uses entropy coding as far as I know.

Nope. PowerPacker is in fact just dictionary, or more precisely it just looks for strings to repeat and has no LZ dictionnary.

Originally Posted by Thorham

I've read something about compression in the Dutch magazine Amiga Magazine. Unless my memory is wrong, PowerPacker most certainly uses Huffman coding. However, I could be wrong

You (or the magazine) must be confusing it with Imploder or Crunch-Mania, which effectively make use of Huffman coding. But PowerPacker is much like ProPack, which ain't Huffman at all.

Originally Posted by Thorham

No, I haven't It needs items, monsters and puzzles

Nothing proves you there are none later in the game
I think you should at least find the upper stairs.

Originally Posted by Thorham

Shouldn't be too hard.

Yes, but if i do this now this will only be by walking on the key to grab it, and there will be no inventory page (or option to use the key ; just walk on the door and you will get past it only if you have the key).

Originally Posted by Thorham

And you need a reasonable AI, or it will be too easy to win.

Just move towards the nearest enemy and have it : why would this make the thing too easy to win ?

Originally Posted by Thorham

Are those Freeciv graphics really suitable for a game like this?

Why wouldn't they ? You haven't even seen them in action !

[Thorham]

The screen shots I was going to take are from Fire Emblem and are in the Zone (small file, less than 100 KB). They should be self explanatory, but if you have any questions, or want to see some more, or you want to try a similar game on your Amiga, than let me know.

Originally Posted by meynaf

For me this doesn't count as "programming"

Haha

I was busy with a gui project in FreeBasic as you know. It's actually done in such a way that it should be a piece of cake to translate to 68030, which might be interesting, but that's a different story altogether

Originally Posted by meynaf

You can recrunch it later with another, better packer, and still gain something significant. Some strings are visible in the stream. And its decrunch routine is simple enough to give this indication anyway.

That's leading me to believe that Power Packer doesn't actually use an entropy coder...

Originally Posted by meynaf

Nope. PowerPacker is in fact just dictionary, or more precisely it just looks for strings to repeat and has no LZ dictionnary.

You (or the magazine) must be confusing it with Imploder or Crunch-Mania, which effectively make use of Huffman coding. But PowerPacker is much like ProPack, which ain't Huffman at all.

You're probably right. I still have the magazine somewhere. However, the point is that Huffman coding used by itself might be able to produce better results on some data (especially after preprocessing) than a combined dictionary/entropy coder.

Originally Posted by meynaf

Nothing proves you there are none later in the game
I think you should at least find the upper stairs.

I gave up after visiting a dozen or so rooms, because I thought it was just a small demo level with little else to do than explore

Originally Posted by meynaf

Yes, but if i do this now this will only be by walking on the key to grab it, and there will be no inventory page (or option to use the key ; just walk on the door and you will get past it only if you have the key).

Hmm, perhaps not so interesting to do it now than. It's better to wait until you've done everything that needs doing properly.

Originally Posted by meynaf

Just move towards the nearest enemy and have it : why would this make the thing too easy to win ?

Because this can be abused. Strategic combat needs more than just attacking the nearest unit; it makes for more interesting game play, in part because the computer's moves won't be so predictable and also because the computer will make better decisions.

Using the most simple way will mean you have to use strength in numbers to make battles challenging, while a smart AI doesn't need numbers per se.

Originally Posted by meynaf

Why wouldn't they ? You haven't even seen them in action !

No, I haven't. I've only seen screenshots from that game.

[meynaf]

Originally Posted by Thorham

The screen shots I was going to take are from Fire Emblem and are in the Zone (small file, less than 100 KB). They should be self explanatory, but if you have any questions, or want to see some more, or you want to try a similar game on your Amiga, than let me know.

Apparently it's just units in a tile world, being given orders to fight or move.
Are orders "stored" and then executed when turn is finished (like Amber series), or carried out immediately (like civi) ? Or is it not turn based ?

Originally Posted by Thorham

I was busy with a gui project in FreeBasic as you know. It's actually done in such a way that it should be a piece of cake to translate to 68030, which might be interesting, but that's a different story altogether

Perhaps it's better to finish it before translating it.

Originally Posted by Thorham

That's leading me to believe that Power Packer doesn't actually use an entropy coder...

Of course it doesn't, even though it's not impossible that this has changed with the very latest versions.

Originally Posted by Thorham

You're probably right. I still have the magazine somewhere. However, the point is that Huffman coding used by itself might be able to produce better results on some data (especially after preprocessing) than a combined dictionary/entropy coder.

As Huffman is itself entropy coder, you're saying here that Huffman alone can produce better results than Huffman + dictionnary.

Originally Posted by Thorham

I gave up after visiting a dozen or so rooms, because I thought it was just a small demo level with little else to do than explore

Then you're up to a BIG surprise if you manage to get out of these little rooms !

Then again, a bit of decoration wouldn't hurt in these starting rooms, but Nethack tile set doesn't provide this.

Originally Posted by Thorham

Hmm, perhaps not so interesting to do it now than. It's better to wait until you've done everything that needs doing properly.

For a start i would like to draw the character with transparency (see the relevant thread i've opened). Would also allow to draw objects on top of floor cells, such as keys

Originally Posted by Thorham

Because this can be abused.

You're not telling how.

Originally Posted by Thorham

Strategic combat needs more than just attacking the nearest unit; it makes for more interesting game play, in part because the computer's moves won't be so predictable and also because the computer will make better decisions.

Using the most simple way will mean you have to use strength in numbers to make battles challenging, while a smart AI doesn't need numbers per se.

Can you give an example battle ?
Let's say you're in a 12x12 cell room. You have one adventurer and three monsters. What can the monsters do apart walking towards the adventurer and fight ?

Originally Posted by Thorham

No, I haven't. I've only seen screenshots from that game.

Screenshots aren't useful here because gfx may vary a lot, depending of the tile set you're using. I took the square (i.e. non isometric) tile set, and turned the 30x30 tiles into 16x16.

[Thorham]

Originally Posted by meynaf

Apparently it's just units in a tile world, being given orders to fight or move.

Yes, it is, but don't be fooled by the two player characters, and two enemies in the screen shots, later in the game you have many characters to control, and many enemies to beat per map (easily 20+ units per map, with additional units joining during the battle).

Originally Posted by meynaf

Are orders "stored" and then executed when turn is finished (like Amber series), or carried out immediately (like civi) ? Or is it not turn based ?

Yes, it's turn based, and commands are executed immediately.

Originally Posted by meynaf

Perhaps it's better to finish it before translating it.

Yeah, that's true. Basically, the mechanics are almost finished, which means it's going to be time to implement the controls soon. I already have a half way finished line editor (just like the text box line editor in winblows), and I think I'm going to finish this after the mechanics. Still some work to do

Originally Posted by meynaf

Of course it doesn't, even though it's not impossible that this has changed with the very latest versions.

Of course? I don't see why they would use something else

Originally Posted by meynaf

As Huffman is itself entropy coder, you're saying here that Huffman alone can produce better results than Huffman + dictionnary.

It might. It may be the case that this depends on the data which is being compressed.

Originally Posted by meynaf

Then you're up to a BIG surprise if you manage to get out of these little rooms !

Okay, perhaps I'll try again.

Originally Posted by meynaf

Then again, a bit of decoration wouldn't hurt in these starting rooms, but Nethack tile set doesn't provide this.

Nope, it doesn't. No decorations at all.

Originally Posted by meynaf

For a start i would like to draw the character with transparency (see the relevant thread i've opened). Would also allow to draw objects on top of floor cells, such as keys

If you only need 16x16 pixels, then this is pretty easy.

Originally Posted by meynaf

You're not telling how.

See next quote.

Originally Posted by meynaf

Can you give an example battle ?
Let's say you're in a 12x12 cell room. You have one adventurer and three monsters. What can the monsters do apart walking towards the adventurer and fight ?

Right. But what about multiple monsters and/or multiple characters? Here's an example:

You have two characters, and one somewhat strong monster, which can only be defeated by your two characters. If one of them dies, you have to run away, or something. One of your chars has full hit points, and can safely be hit a few times, the other char only has a few hit points left and can't handle a single hit without dieing.

The char with full hit points is standing closest to the monster, while the other char is in range of the monster. Now the monster attacks the closest char, the char doesn't die, and you can counter attack with both your chars. The monster attacks the char that it previously attacked again, and you can counter attack with both chars again. Now the monsters fate is sealed, becuse you can kill it after it finishes it's turn.

It would be a lot more interesting if the monster attacked the char with few hit points. This would kill the char which would leave you with one, and one isn't enough to kill the monster, because it will kill your char first.

Of course, in big battles it can go much deeper than this.

Originally Posted by meynaf

Screenshots aren't useful here because gfx may vary a lot, depending of the tile set you're using. I took the square (i.e. non isometric) tile set, and turned the 30x30 tiles into 16x16.

Okay, I though it used a single tile set.