16 color 4bpp displays?

[Karl_Garrison]

What would need to be done to have SDL support 16 color 4bpp visuals? I
would like to get SDL working on the Agenda VR3 Linux-based pda (which runs
XFree86 4.0), but since the server runs in 16-color mode, SDL currently
will not work.

Is it possible for someone familiar with the internals of SDL to describe
what would need to be done so that I could do this myself? I am familar
with C and working with SDL as a library, but I have never delved into the
source of the library itself.

Thanks,

-Karl

[Bill_Kendrick]

(Yay! )

-bill!
(Agenda owner)

PS - I have a whole mailbox full of messages on both SDL and Agenda lists
regarding this, although you can find them easily on the web archivesOn Mon, Oct 15, 2001 at 11:09:01AM -0500, Karl Garrison wrote:

What would need to be done to have SDL support 16 color 4bpp visuals? I
would like to get SDL working on the Agenda VR3 Linux-based pda (which runs
XFree86 4.0), but since the server runs in 16-color mode, SDL currently
will not work.

[Mattias_Engdegard]

Karl Garrison wrote:

What would need to be done to have SDL support 16 color 4bpp visuals? I
would like to get SDL working on the Agenda VR3 Linux-based pda (which runs
XFree86 4.0), but since the server runs in 16-color mode, SDL currently
will not work.

SDL has extremely spotty (or nonexisting) support for <8bpp surfaces,
so so some infrastructure work is needed. I see three possible
approaches, in increasing difficulty order:

A. Implement the screen surface as an 8bpp buffer, and translate to 4bpp
at update time. This requires no changes to SDL (only to the X11 driver),
but makes updates slower, and will not support DGA (if that is at all
possible on the Agenda)
B. Add general support for sub-8bpp surfaces but without any blit support.
The game is responsible for knowing the pixel format, so code won’t be
portable.
C. Add complete support for sub-8bpp surfaces. Then we need to add more
format parameters to the pixel format struct, and write a bunch of
blitters to deal with it

The new format parameters we need is bitmap unit (the size in bytes of a
chunk into which bits are packed) and bit order (in what order the
pixels are stuffed into a bitmap unit). If you can convince the rest of us
that only a very few combinations of those parameters will ever be useful,
this could simplify the code. What format does the Agenda (and other
<8bpp devices) use?

[David_Olofson]

Dunno if it’s of any interest, but the old Amiga’s (OCS, ECS and AGA)
normally used individual bit-planes; up to 5 on OCS, 6 on ECS
(“half-brite” palette - there are still only 32 palette entries), and AGA
can use 8. (The CD32 also had a “chuck pixels” mode, similar to VGA mode
13h, but unfortunately, that was only the CD32; not any other AGA based
machines, AFAIK.) The hardware has one pointer for each bitplane, so
there isn’t even a fixed relation between addresses. Bitplanes are (as
all DMA on those machines) 16 bit word based, and using little endian
format. I think the highest bit is first (ie 15->0 / left->right) - i
can look it up in the old books if anyone cares.

The Atari ST and STe (for which I’ve hardly written a single instruction
of asm, although I did have an STe as well) is using a similar system,
but only one pointer - planes are interleaved on 16 bit word level, same
bit order as the Amiga. (Same CPU, so that makes sense - both machines
are interely designed around the CPU endian.) One bitplane in 640x400
mode (B/W or multisync monitors only), two planes in 640x200 and four
planes in 320x200. The STe had “real” h/w scrolling support and full
4:4:4 palette entries (although encoded in a very weird way, to be ST
compalible, but that’s about it, as far as video is concerned.)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Tuesday 16 October 2001 11:38, Mattias Engdeg?rd wrote:

Karl Garrison wrote:

What would need to be done to have SDL support 16 color 4bpp visuals?
I would like to get SDL working on the Agenda VR3 Linux-based pda
(which runs XFree86 4.0), but since the server runs in 16-color mode,
SDL currently will not work.

SDL has extremely spotty (or nonexisting) support for <8bpp surfaces,
so so some infrastructure work is needed. I see three possible
approaches, in increasing difficulty order:

A. Implement the screen surface as an 8bpp buffer, and translate to
4bpp at update time. This requires no changes to SDL (only to the X11
driver), but makes updates slower, and will not support DGA (if that is
at all possible on the Agenda)
B. Add general support for sub-8bpp surfaces but without any blit
support. The game is responsible for knowing the pixel format, so code
won’t be portable.
C. Add complete support for sub-8bpp surfaces. Then we need to add more
format parameters to the pixel format struct, and write a bunch of
blitters to deal with it

The new format parameters we need is bitmap unit (the size in bytes of
a chunk into which bits are packed) and bit order (in what order the
pixels are stuffed into a bitmap unit). If you can convince the rest of
us that only a very few combinations of those parameters will ever be
useful, this could simplify the code. What format does the Agenda (and
other <8bpp devices) use?

[Teunis_Peters]

And just to add to info about 4bpp displays:

the S3 chipsets (and probably other chipsets) can go into a non-bitplanar
4bpp mode that has [high nibble]:[low nibble] as pixels next to eachother.
Suspect ordering is [high nibble=1st pixel] but can’t remember haven’t
worked on the drivers in a couple of years now… (former S3 GGI driver
maintainer

Most older IBM PC-type videocards tend to be strictly bitplanar though…
(although 8514 could switch to non-bitplanar and since this is what S3 is
based on… which would mean of course that ATI Mach series and beyond
have this

Anyways, SVGAlib has support for <=4bpp IIRC.

btw - monochrome (1bpp) could be genuinely valuable. Only formats I know
are highest bit == 1st pixel and lowest bit==1st pixel. Note I’ve never
seen the latter used -anywhere-.
OpenGL equiv == glBitmap; Very useful with fonts…

G’day, eh?
- Teunis

[David_Olofson]

And just to add to info about 4bpp displays:

the S3 chipsets (and probably other chipsets) can go into a
non-bitplanar 4bpp mode that has [high nibble]:[low nibble] as pixels
next to eachother. Suspect ordering is [high nibble=1st pixel] but
can’t remember haven’t worked on the drivers in a couple of years
now… (former S3 GGI driver maintainer

Most older IBM PC-type videocards tend to be strictly bitplanar
though… (although 8514 could switch to non-bitplanar and since this
is what S3 is based on… which would mean of course that ATI Mach
series and beyond have this

Anyways, SVGAlib has support for <=4bpp IIRC.

btw - monochrome (1bpp) could be genuinely valuable. Only formats I
know are highest bit == 1st pixel and lowest bit==1st pixel. Note I’ve
never seen the latter used -anywhere-.

Nor have I. It seems that the high bit is always first - which actually
may appear a bit weird, considering that we do have two popular byte
endian formats…

OpenGL equiv == glBitmap; Very useful with fonts…

Oh, there are weird 1bpp bitmap formats as well. Remember the C64
"highres" mode?

(For those who never hacked on the C64: It’s similar to character modes;
the screen is arranged in 8x8 pixel character squares, each one
constructed from 8 bytes. The high bit of the first byte is the top-left
pixel of a “tile”, the high bit of the next byte in memory is at (0,1) in
the tile etc. In addition, there is a separate color memory area with the
4 low bits of each byte setting the foreground color [from a fixed
palette of 16] for each character square on the screen. Background color
is for the whole screen.)

And then there’s the 2 bpp multicolor lowres mode, which doubles pixel
width and groups pixels in 2, to index in [screen background, character
color 1, character color 2, character color 3]…

I wouldn’t be surprised if there are more modern hardware with
this kind of strange formats - perhaps even on video cards currently in
production.

(Note that I’m not considering text mode + character generator
reprogramming at all here - those are hardware based “tile engines”,
rather than true pixel graphic displays.)

Anyway, perhaps more interesting to ask is:

* Which formats are supported by drivers currently in use?

* Which formats are used by currently used hardware? (For
  environments where drivers are very low level, or non-
  existent.)

* Which formats are likely to show up sooner or later,
  considering the evolution of the handheld market?
  (In fact, is 4 bpp here to stay, or is it just temporary,
  until there's no justification for by going lower than
  8 bpp?)

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Wednesday 17 October 2001 01:15, winterlion wrote:

[John_R_Hall]

Incidentally, I’ve done the bulk of a Palm OS SDL port, but I threw up my
hands in a fit of despair when I ran into the < 8bpp issues. Recent versions
of Palm OS do support an 8bpp screen mode, but in most cases this is emulated
on monochrome or half-assed color hardware, and to get any real performance
you have to code to the metal.

I’ve given up for now; if you want my partially ported tree, let me know.
When SDL 2.0 comes around, though, we should try not to make assumptions
about having at least one byte per pixel (this is all over the place in the
current video code). It would be nice to get SDL running on various embedded
and PDA platforms.

-JohnOn Tuesday 16 October 2001 02:40 am, you wrote:

On Mon, Oct 15, 2001 at 11:09:01AM -0500, Karl Garrison wrote:

What would need to be done to have SDL support 16 color 4bpp visuals? I
would like to get SDL working on the Agenda VR3 Linux-based pda (which
runs XFree86 4.0), but since the server runs in 16-color mode, SDL
currently will not work.

(Yay! )

-bill!
(Agenda owner)

PS - I have a whole mailbox full of messages on both SDL and Agenda lists
regarding this, although you can find them easily on the web archives

–
John R. Hall
Author, Programming Linux Games
CS Student/Geek, Georgia Tech

[Mattias_Engdegard]

winterlion wrote:

the S3 chipsets (and probably other chipsets) can go into a non-bitplanar
4bpp mode that has [high nibble]:[low nibble] as pixels next to eachother.
[…]
Most older IBM PC-type videocards tend to be strictly bitplanar though…

While I could accept SDL support for a nybbled (non-planar) 4bpp mode,
at least if there were a limited number of variants that had to be supported,
planar modes are probably right out

btw - monochrome (1bpp) could be genuinely valuable. Only formats I know
are highest bit == 1st pixel and lowest bit==1st pixel. Note I’ve never
seen the latter used -anywhere-.

1bpp bitmaps are slightly more useful since they are actually supported by
some reasonably modern hardware as blit masks. But there’s more than
one format; the bits can be in both MSBFirst and LSBFirst order, and be
stuffed in bytes, 16-bit or 32-bit words. I’ve seen at least 3-4 different
variants myself

[Gerry_Jo_Jellestad]

OpenGL equiv == glBitmap; Very useful with fonts…

Oh, there are weird 1bpp bitmap formats as well. Remember the C64
"highres" mode?

Of course =)

(snip)

And then there’s the 2 bpp multicolor lowres mode, which doubles
pixel width and groups pixels in 2, to index in [screen background,
character color 1, character color 2, character color 3]…

Don’t forget the multicolor koala mode: 4x8 pixels per tile (double
width pixels), where the bitmap has its own area in memory, the
actual text screen is ordered into a colormap of two nibbles per
tile, in addition to the standard VIC color nibbles.

Also there’s hacked modes, like the FLI (split the koala color-screen
into 8 screens, each keeping color for two of the colors in the
current 1x8 tile), AFLI, IFLI, and so on, with increasing weirdness,
not to mention a mode i came up with recently, called LFLI, which in
addition to koala and FLI uses pixels and colors in four layers and
several nasty hardware tricks to create hires close-to-truecolor
images on the C64 (of course, that is supposed to be impossible, but
the C64 hardware is so full of bugs that it’s a joy to work with =D).

C64 Rocks =)

Eh, this is getting off-topic, but i couldn’t resist =)

• Which formats are likely to show up sooner or later,
  considering the evolution of the handheld market?
  (In fact, is 4 bpp here to stay, or is it just temporary,
  until there’s no justification for by going lower than
  8 bpp?)

Why not ? You already have that bit-ordering problem with the
16bpp-mode, so i don’t see why the info keeping that in check
couldn’t be used for 4bpp or even 2bpp… After all 4bpp is really
just 16bit RGBA with the BA part stripped off…–
Trick

---

Linux User #229006 * http://counter.li.org

[David_Olofson]

OpenGL equiv == glBitmap; Very useful with fonts…

Oh, there are weird 1bpp bitmap formats as well. Remember the C64
"highres" mode?

Of course =)

(snip)

And then there’s the 2 bpp multicolor lowres mode, which doubles
pixel width and groups pixels in 2, to index in [screen background,
character color 1, character color 2, character color 3]…

Don’t forget the multicolor koala mode: 4x8 pixels per tile (double
width pixels), where the bitmap has its own area in memory, the
actual text screen is ordered into a colormap of two nibbles per
tile, in addition to the standard VIC color nibbles.

Well, that’s actually the “multicolor lowers” mode I was thinking of.
(There’s also a multicolor text mode, but that’s not a real graphics mode
IMHO - although many games indeed use it for fast fullscreen scrolling of
tiled maps.

Also there’s hacked modes, like the FLI (split the koala color-screen
into 8 screens, each keeping color for two of the colors in the
current 1x8 tile), AFLI, IFLI, and so on, with increasing weirdness,
not to mention a mode i came up with recently, called LFLI, which in
addition to koala and FLI uses pixels and colors in four layers and
several nasty hardware tricks to create hires close-to-truecolor
images on the C64

How do you do that? I mean, the palette is (officialy) only 16 colors?

(of course, that is supposed to be impossible, but
the C64 hardware is so full of bugs that it’s a joy to work with =D).

C64 Rocks =)

Yeah, tons of bonus features. The Amiga had some too (like the ability to
"manually" push data into DMA channel buffer registers), but nothing like
the C64.

Eh, this is getting off-topic, but i couldn’t resist =)

Yeah, I know. The good old days, with fun hardware and concistent CPU
speed.

* Which formats are likely to show up sooner or later,
considering the evolution of the handheld market?
(In fact, is 4 bpp here to stay, or is it just temporary,
until there's no justification for by going lower than
8 bpp?)

Why not ? You already have that bit-ordering problem with the
16bpp-mode, so i don’t see why the info keeping that in check
couldn’t be used for 4bpp or even 2bpp… After all 4bpp is really
just 16bit RGBA with the BA part stripped off…

Yeah, but we’re talking about N pixels per byte, rather than N bytes per
pixel… How do you indicate that the bitmasks represent full pixels in
indexed color mode, as opposed to componets of a single pixel? If you
just use the mask with 8 bpp modes, RGB aware code would treat it as
exactly what you mentioned; an “RG” pixel format.

Also, the BytesPerPixel, w, pitch and other things break if you go the
"treat multiple pixels as one" way. (Although that could actually “kind
of” work…) Surface width really is meant to be in pixels, so there
would have to be a fractional BytesPerPixel, or a PixelsPerByte field or
something.

Sure, it can be dealt with, but I can’t see a way to do it without
breaking all existing code that deals with the PixelFormat struct. At the
very least, existing code will crash if it sees surface in one of the new
formats.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 18 October 2001 15:02, Trick wrote:

[Bill_Kendrick]

> > not to mention a mode i came up with recently, called LFLI, which in > > addition to koala and FLI uses pixels and colors in four layers and > > several nasty hardware tricks to create hires close-to-truecolor > > images on the C64 > > How do you do that? I mean, the palette is (officialy) only 16 colors? :-)

“ColorView” mode on the Atari 8-bit is a software-driven graphics mode
which can display 4096 colors (in a hideously low resolution of 80x192),
64 colors (160x192) or 8 colors (320x192).

All it does is flip between three ‘normal’ modes (80x192x16 grey,
160x192x4 paletted, with grey colors, or 320x192x2, with black/white).

Flipping sounds atrocious, thanks to Display List Interrupts (similar to
Copper on Amiga), the screen doesn’t flip between red, green, and blue
images all at once. Thanks to DLIs, it can change the palette (as
well as the ‘where to get the bitmap data from in RAM’ pointer) on each
and every line.

Frame 1: Frame 2: Frame 3: Frame 4: …
Red Green Blue Red
Green Blue Red Green
Blue Red Green Blue
Red Green Blue Red
… … … …

So, while not a perfectly static image, thanks to persistence of vision
in the human eye (and the residual glow of TV/monitor phosphors), the
image looks pretty good. The only noticable flickering is usually a kind
of ‘upwards shimmer’ of the pure colors (pure red, green, or blue…
where the pixel is black 2/3rd of the time)

The idea for this came based on a mode which combined two built-in
displays, 80x192x16 grey, and 80x192x16 hue. (Neither palettized.)
When you interlaced or flickered between them, you could simulate
256 colors. (A slightly desaturated display of the actual 256 colors
which were possible on the Atari, but not anywhere… this mode was
aptly called “APAC: Any Point, Any Color” )

Newer modes some folks have come up with produce more greys, or
’high resolution’ greyscale (eg, perceived 320x192x16 or 32 shades),
or do other tricks to add more coloring to hi- and med-rez (HIP and RIP
modes)

Again, all software based, and works on any Atari with a “GTIA” graphics
chip (all of them except Atari 400s and the earlier Atari 800s)

> Yeah, I know. The good old days, with fun hardware and concistent CPU > speed. :-)

As off-topic as this is getting, this kind of stuff might actually
be useful to people trying to do software-driven graphics tricks to
simulate higher resolution or more colors.

And since we’ve been talking about low-palette SDL stuff (eg, for PDAs
and other small devices), I’m thinking this isn’t QUITE as off-topic
as it seems… all of this C=64, Amiga and Atari 8-bit reminiscing.

> Sure, it can be dealt with, but I can't see a way to do it without > breaking all existing code that deals with the PixelFormat struct. At the > very least, existing code will crash if it sees surface in one of the new > formats.

Maybe a kludge would be to store the bitmap as 8bpp internally, but
then convert on display. Or did someone already suggest that?

Maybe we need a new API! D’oh!

-bill!On Thu, Oct 18, 2001 at 06:37:09PM +0200, David Olofson wrote:

[David_Olofson]

not to mention a mode i came up with recently, called LFLI, which
in addition to koala and FLI uses pixels and colors in four layers
and several nasty hardware tricks to create hires
close-to-truecolor images on the C64

How do you do that? I mean, the palette is (officialy) only 16
colors?

[…software driven Atari 8 bit modes…]

Ok, I’ve seen various variants on that theme… On the Amiga, we called
in “Wide Band Color” (usually to get smoother gradients on “copper
bars”), and there were some graphics programs on the Atari ST that used
similar methods to get well beyond the ST’s 512 colors.

Yeah, I know. The good old days, with fun hardware and concistent CPU
speed.

As off-topic as this is getting, this kind of stuff might actually
be useful to people trying to do software-driven graphics tricks to
simulate higher resolution or more colors.

And since we’ve been talking about low-palette SDL stuff (eg, for PDAs
and other small devices), I’m thinking this isn’t QUITE as off-topic
as it seems… all of this C=64, Amiga and Atari 8-bit reminiscing.

Yeah… The only problem is that most of these tricks require at least
reliable retrace sync and preferably also hardware pageflipping to work.
Neither is at all possible on most of the SDL targets. (That’s a good
reason for missing the old days… heh)

Sure, it can be dealt with, but I can’t see a way to do it without
breaking all existing code that deals with the PixelFormat struct. At
the very least, existing code will crash if it sees surface in one of
the new formats.

Maybe a kludge would be to store the bitmap as 8bpp internally, but
then convert on display. Or did someone already suggest that?

Yes, that was suggested as the easiest way of supporting such modes.
However, it takes quite some CPU power to do such translations
(especially for bitplane modes), and you generally don’t exactly have an
excess of that on handhelds and embedded devices.

Maybe we need a new API! D’oh!

Yeah, probably.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 18 October 2001 19:36, William Kendrick wrote:

On Thu, Oct 18, 2001 at 06:37:09PM +0200, David Olofson wrote:

[Gerry_Jo_Jellestad]

(ON-topic rambling at the end of this mail =)

Also there’s hacked modes, like the FLI (split the koala
color-screen into 8 screens, each keeping color for two of the
colors in the current 1x8 tile), AFLI, IFLI, and so on, with
increasing weirdness, not to mention a mode i came up with
recently, called LFLI, which in addition to koala and FLI uses
pixels and colors in four layers and several nasty hardware
tricks to create hires close-to-truecolor images on the C64

How do you do that? I mean, the palette is (officialy) only 16
colors?

Well, it’s not really using more than those 16 colors. It’s
interlacing them (C64’s got quad-buffering in hardware =) . If you
choose your colors good, you’ll not see much (if any) flickering on
the tv. It also takes advantage of the low resolution of TVs (hires
tv ? nah) so that two pixels next to each other on the same
rasterline seems to “melt” into each other. On a TV, this actually
looks pretty nice =)

Of course this trick doesn’t apply on higher resolution tvs and
monitors, but the interlacing still works if the refresh is set right.

Anyway, once we know this, the only trick is to get this in hires.
So, since we’re interlacing already, we can hardware scroll the
second buffer a pixel to the right, and voila, we’ve got hires =)
That’s what most interlaced modes does. LFLI goes a lot farther than
this and put lots of sprites all over (and under) the interlaced
bitmap (much more than the allowed 8 sprites of course =) , with some
additional trickery to make those sprites texture-mapped (!). The
result is a true hires image with high color density, which looks
rather nice =)

Calling it near-truecolor might be stretching it a bit far, but hey,
mp3 got away with “near-cd-quality at 128k”, so why not

(of course, that is supposed to be impossible, but
the C64 hardware is so full of bugs that it’s a joy to work with
=D).

C64 Rocks =)

Yeah, tons of bonus features. The Amiga had some too (like the
ability to “manually” push data into DMA channel buffer registers),
but nothing like the C64.

Right! You can do anything on that machine!

Now to port SDL to it…

Eh, this is getting off-topic, but i couldn’t resist =)

Yeah, I know. The good old days, with fun hardware and concistent
CPU speed.

Hey, you speak like it’s dead. It’s not =)

It’s fun, too =)

* Which formats are likely to show up sooner or later,
considering the evolution of the handheld market?
(In fact, is 4 bpp here to stay, or is it just temporary,
until there's no justification for by going lower than
8 bpp?)

Why not ? You already have that bit-ordering problem with the
16bpp-mode, so i don’t see why the info keeping that in check
couldn’t be used for 4bpp or even 2bpp… After all 4bpp is really
just 16bit RGBA with the BA part stripped off…

Yeah, but we’re talking about N pixels per byte, rather than N
bytes per pixel… How do you indicate that the bitmasks represent
full pixels in indexed color mode, as opposed to componets of a
single pixel? If you just use the mask with 8 bpp modes, RGB aware
code would treat it as exactly what you mentioned; an “RG” pixel
format.

Right … Hm (see below)

Also, the BytesPerPixel, w, pitch and other things break if you go
the “treat multiple pixels as one” way. (Although that could
actually “kind of” work…) Surface width really is meant to be in
pixels, so there would have to be a fractional BytesPerPixel, or a
PixelsPerByte field or something.

My idea was that we could set BytesPerPixel to 0, and BitsPerPixel to
the bpp as now… (you could treat BytesPerPixel as a fractional value
that way btw =) Then set Rmask to the first pixel, Gmask to the
second pixel, and so on, up to 4 pixels possible in a byte (RGBA).
Then *shift and *loss would work as expected, even.

Sure, it can be dealt with, but I can’t see a way to do it without
breaking all existing code that deals with the PixelFormat struct.
At the very least, existing code will crash if it sees surface in
one of the new formats.

This wouldn’t break compability too much, since apps using the
BytesPerPixel field for something useful should (probably ?) check it
for a supported value in any case. I might be horribly wrong here of
course, i’m just throwing ideas into the air =)–
Trick

---

Linux User #229006 * http://counter.li.org

[David_Olofson]

[…C64…]

Well, I know some people are still having fun with this Greatest Machine
In History; the C64… What kind of development tools are you using these
days?

Back when I was using the Amiga, I started hacking an Amiga->C64 cross
development system, but didn’t take it very far for various reasons. I
planned on first implementing an assembler and a "remote control robot"
on the C64, for data transfers and stuff (I actually had the latter
working to some extent), and then adding an IDE with simple project
management, various tools for grahpics management and so on.

Is there anything like that in a usable state now, or do the native
development tools still rule the world?

[…]

Sure, it can be dealt with, but I can’t see a way to do it without
breaking all existing code that deals with the PixelFormat struct.
At the very least, existing code will crash if it sees surface in
one of the new formats.

This wouldn’t break compability too much, since apps using the
BytesPerPixel field for something useful should (probably ?) check it
for a supported value in any case. I might be horribly wrong here of
course, i’m just throwing ideas into the air =)

Most code seems to do a switch() on the BytesPerPixel value, which indeed
ends up doing nothing for a value of 0 - but what happens after that,
when some variables are left uninitialized…?

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Thursday 18 October 2001 21:13, Trick wrote: