Re: [MiNT] Bit-Depth and Graphics stuff....

[Paul Wratt <paul.wratt@gmail.com>]

On Fri, Jul 9, 2010 at 6:24 AM, Jo Even Skarstein <joska@online.no> wrote:
> On 07/08/2010 04:32 PM, Paul Wratt wrote:
>
>> You (as a programmer) need to respect the users palette settings,
>> unless you modify then restore.
>
> Correct. Unless you're in a truecolour mode, where this doesn't matter.
>
note that the palette is still held, even in true color mode, even
though it is not a palette mode, the VDI (or GEM ?) keeps it active

>> The .pal that currently comes with Taskbar is the same as most "nvdi"
>> or "Jinnee" palettes. I have even checked the alternates, and they
>
> It's the standard NVDI palette. I included this palette because there
> were problems with changing the global palette in fVDI at the time. It's
> only loaded if there's more than 256 colour IIRC, and only changes the
> palette for Taskbar's own workstations.
>
(off topic) I HAVE to use it in all modes, with or without Taskbar,
because of the new icons I created (see below)

>> where in fact the same. There was only one other common palette, and
>> that used the colorset as defined by Atari, which did not give enough
>> of "certain" colors, hence the use of the "nvdi" palette.
>
> Is there such a thing as a palette definition by Atari? The first 16
> colours are defined, but I don't think there is an "official" palette
> beyond that.
>
defined as in the hardware, a default 256 palette see the following
for the exact differences (and there is variation in the 1st 16 colors
too)
http://afros-update.sourceforge.net/aes-skinning.html

The one on the left is the default one. the one on the right is the
NVDI one. The alternate palette (not shown) is supposed to be slighty
different in some way, brightness, tone or hue, but I was unable to
find a .pal file that was actually different fron the standard NVDI
one..

>> The other alternative would be to start using Windom2, as it
>> impliments a "no need to know" set of functions that are quite
>
> This might have changed, but back when I tested Windom I quickly
> discovered that it did a lot of things I didn't like. E.g. it creates
> many objects of it's own, which make (made) Windom-applications look
> non-standard under N.AES and later XaAES.
>
I think the look depend on what you use (from windom) and what you are
trying to create. The other issues are an inevitable (negative?)
side-effect of a one-lib-does-all type solution, thats the compromise
in order to make it portable and simple to use. Windom was a
suggestion based on the fact that it and SDL can be used with LDG and
so gives shared libraries. Wheather this is accurate or not, it would
speed put dev time because bewteen SDL & windom, everything is done
that was required in this case

> Jo Even
>

A note here on web browser interface look and feel.

Most new/current (open source) developments are designed to be OS
independant as far as GUI goes. This is to maintain continuity across
OS's, which will have different GUI's. In reality though, there are
different gui ports any way, and no sooner does it get
standardized/finalized and someone comes along as adds their prefered
gui rendering (gtkWebKit, wxWebKit, qtWebKit, etc)

..in relation to Atari/GEM, if your web browser window has a menu bar,
most of use would expect (want?) it GEM compliant visually speaking.
Then again, we are talking about MODERN web browsers in this case, so
as long as the interface is usable, and "nice", it doesn't really
matter how it is implemented or even what it looks like.

cheers

Paul