it appaered to me some idea of image codec thit i find
fun (sadly i probably not will find time to code it - though idea
is good as a task so if someone would have time my
experiment with it itself) :

the idea is just to store a list of pixels (it is { x, y,color})
and and the use some kind of color interp[olation beetween points
(at first draft my be just linear) to draw the image itself

some simple image, all black for example would be:

0,0, 0x000000,
999,0,0x000000
0,999,0x000000
999,999,0x000000

that would make 1000x1000 pixel bitmap all black
(and that would be 48 bytes or 32 bytes depending if
usung ints or shorts on pixel coordinates

polish flag like image would be

0,0, 0xffffff, 999,0,0xffffff, 0,499,0xffffff, 999,499,0xffffff,
0,500, 0xff0000,999,500,0xff0000,0,999,0xff0000,999,999,0xff0000

ot would be rather ;pssy compression method but it could
be possible imo to obtain very small images imo

i also thing if not to add fourth number to x,y,color, like d or something - coeficient which would encode some info how to interpolete thru this pixel

it seem to me it could be quite fun to write some codec (i mean encoder) that would generate those list of pixel

for exampel i first draft i guess it could be done randomly i mean
given encoder could assume some number of pixels to use (like 1000
for example) and just randomly take it from given photo - then draw
the result with interpolations of given pixels and then compare how
well the resulted rendered picture is distant to oryginal - loop that
many times and then take the one that fits the best

(programatically it seem quite easy = so im not sure maybe i even could try it)

some opinions welcome

/fir

wtorek, 29 listopada 2022 o 22:01:39 UTC+1 fir napisał(a):
> it appaered to me some idea of image codec thit i find
> fun (sadly i probably not will find time to code it - though idea
> is good as a task so if someone would have time my
> experiment with it itself) :
>
> the idea is just to store a list of pixels (it is { x, y,color})
> and and the use some kind of color interp[olation beetween points
> (at first draft my be just linear) to draw the image itself
>
> some simple image, all black for example would be:
>
> 0,0, 0x000000,
> 999,0,0x000000
> 0,999,0x000000
> 999,999,0x000000
>
> that would make 1000x1000 pixel bitmap all black
> (and that would be 48 bytes or 32 bytes depending if
> usung ints or shorts on pixel coordinates
>
> polish flag like image would be
>
> 0,0, 0xffffff, 999,0,0xffffff, 0,499,0xffffff, 999,499,0xffffff,
> 0,500, 0xff0000,999,500,0xff0000,0,999,0xff0000,999,999,0xff0000
>
> ot would be rather ;pssy compression method but it could
> be possible imo to obtain very small images imo
>
> i also thing if not to add fourth number to x,y,color, like d or something - coeficient which would encode some info how to interpolete thru this pixel
>
> it seem to me it could be quite fun to write some codec (i mean encoder) that would generate those list of pixel
>
> for exampel i first draft i guess it could be done randomly i mean
> given encoder could assume some number of pixels to use (like 1000
> for example) and just randomly take it from given photo - then draw
> the result with interpolations of given pixels and then compare how
> well the resulted rendered picture is distant to oryginal - loop that
> many times and then take the one that fits the best
>
> (programatically it seem quite easy = so im not sure maybe i even could try it)
>
> some opinions welcome
>
> /fir

to make it more c specific maybe some contest of c code for such encoder?
it coyld take photo.raw file which could be image in raw format (like 1000x1000x4 bytes of pixel data), such raw image could be probably saved by some program like irfan view

taking this input raw image and writing a code that would produce the outpyut unnamed image format in format i wrote above (name it maybe cip for 'color interpolation') and yet a
renderer that would take the cip file and render it to output raw file

some interested in participating?

wtorek, 29 listopada 2022 o 22:15:09 UTC+1 fir napisał(a):
> wtorek, 29 listopada 2022 o 22:01:39 UTC+1 fir napisał(a):
> > it appaered to me some idea of image codec thit i find
> > fun (sadly i probably not will find time to code it - though idea
> > is good as a task so if someone would have time my
> > experiment with it itself) :
> >
> > the idea is just to store a list of pixels (it is { x, y,color})
> > and and the use some kind of color interp[olation beetween points
> > (at first draft my be just linear) to draw the image itself
> >
> > some simple image, all black for example would be:
> >
> > 0,0, 0x000000,
> > 999,0,0x000000
> > 0,999,0x000000
> > 999,999,0x000000
> >
> > that would make 1000x1000 pixel bitmap all black
> > (and that would be 48 bytes or 32 bytes depending if
> > usung ints or shorts on pixel coordinates
> >
> > polish flag like image would be
> >
> > 0,0, 0xffffff, 999,0,0xffffff, 0,499,0xffffff, 999,499,0xffffff,
> > 0,500, 0xff0000,999,500,0xff0000,0,999,0xff0000,999,999,0xff0000
> >
> > ot would be rather ;pssy compression method but it could
> > be possible imo to obtain very small images imo
> >
> > i also thing if not to add fourth number to x,y,color, like d or something - coeficient which would encode some info how to interpolete thru this pixel
> >
> > it seem to me it could be quite fun to write some codec (i mean encoder) that would generate those list of pixel
> >
> > for exampel i first draft i guess it could be done randomly i mean
> > given encoder could assume some number of pixels to use (like 1000
> > for example) and just randomly take it from given photo - then draw
> > the result with interpolations of given pixels and then compare how
> > well the resulted rendered picture is distant to oryginal - loop that
> > many times and then take the one that fits the best
> >
> > (programatically it seem quite easy = so im not sure maybe i even could try it)
> >
> > some opinions welcome
> >
> > /fir
> to make it more c specific maybe some contest of c code for such encoder?
> it coyld take photo.raw file which could be image in raw format (like 1000x1000x4 bytes of pixel data), such raw image could be probably saved by some program like irfan view
>
> taking this input raw image and writing a code that would produce the outpyut unnamed image format in format i wrote above (name it maybe cip for 'color interpolation') and yet a
> renderer that would take the cip file and render it to output raw file
>
> some interested in participating?

there is yet a problem of interpolation assome you get a list of thet points (say 1000) eaxhg one inside 1000x1000 grid - how to count a color for a given x,y pixel if i want to interpolate between them?

On 11/29/2022 3:01 PM, fir wrote:
> it appaered to me some idea of image codec thit i find
> fun (sadly i probably not will find time to code it - though idea
> is good as a task so if someone would have time my
> experiment with it itself) :
>
> the idea is just to store a list of pixels (it is { x, y,color})
> and and the use some kind of color interp[olation beetween points
> (at first draft my be just linear) to draw the image itself
>
> some simple image, all black for example would be:
>
> 0,0, 0x000000,
> 999,0,0x000000
> 0,999,0x000000
> 999,999,0x000000
>
> that would make 1000x1000 pixel bitmap all black
> (and that would be 48 bytes or 32 bytes depending if
> usung ints or shorts on pixel coordinates
>
> polish flag like image would be
>
> 0,0, 0xffffff, 999,0,0xffffff, 0,499,0xffffff, 999,499,0xffffff,
> 0,500, 0xff0000,999,500,0xff0000,0,999,0xff0000,999,999,0xff0000
>
> ot would be rather ;pssy compression method but it could
> be possible imo to obtain very small images imo
>
> i also thing if not to add fourth number to x,y,color, like d or something - coeficient which would encode some info how to interpolete thru this pixel
>
> it seem to me it could be quite fun to write some codec (i mean encoder) that would generate those list of pixel
>
> for exampel i first draft i guess it could be done randomly i mean
> given encoder could assume some number of pixels to use (like 1000
> for example) and just randomly take it from given photo - then draw
> the result with interpolations of given pixels and then compare how
> well the resulted rendered picture is distant to oryginal - loop that
> many times and then take the one that fits the best
>
> (programatically it seem quite easy = so im not sure maybe i even could try it)
>

If you organize the points into a polygon, then this would be
effectively a vector graphics format. For good measure, could maybe add
some B-Splines or similar (say, so one can draw a circle using a
relatively small number of vertices).

Automatic conversion from raster to vector formats isn't really a thing
AFAIK ("most" software assuming having the user manually trace the image
into a vector format). Could be done in theory by using edge detection
or thresholds to try to split up the image into regions, and then
setting the vertices based on the average color in that region.

Decoding vector formats tends to be a relatively involved process though
(it is effectively a polygon rasterizer).

As for more traditional raster formats:

There is DCT, but realistically one can't really do all that much to
improve "significantly" over T.81 JPEG here (modest gains are possible,
but not usually enough to displace the original; and most of the "JPEG
replacements" also come with significant drawbacks).

Linear filtering plus LZ compression is also well known (PNG works this
way).

Variants on color-cell compression can work well for more specialized
use cases (where quality is less of a priority). Things like S3TC and
DDS are a few better known examples. Some old (early 90s era) video
codecs, namely RPZA and CRAM, also used this. Some further compression
can be gained "cheaply" by throwing an LZ compressor on top of this
(having both a Huffman-coded and Byte-only LZ encoder works well here,
as many frames/images and similar will not benefit from the use of
Huffman encoding; which does have a non-zero speed cost).

For color cell codecs, by themselves, compression is usually bad enough
that one is more likely to end up being IO bound rather than CPU bound
(even on a relatively slow CPU). Adding an LZ compression stage can help
here.

It is possible to improve over Deflate in terms of speed by limiting the
Huffman symbols to 12 bits or so, and compression benefits are possible
by using a larger sliding window (a 128K window works well IME). It is
relatively difficult to push a Huffman based format much past around
600MB/sec though (on a modernish PC).

For a byte-oriented LZ, something like LZ4 works well, though I have my
own format (RP2) which tends to get slightly better compression at a
similar decode speed (typically several GB/sec on a modern PC) for most
data types.

The traditional color-cell formats tend to store pixels at 4x4x2bpp
(RPZA, S3TC, ...) or 4x4x1bpp (CRAM).

A format with multiple block sizes can also work well, say:
4x4x2bpp (32 bits)
4x4x1bpp (16 bits)
2x2x2bpp (8 bits)
2x2x1bpp (4 bits)
Along with a scheme to use a differential encoding on the color
endpoints (may overlap with selecting the block format).

One other promising block format is 6 bits, say:
2b: Horizontal Frequency
2b: Vertical Frequency
1b: Horizontal Polarity
1b: Vertical Polarity

Which is then used as an index into a lookup table of 4x4x2bpp patterns
(generated according to the above).

Say, frequency encodes, say (0..7 logical):
0.00=(5555), 0.01=(6521), 0.10=(6116), 0.11=(6161)
1.00=(2222), 1.01=(1256), 1.10=(1661), 1.11=(1616)
Added up horizontal x vertical, then shifted right by 2 bits to map to
the 0..3 range.

So, one has a command-byte which may encode some combination of:
Emit a pattern block (previous colors);
Apply a delta over the color endpoints;
Encode a run of colors, blocks, or blocks+colors;
Skip or copy-translate blocks from the prior frame.

With an LZ compressor applied on top of this.

In this case, "pppppp00" encoded the 6-bit pattern above, which was the
dominant default block-format used, with 16 bits used to encode a small
color delta, say:
rrrg-ggbb bddd-0011

Where, say, the command prefix was essentially a Rice(1) pattern.
00, 10, 001, 101, 0011, 1011, 00111, 10111, ...
Albeit conceptually read from right to left in this example.

Color space was RGB555, with 5b per component for the center color, and
5b for the (max-min) value (D), so:
Mr=Ar-(D>>1), Mg=Ag-(D>>1), Mb=Ab-(D>>1)
Nr=Mr+D, Ng=Mg+D, Nb=Mb+D
One could encode a delta in 16 bits with 3b per delta (-3 .. +3), or an
escape case to encode a raw endpoint in 24 bits.

I had semi-recently had reasonably good results with a codec sorta like
this. Not necessarily the best image quality, but pretty reasonable in
terms of quality/bitrate and decode speed.

Note that (for decoding blocks to pixels) one would map the above
colorspace to a set of 4 colors, say:
00=Mrgb, 01=(5/8)*Mrgb+(3/8)*Nrgb, 10=(3/8)*Mrgb+(5/8)*Nrgb, 11=Nrgb

Then unpack pixels from a 4x4x2 block something like:
ix0=(px>>0)&3; ix1=(px>>2)&3;
ix2=(px>>4)&3; ix3=(px>>6)&3;
p0=ctab[ix0]; p1=ctab[ix1];
p2=ctab[ix2]; p3=ctab[ix3];
ct[0]=p0; ct[1]=p1;
ct[2]=p2; ct[3]=p3;
ct+=stride;
ix0=(px>> 8)&3; ix1=(px>>10)&3;
ix2=(px>>12)&3; ix3=(px>>14)&3;
p0=ctab[ix0]; p1=ctab[ix1];
p2=ctab[ix2]; p3=ctab[ix3];
ct[0]=p0; ct[1]=p1;
ct[2]=p2; ct[3]=p3;
...

Was fast enough for video playback on an 50 MHz core on an FPGA (IIRC,
was trying for 320x200x30fps; where CRAM was hopelessly IO bound).

But, yeah, for this class of codec, if one has output that "doesn't look
like broken garbage" at around 0.3 bpp or so (~ 500 kbps), one is doing
pretty well... Still pretty weak vs MPEG or similar, but MPEG is an
entirely different class of video codec.

Decode speeds (on my PC) being a little over a gigapixel per second
(single threaded decoder). (For "technical reasons" is being difficult
to get much over a gigapixel per second for a single-threaded decoder).

> some opinions welcome
>
> /fir

środa, 30 listopada 2022 o 03:37:07 UTC+1 BGB napisał(a):
> On 11/29/2022 3:01 PM, fir wrote:
> > it appaered to me some idea of image codec thit i find
> > fun (sadly i probably not will find time to code it - though idea
> > is good as a task so if someone would have time my
> > experiment with it itself) :
> >
> > the idea is just to store a list of pixels (it is { x, y,color})
> > and and the use some kind of color interp[olation beetween points
> > (at first draft my be just linear) to draw the image itself
> >
> > some simple image, all black for example would be:
> >
> > 0,0, 0x000000,
> > 999,0,0x000000
> > 0,999,0x000000
> > 999,999,0x000000
> >
> > that would make 1000x1000 pixel bitmap all black
> > (and that would be 48 bytes or 32 bytes depending if
> > usung ints or shorts on pixel coordinates
> >
> > polish flag like image would be
> >
> > 0,0, 0xffffff, 999,0,0xffffff, 0,499,0xffffff, 999,499,0xffffff,
> > 0,500, 0xff0000,999,500,0xff0000,0,999,0xff0000,999,999,0xff0000
> >
> > ot would be rather ;pssy compression method but it could
> > be possible imo to obtain very small images imo
> >
> > i also thing if not to add fourth number to x,y,color, like d or something - coeficient which would encode some info how to interpolete thru this pixel
> >
> > it seem to me it could be quite fun to write some codec (i mean encoder) that would generate those list of pixel
> >
> > for exampel i first draft i guess it could be done randomly i mean
> > given encoder could assume some number of pixels to use (like 1000
> > for example) and just randomly take it from given photo - then draw
> > the result with interpolations of given pixels and then compare how
> > well the resulted rendered picture is distant to oryginal - loop that
> > many times and then take the one that fits the best
> >
> > (programatically it seem quite easy = so im not sure maybe i even could try it)
> >
> If you organize the points into a polygon, then this would be
> effectively a vector graphics format. For good measure, could maybe add
> some B-Splines or similar (say, so one can draw a circle using a
> relatively small number of vertices).
>
> Automatic conversion from raster to vector formats isn't really a thing
> AFAIK ("most" software assuming having the user manually trace the image
> into a vector format). Could be done in theory by using edge detection
> or thresholds to try to split up the image into regions, and then
> setting the vertices based on the average color in that region.
>
> Decoding vector formats tends to be a relatively involved process though
> (it is effectively a polygon rasterizer).
>
>
>
> As for more traditional raster formats:
>
> There is DCT, but realistically one can't really do all that much to
> improve "significantly" over T.81 JPEG here (modest gains are possible,
> but not usually enough to displace the original; and most of the "JPEG
> replacements" also come with significant drawbacks).
>
> Linear filtering plus LZ compression is also well known (PNG works this
> way).
>
>
> Variants on color-cell compression can work well for more specialized
> use cases (where quality is less of a priority). Things like S3TC and
> DDS are a few better known examples. Some old (early 90s era) video
> codecs, namely RPZA and CRAM, also used this. Some further compression
> can be gained "cheaply" by throwing an LZ compressor on top of this
> (having both a Huffman-coded and Byte-only LZ encoder works well here,
> as many frames/images and similar will not benefit from the use of
> Huffman encoding; which does have a non-zero speed cost).
>
> For color cell codecs, by themselves, compression is usually bad enough
> that one is more likely to end up being IO bound rather than CPU bound
> (even on a relatively slow CPU). Adding an LZ compression stage can help
> here.
>
> It is possible to improve over Deflate in terms of speed by limiting the
> Huffman symbols to 12 bits or so, and compression benefits are possible
> by using a larger sliding window (a 128K window works well IME). It is
> relatively difficult to push a Huffman based format much past around
> 600MB/sec though (on a modernish PC).
>
> For a byte-oriented LZ, something like LZ4 works well, though I have my
> own format (RP2) which tends to get slightly better compression at a
> similar decode speed (typically several GB/sec on a modern PC) for most
> data types.
>
> The traditional color-cell formats tend to store pixels at 4x4x2bpp
> (RPZA, S3TC, ...) or 4x4x1bpp (CRAM).
>
>
> A format with multiple block sizes can also work well, say:
> 4x4x2bpp (32 bits)
> 4x4x1bpp (16 bits)
> 2x2x2bpp (8 bits)
> 2x2x1bpp (4 bits)
> Along with a scheme to use a differential encoding on the color
> endpoints (may overlap with selecting the block format).
>
> One other promising block format is 6 bits, say:
> 2b: Horizontal Frequency
> 2b: Vertical Frequency
> 1b: Horizontal Polarity
> 1b: Vertical Polarity
>
> Which is then used as an index into a lookup table of 4x4x2bpp patterns
> (generated according to the above).
>
> Say, frequency encodes, say (0..7 logical):
> 0.00=(5555), 0.01=(6521), 0.10=(6116), 0.11=(6161)
> 1.00=(2222), 1.01=(1256), 1.10=(1661), 1.11=(1616)
> Added up horizontal x vertical, then shifted right by 2 bits to map to
> the 0..3 range.
>
>
> So, one has a command-byte which may encode some combination of:
> Emit a pattern block (previous colors);
> Apply a delta over the color endpoints;
> Encode a run of colors, blocks, or blocks+colors;
> Skip or copy-translate blocks from the prior frame.
>
> With an LZ compressor applied on top of this.
>
> In this case, "pppppp00" encoded the 6-bit pattern above, which was the
> dominant default block-format used, with 16 bits used to encode a small
> color delta, say:
> rrrg-ggbb bddd-0011
>
> Where, say, the command prefix was essentially a Rice(1) pattern.
> 00, 10, 001, 101, 0011, 1011, 00111, 10111, ...
> Albeit conceptually read from right to left in this example.
>
> Color space was RGB555, with 5b per component for the center color, and
> 5b for the (max-min) value (D), so:
> Mr=Ar-(D>>1), Mg=Ag-(D>>1), Mb=Ab-(D>>1)
> Nr=Mr+D, Ng=Mg+D, Nb=Mb+D
> One could encode a delta in 16 bits with 3b per delta (-3 .. +3), or an
> escape case to encode a raw endpoint in 24 bits.
>
> I had semi-recently had reasonably good results with a codec sorta like
> this. Not necessarily the best image quality, but pretty reasonable in
> terms of quality/bitrate and decode speed.
>
>
> Note that (for decoding blocks to pixels) one would map the above
> colorspace to a set of 4 colors, say:
> 00=Mrgb, 01=(5/8)*Mrgb+(3/8)*Nrgb, 10=(3/8)*Mrgb+(5/8)*Nrgb, 11=Nrgb
>
> Then unpack pixels from a 4x4x2 block something like:
> ix0=(px>>0)&3; ix1=(px>>2)&3;
> ix2=(px>>4)&3; ix3=(px>>6)&3;
> p0=ctab[ix0]; p1=ctab[ix1];
> p2=ctab[ix2]; p3=ctab[ix3];
> ct[0]=p0; ct[1]=p1;
> ct[2]=p2; ct[3]=p3;
> ct+=stride;
> ix0=(px>> 8)&3; ix1=(px>>10)&3;
> ix2=(px>>12)&3; ix3=(px>>14)&3;
> p0=ctab[ix0]; p1=ctab[ix1];
> p2=ctab[ix2]; p3=ctab[ix3];
> ct[0]=p0; ct[1]=p1;
> ct[2]=p2; ct[3]=p3;
> ...
>
>
> Was fast enough for video playback on an 50 MHz core on an FPGA (IIRC,
> was trying for 320x200x30fps; where CRAM was hopelessly IO bound).
>
> But, yeah, for this class of codec, if one has output that "doesn't look
> like broken garbage" at around 0.3 bpp or so (~ 500 kbps), one is doing
> pretty well... Still pretty weak vs MPEG or similar, but MPEG is an
> entirely different class of video codec.
>
>
> Decode speeds (on my PC) being a little over a gigapixel per second
> (single threaded decoder). (For "technical reasons" is being difficult
> to get much over a gigapixel per second for a single-threaded decoder).
>
>
> > some opinions welcome
> >
> > /fir

i think you probably dont get what i said - its not vector graphics

its a bitmap format that contains information on itself as a list of points
with color and is build up - rasterized by some method of color interpolation
between the pixels

On 11/30/2022 9:08 AM, fir wrote:
> środa, 30 listopada 2022 o 03:37:07 UTC+1 BGB napisał(a):
>> On 11/29/2022 3:01 PM, fir wrote:
>>> it appaered to me some idea of image codec thit i find
>>> fun (sadly i probably not will find time to code it - though idea
>>> is good as a task so if someone would have time my
>>> experiment with it itself) :
>>>
>>> the idea is just to store a list of pixels (it is { x, y,color})
>>> and and the use some kind of color interp[olation beetween points
>>> (at first draft my be just linear) to draw the image itself
>>>
>>> some simple image, all black for example would be:
>>>
>>> 0,0, 0x000000,
>>> 999,0,0x000000
>>> 0,999,0x000000
>>> 999,999,0x000000
>>>
>>> that would make 1000x1000 pixel bitmap all black
>>> (and that would be 48 bytes or 32 bytes depending if
>>> usung ints or shorts on pixel coordinates
>>>
>>> polish flag like image would be
>>>
>>> 0,0, 0xffffff, 999,0,0xffffff, 0,499,0xffffff, 999,499,0xffffff,
>>> 0,500, 0xff0000,999,500,0xff0000,0,999,0xff0000,999,999,0xff0000
>>>
>>> ot would be rather ;pssy compression method but it could
>>> be possible imo to obtain very small images imo
>>>
>>> i also thing if not to add fourth number to x,y,color, like d or something - coeficient which would encode some info how to interpolete thru this pixel
>>>
>>> it seem to me it could be quite fun to write some codec (i mean encoder) that would generate those list of pixel
>>>
>>> for exampel i first draft i guess it could be done randomly i mean
>>> given encoder could assume some number of pixels to use (like 1000
>>> for example) and just randomly take it from given photo - then draw
>>> the result with interpolations of given pixels and then compare how
>>> well the resulted rendered picture is distant to oryginal - loop that
>>> many times and then take the one that fits the best
>>>
>>> (programatically it seem quite easy = so im not sure maybe i even could try it)
>>>
>> If you organize the points into a polygon, then this would be
>> effectively a vector graphics format. For good measure, could maybe add
>> some B-Splines or similar (say, so one can draw a circle using a
>> relatively small number of vertices).
>>
>> Automatic conversion from raster to vector formats isn't really a thing
>> AFAIK ("most" software assuming having the user manually trace the image
>> into a vector format). Could be done in theory by using edge detection
>> or thresholds to try to split up the image into regions, and then
>> setting the vertices based on the average color in that region.
>>
>> Decoding vector formats tends to be a relatively involved process though
>> (it is effectively a polygon rasterizer).
>>
>>
>>
>> As for more traditional raster formats:
>>
>> There is DCT, but realistically one can't really do all that much to
>> improve "significantly" over T.81 JPEG here (modest gains are possible,
>> but not usually enough to displace the original; and most of the "JPEG
>> replacements" also come with significant drawbacks).
>>
>> Linear filtering plus LZ compression is also well known (PNG works this
>> way).
>>
>>
>> Variants on color-cell compression can work well for more specialized
>> use cases (where quality is less of a priority). Things like S3TC and
>> DDS are a few better known examples. Some old (early 90s era) video
>> codecs, namely RPZA and CRAM, also used this. Some further compression
>> can be gained "cheaply" by throwing an LZ compressor on top of this
>> (having both a Huffman-coded and Byte-only LZ encoder works well here,
>> as many frames/images and similar will not benefit from the use of
>> Huffman encoding; which does have a non-zero speed cost).
>>
>> For color cell codecs, by themselves, compression is usually bad enough
>> that one is more likely to end up being IO bound rather than CPU bound
>> (even on a relatively slow CPU). Adding an LZ compression stage can help
>> here.
>>
>> It is possible to improve over Deflate in terms of speed by limiting the
>> Huffman symbols to 12 bits or so, and compression benefits are possible
>> by using a larger sliding window (a 128K window works well IME). It is
>> relatively difficult to push a Huffman based format much past around
>> 600MB/sec though (on a modernish PC).
>>
>> For a byte-oriented LZ, something like LZ4 works well, though I have my
>> own format (RP2) which tends to get slightly better compression at a
>> similar decode speed (typically several GB/sec on a modern PC) for most
>> data types.
>>
>> The traditional color-cell formats tend to store pixels at 4x4x2bpp
>> (RPZA, S3TC, ...) or 4x4x1bpp (CRAM).
>>
>>
>> A format with multiple block sizes can also work well, say:
>> 4x4x2bpp (32 bits)
>> 4x4x1bpp (16 bits)
>> 2x2x2bpp (8 bits)
>> 2x2x1bpp (4 bits)
>> Along with a scheme to use a differential encoding on the color
>> endpoints (may overlap with selecting the block format).
>>
>> One other promising block format is 6 bits, say:
>> 2b: Horizontal Frequency
>> 2b: Vertical Frequency
>> 1b: Horizontal Polarity
>> 1b: Vertical Polarity
>>
>> Which is then used as an index into a lookup table of 4x4x2bpp patterns
>> (generated according to the above).
>>
>> Say, frequency encodes, say (0..7 logical):
>> 0.00=(5555), 0.01=(6521), 0.10=(6116), 0.11=(6161)
>> 1.00=(2222), 1.01=(1256), 1.10=(1661), 1.11=(1616)
>> Added up horizontal x vertical, then shifted right by 2 bits to map to
>> the 0..3 range.
>>
>>
>> So, one has a command-byte which may encode some combination of:
>> Emit a pattern block (previous colors);
>> Apply a delta over the color endpoints;
>> Encode a run of colors, blocks, or blocks+colors;
>> Skip or copy-translate blocks from the prior frame.
>>
>> With an LZ compressor applied on top of this.
>>
>> In this case, "pppppp00" encoded the 6-bit pattern above, which was the
>> dominant default block-format used, with 16 bits used to encode a small
>> color delta, say:
>> rrrg-ggbb bddd-0011
>>
>> Where, say, the command prefix was essentially a Rice(1) pattern.
>> 00, 10, 001, 101, 0011, 1011, 00111, 10111, ...
>> Albeit conceptually read from right to left in this example.
>>
>> Color space was RGB555, with 5b per component for the center color, and
>> 5b for the (max-min) value (D), so:
>> Mr=Ar-(D>>1), Mg=Ag-(D>>1), Mb=Ab-(D>>1)
>> Nr=Mr+D, Ng=Mg+D, Nb=Mb+D
>> One could encode a delta in 16 bits with 3b per delta (-3 .. +3), or an
>> escape case to encode a raw endpoint in 24 bits.
>>
>> I had semi-recently had reasonably good results with a codec sorta like
>> this. Not necessarily the best image quality, but pretty reasonable in
>> terms of quality/bitrate and decode speed.
>>
>>
>> Note that (for decoding blocks to pixels) one would map the above
>> colorspace to a set of 4 colors, say:
>> 00=Mrgb, 01=(5/8)*Mrgb+(3/8)*Nrgb, 10=(3/8)*Mrgb+(5/8)*Nrgb, 11=Nrgb
>>
>> Then unpack pixels from a 4x4x2 block something like:
>> ix0=(px>>0)&3; ix1=(px>>2)&3;
>> ix2=(px>>4)&3; ix3=(px>>6)&3;
>> p0=ctab[ix0]; p1=ctab[ix1];
>> p2=ctab[ix2]; p3=ctab[ix3];
>> ct[0]=p0; ct[1]=p1;
>> ct[2]=p2; ct[3]=p3;
>> ct+=stride;
>> ix0=(px>> 8)&3; ix1=(px>>10)&3;
>> ix2=(px>>12)&3; ix3=(px>>14)&3;
>> p0=ctab[ix0]; p1=ctab[ix1];
>> p2=ctab[ix2]; p3=ctab[ix3];
>> ct[0]=p0; ct[1]=p1;
>> ct[2]=p2; ct[3]=p3;
>> ...
>>
>>
>> Was fast enough for video playback on an 50 MHz core on an FPGA (IIRC,
>> was trying for 320x200x30fps; where CRAM was hopelessly IO bound).
>>
>> But, yeah, for this class of codec, if one has output that "doesn't look
>> like broken garbage" at around 0.3 bpp or so (~ 500 kbps), one is doing
>> pretty well... Still pretty weak vs MPEG or similar, but MPEG is an
>> entirely different class of video codec.
>>
>>
>> Decode speeds (on my PC) being a little over a gigapixel per second
>> (single threaded decoder). (For "technical reasons" is being difficult
>> to get much over a gigapixel per second for a single-threaded decoder).
>>
>>
>>> some opinions welcome
>>>
>>> /fir
>
> i think you probably dont get what i said - its not vector graphics
>
> its a bitmap format that contains information on itself as a list of points
> with color and is build up - rasterized by some method of color interpolation
> between the pixels
>
> that format would be generally bad for images that have various pixel level details but should
> be good in compressing images that have wider areas
> that change color slowly, for example if some
> area has solid color say red you could just
> put 3 or 4 red pixels covering the area and
> rasterisation will fill up te in-between space by red
>
> the provlem is how to write c code that would do
> that interpolation - its not only a matter of
> interpolation in triangle in-between 3 points but
> the problem is you got just a list of pixels
> randomly on the image square and there is need to chose
> the oones for that triangle in loop to render tnen
> whole image by those triangles
>

On 30/11/2022 20:01, BGB wrote:

> My custom CPU core would beat out an x86-64 PC pretty hard though at
> this if it had a similar clock speed and memory bandwidth (vs what I can
> get on an Artix-7 FPGA or similar...).
>
>
> Though, the PC would still win pretty big in terms of Dhrystone numbers
> and similar (though, likely depends on compiler; for example, there is
> also a pretty large gap between MSVC and GCC when it comes to Dhrystone
> numbers; and scaled relative to clock-speed, my numbers would be more
> comparable to the MSVC result).
>
> Interestingly, it seems for some tests involving neural nets, my ISA
> would pull more significantly ahead of my PC at this task.
>
>
> Though, it can be noted that the SIMD features are designed a fair bit
> differently than SSE or AVX (and in some cases need fewer instructions
> for similar tasks; and also less memory loads; as vector literals can be
> loaded inline as immediate values).
>
> General peak SIMD FPU performance is currently 200 MFLOP/s at 50MHz
> (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and Binary32
> with 4-wide vectors).
>
> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if using
> scalar instructions).
>
>
> At 50MHz, still don't really have enough "CPU go power" for things like
> non-terrible MPEG decoding though (something like 160x100 at 15fps is,
> bleh...).

My first experiments with video managed 128x128 x 16-level greyscale at
some 0.25fps, uncompressed; 15fps would have looked pretty good!

However this was using a 2.5MHz Z80 and recording frame-grabbed video
onto cassette tape using software PWM.

On 11/30/2022 2:17 PM, Bart wrote:
> On 30/11/2022 20:01, BGB wrote:
>
>> My custom CPU core would beat out an x86-64 PC pretty hard though at
>> this if it had a similar clock speed and memory bandwidth (vs what I
>> can get on an Artix-7 FPGA or similar...).
>>
>>
>> Though, the PC would still win pretty big in terms of Dhrystone
>> numbers and similar (though, likely depends on compiler; for example,
>> there is also a pretty large gap between MSVC and GCC when it comes to
>> Dhrystone numbers; and scaled relative to clock-speed, my numbers
>> would be more comparable to the MSVC result).
>>
>> Interestingly, it seems for some tests involving neural nets, my ISA
>> would pull more significantly ahead of my PC at this task.
>>
>>
>> Though, it can be noted that the SIMD features are designed a fair bit
>> differently than SSE or AVX (and in some cases need fewer instructions
>> for similar tasks; and also less memory loads; as vector literals can
>> be loaded inline as immediate values).
>>
>> General peak SIMD FPU performance is currently 200 MFLOP/s at 50MHz
>> (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and Binary32
>> with 4-wide vectors).
>>
>> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if
>> using scalar instructions).
>>
>>
>> At 50MHz, still don't really have enough "CPU go power" for things
>> like non-terrible MPEG decoding though (something like 160x100 at
>> 15fps is, bleh...).
>
> My first experiments with video managed 128x128 x 16-level greyscale at
> some 0.25fps, uncompressed; 15fps would have looked pretty good!
>
> However this was using a 2.5MHz Z80 and recording frame-grabbed video
> onto cassette tape using software PWM.

I am not quite that old...

Granted, I am now pretty old, but most of my life has been in the
"Desktop PCs with x86 and Windows" era (though, in my childhood, one
might still encounter older PCs running MS-DOS).

During elementary school, I was mostly interacting with PCs running
Win3x and Win95. During the time I was in high-school, the world was
starting to move on to WinXP (I had been running Win2K though, as I
wasn't a big fan of Win98, ...).

But, during my childhood, there was at one point a big craze over
"multimedia", and the ability to put "full motion video" onto CD-ROMs.

So, there were a bunch of typically terrible "FMV Games" which showed
video in a small window on the screen.

Say, they would set the screen to 320x200 256-color mode, then plonk a
160x100 video or similar in the center, and filled the whole rest of the
screen with a mostly static "hud".

IIRC, this was likely because 640x480 was still a bit hit or miss (some
PCs could only do 640x480 16-color, and at best screen redraw was pretty
slow).

The "game" would mostly then consist of occasionally clicking buttons in
said hud (or sometimes one would have a bar of "key items" or similar
which one could "use" in a particular context), and watching sequences
of "live action" video (often chroma keyed onto a static background).

Likewise, the game would also consist of a big stack of CD-ROMs with
frequent need to change CDs.

A few commonly used codecs at the time were CRAM (or "MS Video 1"),
which came standard with Windows; or RPZA ("Apple Quick Time Video")
which was more commonly used for games built on "Apple Quick Time".

Both video codecs were fairly simplistic, but also rather bulky.

If one runs an SDcard at 12MHz, one can get (theoretically) around 1.5
MB/s, in practice it is lower. If one uses polling IO, it is necessary
to significantly reduce this in order to leave CPU time to decode and
display the video (so, an upper limit of 100 to 200 K/s is more reasonable).

The effective bandwidth limit could be higher if the BJX2 core had some
hardware level feature to DMA blocks from the SDcard into RAM, but there
is no such mechanism (and using polling IO and a loop to read stuff by
twiddling bytes over SPI via MMIO addresses kinda puts a damper on things).

320x200 30Hz RPZA or CRAM video will kinda blow out this limit pretty
hard, and if one drops the "quality" setting here, the image quality
tends to go to crap.

Something like 160x100 15Hz will stay more easily within the IO
bandwidth limits, but 160x100 video "does not exactly look good".

Well, and with MPEG, while the bandwidth requirements are less, the
computational cost of decoding it, is asking a lot from a 50 MHz CPU.

If one LZ compresses the video frames, one can get around another 50-60%
size reduction, but in their standard forms, neither codec supports this.

And, if one is going to do a custom codec anyways, may as well try to
improve the compression further.

So, the goal is to get a more significant reduction in bitrate without
significantly increasing the computational cost of the video codec.

Looking at my spec again (vs from memory):
pppppp00 Index into Pattern Table, No Endpoint
pppppp10 Index into Pattern Table, with Color Endpoint
yyyxxx01 Motion Vector (1 block) | Skip (1..8 blocks)
pppp0011 2x2x1 Block, No Endpoint
pppp1011 2x2x1 Block, Has Endpoint
nn000111 Run of 1..4 x 4x4x1 blocks, No Endpoint
nn100111 Run of 1..4 x 4x4x1 blocks, Has Endpoint
nn010111 Run of 2..8 x 2x2x1 blocks, No Endpoint
nn110111 Run of 1..4 x 2x2x2 blocks, No Endpoint
nnp01111 Run of 1..4 x Flat-Color Blocks
nn011111 Run of 1..4 x Color Blocks, Endpoint Per Block
00111111 4x4x2 Block, No Endpoint
10111111 4x4x2 Block, Has Endpoint

With an endpoint format:
rrrrdggggdbbbbd0 (R4 G4 B4 D3)
vvvvvmm1 (Small Delta)
xxxxxxxxxxxxx111 (32b, Pair of RGB555 endpoints).

Looks like the colorspace works by unpacking the former into a pair of
RGB555 endpoints. Deltas then operate on the pair, or both endpoints can
be encoded directly.

This format is a bit more complicated than RPZA or CRAM, but can at
least be still be decoded at roughly similar speeds.

This format is then stored with an additional LZ compression stage
applied (before then being stored in a TLV wrapper and then into an AVI
container).

Uses RP2 LZ Scheme:
dddddddd-dlllrrr0 (L=3..10, D=0..511, R=0..7)
dddddddd-dddddlll-lllrrr01 (L=4..67, D=0..8191, R=0..7)
dddddddd-dddddddd-dlllllll-llrrr011 (L=4..515, D=0..131071, R=0..7)
rrrr0111 (Raw Bytes, R=(r+1)*8, 8..128)
zzz01111 (Long Match / Unused)
rr011111 (Raw Bytes, R=1..3, 0=EOB)

Where: L=Match Length, D=Match Distance, R=Raw Byte Count.
Basic algorithm copies any Raw Bytes, then copies an LZ Match from the
sliding window.
If an EOB marker is encountered, decoding stops.

This format tends to get slightly better compression than LZ4 while
being in a similar speed class.

On my ISA, this format is a little bit faster to decode than LZ4.
This is because LZ4 requires a bunch of additional 1-byte memory
accesses, where accessing a byte from memory may incur a 3-cycle penalty.

Meanwhile, reading 32 bits at a time, and then using shifts, is a little
cheaper. In this case, dispatching based on a unary code isn't
particularly expensive either.

For audio, had generally been using 16 kHz IMA ADPCM (mono), 64 kbps.
Though, 8 kHz can use 32 kbps (but sounds worse).

Generally, a drawback of something like MP3 is that the computational
cost of decoding it is fairly steep if compared with an ADPCM variant.

For my tests at the time, had mostly transcoded a few test videos:
"Bad Apple", which makes interesting use use of monochrome
"Heyyeahyeah", an AMV involving He-Man;
Some assorted Lindsay Stirling videos;
A few random episodes of "Sonic Boom";
...

Of these, a lot of the Lindsay Stirling videos put a lot more strain on
this class of video codec, as these codecs don't deal particularly well
with pan or zoom (whereas her videos tend to use a lot of pan and zoom).

Some of my older codecs, while also "very fast" by modern standards,
were still a bit steep for my CPU core (while many were still color-cell
based, they had switched over to being entropy-coded, whereas my BJX2
Core isn't really fast enough at 50MHz to deal all that effectively with
entropy-coded video codec designs at 320x200 or similar).

....

On 11/30/2022 6:07 PM, BGB wrote:
> On 11/30/2022 2:17 PM, Bart wrote:
>> On 30/11/2022 20:01, BGB wrote:
>>
>>> My custom CPU core would beat out an x86-64 PC pretty hard though at
>>> this if it had a similar clock speed and memory bandwidth (vs what I
>>> can get on an Artix-7 FPGA or similar...).
>>>
>>>
>>> Though, the PC would still win pretty big in terms of Dhrystone
>>> numbers and similar (though, likely depends on compiler; for example,
>>> there is also a pretty large gap between MSVC and GCC when it comes
>>> to Dhrystone numbers; and scaled relative to clock-speed, my numbers
>>> would be more comparable to the MSVC result).
>>>
>>> Interestingly, it seems for some tests involving neural nets, my ISA
>>> would pull more significantly ahead of my PC at this task.
>>>
>>>
>>> Though, it can be noted that the SIMD features are designed a fair
>>> bit differently than SSE or AVX (and in some cases need fewer
>>> instructions for similar tasks; and also less memory loads; as vector
>>> literals can be loaded inline as immediate values).
>>>
>>> General peak SIMD FPU performance is currently 200 MFLOP/s at 50MHz
>>> (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and Binary32
>>> with 4-wide vectors).
>>>
>>> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if
>>> using scalar instructions).
>>>
>>>
>>> At 50MHz, still don't really have enough "CPU go power" for things
>>> like non-terrible MPEG decoding though (something like 160x100 at
>>> 15fps is, bleh...).
>>
>> My first experiments with video managed 128x128 x 16-level greyscale
>> at some 0.25fps, uncompressed; 15fps would have looked pretty good!
>>
>> However this was using a 2.5MHz Z80 and recording frame-grabbed video
>> onto cassette tape using software PWM.
>
> I am not quite that old...
>
>
> Granted, I am now pretty old, but most of my life has been in the
> "Desktop PCs with x86 and Windows" era (though, in my childhood, one
> might still encounter older PCs running MS-DOS).
>
> During elementary school, I was mostly interacting with PCs running
> Win3x and Win95. During the time I was in high-school, the world was
> starting to move on to WinXP (I had been running Win2K though, as I
> wasn't a big fan of Win98, ...).
>
>
> But, during my childhood, there was at one point a big craze over
> "multimedia", and the ability to put "full motion video" onto CD-ROMs.
>
> So, there were a bunch of typically terrible "FMV Games" which showed
> video in a small window on the screen.
[...]

Phantasmagoria was pretty fun. I was always fond of Sierra games.

https://youtu.be/oAXC-MwfpHA

On 11/30/2022 8:28 PM, Chris M. Thomasson wrote:
> On 11/30/2022 6:07 PM, BGB wrote:
>> On 11/30/2022 2:17 PM, Bart wrote:
>>> On 30/11/2022 20:01, BGB wrote:
>>>
>>>> My custom CPU core would beat out an x86-64 PC pretty hard though at
>>>> this if it had a similar clock speed and memory bandwidth (vs what I
>>>> can get on an Artix-7 FPGA or similar...).
>>>>
>>>>
>>>> Though, the PC would still win pretty big in terms of Dhrystone
>>>> numbers and similar (though, likely depends on compiler; for
>>>> example, there is also a pretty large gap between MSVC and GCC when
>>>> it comes to Dhrystone numbers; and scaled relative to clock-speed,
>>>> my numbers would be more comparable to the MSVC result).
>>>>
>>>> Interestingly, it seems for some tests involving neural nets, my ISA
>>>> would pull more significantly ahead of my PC at this task.
>>>>
>>>>
>>>> Though, it can be noted that the SIMD features are designed a fair
>>>> bit differently than SSE or AVX (and in some cases need fewer
>>>> instructions for similar tasks; and also less memory loads; as
>>>> vector literals can be loaded inline as immediate values).
>>>>
>>>> General peak SIMD FPU performance is currently 200 MFLOP/s at 50MHz
>>>> (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and
>>>> Binary32 with 4-wide vectors).
>>>>
>>>> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if
>>>> using scalar instructions).
>>>>
>>>>
>>>> At 50MHz, still don't really have enough "CPU go power" for things
>>>> like non-terrible MPEG decoding though (something like 160x100 at
>>>> 15fps is, bleh...).
>>>
>>> My first experiments with video managed 128x128 x 16-level greyscale
>>> at some 0.25fps, uncompressed; 15fps would have looked pretty good!
>>>
>>> However this was using a 2.5MHz Z80 and recording frame-grabbed video
>>> onto cassette tape using software PWM.
>>
>> I am not quite that old...
>>
>>
>> Granted, I am now pretty old, but most of my life has been in the
>> "Desktop PCs with x86 and Windows" era (though, in my childhood, one
>> might still encounter older PCs running MS-DOS).
>>
>> During elementary school, I was mostly interacting with PCs running
>> Win3x and Win95. During the time I was in high-school, the world was
>> starting to move on to WinXP (I had been running Win2K though, as I
>> wasn't a big fan of Win98, ...).
>>
>>
>> But, during my childhood, there was at one point a big craze over
>> "multimedia", and the ability to put "full motion video" onto CD-ROMs.
>>
>> So, there were a bunch of typically terrible "FMV Games" which showed
>> video in a small window on the screen.
> [...]
>
> Phantasmagoria was pretty fun. I was always fond of Sierra games.
>
> https://youtu.be/oAXC-MwfpHA
>

Actually, I wonder if they still have the high res footage.

On 11/30/2022 10:28 PM, Chris M. Thomasson wrote:
> On 11/30/2022 6:07 PM, BGB wrote:
>> On 11/30/2022 2:17 PM, Bart wrote:
>>> On 30/11/2022 20:01, BGB wrote:
>>>
>>>> My custom CPU core would beat out an x86-64 PC pretty hard though at
>>>> this if it had a similar clock speed and memory bandwidth (vs what I
>>>> can get on an Artix-7 FPGA or similar...).
>>>>
>>>>
>>>> Though, the PC would still win pretty big in terms of Dhrystone
>>>> numbers and similar (though, likely depends on compiler; for
>>>> example, there is also a pretty large gap between MSVC and GCC when
>>>> it comes to Dhrystone numbers; and scaled relative to clock-speed,
>>>> my numbers would be more comparable to the MSVC result).
>>>>
>>>> Interestingly, it seems for some tests involving neural nets, my ISA
>>>> would pull more significantly ahead of my PC at this task.
>>>>
>>>>
>>>> Though, it can be noted that the SIMD features are designed a fair
>>>> bit differently than SSE or AVX (and in some cases need fewer
>>>> instructions for similar tasks; and also less memory loads; as
>>>> vector literals can be loaded inline as immediate values).
>>>>
>>>> General peak SIMD FPU performance is currently 200 MFLOP/s at 50MHz
>>>> (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and
>>>> Binary32 with 4-wide vectors).
>>>>
>>>> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if
>>>> using scalar instructions).
>>>>
>>>>
>>>> At 50MHz, still don't really have enough "CPU go power" for things
>>>> like non-terrible MPEG decoding though (something like 160x100 at
>>>> 15fps is, bleh...).
>>>
>>> My first experiments with video managed 128x128 x 16-level greyscale
>>> at some 0.25fps, uncompressed; 15fps would have looked pretty good!
>>>
>>> However this was using a 2.5MHz Z80 and recording frame-grabbed video
>>> onto cassette tape using software PWM.
>>
>> I am not quite that old...
>>
>>
>> Granted, I am now pretty old, but most of my life has been in the
>> "Desktop PCs with x86 and Windows" era (though, in my childhood, one
>> might still encounter older PCs running MS-DOS).
>>
>> During elementary school, I was mostly interacting with PCs running
>> Win3x and Win95. During the time I was in high-school, the world was
>> starting to move on to WinXP (I had been running Win2K though, as I
>> wasn't a big fan of Win98, ...).
>>
>>
>> But, during my childhood, there was at one point a big craze over
>> "multimedia", and the ability to put "full motion video" onto CD-ROMs.
>>
>> So, there were a bunch of typically terrible "FMV Games" which showed
>> video in a small window on the screen.
> [...]
>
> Phantasmagoria was pretty fun. I was always fond of Sierra games.
>
> https://youtu.be/oAXC-MwfpHA
>

Bonus points for Phantasmagoria:
They are at least using most of the screen for the video...

Looks like they were using 284x160, which is a fair bit better than some
of what I had seen.

But, I was thinking of examples more like Critical Path, where most of
the screen was used up by "hud" (there were more like this, but I don't
remember their names at the moment).

But, yeah, same basic genre; there was a point in time when there were
*a lot* of these sorts of games...

I guess I can note that at one point there were also the Tex Murphy
games, some of which were sorta like if one hybridized an FMV game with
Doom style 3D (just with more first-person walking from one location to
another; arriving at locations or interacting with characters serving to
trigger FMV cutscenes).

So, yeah, I guess I can note that not all FMV games are terrible, but
there *were* a lot of them that were, not exactly good...

Also I remember one minor annoyance was when I was in middle school, had
went over to NT4 (dual booting with Linux), and while NT4 would crash
less than Win9x, its game selection was more limited as many games of
that era would straight up refuse to run on Windows NT (and by
high-school went over to Win2K, still set up to dual boot with Linux).

Eventually I gave up on dual booting, and switched over mostly to
occasionally running Linux in an emulator with Windows as the primary OS
(since trying to "actually use Linux as an OS" was an endless source of
hassle).

But, in my case, I ended up much preferring an OS where I could compile
stuff (mostly using Cygwin and similar at this point), and not have the
OS crash all the time (and NT and 2K had a big advantage over 9x on this
front).

IIRC, I think it was sometime around this time that I started hanging
around on Usenet... Still not really sure if I have made effective use
of my span of existence...

....

On 11/30/2022 10:29 PM, Chris M. Thomasson wrote:
> On 11/30/2022 8:28 PM, Chris M. Thomasson wrote:
>> On 11/30/2022 6:07 PM, BGB wrote:
>>> On 11/30/2022 2:17 PM, Bart wrote:
>>>> On 30/11/2022 20:01, BGB wrote:
>>>>
>>>>> My custom CPU core would beat out an x86-64 PC pretty hard though
>>>>> at this if it had a similar clock speed and memory bandwidth (vs
>>>>> what I can get on an Artix-7 FPGA or similar...).
>>>>>
>>>>>
>>>>> Though, the PC would still win pretty big in terms of Dhrystone
>>>>> numbers and similar (though, likely depends on compiler; for
>>>>> example, there is also a pretty large gap between MSVC and GCC when
>>>>> it comes to Dhrystone numbers; and scaled relative to clock-speed,
>>>>> my numbers would be more comparable to the MSVC result).
>>>>>
>>>>> Interestingly, it seems for some tests involving neural nets, my
>>>>> ISA would pull more significantly ahead of my PC at this task.
>>>>>
>>>>>
>>>>> Though, it can be noted that the SIMD features are designed a fair
>>>>> bit differently than SSE or AVX (and in some cases need fewer
>>>>> instructions for similar tasks; and also less memory loads; as
>>>>> vector literals can be loaded inline as immediate values).
>>>>>
>>>>> General peak SIMD FPU performance is currently 200 MFLOP/s at 50MHz
>>>>> (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and
>>>>> Binary32 with 4-wide vectors).
>>>>>
>>>>> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if
>>>>> using scalar instructions).
>>>>>
>>>>>
>>>>> At 50MHz, still don't really have enough "CPU go power" for things
>>>>> like non-terrible MPEG decoding though (something like 160x100 at
>>>>> 15fps is, bleh...).
>>>>
>>>> My first experiments with video managed 128x128 x 16-level greyscale
>>>> at some 0.25fps, uncompressed; 15fps would have looked pretty good!
>>>>
>>>> However this was using a 2.5MHz Z80 and recording frame-grabbed
>>>> video onto cassette tape using software PWM.
>>>
>>> I am not quite that old...
>>>
>>>
>>> Granted, I am now pretty old, but most of my life has been in the
>>> "Desktop PCs with x86 and Windows" era (though, in my childhood, one
>>> might still encounter older PCs running MS-DOS).
>>>
>>> During elementary school, I was mostly interacting with PCs running
>>> Win3x and Win95. During the time I was in high-school, the world was
>>> starting to move on to WinXP (I had been running Win2K though, as I
>>> wasn't a big fan of Win98, ...).
>>>
>>>
>>> But, during my childhood, there was at one point a big craze over
>>> "multimedia", and the ability to put "full motion video" onto CD-ROMs.
>>>
>>> So, there were a bunch of typically terrible "FMV Games" which showed
>>> video in a small window on the screen.
>> [...]
>>
>> Phantasmagoria was pretty fun. I was always fond of Sierra games.
>>
>> https://youtu.be/oAXC-MwfpHA
>>
>
> Actually, I wonder if they still have the high res footage.

Dunno there...

I was looking more at some more screenshots, and an realizing that it is
proving annoyingly difficult to try to determine the original video
resolution from the screenshots (pretty much all of them seem to have
been resized in inconsistent ways).

Appears like overall resolution was "close to but not quite 640x480"; it
also appears video frame area may have been 512x256.

Looking at some of the images, pretty sure the video codec is neither
CRAM nor RPZA:
* Images tend to have more than 2 or 4 unique colors per 4x4 block (1);
* What compression artifacts it does have, make it look more like it is
repeatedly drawing new spans of changed pixels on top of the old pixels.

1: While both formats did have a block that could express 16 unique
pixels, the normal blocks would only do 2 colors (in CRAM), or 4
interpolated colors (RPZA). The full-detail blocks were used rarely due
to cost.

The video in this case does not seem to obey these rules, but does have
more obvious pixel-span artifacts.

Framerate appears to be somewhere around 8 fps (so, errm, the "full
motion" part is a bit more questionable).

So, it looks almost more like if one were doing video deltas via a
modified LZ77 decoder or similar.

So, a guess of how the codec may have worked by looking at the output:
There is a 512x256 frame of pixels;
Each pixel is 256 colors, with a transparent color (for the background).

Compression scheme was either:
Skip pixels from previous frame;
Draw a run of new pixels on top of the old pixels;
Copy pixels from somewhere else within the partially redrawn frame.

Where the encoder decides what to do based on some metric of the error
within a given span of pixels. Though in this case, the error tolerance
seems to have been fairly low.

Not sure what sort of bitrate one could get with this scheme.

Likely worst case: ~ 8 mbps (~ 1 MB/s, ... at 8Hz ...), ~ 8.0 bpp.
Assuming roughly 1/4 of the frame is updated each frame, ~ 256 K/s.

If I were to design a format like this, say:
dddddddd-dlllrrr0 (L=3..10, D=+/-255, R=0..7)
dddddddd-dddddlll-lllrrr01 (L=4..67, D=+/-4K, R=0..7)
dddddddd-dddddddd-dlllllll-llrrr011 (L=4..515, D=+/-64K, R=0..7)
rrrr0111 (Raw Bytes, R=(r+1)*8, 8..128)
rrrrrrrr-rrp01111 (Big Raw | Skip)
rr011111 (Raw Bytes, R=1..3, 0=EOB)

So, basically a modified RP2 but with distances being signed.
If (D==0), it is effectively a skip span.

Seems like a possibly interesting approach, though most likely the
bitrate would *suck* (... probably why they were doing the video at
roughly 8 fps? ...).

If so, if used for full-scene video, one would likely be hard pressed to
get much under 1.0 bpp without some pretty severe compression artifacts.

środa, 30 listopada 2022 o 21:01:58 UTC+1 BGB napisał(a):
> On 11/30/2022 9:08 AM, fir wrote:
> > środa, 30 listopada 2022 o 03:37:07 UTC+1 BGB napisał(a):
> >> On 11/29/2022 3:01 PM, fir wrote:
> >>> it appaered to me some idea of image codec thit i find
> >>> fun (sadly i probably not will find time to code it - though idea
> >>> is good as a task so if someone would have time my
> >>> experiment with it itself) :
> >>>
> >>> the idea is just to store a list of pixels (it is { x, y,color})
> >>> and and the use some kind of color interp[olation beetween points
> >>> (at first draft my be just linear) to draw the image itself
> >>>
> >>> some simple image, all black for example would be:
> >>>
> >>> 0,0, 0x000000,
> >>> 999,0,0x000000
> >>> 0,999,0x000000
> >>> 999,999,0x000000
> >>>
> >>> that would make 1000x1000 pixel bitmap all black
> >>> (and that would be 48 bytes or 32 bytes depending if
> >>> usung ints or shorts on pixel coordinates
> >>>
> >>> polish flag like image would be
> >>>
> >>> 0,0, 0xffffff, 999,0,0xffffff, 0,499,0xffffff, 999,499,0xffffff,
> >>> 0,500, 0xff0000,999,500,0xff0000,0,999,0xff0000,999,999,0xff0000
> >>>
> >>> ot would be rather ;pssy compression method but it could
> >>> be possible imo to obtain very small images imo
> >>>
> >>> i also thing if not to add fourth number to x,y,color, like d or something - coeficient which would encode some info how to interpolete thru this pixel
> >>>
> >>> it seem to me it could be quite fun to write some codec (i mean encoder) that would generate those list of pixel
> >>>
> >>> for exampel i first draft i guess it could be done randomly i mean
> >>> given encoder could assume some number of pixels to use (like 1000
> >>> for example) and just randomly take it from given photo - then draw
> >>> the result with interpolations of given pixels and then compare how
> >>> well the resulted rendered picture is distant to oryginal - loop that
> >>> many times and then take the one that fits the best
> >>>
> >>> (programatically it seem quite easy = so im not sure maybe i even could try it)
> >>>
> >> If you organize the points into a polygon, then this would be
> >> effectively a vector graphics format. For good measure, could maybe add
> >> some B-Splines or similar (say, so one can draw a circle using a
> >> relatively small number of vertices).
> >>
> >> Automatic conversion from raster to vector formats isn't really a thing
> >> AFAIK ("most" software assuming having the user manually trace the image
> >> into a vector format). Could be done in theory by using edge detection
> >> or thresholds to try to split up the image into regions, and then
> >> setting the vertices based on the average color in that region.
> >>
> >> Decoding vector formats tends to be a relatively involved process though
> >> (it is effectively a polygon rasterizer).
> >>
> >>
> >>
> >> As for more traditional raster formats:
> >>
> >> There is DCT, but realistically one can't really do all that much to
> >> improve "significantly" over T.81 JPEG here (modest gains are possible,
> >> but not usually enough to displace the original; and most of the "JPEG
> >> replacements" also come with significant drawbacks).
> >>
> >> Linear filtering plus LZ compression is also well known (PNG works this
> >> way).
> >>
> >>
> >> Variants on color-cell compression can work well for more specialized
> >> use cases (where quality is less of a priority). Things like S3TC and
> >> DDS are a few better known examples. Some old (early 90s era) video
> >> codecs, namely RPZA and CRAM, also used this. Some further compression
> >> can be gained "cheaply" by throwing an LZ compressor on top of this
> >> (having both a Huffman-coded and Byte-only LZ encoder works well here,
> >> as many frames/images and similar will not benefit from the use of
> >> Huffman encoding; which does have a non-zero speed cost).
> >>
> >> For color cell codecs, by themselves, compression is usually bad enough
> >> that one is more likely to end up being IO bound rather than CPU bound
> >> (even on a relatively slow CPU). Adding an LZ compression stage can help
> >> here.
> >>
> >> It is possible to improve over Deflate in terms of speed by limiting the
> >> Huffman symbols to 12 bits or so, and compression benefits are possible
> >> by using a larger sliding window (a 128K window works well IME). It is
> >> relatively difficult to push a Huffman based format much past around
> >> 600MB/sec though (on a modernish PC).
> >>
> >> For a byte-oriented LZ, something like LZ4 works well, though I have my
> >> own format (RP2) which tends to get slightly better compression at a
> >> similar decode speed (typically several GB/sec on a modern PC) for most
> >> data types.
> >>
> >> The traditional color-cell formats tend to store pixels at 4x4x2bpp
> >> (RPZA, S3TC, ...) or 4x4x1bpp (CRAM).
> >>
> >>
> >> A format with multiple block sizes can also work well, say:
> >> 4x4x2bpp (32 bits)
> >> 4x4x1bpp (16 bits)
> >> 2x2x2bpp (8 bits)
> >> 2x2x1bpp (4 bits)
> >> Along with a scheme to use a differential encoding on the color
> >> endpoints (may overlap with selecting the block format).
> >>
> >> One other promising block format is 6 bits, say:
> >> 2b: Horizontal Frequency
> >> 2b: Vertical Frequency
> >> 1b: Horizontal Polarity
> >> 1b: Vertical Polarity
> >>
> >> Which is then used as an index into a lookup table of 4x4x2bpp patterns
> >> (generated according to the above).
> >>
> >> Say, frequency encodes, say (0..7 logical):
> >> 0.00=(5555), 0.01=(6521), 0.10=(6116), 0.11=(6161)
> >> 1.00=(2222), 1.01=(1256), 1.10=(1661), 1.11=(1616)
> >> Added up horizontal x vertical, then shifted right by 2 bits to map to
> >> the 0..3 range.
> >>
> >>
> >> So, one has a command-byte which may encode some combination of:
> >> Emit a pattern block (previous colors);
> >> Apply a delta over the color endpoints;
> >> Encode a run of colors, blocks, or blocks+colors;
> >> Skip or copy-translate blocks from the prior frame.
> >>
> >> With an LZ compressor applied on top of this.
> >>
> >> In this case, "pppppp00" encoded the 6-bit pattern above, which was the
> >> dominant default block-format used, with 16 bits used to encode a small
> >> color delta, say:
> >> rrrg-ggbb bddd-0011
> >>
> >> Where, say, the command prefix was essentially a Rice(1) pattern.
> >> 00, 10, 001, 101, 0011, 1011, 00111, 10111, ...
> >> Albeit conceptually read from right to left in this example.
> >>
> >> Color space was RGB555, with 5b per component for the center color, and
> >> 5b for the (max-min) value (D), so:
> >> Mr=Ar-(D>>1), Mg=Ag-(D>>1), Mb=Ab-(D>>1)
> >> Nr=Mr+D, Ng=Mg+D, Nb=Mb+D
> >> One could encode a delta in 16 bits with 3b per delta (-3 .. +3), or an
> >> escape case to encode a raw endpoint in 24 bits.
> >>
> >> I had semi-recently had reasonably good results with a codec sorta like
> >> this. Not necessarily the best image quality, but pretty reasonable in
> >> terms of quality/bitrate and decode speed.
> >>
> >>
> >> Note that (for decoding blocks to pixels) one would map the above
> >> colorspace to a set of 4 colors, say:
> >> 00=Mrgb, 01=(5/8)*Mrgb+(3/8)*Nrgb, 10=(3/8)*Mrgb+(5/8)*Nrgb, 11=Nrgb
> >>
> >> Then unpack pixels from a 4x4x2 block something like:
> >> ix0=(px>>0)&3; ix1=(px>>2)&3;
> >> ix2=(px>>4)&3; ix3=(px>>6)&3;
> >> p0=ctab[ix0]; p1=ctab[ix1];
> >> p2=ctab[ix2]; p3=ctab[ix3];
> >> ct[0]=p0; ct[1]=p1;
> >> ct[2]=p2; ct[3]=p3;
> >> ct+=stride;
> >> ix0=(px>> 8)&3; ix1=(px>>10)&3;
> >> ix2=(px>>12)&3; ix3=(px>>14)&3;
> >> p0=ctab[ix0]; p1=ctab[ix1];
> >> p2=ctab[ix2]; p3=ctab[ix3];
> >> ct[0]=p0; ct[1]=p1;
> >> ct[2]=p2; ct[3]=p3;
> >> ...
> >>
> >>
> >> Was fast enough for video playback on an 50 MHz core on an FPGA (IIRC,
> >> was trying for 320x200x30fps; where CRAM was hopelessly IO bound).
> >>
> >> But, yeah, for this class of codec, if one has output that "doesn't look
> >> like broken garbage" at around 0.3 bpp or so (~ 500 kbps), one is doing
> >> pretty well... Still pretty weak vs MPEG or similar, but MPEG is an
> >> entirely different class of video codec.
> >>
> >>
> >> Decode speeds (on my PC) being a little over a gigapixel per second
> >> (single threaded decoder). (For "technical reasons" is being difficult
> >> to get much over a gigapixel per second for a single-threaded decoder)..
> >>
> >>
> >>> some opinions welcome
> >>>
> >>> /fir
> >
> > i think you probably dont get what i said - its not vector graphics
> >
> > its a bitmap format that contains information on itself as a list of points
> > with color and is build up - rasterized by some method of color interpolation
> > between the pixels
> >
> > that format would be generally bad for images that have various pixel level details but should
> > be good in compressing images that have wider areas
> > that change color slowly, for example if some
> > area has solid color say red you could just
> > put 3 or 4 red pixels covering the area and
> > rasterisation will fill up te in-between space by red
> >
> > the provlem is how to write c code that would do
> > that interpolation - its not only a matter of
> > interpolation in triangle in-between 3 points but
> > the problem is you got just a list of pixels
> > randomly on the image square and there is need to chose
> > the oones for that triangle in loop to render tnen
> > whole image by those triangles
> >
> By the time you are dealing with points, triangles, and interpolation...
> It has crossed over into vector graphics territory.
>
> Even if your coordinate space is still specified in terms of pixels.
>
>
> > how to do that?
>
>
> Usual strategy is to order the pixels such that the one with the
> smallest Y is on top and the largest is on the bottom.
>
> One then calculates how much to step along the left and right edges for
> each Y unit to the middle vertex, and then again from the midpoint to
> the bottom vertex (with two separate cases for whether the midpoint is
> to the left or right of the bottom vertex).
>
> One starts with the values (in each edge) for the starting (top) vertex.
> Then, walk down in Y towards the midpoint, drawing a span for each line.
>
> Once at the midpoint, one switches to the step vectors to the bottom
> vertex, and steps from the middle to the bottom, drawing a span for each
> scanline.
>
> For drawing a span, process is (pseudo-code):
> Calculate the step vectors from the left edge to the right edge (in X);
> dist=(RHS.X-LHS.X);
> if(dist<=0)
> return;
> Step.RGBA=(RHS.RGBA-LHS.RGBA)/dist;
> ... one can add in other parameters here as well ...
> Check that the span is inside the destination buffer;
> if(RHS.X<=0)
> return;
> if(LHS.X<0)
> { ... adjust LHS rightward by -LHS.X pixels;
> LHS.X=0; dist=RHS.X; }
> if(RHS.X>=Window.XSize)
> { dist=Window.XSize-LHS.X; }
> Loop over the pixels, applying steps, and drawing pixels.
>
>
> If one adds textures, ST coordinates, a blending operator, ..., one
> basically has enough to do the inner loops of OpenGL 1.x in software
> (OpenGL 2.x adds shaders, which basically make things a whole lot more
> complicated).
>
> If performance matters, one generally may end up using a whole lot of
> SIMD here. Also with span functions that can be swapped out (via
> function pointers) based on rendering settings and blending mode (for
> common modes, say, (SRC_ALPHA, ONE_MINUS_SRC_ALPHA), etc, one can gain a
> fair bit of performance by having specialized span-drawing functions,
> and only falling back to "generic" versions for more unusual modes).
>
>
> For drawing a polygon, one can decompose it into triangles.
> Typical strategy is to treat the starting vertex as fixed, and then each
> following edge emits another triangle.
>
> For 3D, one might also do:
> Convert treat each XYZ as XYZW with W=1.0;
> Multiply XYZW by a 4x4 Transform*Projection matrix;
> Scale the vector by 1.0/W;
> One then (typically) now has a screen space vector (XYZW).
>
> For texture-mapping and 3D, one big ugly issue is affine warping.
> One "cheapish" option is:
> Calculate the combined total of the edge lengths;
> If larger than a threshold, subdivide triangle and try again.
> Calculate the midpoint vertices, and one triangle becomes 4.
>
> Though, at the high level, it may also make sense to treat quads as a
> primitive, partly as they subdivide more efficiently. There is also
> "perspective correct filtering", but this requires a reasonably fast
> floating-point divide (otherwise, subdividing large primitives tends to
> be cheaper).
>
>
> At the lower level, quads can also make sense (if more complicated to
> rasterize than triangles) as the affine warping tends to be less
> noticeable for quads (and thus they don't need to be divided as much).
>
> For drawing a polygon:
> If N==3:
> Draw a triangle
> If N==4:
> Draw a quad
> If N==5:
> Draw as a quad and a triangle
> If N==6:
> Draw as two quads
> Else:
> Fall back to triangles.
> ...
>
>
> For 2D, one doesn't really need to care about affine warping though.
>
> Typically, if a primitive falls entirely off-screen during the
> projection and subdivision stage, it can be discarded.
>
>
> Things like NURBS or B-Splines would add a little more complexity, as
> these generally involve subdivision at the level of mesh geometry. This
> is mostly N/A for something like OpenGL though (the program itself
> generally deals with this).
>
> A lot of vector-graphics formats have this though.
>
>
>
>
> Admittedly, I had done my own software implementation of the OpenGL API,
> so this may effect things.
>
> Interestingly, it maps "relatively OK" to my custom ISA (and in terms of
> "clock cycles per pixel" tends to beat out running it on a modern x86-64
> CPU; though my PC still wins pretty big in terms of absolute fill rate
> due to having around a 74x higher clock speed and around 100x more
> memory bandwidth...).
>
> My custom CPU core would beat out an x86-64 PC pretty hard though at
> this if it had a similar clock speed and memory bandwidth (vs what I can
> get on an Artix-7 FPGA or similar...).
>
>
> Though, the PC would still win pretty big in terms of Dhrystone numbers
> and similar (though, likely depends on compiler; for example, there is
> also a pretty large gap between MSVC and GCC when it comes to Dhrystone
> numbers; and scaled relative to clock-speed, my numbers would be more
> comparable to the MSVC result).
>
> Interestingly, it seems for some tests involving neural nets, my ISA
> would pull more significantly ahead of my PC at this task.
>
>
> Though, it can be noted that the SIMD features are designed a fair bit
> differently than SSE or AVX (and in some cases need fewer instructions
> for similar tasks; and also less memory loads; as vector literals can be
> loaded inline as immediate values).
>
> General peak SIMD FPU performance is currently 200 MFLOP/s at 50MHz
> (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and Binary32
> with 4-wide vectors).
>
> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if using
> scalar instructions).
>
>
> At 50MHz, still don't really have enough "CPU go power" for things like
> non-terrible MPEG decoding though (something like 160x100 at 15fps is,
> bleh...).
>
> Partial reason I focused on color cell + LZ in this case is this sort of
> codec can do 320x200 at 30fps, at least provided things don't become IO
> bound by the SDcard interface or similar.
>
>
> One other "semi-interesting" approach though, is a format that looks
> like JPEG on the high level, but then uses an LZ encoder on the output
> end (rather than bare Huffman+VLC). Though, past experiments along these
> lines didn't gain much in terms of speed (but did have some promising
> results on the compression front).
>
> The VLC stage would be partly replaced with a byte-oriented encoding, say:
> cccc-zzz0 (Coeff=-8..7)
> cccz-zz01 cccc-cccc (Coeff=-1024..1023)
> ...
> Where 'c' is the sign-folded coefficient, and z is the number of zeroes
> (0..6, with 7 as an escape case).
>
> Which may be either:
> Dumped as raw bytes;
> Compressed with a byte-oriented LZ (such as LZ4);
> Compressed with a Huffman-based LZ (such as Deflate or similar).
>
> ...

On 01/12/2022 15:29, fir wrote:

> its not about rasterization i rather need
> a function that returns color for x,y
> and as an input takes 3 vertices of a triangle
> with 3 colors
>
> unsigned GiveInterpolatedColor(float x, float y, float x1, float y1, unsigned c1, float x2, float y2, unsigned c2, float x3, float y3, unsigned c3)
> {
> //....
> }

So given a triangle with corners A, B, C, of colours C1, C2, C3
respectfully, you want to interpolate the colour at any point P within
the triangle?

You'd first need to define exactly how you'd want it to work. Googling
for 'interpolate colour within triangle' gives me links like these:

https://codeplea.com/triangular-interpolation

https://observablehq.com/@jobleonard/linear-interpolation-along-a-triangle-with-barycentric-co

On 12/1/2022 9:46 AM, Bart wrote:
> On 01/12/2022 15:29, fir wrote:
>
>> its not about rasterization i rather need
>> a function that returns color for x,y
>> and as an input takes 3 vertices of a triangle
>> with 3 colors
>>
>> unsigned GiveInterpolatedColor(float x, float y, float x1, float y1,
>> unsigned c1, float x2, float y2, unsigned c2, float x3, float y3,
>> unsigned c3)
>> {
>>    //....
>> }
>
>
> So given a triangle with corners A, B, C, of colours C1, C2, C3
> respectfully, you want to interpolate the colour at any point P within
> the triangle?
>
> You'd first need to define exactly how you'd want it to work. Googling
> for 'interpolate colour within triangle' gives me links like these:
>
> https://codeplea.com/triangular-interpolation
>
> https://observablehq.com/@jobleonard/linear-interpolation-along-a-triangle-with-barycentric-co

You can do this, along with adding logic to check whether a given X/Y
falls inside a given triangle (so as to whether or not the triangle
contributes to the color).

Big obvious drawback is speed:
Doing it this way is likely to be several orders of magnitude slower
than the "walk triangle edges and draw spans" approach.

Granted, if one is not trying to draw the images in real time (or even
particularly quickly), I guess it could work...

....

On 01/12/2022 17:13, BGB wrote:
> On 12/1/2022 9:46 AM, Bart wrote:
>> On 01/12/2022 15:29, fir wrote:
>>
>>> its not about rasterization i rather need
>>> a function that returns color for x,y
>>> and as an input takes 3 vertices of a triangle
>>> with 3 colors
>>>
>>> unsigned GiveInterpolatedColor(float x, float y, float x1, float y1,
>>> unsigned c1, float x2, float y2, unsigned c2, float x3, float y3,
>>> unsigned c3)
>>> {
>>>    //....
>>> }
>>
>>
>> So given a triangle with corners A, B, C, of colours C1, C2, C3
>> respectfully, you want to interpolate the colour at any point P within
>> the triangle?
>>
>> You'd first need to define exactly how you'd want it to work. Googling
>> for 'interpolate colour within triangle' gives me links like these:
>>
>> https://codeplea.com/triangular-interpolation
>>
>> https://observablehq.com/@jobleonard/linear-interpolation-along-a-triangle-with-barycentric-co
>
> You can do this, along with adding logic to check whether a given X/Y
> falls inside a given triangle (so as to whether or not the triangle
> contributes to the color).
>
> Big obvious drawback is speed:
> Doing it this way is likely to be several orders of magnitude slower
> than the "walk triangle edges and draw spans" approach.
>
> Granted, if one is not trying to draw the images in real time (or even
> particularly quickly), I guess it could work...

OP said they weren't interested in rastering.

Thinking about it, I probably did something like this when shading
surfaces (made up of quads in my case), when I needed a 'smooth shading'
effect to overcome the faceted artefacts. But that was during rasterising.

(It wasn't fast either done in software, but likely faster than a
function like the one proposed.)

czwartek, 1 grudnia 2022 o 16:47:08 UTC+1 Bart napisał(a):
> On 01/12/2022 15:29, fir wrote:
>
> > its not about rasterization i rather need
> > a function that returns color for x,y
> > and as an input takes 3 vertices of a triangle
> > with 3 colors
> >
> > unsigned GiveInterpolatedColor(float x, float y, float x1, float y1, unsigned c1, float x2, float y2, unsigned c2, float x3, float y3, unsigned c3)
> > {
> > //....
> > }
> So given a triangle with corners A, B, C, of colours C1, C2, C3
> respectfully, you want to interpolate the colour at any point P within
> the triangle?
>
> You'd first need to define exactly how you'd want it to work. Googling
> for 'interpolate colour within triangle' gives me links like these:
>
> https://codeplea.com/triangular-interpolation
>
> https://observablehq.com/@jobleonard/linear-interpolation-along-a-triangle-with-barycentric-co
ok it helps but this is the easier part
the harder part is: you got a list of N points (within some recrangle which is a photo area)

how to get a list of triangles 'spanned' on this points that cover the photo area as a set of triangles (then i could interpolate)

i dont know how this problem is named..

czwartek, 1 grudnia 2022 o 19:10:03 UTC+1 fir napisał(a):
> czwartek, 1 grudnia 2022 o 16:47:08 UTC+1 Bart napisał(a):
> > On 01/12/2022 15:29, fir wrote:
> >
> > > its not about rasterization i rather need
> > > a function that returns color for x,y
> > > and as an input takes 3 vertices of a triangle
> > > with 3 colors
> > >
> > > unsigned GiveInterpolatedColor(float x, float y, float x1, float y1, unsigned c1, float x2, float y2, unsigned c2, float x3, float y3, unsigned c3)
> > > {
> > > //....
> > > }
> > So given a triangle with corners A, B, C, of colours C1, C2, C3
> > respectfully, you want to interpolate the colour at any point P within
> > the triangle?
> >
> > You'd first need to define exactly how you'd want it to work. Googling
> > for 'interpolate colour within triangle' gives me links like these:
> >
> > https://codeplea.com/triangular-interpolation
> >
> > https://observablehq.com/@jobleonard/linear-interpolation-along-a-triangle-with-barycentric-co
> ok it helps but this is the easier part
> the harder part is: you got a list of N points (within some recrangle which is a photo area)
>
> how to get a list of triangles 'spanned' on this points that cover the photo area as a set of triangles (then i could interpolate)
>
> i dont know how this problem is named..

probably this is what im talking about

https://en.wikipedia.org/wiki/Delaunay_triangulation

esp see that 100 random points image ..but yet need to write co code for that

input is a list of N colored points and outout is an image with those triangles interpolated

czwartek, 1 grudnia 2022 o 19:22:53 UTC+1 fir napisał(a):
> czwartek, 1 grudnia 2022 o 19:10:03 UTC+1 fir napisał(a):
> > czwartek, 1 grudnia 2022 o 16:47:08 UTC+1 Bart napisał(a):
> > > On 01/12/2022 15:29, fir wrote:
> > >
> > > > its not about rasterization i rather need
> > > > a function that returns color for x,y
> > > > and as an input takes 3 vertices of a triangle
> > > > with 3 colors
> > > >
> > > > unsigned GiveInterpolatedColor(float x, float y, float x1, float y1, unsigned c1, float x2, float y2, unsigned c2, float x3, float y3, unsigned c3)
> > > > {
> > > > //....
> > > > }
> > > So given a triangle with corners A, B, C, of colours C1, C2, C3
> > > respectfully, you want to interpolate the colour at any point P within
> > > the triangle?
> > >
> > > You'd first need to define exactly how you'd want it to work. Googling
> > > for 'interpolate colour within triangle' gives me links like these:
> > >
> > > https://codeplea.com/triangular-interpolation
> > >
> > > https://observablehq.com/@jobleonard/linear-interpolation-along-a-triangle-with-barycentric-co
> > ok it helps but this is the easier part
> > the harder part is: you got a list of N points (within some recrangle which is a photo area)
> >
> > how to get a list of triangles 'spanned' on this points that cover the photo area as a set of triangles (then i could interpolate)
> >
> > i dont know how this problem is named..
> probably this is what im talking about
>
> https://en.wikipedia.org/wiki/Delaunay_triangulation
>
> esp see that 100 random points image ..but yet need to write co code for that
>
> input is a list of N colored points and outout is an image with those triangles interpolated

so the next question: write code loop that takes list of points as an inpud and produces
this triangle lis as an output (may be ram output or loop sequence output)

im terribly tired last times (but may use an approach of gynvael coldwind - divide thing you do on long series of enough easy steps)

On 12/1/2022 12:07 PM, Bart wrote:
> On 01/12/2022 17:13, BGB wrote:
>> On 12/1/2022 9:46 AM, Bart wrote:
>>> On 01/12/2022 15:29, fir wrote:
>>>
>>>> its not about rasterization i rather need
>>>> a function that returns color for x,y
>>>> and as an input takes 3 vertices of a triangle
>>>> with 3 colors
>>>>
>>>> unsigned GiveInterpolatedColor(float x, float y, float x1, float y1,
>>>> unsigned c1, float x2, float y2, unsigned c2, float x3, float y3,
>>>> unsigned c3)
>>>> {
>>>>    //....
>>>> }
>>>
>>>
>>> So given a triangle with corners A, B, C, of colours C1, C2, C3
>>> respectfully, you want to interpolate the colour at any point P
>>> within the triangle?
>>>
>>> You'd first need to define exactly how you'd want it to work.
>>> Googling for 'interpolate colour within triangle' gives me links like
>>> these:
>>>
>>> https://codeplea.com/triangular-interpolation
>>>
>>> https://observablehq.com/@jobleonard/linear-interpolation-along-a-triangle-with-barycentric-co
>>
>> You can do this, along with adding logic to check whether a given X/Y
>> falls inside a given triangle (so as to whether or not the triangle
>> contributes to the color).
>>
>> Big obvious drawback is speed:
>> Doing it this way is likely to be several orders of magnitude slower
>> than the "walk triangle edges and draw spans" approach.
>>
>> Granted, if one is not trying to draw the images in real time (or even
>> particularly quickly), I guess it could work...
>
> OP said they weren't interested in rastering.
>
> Thinking about it, I probably did something like this when shading
> surfaces (made up of quads in my case), when I needed a 'smooth shading'
> effect to overcome the faceted artefacts. But that was during rasterising.
>
> (It wasn't fast either done in software, but likely faster than a
> function like the one proposed.)
>

OK.

I am admittedly kinda biased more towards "things than can be done at a
reasonable level of performance".

So, for example, things like doing an OpenGL backend capable of running
the Quake 1/2/3 engines at usable framerates (well, and also a few of my
own "Minecraft clone" style engines).

But, yeah, rasterizing is likely nearly the only viable option in this
case. I had used linear interpolation along the edges, which was
admittedly rather prone to affine warping.

Hadn't usually done the "perspective correct" approach as the use of
floating-point divide in an inner loop is a bit of a problem here.

In my ISA, I have a hardware FDIV that currently takes around 120 clock
cycles (it is built on top of the Integer Divide unit, which uses a
1-bit-per-cycle "Shift and Add" mechanism). In low-precision cases it is
usually faster to fake this in software (usually a "fast approximation",
followed by 1 to 3 Newton-Raphson stages).

Granted, subdividing triangles and quads isn't cheap either, but isn't
too painful if one is conservative, say:
(A+B+C) > 120 pixels //triangle
(A+B+C+D) > 160 pixels //quad
Though, in my case, these checks are done more like:
(A^2+B^2+C^2) > 120^2

Because, sqrt is also expensive (and the usual ways of calculate edge
length naturally result in squared distances), eg:
T=A.xy-B.xy;
Da=dot(T,T);

So, say, limiting the primitives to around 40 pixels on each edge is
enough to mostly limit obvious warping (most obvious on large
primitives) while also mostly leaving smaller primitives unaffected.

If one tries to divide finer (say, much under 24..32 pixels per edge),
one may reach a point where "just do perspective correct rendering"
becomes the faster option (say, with a "divide by interpolated Z" every
16 pixels or so).

One may need to use finer division for primitives which cross the
frustum edges or the near plane though, as "the math can get wacky
here". Many implementations simply do polygon clipping in these cases.

Say, to CSG clip the primitives to be entirely within the frustum (which
would effectively avoid this issue). My current implementation does not
do this though.

Technically also applied to color gradient primitives as well, but
people are less likely to notice the effects of affine warping in color
gradients than they are with jittery/warping textures.

There is possible debate as to whether OpenGL is the end-all / be-all
API though, as it does have a bit of "weight" in the front-end stages.

One could argue maybe for a differently designed API, or for a
lower-level interface. Likewise, if one has a slow CPU, all these
"extra" function calls (using glEnable/glDisable to essentially twiddle
flag bits and similar) are not free.

Some state that is global in OpenGL (such as blending modes, ...) might
almost make more sense if bound to a texture or "material" list.

So, instead of, say:
glEnable / glDisable stuff;
Set blending mode, etc;
glEnableClientState(xxx); //for each sub-array
glVertexPointer(*);
...
glDrawArrays(*);
glDisableClientState(xxx); //for each sub-array

It is more like:
apiSetPointer(matid1, which, *); //for each array
apiDrawArrays(matid1, *);
Where, say, 'matid' remembers most of the rendering state, and one then
mostly just reassigns the vertex arrays and textures and similar as-needed.

So, say, one does not have to change a bunch of state when going from
drawing surface geometry to drawing lightmaps, or from the 3D part of
the scene to drawing the HUD.

Granted, would not likely save programs like Quake from burning a
significant amount of CPU time mostly doing the BSP walk and walking and
drawing lists of "surfaces" and similar (on a slow CPU, the time spent
walking the BSP tree being itself non-trivial).

And, then the PVS system is relatively conservative so there is still a
fair bit of overdraw.

A potentially more efficient approach being to use an octree and raycast
based visibility determination (needs an octree mostly because otherwise
the cost of raycasting through the BSP is higher than the cost of
overdraw due to PVS conservatism; where an octree is a little better
suited to using dynamic raycasts for visibility checks).

....

On 11/30/2022 9:52 PM, BGB wrote:
> On 11/30/2022 10:28 PM, Chris M. Thomasson wrote:
>> On 11/30/2022 6:07 PM, BGB wrote:
>>> On 11/30/2022 2:17 PM, Bart wrote:
>>>> On 30/11/2022 20:01, BGB wrote:
>>>>
>>>>> My custom CPU core would beat out an x86-64 PC pretty hard though
>>>>> at this if it had a similar clock speed and memory bandwidth (vs
>>>>> what I can get on an Artix-7 FPGA or similar...).
>>>>>
>>>>>
>>>>> Though, the PC would still win pretty big in terms of Dhrystone
>>>>> numbers and similar (though, likely depends on compiler; for
>>>>> example, there is also a pretty large gap between MSVC and GCC when
>>>>> it comes to Dhrystone numbers; and scaled relative to clock-speed,
>>>>> my numbers would be more comparable to the MSVC result).
>>>>>
>>>>> Interestingly, it seems for some tests involving neural nets, my
>>>>> ISA would pull more significantly ahead of my PC at this task.
>>>>>
>>>>>
>>>>> Though, it can be noted that the SIMD features are designed a fair
>>>>> bit differently than SSE or AVX (and in some cases need fewer
>>>>> instructions for similar tasks; and also less memory loads; as
>>>>> vector literals can be loaded inline as immediate values).
>>>>>
>>>>> General peak SIMD FPU performance is currently 200 MFLOP/s at 50MHz
>>>>> (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and
>>>>> Binary32 with 4-wide vectors).
>>>>>
>>>>> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if
>>>>> using scalar instructions).
>>>>>
>>>>>
>>>>> At 50MHz, still don't really have enough "CPU go power" for things
>>>>> like non-terrible MPEG decoding though (something like 160x100 at
>>>>> 15fps is, bleh...).
>>>>
>>>> My first experiments with video managed 128x128 x 16-level greyscale
>>>> at some 0.25fps, uncompressed; 15fps would have looked pretty good!
>>>>
>>>> However this was using a 2.5MHz Z80 and recording frame-grabbed
>>>> video onto cassette tape using software PWM.
>>>
>>> I am not quite that old...
>>>
>>>
>>> Granted, I am now pretty old, but most of my life has been in the
>>> "Desktop PCs with x86 and Windows" era (though, in my childhood, one
>>> might still encounter older PCs running MS-DOS).
>>>
>>> During elementary school, I was mostly interacting with PCs running
>>> Win3x and Win95. During the time I was in high-school, the world was
>>> starting to move on to WinXP (I had been running Win2K though, as I
>>> wasn't a big fan of Win98, ...).
>>>
>>>
>>> But, during my childhood, there was at one point a big craze over
>>> "multimedia", and the ability to put "full motion video" onto CD-ROMs.
>>>
>>> So, there were a bunch of typically terrible "FMV Games" which showed
>>> video in a small window on the screen.
>> [...]
>>
>> Phantasmagoria was pretty fun. I was always fond of Sierra games.
>>
>> https://youtu.be/oAXC-MwfpHA
>>
>
> Bonus points for Phantasmagoria:
> They are at least using most of the screen for the video...
>
> Looks like they were using 284x160, which is a fair bit better than some
> of what I had seen.
>
>
> But, I was thinking of examples more like Critical Path, where most of
> the screen was used up by "hud" (there were more like this, but I don't
> remember their names at the moment).
>
> But, yeah, same basic genre; there was a point in time when there were
> *a lot* of these sorts of games...
[...]

Damn! I need more time to give a proper response. Fwiw, remember the
laser disc games? Dragons lair comes to mind.

On 12/1/2022 12:30 AM, BGB wrote:
> On 11/30/2022 10:29 PM, Chris M. Thomasson wrote:
>> On 11/30/2022 8:28 PM, Chris M. Thomasson wrote:
>>> On 11/30/2022 6:07 PM, BGB wrote:
>>>> On 11/30/2022 2:17 PM, Bart wrote:
>>>>> On 30/11/2022 20:01, BGB wrote:
>>>>>
>>>>>> My custom CPU core would beat out an x86-64 PC pretty hard though
>>>>>> at this if it had a similar clock speed and memory bandwidth (vs
>>>>>> what I can get on an Artix-7 FPGA or similar...).
>>>>>>
>>>>>>
>>>>>> Though, the PC would still win pretty big in terms of Dhrystone
>>>>>> numbers and similar (though, likely depends on compiler; for
>>>>>> example, there is also a pretty large gap between MSVC and GCC
>>>>>> when it comes to Dhrystone numbers; and scaled relative to
>>>>>> clock-speed, my numbers would be more comparable to the MSVC result).
>>>>>>
>>>>>> Interestingly, it seems for some tests involving neural nets, my
>>>>>> ISA would pull more significantly ahead of my PC at this task.
>>>>>>
>>>>>>
>>>>>> Though, it can be noted that the SIMD features are designed a fair
>>>>>> bit differently than SSE or AVX (and in some cases need fewer
>>>>>> instructions for similar tasks; and also less memory loads; as
>>>>>> vector literals can be loaded inline as immediate values).
>>>>>>
>>>>>> General peak SIMD FPU performance is currently 200 MFLOP/s at
>>>>>> 50MHz (would be 14.8 GFLOP/s at 3.7GHz). At least for Binary16 and
>>>>>> Binary32 with 4-wide vectors).
>>>>>>
>>>>>> For Binary64 SIMD, would only be 12.4 MFLOP/s at 50MHz (or 8.3 if
>>>>>> using scalar instructions).
>>>>>>
>>>>>>
>>>>>> At 50MHz, still don't really have enough "CPU go power" for things
>>>>>> like non-terrible MPEG decoding though (something like 160x100 at
>>>>>> 15fps is, bleh...).
>>>>>
>>>>> My first experiments with video managed 128x128 x 16-level
>>>>> greyscale at some 0.25fps, uncompressed; 15fps would have looked
>>>>> pretty good!
>>>>>
>>>>> However this was using a 2.5MHz Z80 and recording frame-grabbed
>>>>> video onto cassette tape using software PWM.
>>>>
>>>> I am not quite that old...
>>>>
>>>>
>>>> Granted, I am now pretty old, but most of my life has been in the
>>>> "Desktop PCs with x86 and Windows" era (though, in my childhood, one
>>>> might still encounter older PCs running MS-DOS).
>>>>
>>>> During elementary school, I was mostly interacting with PCs running
>>>> Win3x and Win95. During the time I was in high-school, the world was
>>>> starting to move on to WinXP (I had been running Win2K though, as I
>>>> wasn't a big fan of Win98, ...).
>>>>
>>>>
>>>> But, during my childhood, there was at one point a big craze over
>>>> "multimedia", and the ability to put "full motion video" onto CD-ROMs.
>>>>
>>>> So, there were a bunch of typically terrible "FMV Games" which
>>>> showed video in a small window on the screen.
>>> [...]
>>>
>>> Phantasmagoria was pretty fun. I was always fond of Sierra games.
>>>
>>> https://youtu.be/oAXC-MwfpHA
>>>
>>
>> Actually, I wonder if they still have the high res footage.
>
> Dunno there...
>
>
> I was looking more at some more screenshots, and an realizing that it is
> proving annoyingly difficult to try to determine the original video
> resolution from the screenshots (pretty much all of them seem to have
> been resized in inconsistent ways).
>
>
> Appears like overall resolution was "close to but not quite 640x480"; it
> also appears video frame area may have been 512x256.
>
>
> Looking at some of the images, pretty sure the video codec is neither
> CRAM nor RPZA:
> * Images tend to have more than 2 or 4 unique colors per 4x4 block (1);
> * What compression artifacts it does have, make it look more like it is
> repeatedly drawing new spans of changed pixels on top of the old pixels.
>
> 1: While both formats did have a block that could express 16 unique
> pixels, the normal blocks would only do 2 colors (in CRAM), or 4
> interpolated colors (RPZA). The full-detail blocks were used rarely due
> to cost.
>
> The video in this case does not seem to obey these rules, but does have
> more obvious pixel-span artifacts.
>
>
> Framerate appears to be somewhere around 8 fps (so, errm, the "full
> motion" part is a bit more questionable).
>
>
> So, it looks almost more like if one were doing video deltas via a
> modified LZ77 decoder or similar.
>
> So, a guess of how the codec may have worked by looking at the output:
> There is a 512x256 frame of pixels;
> Each pixel is 256 colors, with a transparent color (for the background).
>
> Compression scheme was either:
>   Skip pixels from previous frame;
>   Draw a run of new pixels on top of the old pixels;
>   Copy pixels from somewhere else within the partially redrawn frame.
>
> Where the encoder decides what to do based on some metric of the error
> within a given span of pixels. Though in this case, the error tolerance
> seems to have been fairly low.
>
>
> Not sure what sort of bitrate one could get with this scheme.
>
> Likely worst case: ~ 8 mbps (~ 1 MB/s, ... at 8Hz ...), ~ 8.0 bpp.
> Assuming roughly 1/4 of the frame is updated each frame, ~ 256 K/s.
>
>
> If I were to design a format like this, say:
>                     dddddddd-dlllrrr0 (L=3..10, D=+/-255, R=0..7)
>            dddddddd-dddddlll-lllrrr01 (L=4..67, D=+/-4K, R=0..7)
>   dddddddd-dddddddd-dlllllll-llrrr011 (L=4..515, D=+/-64K, R=0..7)
>                              rrrr0111 (Raw Bytes, R=(r+1)*8, 8..128)
>                     rrrrrrrr-rrp01111 (Big Raw | Skip)
>                              rr011111 (Raw Bytes, R=1..3, 0=EOB)
>
> So, basically a modified RP2 but with distances being signed.
> If (D==0), it is effectively a skip span.
>
>
> Seems like a possibly interesting approach, though most likely the
> bitrate would *suck* (... probably why they were doing the video at
> roughly 8 fps? ...).
>
> If so, if used for full-scene video, one would likely be hard pressed to
> get much under 1.0 bpp without some pretty severe compression artifacts.
>
>

Humm... Iirc, there is a video where Ken:

https://en.wikipedia.org/wiki/Ken_Williams_(game_developer)

Is talking about some of the details of the rigs they had to buy to make
the game. Iirc, they might of been over 9000$ a piece. Damn, I cannot
remember right of the bat right now. Perhaps some of the expensive
Silicon Graphics workstations?

On 12/1/2022 7:46 AM, Bart wrote:
> On 01/12/2022 15:29, fir wrote:
>
>> its not about rasterization i rather need
>> a function that returns color for x,y
>> and as an input takes 3 vertices of a triangle
>> with 3 colors
>>
>> unsigned GiveInterpolatedColor(float x, float y, float x1, float y1,
>> unsigned c1, float x2, float y2, unsigned c2, float x3, float y3,
>> unsigned c3)
>> {
>>    //....
>> }
>
>
> So given a triangle with corners A, B, C, of colours C1, C2, C3
> respectfully, you want to interpolate the colour at any point P within
> the triangle?

[...]

Just like an OpenGL shader wrt giving a different color at each vertex
using a color that is passed into the GLSL shader via uniform.

It interpolates the color.

On 12/1/2022 1:11 PM, Chris M. Thomasson wrote:
> On 12/1/2022 7:46 AM, Bart wrote:
>> On 01/12/2022 15:29, fir wrote:
>>
>>> its not about rasterization i rather need
>>> a function that returns color for x,y
>>> and as an input takes 3 vertices of a triangle
>>> with 3 colors
>>>
>>> unsigned GiveInterpolatedColor(float x, float y, float x1, float y1,
>>> unsigned c1, float x2, float y2, unsigned c2, float x3, float y3,
>>> unsigned c3)
>>> {
>>>    //....
>>> }
>>
>>
>> So given a triangle with corners A, B, C, of colours C1, C2, C3
>> respectfully, you want to interpolate the colour at any point P within
>> the triangle?
>
> [...]
>
> Just like an OpenGL shader wrt giving a different color at each vertex
> using a color that is passed into the GLSL shader via uniform.
>
> It interpolates the color.
>

The vertex buffer can contain colors.

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>On 12/1/2022 12:30 AM, BGB wrote:
>> On 11/30/2022 10:29 PM, Chris M. Thomasson wrote:
>>> On 11/30/2022 8:28 PM, Chris M. Thomasson wrote:
>>>> On 11/30/2022 6:07 PM, BGB wrote:
>>>>> On 11/30/2022 2:17 PM, Bart wrote:
>>>>>> On 30/11/2022 20:01, BGB wrote:

>> Seems like a possibly interesting approach, though most likely the
>> bitrate would *suck* (... probably why they were doing the video at
>> roughly 8 fps? ...).
>>
>> If so, if used for full-scene video, one would likely be hard pressed to
>> get much under 1.0 bpp without some pretty severe compression artifacts.
>>
>>
>
>Humm... Iirc, there is a video where Ken:
>
>https://en.wikipedia.org/wiki/Ken_Williams_(game_developer)
>
>Is talking about some of the details of the rigs they had to buy to make
>the game. Iirc, they might of been over 9000$ a piece. Damn, I cannot
>remember right of the bat right now. Perhaps some of the expensive
>Silicon Graphics workstations?

At that price, probably not an Octane, but more likely and Indigo2
or possibly an Indy.

I had a 2P Octane R10K (with a 27" monitor that weighed in at 80#)
as my desktop when at SGI. Very nice box.