#18 Bit Color
32 messages in this thread
Andrew,
On the minus side, not only memory (really, task) protection, but VM is
missing also. These are critical features, CBM's opinion notwithstanding.
On the plus side, current Amigas ship with 18 bit color, standard. More
than 16. Without adding anything.
I agree that word & other similar apps are required if the user base is to
expand beyond video & the techno phreaks.
–Ben
…via AutoPilot
The Amiga's 18 bit color may be useful for your program, but it's useless for
our type of application. The Amiga's limited to 256 colors for our type of
application.
Michael
That's debatable (if your application is PageStream). 18-bit color is really
fine (but a bit slow in the display) if you simply do what Brilliance does…
maintain 24-bit (or 32-bit) data fidelity and use the 18-bit as a quicker
display. Other systems do it all the time…8-bit displays are the norm with
the exception of photo-retouching and a few like apps…as long as that 24-bit
data is kept there.
-Chas
If you want to use windows, requesters and gadgets, the Amiga is limited to 8
bit color. There is no way around this. You can only use >256 colors for paint
type applications.
Michael @ Soft-Logik Publishing Corp.
Mike, that's incorrect, as I described, you can easily use HAM8 in a
windows, requesters, menus and etc environment. Not using it is a choice –
NOT a requirement of the Amiga architecture.
–Ben
…via AutoPilot
Ben, forgive me because I'm not a programmer and do not understand the details
of the Amiga's color system.
As I understand it, the Amiga's interface can work in a max of 256 colors. HAM
is not a suitable mode for its windowing system.
If the Amiga's 18 bit color mode was suitable for applications, why isn't the
workbench available in 18 bit mode? Why aren't there dozens of applications
available that open multiple windows in 18 bit color mode?
Michael @ Soft-Logik Publishing Corp.
Aw heck, I forgive you. Now if only my mom would forgive me FOR being a
programmer, I'd be allright… :^)
The Amiga's software can work in a max of 8 bits. Not 256 colors. 8 bits.
That's a big distinction, because in fact, HAM8 is 8 bits, _the same as
256 register colors_.
Why isn't the workbench available in 18 bit mode? Good question. It should
be. Why aren't there dozens of applications available that open multiple
windows in 18 bit mode? Well, there _are_ a few – but I think you can
generalize that to why aren't there dozens of applciations, period, that
use sophisticated windowing. Very few do, actually. The Amiga's OS is
*very* strong deep down "in there"; you can ask other similar questions
such as why not use dual playfield and get the same answer – it's not
trivial.
But lets back up a step. There have been many applciations that used HAM6
(the original Amiga HAM mode, not ours), a 6 bit mode (which would be 64
colors if it was palette mapped, but instead is 4096 when HAMmed. Some
worked better than others, and some where, um, "crude". But it's been done
and the problems are _less_ with HAM8 than HAM6. How so? First, HAM6 was
lores only, pre-AGA. That's pretty crippling for anything but imaging.
HAM8 is not only hires, but _also_ available in _superhighres_ which is
pretty fabulous for submerging the HAM errors that are inhereent in the
mode. Second, there were only 16 color registers, all of which were really
needed to come up with a pretty good HAM6 image, which left -0- for
drawing window borders and such tasks – HAM8 has 64, which is enough to
provide a few (4 is good) for windows and borders and other control, and
still leave 60 left over for making the HAM8 look _very_ good.
Bottom line: HAM6 or HAM8 both work much better under the Amiga's
windowing system than you'd think. Certainly well enough to be used and
used very well. Easy? No… but not a programmer-killer, either. In the
Amiga market, you have to think carefully before doing something the hard
way, if there's an easy way. 256 register colors _can_ look very, very
good – ten minutes with Imagemaster on an AGA machine will convince anyone
of that. And it's relatively easy to handle. So probably 256 colors is a
very sane choice for SoftLogic's new "thing", whatever that may be. I just
want to reiterate that I'm only saying that it's doable.
–Ben
…via AutoPilot
What application is that, Mike? You can't mean PageStream…? In fact, I
can't think of anything where you're inherently limited from using the 18
bit mode. Enlighten me… :^)
–Ben
…via AutoPilot
If you want to use windows, requesters and gadgets, the Amiga is limited to 8
bit color. How would you propose that we open multiple windows, palettes and
requesters in >256 colors?
Your type of application is different. You can use >256 colors. We can't.
Michael @ Soft-Logik Publishing Corp.
Well, since you asked:
The way to use HAM8 with windows, requesters and gadgets is *very*
straightforward.
HAM8, like HAM, has color registers. Unlike HAM, it has 64 of them. You
can very easily design your application such that a certain number (I'd
suggest 4 at a minimum, 8 at the outside) are available as preset colors.
These would never be changed. All window & requester elements (aside from
variable images) would be rendered using these unchanged values. Thus,
palette recomputes never affect them. When the display background is color
0, and all UI elements are within windows which have their borders drawn
with registers, the only questionable area occurs when one window overlaps
another horizontally as a trailing edge. Since the window layering is a
rectangular problem, which is trivial to solve, quick fixup during
rearrangement is trivial to accomplish. If you don't allow overlay, which
is another option, there is *no* problem.
I don't accept that "you can't" by fiat. You can't if you design it so it
can't; you can if you design it to work that way. You can design it to
work both ways, should you care to spend the time to do so. Mind you I am
not suggesting that you do so (in fact, given the state of the market, if
I knew your particulars I might say forget it instead) but I am simply
pointing out that it is perfectly practical to use HAM8 in a windowed
environment. We thought all this out and tested the concepts when we
designed HAM8. :^)
–Ben
…via AutoPilot
I concur with Ben – way back when even FractalPro's original version (HAM6
only) used menus, requesters, etc. on a HAM6 screen. And not as well as Ben has
pointed out can be done, but it did work. Now even FractalPro version 6 uses
HAM6 and HAM8 and a palette requester can come up right on the graphics screen
(menus, gadgets, etc. are on a separate control screen nowadays).
Well, yes, it's technically possible to use a HAM screen for an application.
But you'd have to program it specifically for that mode, which isn't very
practical.
PageStream works in up to 8 bit color for the same reason that most other
applications work in up to 8 bit color—because the Amiga's standard color
modes only go up to 8 bit color.
Michael @ Soft-Logik Publishing Corp.
Michael,
Stick to the line that you're not a programmer.
Michael,
Hire and fire if you must, but you guys need to get some programmers in there
that *want* to do a little bit of ground breaking when it comes to graphics
development. PageStream 3.0 will not be accepted in the industry if it does
not support more than 256 colors. I hate to say it, but it's true. Also, I
would highly suggest that you seriously change your color seperation techniques
to match what service bureaus require for proper output. Every ad I made for
Amazing Computing and/or AmigaWorld using PageStream (2.0 thru the latest) has
been color shifted by 30%. I talked to SoftLogic about it, and they blame the
service bureau…. and of course the service bureau blames you guys. Either
way, it resulted in ads that look terrible because of the color shifting AND
because the inability to see what the ad looks like in color. Look at the
latest AmigaWorld for our ad (for EMPLANT)… Quark Express… no manual.. 10
minutes.. perfect.
I would love to see you guys burn Quark to the ground. 🙂 If you would like
any help dealing with 3rd party video boards, please let me know. We support
*every* video board on the market at low level, so we know them inside and
out…
Jim Drew, CEO – Utilities Unlimited Intl., Inc.
🙂 🙂 🙂 🙂 🙂
"Quark Express… no manual.. 10 minutes.. perfect."
🙂 🙂 🙂
There was a typo in the first line of your ad. harddare instead of hardware
🙂 🙂 🙂
OTOH, I sold another Emplant yesterday — people like the product.
-Chas
Oops. That was the *last* ad. Sorry. I just got a new AMigaWorld — 1000%
improvement in the ad. It *really* looks better. (No typos, either. 🙂
-Chas
Actually, the new ad done in Quark has no mis-spelled words.. The spelling
checker in WordPerfect missed 'harddare' when I made the original text.
Actually when I did the early versions of what became FractalPro, I did NO
special programming for the Intuition user interface (menus only at that stage,
but some requesters, too) to exist on the HAM graphics screen right along with
the fractal image. My approach, though, was pretty simple – just do it. The
menus and requesters did cause temporary streaks to appear on the fractal image
when the menus or requesters were on screen and in use, but it caused no other
ill consequences. I have no objections to how Pagestream works – I use it every
day. I haven't used a wordprocessor in years, since I began using Pagestream.
Now I neArt Expressions … I think Ben is just making a point and he is
correct – you can surely do the programming necessary to make Pagestream work
in HAM. I'd do a better job of it if I was doing it again and assure (using
mouse menu click detection, etc.) that when menus get pulled down that
temporary action is taken to eliminate even temporary streaks. It can be done
– it just may not be worth doing from your point of view. PageStream is a
terrific product regardless. That's not the issue.
"On the plus side, current Amigas ship with 18 bit color, standard.
"More than 16. Without adding anything.
Now don't play games. While there's a big palette of colors, Amigas are
limited to 256 colors on screen, or HAM8 which is brutal from a computation
standpoint. Fine for playback of already produced anims, of course. As you
well know, a flat 24 bit display is easier to manipulate than HAM8. Things
would be much better if Commodore had updated their graphics subsystem
significantly so the programmer wouldn't have to know quite so much about the
hardware.
Play games? Hardly – we manufacture software that directly manipulates
images upon a HAM8 display. No, it's not easy. Yes, it would be a darned
sight faster on a 24 bit display (and is… we drive the FC24 at MUCH
higher rates, all else being the same such as cpu, etc). But it's
completely inappropriate to discard the fact that it's there or to imply
it's unusable, because in fact it's not. And as you point out, it's just
fine for precomputed things, in fact its more than fine, it's _better_
than 24 bit, 2/3rds better in terms of storage and speed.
We do Windows graphics software. From that perspective, I'll put a
question to you: Have you actually _looked_ at the 16 bit color encodings
for some of the PC boards? I'll save you the trouble – they're 8->16 bit,
and considerably more difficult to directly compute than HAM8 is. Some
boards just use flat 5:6:5 or 5:5:5 and those are easy, of course. But
many of those "16-bit" boards use 8-bit encodings just like the Amiga does
(well, not "just like.. it's not ham8, it's something else, but you get
the idea). Some of the boards come with libraries (DLLs) and those are
considerably easier to deal with – as would HAM8 be if CBM would provide a
render library (as IMHO they should have long ago.. as we did when we
produced the HAM-E).
And I also wouldn't argue for a second that 24 bits should be standard.
Been saying so for years. In fact, if you had CIS records going back that
far, you'd find me saying way back when and getting poo-pooed. :^)
My point was – and is – the Amiga hardware' snot lacking in the area of
being able to display high color images. It does pretty darned good.
–Ben
…via AutoPilot
What's wrong with 24bit other than that it doesn't specify all possible
colors?
Paul
I can answer that… Storage and load times. Not to mention trying to
display them at higher res's on an IBM PC! XGA is limited to 8 bit (or
less) on anything over 800×600. (and Windows / OS/2 dithering patterns are
a little less than pleasing to look at.)
Bob Comer — Cruising the nets on Autopilot!
Cheyenne, Wyoming U.S.A.
That's kind of a "have you stopped beatin gyou…" question.
In the context that I was discussing, 24-bit is inferior to 8-bit
encodings in that there is 3x the data which has a two level cost. First,
it simply takes more space – memory, both ram and filesystem, is a finite
resource. An 8bit encoding, if adequate to the task (as HAM8 is for most
frame animation) requires 1/3 the filesystem & ram resource for the same
image in 24 bit. Turning that around, 24bit costs 3x as much resource wise
as 8 bit, and that would be "what is wrong with 24bit" in this context.
Additionally, 24bit image data being 3x the size pretty much inevitably
takes 3x the time to _move_ so limiting the upper frame rate attainable to
1/3 that of 8bit data; and for any given frame rate you pick, 24bit data
uses 3x the _bandwidth_ or 8bit data, which in turn limits the amount of
_other_ things you can do _while_ the 24 bit data is being moved, as
compared to 8bit data. So there is the other "thing that is wrong with
24bit data" in the context which I was speaking.
There's a lot that is "right" with 24bit data. It's easy – trivially easy
– to program for. HAM8 is not easy, it's not even medium hard, it's on the
middle edge of difficult when you have to deal with issues like windows.
Nothing a good programmer couldn't do, but it becomes a price/performance
call for the developer: spend the time doing this hard thing for that
particular benefit? Yes, or no? And, HAM8 being "hard", it's also slower
because there is more to do (this is for live work – not animations, for
which it is much faster in playback).
–Ben
…via AutoPilot
AMEN, Ben – I was a bit reluctant, but have been very pleased I took your
advice to handle 24-bit as standard in FractalPro. Adding support for 24-bit
boards has been fairly easy as I maintain the full 24-bit image in a bitplane
(not chunky pixel) array. Computing is fast, and that also lets FractalPro do
some nifty bitplane shuffling tricks to rearrange colors on already rendered
24-bit pics in no-time.
yep, 24bit data is a great thign to have – as the gfx stuff comes up in
capability, theings just keep looking better and better. :^)
–Ben
…via AutoPilot
Ben, indeed – 24 bit is really the correct preparation for the future.
Now now… considering the fact that we can do chunky->planar conversion in
software faster than Akiko can do it (CD-32 hardware), there is NO reason for
not do HAM8 conversion for graphics.. in fact, I am doing a HAM8 'thousands'
mode driver for the MAC emulation right now and it screams… we can convert
the data faster than the AGA hardware can display it.
Jim,
I think you're preaching to the converted. :^)
–Ben
…via AutoPilot
Jim,
I'd _love_ to see your conversion routine. (chunky to planar)
Well said!
Render Library, hmmmm, now that makes sense! Grrrrrrrrrrrrrr! C=
should've done this.
Bob Comer — Cruising the nets on Autopilot!
Cheyenne, Wyoming U.S.A.
Yes, I really think so. We provided two: One has the change from 24bit to
HAM8 code, the other had all _kinds_ of cool stuff, like text, ellipse and
line drawing, sort of like graphics library but these routines worked in
HAM8. We supplied a demo that (surprise!) had windows, requesters, etc.
Even anmiations.
–Ben
…via AutoPilot
for a few $$$ I'll show you how to use HAM8 in a very nifty way with very low
computation overhead and fringeless 12-bit color!