Misc programming discussion (from pms).

[Thorham]

This discussion has been moved from pm to thread (hence the double quoting), hoping it will be interesting to others, and giving everyone a chance to come up with sugestions.

Originally Posted by meynaf

Alas, no, e.g. that multiply-by-the-square-root-of-two (for stereo handling) was indeed slower than the mul.
Not by much, ok, and it was still faster than a long mul

For stereo? What an odd number, root of two. Why is it used? And because it's 1.414213562, can't you just use 1.5? Or does that mess up the sound? (Yup, lots of questions )

Originally Posted by meynaf

Of course you can get the number of consecutive 0 or 1 bits in a number and find the instructions according to that. But the number of clock cycles will raise quickly, and I'm not sure it's a good method for big and not-so-easy constants. For a good example see my $DC79 multiply (an horror to do with a binary method).

Hmm, after thinking it through, I have to say you're right. I've seen that dc79, and it seems to take 22 cycles, which is as much as a mul, or am I mistaken? If I'm not, I'd just replace it with a mul permanently.

Originally Posted by meynaf

I wrote it from scratch. Only used existing code to find out what had to be done, when the spec wasn't clear enough. Files of frequencies lower than 44.1 khz or 44.1 encoded with careful settings can be played in realtime on my '030 - that was clearly NOT the case with their original decoder !

Cool stugg That is never going to be the case with peecee software I assume it can be downloaded from your site?

Originally Posted by meynaf

LOL are you telling what we're saying here is uninteresting ? Oh, well...

Erm, that didn't come out right. I just meant something to start the thread with, instead of just continuing from the pms. Which is what I've done now! Of course what we're talking about is interesting

Originally Posted by meynaf

Don't worry about the huffman table builder, as it's not heavily used (only at start), and I have one in the jpeg part anyway.

Not in zlib streams, which also use dynamic codes, meaning for some blocks a new table has to be calculated, which plain sucks It also seems that zlib streams send new tables reletively often, meaning the tables have to be calculated relatively often, and on top of that, theres always two tables per block. It's not easy for me to get that speedy.

Originally Posted by meynaf

No problem, Sir

Why, thank you, Sir

Originally Posted by meynaf

I wonder if one day software will not become so slow that it'll be completely unusable...

Quite a good question. Some of it is already uselessly slow on my peecee, on the other hand, there are people who like to make their programs fast, such as the before mentioned video player, but it's true that theres a lot of slow junk out there. And then people say 'Your computer is slow', yeah right, over a billion instructions per second slow? Please And another good one is calling software 'technology' Don't they now that a program isn't anything more than a list of instructions which tell a computer what to do? Crazy world out there.

[meynaf]

Originally Posted by Thorham

For stereo? What an odd number, root of two. Why is it used? And because it's 1.414213562, can't you just use 1.5? Or does that mess up the sound? (Yup, lots of questions )

I don't exactly know why we need to do that, but it's needed. Changing the constant would mess up the sound in some cases, and remain totally undetectable in others. This is the beauty of MP3

Originally Posted by Thorham

Hmm, after thinking it through, I have to say you're right. I've seen that dc79, and it seems to take 22 cycles, which is as much as a mul, or am I mistaken? If I'm not, I'd just replace it with a mul permanently.

This multiply code replaces a LONG mul, which is 44 cycles or so, not 26 (28 ?) like a short one, which would have been impossible anyway.

Originally Posted by Thorham

Cool stugg That is never going to be the case with peecee software I assume it can be downloaded from your site?

Stugg ? I think you meant stuff. Damn keyboards, the g is just too close to the f

If you want my flac player, in fact you already have it. Remember my little player which did waves and aiffs ?

Originally Posted by Thorham

Not in zlib streams, which also use dynamic codes, meaning for some blocks a new table has to be calculated, which plain sucks It also seems that zlib streams send new tables reletively often, meaning the tables have to be calculated relatively often, and on top of that, theres always two tables per block. It's not easy for me to get that speedy.

But you got it to work, didn't you ? May I have a look at it ?

Originally Posted by Thorham

Quite a good question. Some of it is already uselessly slow on my peecee, on the other hand, there are people who like to make their programs fast, such as the before mentioned video player, but it's true that theres a lot of slow junk out there. And then people say 'Your computer is slow', yeah right, over a billion instructions per second slow? Please And another good one is calling software 'technology' Don't they now that a program isn't anything more than a list of instructions which tell a computer what to do? Crazy world out there.

Yeah, crazy world.

[Thorham]

Originally Posted by meynaf

I don't exactly know why we need to do that, but it's needed. Changing the constant would mess up the sound in some cases, and remain totally undetectable in others. This is the beauty of MP3

Hmm, stange, but have you actually tried it, or is it theory? If not, I would certainly try it, and test with a number of different mp3s.

Originally Posted by meynaf

This multiply code replaces a LONG mul, which is 44 cycles or so, not 26 (28 ?) like a short one, which would have been impossible anyway.

Well, than at least it is faster.

Originally Posted by meynaf

Stugg ? I think you meant stuff. Damn keyboards, the g is just too close to the f

If you want my flac player, in fact you already have it. Remember my little player which did waves and aiffs ?

Stugg? Hoo boy, now why would they put the f so close to the g

That one? Cool, I think I'm going to make some hq flacs, and try it out.

Originally Posted by meynaf

But you got it to work, didn't you ? May I have a look at it ?

Certainly. The code is not large, so I've put in in a code block at the end of this post.

Originally Posted by meynaf

Yeah, crazy world.

Insane

Here's the code. It handles the zlib stream header and makes the two fixed Huffman tables. That code should work properly. The expand table code makes a look up table from the large Huffman table, but it isn't well tested yet; seems to work, though.

;-----------------------------------------------------------------------------------
;Inflate.
;-----------------------------------------------------------------------------------
	incdir	"include:"
	include	"exec/exec_lib.i"
	include	"dos/dos_lib.i"
;-----------------------------------------------------------------------------------
;Allocmem flags:
;-----------------------------------------------------------------------------------
Mem_Public	=$00001
Mem_Chip	=$00002
Mem_Fast	=$00004
Mem_Public_Clear=$10001
Mem_Chip_Clear	=$10002
Mem_Fast_Clear	=$10004
;-----------------------------------------------------------------------------------
;Inflate constants:
;-----------------------------------------------------------------------------------
MAXBITS=15		;maximum bits in a code.
MAXLCODES=286		;maximum number of literal/length codes.
MAXDCODES=30		;maximum number of distance codes.
MAXCODES=MAXLCODES+MAXDCODES ;maximum codes lengths to read.
FIXLCODES=288		;number of fixed literal/length codes.
;-----------------------------------------------------------------------------------
;Inflate state structure (may not be needed after optimization):
;-----------------------------------------------------------------------------------
state.out	=00	;/* output buffer */
state.outlen	=04	;/* available space at out */
state.outcnt	=08	;/* bytes written to out so far */
state.in	=12	;/* input buffer */
state.inlen	=16	;/* available input at in */
state.incnt	=20	;/* bytes read so far */
state.bitbuf	=24	;/* bit buffer */
state.bitcnt	=28	;/* number of bits in bit buffer */
;-----------------------------------------------------------------------------------
Start	movem.l	d0-a6,-(sp)

	move.l	#In,a0

	move.l	#InData+12,00(a0)
	bsr	InflateInit

	movem.l	(sp)+,d0-a6
	rts
;-----------------------------------------------------------------------------------
InflateInit ;Initalization for Inflate.
;-----------------------------------------------------------------------------------
;In	00=data
;
;Out	00=Error value
;-----------------------------------------------------------------------------------
	movem.l	d0-a6,-(sp)

	move.l	#In,a0
	move.l	#Out,a6
	move.l	00(a0),a1	;Input data.

InlateInit_Handle_Header

	moveq	#0,d1
	move.b	(a1),d1		;Read CMF (Compression Method and flags).
	move.b	d1,d2

	and.b	#15,d1		;Get CM (compression mode).
	lsr.b	#4,d2		;Get CINFO (compression info).

	move.l	#-1,00(a6)
	cmp.l	#8,d1		;Check is stream is valid.
	bne	InflateInit_Error ;Error: Invalid stream.

	move.l	#-2,00(a6)
	cmp.l	#7,d2		;Check if sliding window size is valid.
	bgt	InflateInit_Error ;Error: Invalid sliding window size.

	move.l	#-3,00(a6)
	move.w	(a1)+,d3	;Check CMF+FCHECK to be multiple of 31--->

	btst.l	#5,d3		;Test if FLG.FDICT is set.
	bne	.cnt		;If so...
	move.l	(a1)+,dictid	;...store DICTID from stream.

.cnt	divu.w	#31,d3		;--->
	swap.w	d3		;
	cmp.w	#0,d3		;
	bne	InflateInit_Error ;Error: Invalid CMF+FCHECK.

	move.l	#0,00(a6)

	addq.l	#8,d2		;Calculate sliding window size...
	moveq	#1,d3		;...
	lsl.l	d2,d3		;...
	move.l	d3,winsize

InflateInit_Long_Table

.make_fixed
	move.l	#fixed_data,a0
	move.l	#fixed1_lens,a1
	moveq	#3,d0
.make_fixed_lp
	move.l	(a0)+,d1
	move.l	(a0)+,d2
.make_fixed_lp1
	move.l	d1,(a1)+
	dbra	d2,.make_fixed_lp1
	dbra	d0,.make_fixed_lp

;
; The follwing three loops are from inflates huffman table generator.
; Original code:
;
;1) Count the number of codes for each code length.  Let bl_count[N] be the
;number of codes of length N, N >= 1.
;
;2) Find the numerical value of the smallest code for each code length: 
;
;    code = 0;
;    bl_count[0] = 0;
;    for (bits = 1; bits <= MAX_BITS; bits++) {
;        code = (code + bl_count[bits-1]) << 1;
;        next_code[bits] = code;
;    }
;
;3) Assign  numerical values to  all codes, using consecutive values for all
;codes  of the same length with the base values determined at step 2.  Codes
;that  are never used (which have a bit length of zero) must not be assigned
;a value.
;
;    for (n = 0;  n <= max_code; n++) {
;        len = tree[n].Len;
;        if (len != 0) {
;            tree[n].Code = next_code[len];
;            next_code[len]++;
;        }
;    }
;
; This code is also going to be in the inflate loop.
;

.count_len
	move.l	#fixed1_lens,a6
	move.l	a6,a0
	move.l	#fixed1_bl_count,a1
	move.l	#fixlcodes,d7
	move.l	d7,d1
	subq.l	#1,d1
.count_len_lp
	move.l	(a0)+,d0
	addq.l	#1,(a1,d0.l*4)
	dbra	d1,.count_len_lp
.count_len_end

.find_smalest
	move.l	#fixed1_next_code,a5
	moveq	#0,d0
	move.l	d0,(a1)
	move.l	a5,a2
	addq.l	#4,a2
	moveq	#1,d1
	moveq	#maxbits-1,d3

.find_smalest_lp
	add.l	(a1)+,d0
	add.l	d0,d0
	move.l	d0,(a2)+
	dbra	d3,.find_smalest_lp
.find_smalest_end

.assign_val
	move.l	#fixed1_tree-4,a1

.assign_val_lp
	addq.l	#4,a1
	subq.l	#1,d7
	beq	.assign_val_end

	move.l	(a6)+,d2
	beq	.assign_val_lp

	move.l	(a5,d2.l*4),(a1)
	addq.l	#1,(a5,d2.l*4)
	bra	.assign_val_lp
.assign_val_end

;
; Because the Huffman codes in the zlib stream are reversed, a streight
; look-up table is calculated here.
;

.expand_table
	move.l	#fixed1_tree+(fixlcodes*4)-4,a0
	move.l	#fixed1_table,a1
	move.l	#fixed1_lens,a2
	move.l	#fixlcodes,d0
	move.w	#$cccc,d7	;11001100
	move.w	#$3333,d6	;00110011
	move.w	#$aaaa,d5	;10101010
	move.w	#$5555,d4	;01010101
	moveq	#8,d2	
	sub.l	a5,a5

.expand_table_lp
	subq.l	#1,d0
	beq	.expand_table_exit

	move.l	-(a0),d1
	move.l	(a2)+,a3

	sub.l	a4,a4

	cmp.l	d2,a3
	bgt	.expand_table_9
	beq	.expand_table_8

.expand_table_7
	addq.l	#2,a4
.expand_table_8
	addq.l	#2,a4
.expand_table_9

.expand_table_reverse
	ror.w	#1,d1	;byte 'swap' (works because above there was lsl.w #7,d1

	move.w	d1,d3

	and.w	d4,d1	;swap 1x1
	add.w	d1,d1
	and.w	d5,d3
	lsr.w	#1,d3
	or.w	d3,d1

	move.w	d1,d3

	and.w	d6,d1	;swap 2x1
	lsl.w	#2,d1
	and.w	d7,d3
	lsr.w	#2,d3
	or.w	d3,d1

	rol.b	#4,d1	;swap 4x1
	rol.w	#8,d1
	rol.b	#4,d1
	rol.w	#8,d1

	move.l	a4,d3
	beq	.expand_table2
	subq.l	#1,d3
	move.l	d1,a5
.expand_table_lp2
	move.l	a5,d1
	or.l	d3,d1

	move.l	d0,(a1,d1.l*4)

	subq.l	#1,d3
	bne	.expand_table_lp2

	move.l	a5,d1
	or.l	d3,d1

	move.l	d0,(a1,d1.l*4)
	bra	.expand_table_lp

.expand_table2
	move.l	d0,(a1,d1.l*4)
	bra	.expand_table_lp

.expand_table_exit

;
; Because the short table uses almost all possible five bit combinations
; it's impossible to make Huffman codes for them, so this loop should be
; enough.
;

InflateInit_Short_Table

.make_tree
	move.l	#fixed2_tree,a1
	moveq	#maxdcodes-1,d0
	moveq	#0,d1
.make_tree_lp
	move.l	d1,(a1)+
	addq.l	#1,d1
	dbra	d0,.make_tree_lp






InflateInit_Error
InflateInit_Exit

	movem.l	(sp)+,d0-a6
	rts
;-----------------------------------------------------------------------------------
In		dcb.l	32
Out		dcb.l	32
;-----------------------------------------------------------------------------------
		section	data,data_f
InData		incbin	"pngdata.deflate"
InDataEnd
InDataSize	=InDataEnd-InData
		even

		section	out_data,data_f
OutData		;dcb.b	2*1024*1024

		section	data2,data_f

fixed_data	dc.l	8,143-0
		dc.l	9,255-143
		dc.l	7,279-256
		dc.l	8,287-280

fixed1_lens	dcb.l	512
fixed1_tree	dcb.l	1024
fixed1_bl_count	dcb.l	1024
fixed1_next_code dcb.l	1024
fixed1_table	dcb.l	1024

fixed2_tree	dcb.l	1024

winsize		dc.l	0
dictid		dc.l	0
;-----------------------------------------------------------------------------------

That's it. When the look-up table routine works, I can start on decoding the Huffman codes, this part is the hardest. After that it's just LZ77s simple sliding window algorithm, which is a cake walk.

By the way, hows your internet conncetion? Still what you had, or have you sorted out something better? For your sake I hope it's getting fixed; being stuck with a slow/bad connection sucks (although, better slow and stable, than fast and down half the time)

Have fun

[meynaf]

Originally Posted by Thorham

Hmm, stange, but have you actually tried it, or is it theory? If not, I would certainly try it, and test with a number of different mp3s.

Ok, I have to admit it : I can't hear a difference or whatsoever.
But the speed gain is tiny : something like 1.33 seconds out of 1 minute, which is far from enough to be able to play in stereo high quality

But what I prefer is to quicken that stuff as much as possible to reach higher quality settings, not to decrease quality further.

Anyway this made another equ setting at the beginning...

Originally Posted by Thorham

Well, than at least it is faster.

Yes. But it wasn't hard : long muls are deadly slow

Originally Posted by Thorham

That one? Cool, I think I'm going to make some hq flacs, and try it out.

Since flac is a lossless format, high quality here is meaningless : quality is always at maximum.
If you meant high frequency, then you'd better not, as they won't play (too slow).
The better the compression ratio, the slower it will be. No big deal if stream is in mono or of a frequency lower than 28 khz, but in 44.1 stereo I had to limit lpc to 5 (you probably need to limit further because of 70ns ram).

Originally Posted by Thorham

Here's the code. It handles the zlib stream header and makes the two fixed Huffman tables. That code should work properly. The expand table code makes a look up table from the large Huffman table, but it isn't well tested yet; seems to work, though.

Damn little endian. The bit inversion looked like the hard part to me. Else I don't have much to say. This looked good to me.

Originally Posted by Thorham

That's it. When the look-up table routine works, I can start on decoding the Huffman codes, this part is the hardest. After that it's just LZ77s simple sliding window algorithm, which is a cake walk.

Then there's little remaining : just read the table from the data instead of making a fixed one, and decode the lz77. Good !

Originally Posted by Thorham

By the way, hows your internet conncetion? Still what you had, or have you sorted out something better? For your sake I hope it's getting fixed; being stuck with a slow/bad connection sucks (although, better slow and stable, than fast and down half the time)

Have fun

It's not very good, but it works enough for my use. And it's cheap

[Thorham]

Originally Posted by meynaf

Ok, I have to admit it : I can't hear a difference or whatsoever.
But the speed gain is tiny : something like 1.33 seconds out of 1 minute, which is far from enough to be able to play in stereo high quality

But what I prefer is to quicken that stuff as much as possible to reach higher quality settings, not to decrease quality further.

Yes, I know you like the quality to be the best possible, but if some constants can be simplyfied without affecting the quality, I'd try it if I were you. If your ears function normally, you should be able to experiment.

Originally Posted by meynaf

Anyway this made another equ setting at the beginning...

Of course making it an option is possible, too

Originally Posted by meynaf

Yes. But it wasn't hard : long muls are deadly slow

Yeah, those stinkers suck big time. The 'advantage' is that they can be very well optimized, though

Originally Posted by meynaf

Since flac is a lossless format, high quality here is meaningless : quality is always at maximum.
If you meant high frequency, then you'd better not, as they won't play (too slow).
The better the compression ratio, the slower it will be. No big deal if stream is in mono or of a frequency lower than 28 khz, but in 44.1 stereo I had to limit lpc to 5 (you probably need to limit further because of 70ns ram).

Hmm, interesting. What compression method do they actually use for flac?

Originally Posted by meynaf

Damn little endian. The bit inversion looked like the hard part to me. Else I don't have much to say. This looked good to me.

Thanks Yes, bit level little endian sucks, because all the bits are reversed, not just bytes (then a swap and two rotates whould do ). This thing is almost like transposing for c2p. It's also code I've added, as it's not in the original table generation routines, and actually it wasn't that hard to write, but I want it optimized if possible.

Originally Posted by meynaf

Then there's little remaining : just read the table from the data instead of making a fixed one, and decode the lz77. Good !

Erm, I can't! Two fixed tables are always needed, and the dynamic Huffman tables are stored with just the code lengths, so that each code can be stored with just four bits, and then those codes are, you guesed it, Huffman encoded, too, argh

Originally Posted by meynaf

It's not very good, but it works enough for my use. And it's cheap

Well, as long as it isn't dial-up, how bad can it be?

[meynaf]

Originally Posted by Thorham

Yes, I know you like the quality to be the best possible, but if some constants can be simplyfied without affecting the quality, I'd try it if I were you. If your ears function normally, you should be able to experiment.

Certainly, but I already had troubles with some "simplifications" I did. They worked perfectly... and one day I found an MP3 on which they failed.
So I prefer to be mistrustful about that, and look for the binary equivalence first.
Also, I can't say I listen on those on a hi-fi system, so some differences might escape

Originally Posted by Thorham

Of course making it an option is possible, too

And it's done. Like the removal of the frequency filter

Originally Posted by Thorham

Yeah, those stinkers suck big time. The 'advantage' is that they can be very well optimized, though

Sadly, not all of them. They can't be optimized if both values to multiply are variable. The case happens in my flac decoder when values reach 17 bits.

On the other hand longs muls are very practical if speed isn't an issue.

Originally Posted by Thorham

Hmm, interesting. What compression method do they actually use for flac?

They generate a waveform with some sort of mathematical artifact, and try to get as close as possible by changing some parameters of it. Then they encode the difference between this prediction and the real signal with Rice codes.
Of course they operate on small blocks.

There probably is a lot of litterature about this on the net, google it if you want more detailed information than mine. I'm not an expert

Also see the "shorten" program on Aminet, it's pretty much the same.

Originally Posted by Thorham

Thanks Yes, bit level little endian sucks, because all the bits are reversed, not just bytes (then a swap and two rotates whould do ). This thing is almost like transposing for c2p. It's also code I've added, as it's not in the original table generation routines, and actually it wasn't that hard to write, but I want it optimized if possible.

Too bad we don't have the coldfire instructions, the "bitrev" one would have been very handy !
However, maybe a 256-byte table could spare some work ?

Originally Posted by Thorham

Erm, I can't! Two fixed tables are always needed, and the dynamic Huffman tables are stored with just the code lengths, so that each code can be stored with just four bits, and then those codes are, you guesed it, Huffman encoded, too, argh

Yeah, huffman encoded with huffman. We could scream, but even lha does that

Originally Posted by Thorham

Well, as long as it isn't dial-up, how bad can it be?

Errrhm... ahem... It is dial-up...
Then again I don't use it a lot, so to get my emails and post here, it's enough. And I'm using the miggy to do all that
Knowing myself if I had a quick connection I would be over the net all day long

[Thorham]

Originally Posted by meynaf

Certainly, but I already had troubles with some "simplifications" I did. They worked perfectly... and one day I found an MP3 on which they failed.
So I prefer to be mistrustful about that, and look for the binary equivalence first.
Also, I can't say I listen on those on a hi-fi system, so some differences might escape

Hmm, then you'd better leave it the way it is. This is quite different from jpegs where those simplifications have a lot less effect.

Originally Posted by meynaf

And it's done. Like the removal of the frequency filter

Good, the more options for users to play with, the better.

Originally Posted by meynaf

Sadly, not all of them. They can't be optimized if both values to multiply are variable. The case happens in my flac decoder when values reach 17 bits.

Can you perhaps make a table? Or are there too many different values?

Originally Posted by meynaf

On the other hand longs muls are very practical if speed isn't an issue.

They are. But for non optimizeable multiplications you don't have a choice any way.

Originally Posted by meynaf

They generate a waveform with some sort of mathematical artifact, and try to get as close as possible by changing some parameters of it. Then they encode the difference between this prediction and the real signal with Rice codes.
Of course they operate on small blocks.

Hey, that looks like something I once came up with. Never looked at it seriously though, because my math knowledge is vastly lacking.

Originally Posted by meynaf

There probably is a lot of litterature about this on the net, google it if you want more detailed information than mine. I'm not an expert

Also see the "shorten" program on Aminet, it's pretty much the same.

Interesting stuff; I'm going to take a look to see.

Originally Posted by meynaf

Too bad we don't have the coldfire instructions, the "bitrev" one would have been very handy !
However, maybe a 256-byte table could spare some work ?

Yes, it would really be handy. I suppose a swap table would do the trick, thanks for the tip

Originally Posted by meynaf

Yeah, huffman encoded with huffman. We could scream, but even lha does that

Wonderful, isn't it Oh well, who cares, even though it kind of sucks.

Originally Posted by meynaf

Errrhm... ahem... It is dial-up...
Then again I don't use it a lot, so to get my emails and post here, it's enough. And I'm using the miggy to do all that
Knowing myself if I had a quick connection I would be over the net all day long

I know exactly what you mean. I've got a 10 megabit connection (part of the flat) and I spend way too much time online. It's a huge waste of time, and it's the reason why I'm so slow with coding. Bah, it's just ridiculous

I think I can finish the inflater this week, if only I wouldn't spend so much time online. I'll try to cutback and do some work for a change

[meynaf]

Originally Posted by Thorham

Hmm, then you'd better leave it the way it is. This is quite different from jpegs where those simplifications have a lot less effect.

The problem with those is that one file may behave very different from another. You simplify a multiply : well. But if the file you test afterwards doesn't contain that particular affected frequency, you've missed the point.

Originally Posted by Thorham

Good, the more options for users to play with, the better.

Options at source level only I'm afraid...

Originally Posted by Thorham

Can you perhaps make a table? Or are there too many different values?

Make a table ? If the making of this table is quick enough, then maybe. But one of the input is the data itself, where the other is directly given in the header of a frame. A frame here means 4096 samples or so ; may be more or less.

I thought about some sort of a JIT to generate multiply code on-the-fly when reading that coefficient array (which is 32 entries at maximum). Gosh. Just too much work.

Originally Posted by Thorham

They are. But for non optimizeable multiplications you don't have a choice any way.

Sure. If only the '030 had hardwired multiplies like the '060...

Originally Posted by Thorham

Hey, that looks like something I once came up with. Never looked at it seriously though, because my math knowledge is vastly lacking.

This is quite common stuff, a lot of lossless audio formats (e.g. Monkey Audio) do the same. Then again, what else to do ?

Originally Posted by Thorham

Interesting stuff; I'm going to take a look to see.

Personnally I hunted for a lossless coding when I wanted to reduce disk space occupied by my wave files. I found flac to be good for me because it only uses integer maths. I just hate floating-point stuff

Originally Posted by Thorham

Yes, it would really be handy. I suppose a swap table would do the trick, thanks for the tip

Oh, it's not my trick. I just found it in Silmarils games
(was used to reverse the gfx horizontally).

Originally Posted by Thorham

Wonderful, isn't it Oh well, who cares, even though it kind of sucks.

Maybe you can use the same routine for huffman codes and the data itself ? If so, that stuff won't bother you anymore !

Originally Posted by Thorham

I know exactly what you mean. I've got a 10 megabit connection (part of the flat) and I spend way too much time online. It's a huge waste of time, and it's the reason why I'm so slow with coding. Bah, it's just ridiculous

I think I can finish the inflater this week, if only I wouldn't spend so much time online. I'll try to cutback and do some work for a change

Internet creates a drug-like dependency, that's why I think it is toxic

[Thorham]

Sorry for taking so looooong to reply

Originally Posted by meynaf

The problem with those is that one file may behave very different from another. You simplify a multiply : well. But if the file you test afterwards doesn't contain that particular affected frequency, you've missed the point.

Right. Same applies to png files, where each line can be encoded in one of five ways. Not a problem to optimize, though.

Originally Posted by meynaf

Options at source level only I'm afraid...

And I'd keep it that way. First debug the software properly, then write an option parser. These are simple, of course, but you still only want to make one once the software works, and also only once; one properly written parser can be reused over and over again.

Originally Posted by meynaf

Make a table ? If the making of this table is quick enough, then maybe. But one of the input is the data itself, where the other is directly given in the header of a frame. A frame here means 4096 samples or so ; may be more or less.

Oops, 4k samples is nothing. I have a similar problem with dynamic Huffman decoding; if a block is short, the table will require too long to make.

Originally Posted by meynaf

I thought about some sort of a JIT to generate multiply code on-the-fly when reading that coefficient array (which is 32 entries at maximum). Gosh. Just too much work.

Hey, cool! Wouldn't it be a good idea to just generate the code before playing the flac, and then store the code with the flac file? I know that the amount of work won't decrease, but it would still be pretty damned bitchin' if you ask me. You're right, of course; it would be a lot of work. It's something I once thought of to get snes and gba games to work on the Amiga. Guess it's easier to just port them by hand.

Originally Posted by meynaf

Sure. If only the '030 had hardwired multiplies like the '060...

Yes, indeed, but it does increase the challenge.

Originally Posted by meynaf

This is quite common stuff, a lot of lossless audio formats (e.g. Monkey Audio) do the same. Then again, what else to do ?

Why not make an intelligent system that can separate the channels, extract the frequencies of all the samples, and just convert the music to mod? Also, with a simple speech synth, the software could also sing all the lyrics Hehe, if only we knew how to write something like that; it'd be fantastic, but you're right, if you want to keep it simple, you don't have much choice at all.

Originally Posted by meynaf

Personnally I hunted for a lossless coding when I wanted to reduce disk space occupied by my wave files. I found flac to be good for me because it only uses integer maths. I just hate floating-point stuff

Makes sense, but I prefer to store them plain, because of replay overhead; I use 16bit 24khz stereo wavs, which means I get very little cpu usage. If only Commodore had doubled the audio dma speed, but as it stands, I just convert from 44khz to 24khz.

As for disk space, I have a 40gig hd and I'm now using sfs with ide fix (gonna register it) so I can use the whole disk. Yep, I finally took the time to set this up. Seemed like a waste, especially because I bought the drive new for my miggy; it's not some old spare hd (don't use old drives as work drives, new is large and cheap) so I basically had 36gigs of brand new, unused disk space. This size is rediculous for an Amiga, so I thought, why not just fill it up with wavs?

Originally Posted by meynaf

Oh, it's not my trick. I just found it in Silmarils games
(was used to reverse the gfx horizontally).

Ah, the good old sprite flipping trick. Old consoles, like the snes, can do it in hardware. Still, it's a good idea that I didn't come up with, so thanks anyway

Originally Posted by meynaf

Maybe you can use the same routine for huffman codes and the data itself ? If so, that stuff won't bother you anymore !

Maybe. Hopefully. But that's actually the least of my problems. Remember I said I could finish the code in the rest of last (?) week? Well, although I haven't worked on it a lot, there was more trouble; using a table based decoding scheme for the fixed Huffman parts is simple enough, because there are only four types of codes: 5, 7, 8 and 9 bit codes. And the 5 bit codes aren't really Huffman codes, but just plain numbers (if I'm correct). The problem is with the dynamic Huffman codes, which can be anything from 1 bit to 15 bits long. Although I must again admit I haven't worked on it a lot, I have been putting it off in favor of something else important, the png decoder it self, check it out:

;-----------------------------------------------------------------------------------
Decode_Png_24	;Decodes a decompressed 24bit png image.
;-----------------------------------------------------------------------------------
	movem.l	d0-a6,-(sp)

	move.l	#rgb_out,a0
	move.l	#png_image,a1

	move.l	png_width,d7
	mulu.w	#3,d7
	move.l	png_height,d1

	addq.l	#1,d1
.loop_y
	subq.l	#1,d1
	beq	.end

	move.b	(a1)+,d2

	cmp.b	#3,d2
	bgt	.case4
	beq	.case3
	cmp.b	#1,d2
	bgt	.case2
	beq	.case1

.case0
	move.l	png_width,d3
	lsr.l	#2,d3
	subq.l	#1,d3
.case0_loop
	move.l	(a1)+,(a0)+
	move.l	(a1)+,(a0)+
	move.l	(a1)+,(a0)+

	dbra	d3,.case0_loop
	bra	.loop_y

.case1
	move.l	png_width,d3
	subq.l	#1,d3

	moveq	#0,d4
	moveq	#0,d5
	moveq	#0,d6
.case1_loop
	add.b	(a1)+,d4
	move.b	d4,(a0)+

	add.b	(a1)+,d5
	move.b	d5,(a0)+

	add.b	(a1)+,d6
	move.b	d6,(a0)+

	dbra	d3,.case1_loop
	bra	.loop_y

.case2
	move.l	png_width,d3
	subq.l	#1,d3

	move.l	a0,a2
	sub.l	d7,a2
.case2_loop
	move.b	(a2)+,d4
	add.b	(a1)+,d4
	move.b	d4,(a0)+

	move.b	(a2)+,d4
	add.b	(a1)+,d4
	move.b	d4,(a0)+

	move.b	(a2)+,d4
	add.b	(a1)+,d4
	move.b	d4,(a0)+

	dbra	d3,.case2_loop
	bra	.loop_y

.case3
	move.l	png_width,d3
	subq.l	#1,d3

	move.l	a0,a2
	sub.l	d7,a2

	moveq	#0,d2
	moveq	#0,d4
	moveq	#0,d5
	moveq	#0,d6
.case3_loop
	move.b	(a2)+,d2
	add.w	d2,d4
	lsr.w	#1,d4
	add.b	(a1)+,d4
	move.b	d4,(a0)+

	move.b	(a2)+,d2
	add.w	d2,d5
	lsr.w	#1,d5
	add.b	(a1)+,d5
	move.b	d5,(a0)+

	move.b	(a2)+,d2
	add.w	d2,d6
	lsr.w	#1,d6
	add.b	(a1)+,d6
	move.b	d6,(a0)+

	dbra	d3,.case3_loop
	bra	.loop_y

;			If y>0 Then c=Point(x,y-1) Else c=0
;			r2=c\65536:g2=(c\256) And 255:b2=c And 255
;			If y>0 And x>0 Then c=Point(x-1,y-1) Else c=0
;			r3=c\65536:g3=(c\256) And 255:b3=c And 255
;
;			r=dat(adr+0)+Paeth(r1,r2,r3)
;			g=dat(adr+1)+Paeth(g1,g2,g3)
;			b=dat(adr+2)+Paeth(b1,b2,b3)
;			PSet(x,y),RGB(r,g,b)

;The following loop needs to be unrolled once. Also, because decoding a whole pixel in one go makes.
;the loop too large for the cache, it's going to handle the date per gun color, and just get executed
;three times per scan line.

.case4
	move.l	png_width,d3
	subq.l	#1,d3

	move.l	a0,a2
	sub.l	d7,a2		;x,y-1
	move.l	a2,a3
	subq.l	#3,a3		;x-1,y-1

	movem.l	d1/d7,-(sp)

	moveq	#0,d0
	moveq	#0,d2
	moveq	#0,d4

.case4_loop
	move.b	(a2),d2		;r2
	move.b	(a3),d0		;r3

.case4_peath
	move.l	d4,d1
	add.l	d2,d1
	sub.l	d0,d1

	move.l	d1,d5
	sub.l	d4,d5
	bge	.case4_peath1
	neg.l	d5

.case4_peath1
	move.l	d1,d6
	sub.l	d2,d6
	bge	.case4_peath2
	neg.l	d6

.case4_peath2
	move.l	d1,d7
	sub.l	d0,d7
	bge	.case4_peath3
	neg.l	d7

.case4_peath3
	cmp.l	d6,d5
	bgt	.case4_peath4
	cmp.l	d7,d5
	bgt	.case4_peath4

	add.b	(a1),d4
	bra	.case4_peati

.case4_peath4
	move.b	(a1),d4

	cmp.l	d7,d6
	bgt	.case4_peath5

	add.b	d2,d4
	bra	.case4_peati

.case4_peath5
	add.b	d0,d4

.case4_peati
	move.b	d4,(a0)
	addq.l	#3,a0
	addq.l	#3,a1
	addq.l	#3,a2
	addq.l	#3,a3

.end
	movem.l	(sp)+,d0-a6
	rts
;-----------------------------------------------------------------------------------
png_width	dc.l	640
png_height	dc.l	512
png_image
rgb_out
;-----------------------------------------------------------------------------------

[Thorham]

The above code is besed on the algorithms in the following freebasic code:

function Paeth(a As integer, b As integer, c As Integer) As integer
	Dim As Integer p,pa,pb,pc
	' a = left, b = above, c = upper Left
	p = a + b - c        ' initial estimate
	pa = abs(p - a)      ' distances to a, b, c
	pb = abs(p - b)
	pc = abs(p - c)
	' return nearest of a,b,c,
	' breaking ties in order a,b,c.
	if pa <= pb AND pa <= pc Then
		return a
	elseif pb <= pc then
		return b
	Else
		return c
	EndIf


End function

ScreenRes 1280,1024,32

Dim As Integer f,l

f = FreeFile
Open "e:\out.inf" For Binary As #f
l=Lof(f)
Dim As UByte dat(l)
Get #f, , dat()
Close #f


Dim As uInteger x,y,adr,c
Dim As Ubyte r,g,b
Dim As ubyte r1,g1,b1
Dim As ubyte r2,g2,b2
Dim As ubyte r3,g3,b3

For y=0 To 768-1
	If InKey$<>"" Then stop
	f=dat(adr)
	adr=adr+1
	r=0:g=0:b=0
	For x=0 To 500-1

		r1=r:g1=g:b1=b

		If f=0 Then
			PSet(x,y),RGB(dat(adr+0),dat(adr+1),dat(adr+2))
		End if

		If f=1 Then
			r=r1+dat(adr+0):g=g1+dat(adr+1):b=b1+dat(adr+2)
			PSet(x,y),RGB(r,g,b)
		End if

		If f=2 Then
			If y>0 Then c=Point(x,y-1) Else c=0
			r2=c\65536:g2=(c\256) And 255:b2=c And 255

			r=dat(adr+0)+r2
			g=dat(adr+1)+g2
			b=dat(adr+2)+b2
			PSet(x,y),RGB(r,g,b)
		EndIf

		If f=3 Then
			If y>0 Then c=Point(x,y-1) Else c=0
			r2=c\65536:g2=(c\256) And 255:b2=c And 255

			r=dat(adr+0)+(r1+r2)\2
			g=dat(adr+1)+(g1+g2)\2
			b=dat(adr+2)+(b1+b2)\2
			PSet(x,y),RGB(r,g,b)
		End if

		If f=4 Then
			If y>0 Then c=Point(x,y-1) Else c=0
			r2=c\65536:g2=(c\256) And 255:b2=c And 255
			If y>0 And x>0 Then c=Point(x-1,y-1) Else c=0
			r3=c\65536:g3=(c\256) And 255:b3=c And 255

			r=dat(adr+0)+Paeth(r1,r2,r3)
			g=dat(adr+1)+Paeth(g1,g2,g3)
			b=dat(adr+2)+Paeth(b1,b2,b3)
			PSet(x,y),RGB(r,g,b)
		End if




		adr=adr+3

	Next
Next

sleep

Basically, the above assembler code has almost everything implemented, I just have to tie up the loose ends, and thats it. However, if you look at the terribly unoptimized basic code (freebasic is actually quite fast, but I've written this as simple as possible), you'll see that it's possible to decode two lines in one go. This will save some memory reads. Because you can't have all combinations of cases, theres only about 19 (I think) useful combinations (jump to with a bra table). This would be most useful for case 4, the Peath case.

So I haven't been doing nothing, the progress is just a little slow.

Originally Posted by meynaf

Internet creates a drug-like dependency, that's why I think it is toxic

It is. I've only had internet since the end of last year, and I'm already an addict. I used to just go to the library to use the net for free when I really needed something. They provide a great service; you get to use the net for 30 minutes. If it's not busy, you can use it for as long as you like, until it does get busy, they allow usb sticks, and they can burn what you've downloaded to cd, for free. Further more, it's only a five minute walk from where I live, so what more does a person need? Having a fast connection at home is convenient, but it's also just a luxury one can live without. Although, if you have to believe some people, internet is essential, and you can't live without it, yeah right, what a load of bull droppings

Originally Posted by vBulletin® Version 3.7.0

1. The text that you have entered is too long (11381 characters). Please shorten it to 10000 characters long.

To any moderators reading this, is there any way to increase the post size? Or has is been limited on purpose?

[meynaf]

Originally Posted by Thorham

Sorry for taking so looooong to reply

Happy to see you're still alive

Originally Posted by Thorham

Right. Same applies to png files, where each line can be encoded in one of five ways. Not a problem to optimize, though.

Yeah, those 5 ways are quite simple, at least the first 4

Originally Posted by Thorham

And I'd keep it that way. First debug the software properly, then write an option parser. These are simple, of course, but you still only want to make one once the software works, and also only once; one properly written parser can be reused over and over again.

I rather planned to do several versions with that ; say, one for '030, one for'040, one for '060, depending on which settings are the most efficient, and leave the "quality-damaging" stuff on the existing "quality" setting.
Say, if we selected "low" quality, we don't bother about a frequency filter

About the option parser : for now dos.library's ReadArgs() is enough for me...
But as a general rule, when I have something that works well, I keep it for reusing. My "sysbtm.i" include is full of that stuff

Originally Posted by Thorham

Oops, 4k samples is nothing. I have a similar problem with dynamic Huffman decoding; if a block is short, the table will require too long to make.

Bah, I wouldn't worry about short blocks if I were you. We just need to be faster than other viewers, and they have the same problem.

Originally Posted by Thorham

Hey, cool! Wouldn't it be a good idea to just generate the code before playing the flac, and then store the code with the flac file? I know that the amount of work won't decrease, but it would still be pretty damned bitchin' if you ask me. You're right, of course; it would be a lot of work.

Store the code in the flac file... Hmmm... would take up some space, but that would be compensated with a higher LPC setting... This idea has to be thought twice about !

Originally Posted by Thorham

It's something I once thought of to get snes and gba games to work on the Miggy. Guess it's easier to just port them by hand.

Ah, seeing that old good Zelda 3 on the Miggy... Technically it is doable, but... *ahem*

Originally Posted by Thorham

Yes, indeed, but it does increase the challenge.

I don't think we need this to get a challenge if you ask me

Originally Posted by Thorham

Why not make an intelligent system that can separate the channels, extract the frequencies of all the samples, and just convert the music to mod? Also, with a simple speech synth, the software could also sing all the lyrics
Hehe, if only we knew how to write something like that; it'd be fantastic, but you're right, if you want to keep it simple, you don't have much choice at all.

Getting the frequencies is no big deal, but getting the samples from that is something else. AFAIK existing speech recognition software have big problems with background noise, so separating instruments isn't for today...

Anyway this may well be the future of sound compression. If you listen at the average song you will discover it is very repetitive, and actual compressors aren't removing this redundancy !

Originally Posted by Thorham

Makes sense, but I prefer to store them plain, because of replay overhead; I use 16bit 24khz stereo wavs, which means I get very little cpu usage. If only Commodore had doubled the audio dma speed, but as it stands, I just convert from 44khz to 24khz.

I personnally convert them to 26460 Hz (easy-to-do 5:3), but if you encode your waves with -l 1 option of flac encoder, you'll end up with flacs that can be played with 20-30% cpu use.

Originally Posted by Thorham

As for disk space, I have a 40gig hd and I'm now using sfs with ide fix (gonna register it) so I can use the whole disk. Yep, I finally took the time to set this up. Seemed like a waste, especially because I bought the drive new for my miggy; it's not some old spare hd (don't use old drives as work drives, new is large and cheap) so I basically had 36gigs of brand new, unused disk space. This size is rediculous for an Amiga, so I thought, why not just fill it up with wavs?

Strange... My 20 GB HD is 80-90% full...
Then again I've got a huge collection of MP3's that need to be sorted
Not to mention the 2 Gb of -ahem- jpegs.

Originally Posted by Thorham

Ah, the good old sprite flipping trick. Old consoles, like the snes, can do it in hardware. Still, it's a good idea that I didn't come up with, so thanks anyway

Why, even DM2 - that very same DM2 you play with Torham alone (how far can one go like that ?!) - does this

Originally Posted by Thorham

Maybe. Hopefully. But that's actually the least of my problems. Remember I said I could finish the code in the rest of last (?) week? Well, although I haven't worked on it a lot, there was more trouble; using a table based decoding scheme for the fixed Huffman parts is simple enough, because there are only four types of codes: 5, 7, 8 and 9 bit codes. And the 5 bit codes aren't really Huffman codes, but just plain numbers (if I'm correct). The problem is with the dynamic Huffman codes, which can be anything from 1 bit to 15 bits long. Although I must again admit I haven't worked on it a lot, I have been putting it off in favor of something else important, the png decoder it self, check it out

Hey, but that means that if we can encode uncompressed pngs, we're very close to be able to actually see something ???

I admit I haven't worked on my viewer recently ; even the mpeg audio project is rather sleepy these days (even though Don Adan - whom I helped quite a lot with his ADPCM player and is helping me in return here - sometimes wakes it up with opt ideas).
I'm actually attempting to design a custom dungeon for good old DM1 and it takes a lot of time

Originally Posted by Thorham

The above code is besed on the algorithms in the following freebasic code
(...)

Basically, the above assembler code has almost everything implemented, I just have to tie up the loose ends, and thats it. However, if you look at the terribly unoptimized basic code (freebasic is actually quite fast, but I've written this as simple as possible), you'll see that it's possible to decode two lines in one go. This will save some memory reads. Because you can't have all combinations of cases, theres only about 19 (I think) useful combinations (jump to with a bra table). This would be most useful for case 4, the Peath case.

So I haven't been doing nothing, the progress is just a little slow.

No problem, we have the time

Originally Posted by Thorham

It is. I've only had internet since the end of last year, and I'm already an addict. I used to just go to the library to use the net for free when I really needed something. They provide a great service; you get to use the net for 30 minutes. If it's not busy, you can use it for as long as you like, until it does get busy, they allow usb sticks, and they can burn what you've downloaded to cd, for free. Further more, it's only a five minute walk from where I live, so what more does a person need? Having a fast connection at home is convenient, but it's also just a luxury one can live without. Although, if you have to believe some people, internet is essential, and you can't live without it, yeah right, what a load of bull droppings

What's strange is that I've had a connexion since year 1999 or so and I never used it too much...

[Thorham]

Originally Posted by meynaf

Happy to see you're still alive

Thank you

Originally Posted by meynaf

Yeah, those 5 ways are quite simple, at least the first 4

In my opinion, peath is also not too hard. They did a great job explaining it with pseudo code that was very easy to get to work if freebasic. The only problem with it is that the code won't fit inside the cache if you try to do whole pixels in one go. But that's no problem seeing how png works on bytes, not pixels.

Originally Posted by meynaf

I rather planned to do several versions with that ; say, one for '030, one for'040, one for '060, depending on which settings are the most efficient, and leave the "quality-damaging" stuff on the existing "quality" setting.

That would be necessary, of course. But, how are you going to test all those different versions if you would decide to do it? Do you have multiple accelerator boards? If so, then you're a lucky git

Originally Posted by meynaf

Say, if we selected "low" quality, we don't bother about a frequency filter

I know flac is lossless, but if it's possible to just decode with a lower precision, then speed should be gained, while it wouldn't necessarily be audible in 14bit playback, or at least it shouldn't sound nasty. Oh, and what does the frequency filter do? Does it just remove frequencies? If so, I'd really just dump it.

Originally Posted by meynaf

About the option parser : for now dos.library's ReadArgs() is enough for me...

I didn't know dos had a parser. Is it any good? It wouldn't be hard to write an advanced one.

Originally Posted by meynaf

But as a general rule, when I have something that works well, I keep it for reusing. My "sysbtm.i" include is full of that stuff

Yeah, it'd be stupid to throw perfectly good code away, plus, when you reuse the same code in the way you do with sysbtm.i, if you find a bug, just fix it, and reassemble all you're programs. Done.

Originally Posted by meynaf

Bah, I wouldn't worry about short blocks if I were you. We just need to be faster than other viewers, and they have the same problem.

I guess so, but it still bothers me that I can't really think of a really good method. I may be getting there, but it's not as easy as I had hoped at all

Originally Posted by meynaf

Store the code in the flac file... Hmmm... would take up some space, but that would be compensated with a higher LPC setting... This idea has to be thought twice about !

Well, not exactly in the file, just as a separate file so that the flac stays compatible with all the other players. That also has the added advantage of making the flac code easy to update with better jitted (new word) coded. Also, how much code are we talking about per flac? Probably not that much, and it could be compressed.

Originally Posted by meynaf

Ah, seeing that old good Zelda 3 on the Miggy... Technically it is doable, but... *ahem*

Such games are quite easy to port. Zelda 3 from the snes has all the graphics in planar mode already, so the only problem with porting those games is actually getting hold of all the graphics, sound effects and music (and levels...). In the snes case, the gfx can be encoded/compressed (they do that on the gba a lot, which has decompression routines in the bios, which sucks rocks big time), and the sound effects and music are handled by a separate cpu (which may actually be an advantage). Or just use zsnes (current version is totally amazing).

Originally Posted by meynaf

I don't think we need this to get a challenge if you ask me

You're right, of course. Some people do like challenges I'm one of them, but not always.

Originally Posted by meynaf

Getting the frequencies is no big deal, but getting the samples from that is something else. AFAIK existing speech recognition software have big problems with background noise, so separating instruments isn't for today...

Anyway this may well be the future of sound compression. If you listen at the average song you will discover it is very repetitive, and actual compressors aren't removing this redundancy !

Yes, it's not of today. Also, as long as they're fooling around with neural nets, trying to emulate brain functions and not concentrating on making proper algorithms, which would beat the brain into a pulp anyway (the brain is a horrible mess of cemplexity, and it's slow: 1000 hz, why anyone would want to waste the awesome power that is the cpu on that crap is beyond me), it's not going to happen. As you can see, I have strong feelings about this. However, I meant the idea, which in theory should work just fine, as a joke. But as you've mentioned all the repeating patterns, it made me wonder if it really is a joke, or a serious possibility.

Originally Posted by meynaf

I personnally convert them to 26460 Hz (easy-to-do 5:3), but if you encode your waves with -l 1 option of flac encoder, you'll end up with flacs that can be played with 20-30% cpu use.

20 to 30 percent isn't really a lot. Those are very good results, especially if the sound quality is good. Do you know of any good peecee programs to convert wavs with? Or, better yet, mp3 to flac directly with controllable frequency?

Originally Posted by meynaf

Strange... My 20 GB HD is 80-90% full...
Then again I've got a huge collection of MP3's that need to be sorted
Not to mention the 2 Gb of -ahem- jpegs.

Wow, that's just amazing. I don't have a lot of music and pictures on my miggy, although the music is going to change. I even have all of Killer Gorillas whdload packages on the hd (games and demos) and that still is only about three gigs.

Originally Posted by meynaf

Why, even DM2 - that very same DM2 you play with Torham alone (how far can one go like that ?!) - does this

Didn't know that. I always assumed everyone just preflipped all their graphics. On a side note, both DM1 and DM2 are perfectly completable with just one character. Because of the leveling system, that single character ends up being a lot stronger in all areas (except maybe ninja levels) than the characters in a four character party. Really, you should try it.

Originally Posted by meynaf

Hey, but that means that if we can encode uncompressed pngs, we're very close to be able to actually see something ???

Yes, but only for decompressed pngs, not for noncompressed ones, as these don't encode the data, and are similar to bmps. The whole encoding scheme is just there to achieve better compression ratios. I have, however, modified a little freebasic program that allows decompressing zlib streams, so yes, we're very close to seeing something, especially since the freebasic decoder is fully functioning code. Hey, as I've said, I'm not doing nothing, it's just going slow

Originally Posted by meynaf

I admit I haven't worked on my viewer recently ; even the mpeg audio project is rather sleepy these days (even though Don Adan - whom I helped quite a lot with his ADPCM player and is helping me in return here - sometimes wakes it up with opt ideas).
I'm actually attempting to design a custom dungeon for good old DM1 and it takes a lot of time

It's hard to finish things, isn't it? A few months ago, I started work on a brilliance clone in freebasic, because I was getting fed up with all that peecee crap. The only work that has been done so far, is a fast indexed screen with 32 bit indexes Important, but still only a small part.

As for that dungeon, if it turns out to be a good dungeon, upload to the zone, please.

Originally Posted by meynaf

No problem, we have the time

All the time in the universe. But still, I'd really like to finish something sometime soon.

Originally Posted by meynaf

What's strange is that I've had a connexion since year 1999 or so and I never used it too much...

Trust me, if you've got a broadband connection on a quick peecee, you'll end up using it more than you really need to. Before I had mine, I didn't use the net a lot either.

And how come you don't have a peecee? Do you hate them that much

[BippyM]

Guys why don't you just reply here instead of wasting that little bit of bandwidth of posting the PMs twice (as a PM and here!)

[Thorham]

Originally Posted by bippym

Guys why don't you just reply here instead of wasting that little bit of bandwidth of posting the PMs twice (as a PM and here!)

We're not posting pms here. This discussions originally started out through the pm system, but we've stopped that and continued here!

[meynaf]

Originally Posted by Thorham

We're not posting pms here. This discussions originally started out through the pm system, but we've stopped that and continued here!

But apparently no-one can follow us

[meynaf]

Originally Posted by Thorham

In my opinion, peath is also not too hard. They did a great job explaining it with pseudo code that was very easy to get to work if freebasic. The only problem with it is that the code won't fit inside the cache if you try to do whole pixels in one go. But that's no problem seeing how png works on bytes, not pixels.

Sure. The main problem about png is that deflate thingy.

Originally Posted by Thorham

That would be necessary, of course. But, how are you going to test all those different versions if you would decide to do it? Do you have multiple accelerator boards? If so, then you're a lucky git

Alas I don't have anything but 020/030. However there might be people here on these fine forums who have 040 or 060, I think. Maybe one will be willing to test...

Originally Posted by Thorham

I know flac is lossless, but if it's possible to just decode with a lower precision, then speed should be gained, while it wouldn't necessarily be audible in 14bit playback, or at least it shouldn't sound nasty.

Unfortunately this is not possible. The decoding process relies a lot on previously emitted data, and an error here would accumulate and completely destroy the wave form.
Besides, there is no significant speed difference between 8 and 16 bits. Just the size changes, and most of the code is common for both.

Originally Posted by Thorham

Oh, and what does the frequency filter do? Does it just remove frequencies? If so, I'd really just dump it.

It is an anti-alias sort of filtering. I don't know much about it ; I already have an equate to dump it.
The sound is slightly clearer with it, and it roughly takes 3% cpu. An option to be kept for high quality setting and dropped for low and medium, I think.

Originally Posted by Thorham

I didn't know dos had a parser. Is it any good? It wouldn't be hard to write an advanced one.

Is ReadArgs() good ? For me, it simply rocks ! One of the reasons I love AmigaOS !
It appeared in 2.0 roms, and is perhaps among the things that made arp.library obsolete. See docs if you want to know more about it ; must have been a pain to write.

Originally Posted by Thorham

Yeah, it'd be stupid to throw perfectly good code away, plus, when you reuse the same code in the way you do with sysbtm.i, if you find a bug, just fix it, and reassemble all you're programs. Done.

Done. And now opening an Intuition screen is 4 lines of code

Originally Posted by Thorham

I guess so, but it still bothers me that I can't really think of a really good method. I may be getting there, but it's not as easy as I had hoped at all

Then you're a perfectionnist. I sure can understand that

Originally Posted by Thorham

Well, not exactly in the file, just as a separate file so that the flac stays compatible with all the other players. That also has the added advantage of making the flac code easy to update with better jitted (new word) coded.

The flac could stay compatible anyway, if we use some reserved chunk type or something like that. But for the update, yes, it's a clear advantage to use a separate file.

Originally Posted by Thorham

Also, how much code are we talking about per flac? Probably not that much, and it could be compressed.

Not much ? Can be up to 32 multiplies for a block as small as 4096 samples or even smaller (could be 1024 or less).
I am unsure it wouldn't be better to store the code in the decoder itself or in a data file giver with it ; decoding would simply fetch the relevant entry.

Originally Posted by Thorham

Such games are quite easy to port. Zelda 3 from the snes has all the graphics in planar mode already, so the only problem with porting those games is actually getting hold of all the graphics, sound effects and music (and levels...). In the snes case, the gfx can be encoded/compressed (they do that on the gba a lot, which has decompression routines in the bios, which sucks rocks big time), and the sound effects and music are handled by a separate cpu (which may actually be an advantage). Or just use zsnes (current version is totally amazing).

Easy to port ? Gosh, I doubt ! Would have been long done else !
And zsnes won't bring those on your miggy but on your peecee. That's not the same thing

Originally Posted by Thorham

You're right, of course. Some people do like challenges I'm one of them, but not always.

Depends on what sort of challenge I guess.

Originally Posted by Thorham

Yes, it's not of today. Also, as long as they're fooling around with neural nets, trying to emulate brain functions and not concentrating on making proper algorithms, which would beat the brain into a pulp anyway (the brain is a horrible mess of cemplexity, and it's slow: 1000 hz, why anyone would want to waste the awesome power that is the cpu on that crap is beyond me), it's not going to happen. As you can see, I have strong feelings about this.

I don't agree ; the brain isn't a horrible mess of useless complexity. You say it works @ 1000 hz but it isn't really true. What it can do in a few milliseconds, even the most powerful computers simply can't do it, e.g. separating sounds, shape recognition, and so on. Computers will never beat the brain into a pulp. They have no imagination. They can't learn. And they can't program
Trying to emulate brain functions isn't a waste according to me. It may be evil, but it's not a pure waste.

Originally Posted by Thorham

However, I meant the idea, which in theory should work just fine, as a joke. But as you've mentioned all the repeating patterns, it made me wonder if it really is a joke, or a serious possibility.

Who knows... Only time will tell.

Originally Posted by Thorham

20 to 30 percent isn't really a lot. Those are very good results, especially if the sound quality is good. Do you know of any good peecee programs to convert wavs with? Or, better yet, mp3 to flac directly with controllable frequency?

Good peecee programs ? I used the standard encoder given on the flac home page. You may also try flake, but it won't work on 8-bit files.
Converting mp3 to flac is probably a waste, since you wouldn't gain anything in quality and use much more space - of course you can do it for cpu usage only, but it would either periodically read from disk, or use more memory to load the file. Unsure it is a winner...

Originally Posted by Thorham

Wow, that's just amazing. I don't have a lot of music and pictures on my miggy, although the music is going to change. I even have all of Killer Gorillas whdload packages on the hd (games and demos) and that still is only about three gigs.

Aoh, yeah, I also have some gigs of (mostly untested) games. Just forgot them

Originally Posted by Thorham

Didn't know that. I always assumed everyone just preflipped all their graphics.

They may preflip them while loading, but DM1 doesn't. It even doesn't store resized gfx for distant views except for walls and floors (but Captive does).

Originally Posted by Thorham

On a side note, both DM1 and DM2 are perfectly completable with just one character. Because of the leveling system, that single character ends up being a lot stronger in all areas (except maybe ninja levels) than the characters in a four character party. Really, you should try it.

And you have much less mana to use. For fireball users like me it's not good
Also, I remember beating the DM2 boss just by sending him attack minions like he does
I have tried one, and I still prefer using 4 characters. Even 4 isn't enough for me.
But it may be simply because those games aren't challenging enough for hardcore dungeoneers like you

Originally Posted by Thorham

Yes, but only for decompressed pngs, not for noncompressed ones, as these don't encode the data, and are similar to bmps. The whole encoding scheme is just there to achieve better compression ratios. I have, however, modified a little freebasic program that allows decompressing zlib streams, so yes, we're very close to seeing something, especially since the freebasic decoder is fully functioning code. Hey, as I've said, I'm not doing nothing, it's just going slow

He who goes slow goes safe...

Originally Posted by Thorham

It's hard to finish things, isn't it? A few months ago, I started work on a brilliance clone in freebasic, because I was getting fed up with all that peecee crap. The only work that has been done so far, is a fast indexed screen with 32 bit indexes Important, but still only a small part.

You start something, get fed up, and drop. My HD is full of such projects, but hopefully some have reached the usable state (my picture viewer at least did).
However, what makes me think I'll never finish the dungeon is simply because I ran into some of the game's limitations. I ran out of actuators, man, and that's bad

Originally Posted by Thorham

As for that dungeon, if it turns out to be a good dungeon, upload to the zone, please.

Upload that to the zone ? Poor people ! I have to warn them that it isn't meant for beginners ! (not to mention they might run into bogus areas because it's far from finished)
On the other hand I can do a preview for your own use, so that I'll know which areas must be expanded first.
Anyway I am not the judge to say it is a good dungeon

Originally Posted by Thorham

All the time in the universe. But still, I'd really like to finish something sometime soon.

Maybe you should start with something small ? (just my 2 cents)

Originally Posted by Thorham

Trust me, if you've got a broadband connection on a quick peecee, you'll end up using it more than you really need to. Before I had mine, I didn't use the net a lot either.

One more reason for not having it

Originally Posted by Thorham

And how come you don't have a peecee? Do you hate them that much

Yeah. PC sucks.

[Thorham]

Originally Posted by meynaf

Alas I don't have anything but 020/030. However there might be people here on these fine forums who have 040 or 060, I think. Maybe one will be willing to test...

They better help.

Originally Posted by meynaf

Unfortunately this is not possible. The decoding process relies a lot on previously emitted data, and an error here would accumulate and completely destroy the wave form.
Besides, there is no significant speed difference between 8 and 16 bits. Just the size changes, and most of the code is common for both.

I can see how that would be 'a little problematic'.

Originally Posted by meynaf

It is an anti-alias sort of filtering. I don't know much about it ; I already have an equate to dump it. The sound is slightly clearer with it, and it roughly takes 3% cpu. An option to be kept for high quality setting and dropped for low and medium, I think.

Three percent is not what I was hoping for; it's almost insignificant. Isn't there any good way to optimize this?

Originally Posted by meynaf

Is ReadArgs() good ? For me, it simply rocks ! One of the reasons I love AmigaOS ! It appeared in 2.0 roms, and is perhaps among the things that made arp.library obsolete. See docs if you want to know more about it ; must have been a pain to write.

If it rocks, I certainly won't write one. I think I'm going to use this in my simple system frame for utilities, although it still depends on what it can do.

Originally Posted by meynaf

Done. And now opening an Intuition screen is 4 lines of code

Wow, thats short I always thought that these things were a pain to write.

Originally Posted by meynaf

Then you're a perfectionnist. I sure can understand that

Yes, I suppose I am. But why write code thats not even close to how well you can make it? With programming I certainly am a perfectionist, and I usually try to do my best.

Originally Posted by meynaf

The flac could stay compatible anyway, if we use some reserved chunk type or something like that. But for the update, yes, it's a clear advantage to use a separate file.

Reserved chunks sound good, and the player could actually just update the code in the flac file.

Originally Posted by meynaf

Not much ? Can be up to 32 multiplies for a block as small as 4096 samples or even smaller (could be 1024 or less). I am unsure it wouldn't be better to store the code in the decoder itself or in a data file giver with it ; decoding would simply fetch the relevant entry.

Ouch, that would be a lot of code. 4096 samples is nothing. I'd try to optimize it as much as possible in other ways first, and see if it's still worth it.

Originally Posted by meynaf

Easy to port ? Gosh, I doubt ! Would have been long done else !
And zsnes won't bring those on your miggy but on your peecee. That's not the same thing

Program technically it's probably not a difficult game to port. Most of those old snes games aren't, but getting all the data from the rom file could be a major pain.

Originally Posted by meynaf

I don't agree ; the brain isn't a horrible mess of useless complexity. You say it works @ 1000 hz but it isn't really true. What it can do in a few milliseconds, even the most powerful computers simply can't do it, e.g. separating sounds, shape recognition, and so on. Computers will never beat the brain into a pulp. They have no imagination. They can't learn. And they can't program
Trying to emulate brain functions isn't a waste according to me. It may be evil, but it's not a pure waste.

Well, you forget that the brain itself can only do what the neural connections make it able to do. A brain without connections between it's cells can not do anything at all. A blank brain is like a computer without software. Never say never No one knows all the true possibilities. Evil? Truly

Originally Posted by meynaf

Good peecee programs ? I used the standard encoder given on the flac home page. You may also try flake, but it won't work on 8-bit files.
Converting mp3 to flac is probably a waste, since you wouldn't gain anything in quality and use much more space - of course you can do it for cpu usage only, but it would either periodically read from disk, or use more memory to load the file. Unsure it is a winner...

Ok, the flac page it is then. Yup, mp3 to flac I need. It's a little handier to just do it in one go, instead of first converting to wav.

Originally Posted by meynaf

Aoh, yeah, I also have some gigs of (mostly untested) games. Just forgot them

Are they the KG game packs?

Originally Posted by meynaf

They may preflip them while loading, but DM1 doesn't. It even doesn't store resized gfx for distant views except for walls and floors (but Captive does).

Doing it while loading is actually quite smart. Nice.

Originally Posted by meynaf

And you have much less mana to use. For fireball users like me it's not good Also, I remember beating the DM2 boss just by sending him attack minions like he does
I have tried one, and I still prefer using 4 characters. Even 4 isn't enough for me.
But it may be simply because those games aren't challenging enough for hardcore dungeoneers like you

That's true about the mana there. And is made worse by the fact that I always reincarnate Halk who has no mana at the start. Playing with one char really isn't that much more difficult in most parts of the games, although sometimes a full party for all those fireballs is really handy.

Originally Posted by meynaf

He who goes slow goes safe...

But he who goes too slow, goes no where at all

Originally Posted by meynaf

You start something, get fed up, and drop. My HD is full of such projects, but hopefully some have reached the usable state (my picture viewer at least did).
However, what makes me think I'll never finish the dungeon is simply because I ran into some of the game's limitations. I ran out of actuators, man, and that's bad

Yeah, and it's a bloody waste, if you ask me. What are actuators? Can't the game be hacked to allow more of them?

Originally Posted by meynaf

Upload that to the zone ? Poor people ! I have to warn them that it isn't meant for beginners ! (not to mention they might run into bogus areas because it's far from finished)
On the other hand I can do a preview for your own use, so that I'll know which areas must be expanded first.
Anyway I am not the judge to say it is a good dungeon

Ok then, I'd love to see it!

Originally Posted by meynaf

Maybe you should start with something small ? (just my 2 cents)

You are absolutely right. I think I'm going to stick with the code I'm doing for your viewer for now instead of wasting my time on a million and one things.

Originally Posted by meynaf

Yeah. PC sucks.

But why? They are so faaaaaaast

[musojon74]

Originally Posted by meynaf

Alas I don't have anything but 020/030. However there might be people here on these fine forums who have 040 or 060, I think. Maybe one will be willing to test...

I will be pleased to help test your player on 060/66 if this is any assistance? I'd be very interested to play with flac on my Amiga!

[meynaf]

Originally Posted by Thorham

They better help.

Apparently we have someone for 060

Originally Posted by Thorham

I can see how that would be 'a little problematic'.

Not to mention it wouldn't gain much...

Originally Posted by Thorham

Three percent is not what I was hoping for; it's almost insignificant. Isn't there any good way to optimize this?

Probably more like two percent now, as I made some opts in that one

You ask if there is any good way to optimize this... but every good way I could think about is already there.
And even more, as Don Adan helped me a lot on the IMDCT part.

Now what we couldn't play at all can be played at high quality (in mono).
And with that extra help we gained a further 10%, playing with 89% cpu what we previously played in 99% (still mono though).

Originally Posted by Thorham

If it rocks, I certainly won't write one. I think I'm going to use this in my simple system frame for utilities, although it still depends on what it can do.

You're doing a simple system frame for utilities ? Isn't that some sort of an application framework ?

Originally Posted by Thorham

Wow, thats short

Yeah, that's what all women tell m... errh... never mind

Originally Posted by Thorham

I always thought that these things were a pain to write.

Oh it was a pain to write, yes. This code originated in an old version of my picture viewer. I got it out of there and made it more generic. And as always I planned more features than I actually did

Originally Posted by Thorham

Yes, I suppose I am. But why write code thats not even close to how well you can make it? With programming I certainly am a perfectionist, and I usually try to do my best.

You can start by writing code that's not your best shot but simply works, then rework it. I did that for my progressive jpeg support.

Originally Posted by Thorham

Reserved chunks sound good, and the player could actually just update the code in the flac file.

I'm actually more worried about how to write the code than where to put it...

Originally Posted by Thorham

Ouch, that would be a lot of code. 4096 samples is nothing. I'd try to optimize it as much as possible in other ways first, and see if it's still worth it.

Other ways are already done I'm afraid.

Originally Posted by Thorham

Program technically it's probably not a difficult game to port. Most of those old snes games aren't, but getting all the data from the rom file could be a major pain.

I have made a few game ports (not snes though) and getting the data wasn't the hardest thing.
The SPC700 (Snes soundchip) emulation could be much more annoying if you ask me.

Originally Posted by Thorham

Well, you forget that the brain itself can only do what the neural connections make it able to do. A brain without connections between it's cells can not do anything at all.

I still don't agree
A brain without connections is pretty like a baby, and it can still do something no computer can do : it can learn.

Originally Posted by Thorham

A blank brain is like a computer without software.

See above... Consider how complex a tongue (e.g. English) can be to learn. Consider the time it takes to a baby to actually speak it - just by listening at it. Can a computer do this ???

Originally Posted by Thorham

Never say never No one knows all the true possibilities. Evil? Truly

Fear not. It will be hard to beat 4 billion years of evolution.

Originally Posted by Thorham

Ok, the flac page it is then. Yup, mp3 to flac I need. It's a little handier to just do it in one go, instead of first converting to wav.

I still don't see the point in converting mp3 to flac

Originally Posted by Thorham

Are they the KG game packs?

No. Most of them are just floppy images I got long ago.

Originally Posted by Thorham

Doing it while loading is actually quite smart. Nice.

Yes, if you have enough memory. But Dm1 was made to work in 512 kb

Originally Posted by Thorham

That's true about the mana there. And is made worse by the fact that I always reincarnate Halk who has no mana at the start. Playing with one char really isn't that much more difficult in most parts of the games, although sometimes a full party for all those fireballs is really handy.

Ever tried Chaos Strikes Back with only one character ? I did it with reincarnated characters and it was challenging enough for me...

Originally Posted by Thorham

But he who goes too slow, goes no where at all

LOL

Originally Posted by Thorham

Yeah, and it's a bloody waste, if you ask me. What are actuators? Can't the game be hacked to allow more of them?

Actuators are things such as pressure plates, buttons, levers, and all the (sometimes complex) logic behind them.
As all other things that go in a dungeon and are not tiles, they are limited to 1024 per dungeon.

Why this limitation? you might ask. It's because they are referenced with a 16-bit word which is some sort of a pointer and looks like that : 2 bits for direction, 4 bits for type, 10 bits for number.

There are 4 directions, 16 types (of which only 13 are used : doors, teleports, texts, actuators, monsters, weapons, clothing, scrolls, potions, chests, misc. objects, projectiles, explosions)... and a maximum of 1024 objects of each type because of the 10-bit field.

So hacking isn't that easy.
Besides, this would mean that no other version of the game but mine can use that dungeon file. Oh, well. I'll do it anyway.

That thing may seem off-topic, but it really will end up with a lot of programming.
And although the game was cleverly designed, Megamax Laser C made a mess out of it...

Originally Posted by Thorham

Ok then, I'd love to see it!

Look in the zone, there's something for you !

Please tell me how your journey looked like, say, something such as "I got surrounded by monsters and was killed", or "I fell into a pit, had two deaths out of 4 characters - then some monsters came and it was the end"

Originally Posted by Thorham

You are absolutely right. I think I'm going to stick with the code I'm doing for your viewer for now instead of wasting my time on a million and one things.

I am absolutely right ? Damn, I must have made some mistake then

Originally Posted by Thorham

But why? They are so faaaaaaast

Fast ? Depends on what they do.
They are grandmas doped with transgenic kryptonite.

[meynaf]

Originally Posted by musojon74

I will be pleased to help test your player on 060/66 if this is any assistance? I'd be very interested to play with flac on my Amiga!

Here is a good place to start for you then :
http://meynaf.free.fr/tmp/p.zip

It's a simple command-line player. Very crude I'm afraid. Maybe still full of bugs (probably ).

On your 060 you should have no problem playing flacs, unless the long muls are really too slow.

Also, there may be several other things I need to test on 060, e.g. my picture viewer.