XaAES with extended textures for MiNT 1.16 (readme.txt)
68040 Pastel Color Pack, XaAES with extended textures for MiNT 1.16, in 6 flavours (readme.txt)
sources files XaAES (src.km) with extended textures and gradient files for MiNT 1.16.3 (readme.txt)
Update:
The mentioned issues with current MiNT v1.17 are being looked into, and
I have seen a bug fixed version
of XaAES that has a slightly different pixel detection function, which
does seem to provide a solution. I am as yet unconvinced that this is
not hiding something deeper, however
it should be noted the texture and gradient issues I have experience
with ARAnyM usning 1.17 are not present on all systems or setups, so it
may be enough, and we may never know
the real cause of the issue. Expect a fixed version in a full release of
AFROS-update, which should be 9.12 (this month in 09).
Whats Available
Apart from the packages uploaded to the afros-update project,
you
can also find here OS wide themes, AES frame widgets, AES frame skins,
extra AES widgets, AES scroll sets, and complete AES themes. Also
there are application specific skins, icons and themes. Where ever
possible I have tried to complete all AES related work
to be made available for MyAeS (v0.92) AND XaAES (v0.998 Alpha), both of
which can be used with AFROS, ARAnyM, and MiNT.
MyAeS skins, themes and scrollsets are tested on a ARAnyM Falcon setup
(TOS 4.04), so they should work 100% on whatever
other platforms that MyAeS successfully runs on. At some point I may
start supplying Magic compatible themes, widgets and
skins, same for N.AES, but only if there is demand, and only then on an
"available time" basis. Let me know if you want them.
I have many projects on the go at any one time, and as you may find out, some of the downloads here (and on afros-update) are
preview, "work in progress", or incomplete. These are continuosly being updated, improved and worked upon, but you may
however request an update, fix, extension, or supply alternates and improvements. Some of these packages contain textures
or icons that have taken days to get looking right on an Atari ST, and may be one of 3-6 alternative for that single image.
Often there are enough individual pieces to mix and match up to about 6 different styles of one theme or skin. With this in
mind, know that there are often included configuration and description files, to be used with something simply called
Config.R8R.
At the moment, you need to do at least a small amount of reading in
order to know what to do with, or where to put, these
packages. Basically I suggest keeping everything in one "skins"
directory somewhere, especially the MyAeS skins (ie
keep only a folder called "default" in the "C:\GEMSYS\MYAES\SKINS"
directory, you have been warned), as this will be
used by config.r8r as a default stroage, from which all "options" will
be installed from. The folder name will be user
defined to help non-english users keep there filesystem organised
properly. At the moment it is just a collection of bash (or shell)
scripts, which will be released with "various intermediate front-ends"
to start them, and hide them from view. A Thing groups
file is one for, because this is the basis for Taskbar's menu system,
and there are enough users still using Thing Desktop.
Eventually the config.r8r will come as a front end app. It will allow
"dynamic resource creation", run-time program configuration
changes, multiple boot-time configurations, GEM-script process config
changers (for supported apps), a program patcher,
and file/version backup, copier & packager, as well as multi-version
MiNT configuration, and "single file" XaAES and MyAeS
configurations, all from one frontend, but with fallback scripts for
those who would "do it their own way". This too is
obviously a lot of work, which may take 12 months or more to complete to
a usable level, but it will be modular, so that
it can be easily extended to be used to configure other CNF and INF
files, as well as other programs. If you can imagine
a kcontrol (KDE Kontrol Center) for MiNT/AFROS/ARAnyM/ATARI, then you
might be close.
Things You Need To Know
What I am about to write here is not "an afternoon trying" or "an hour here or there", but comes from 8 to 20 hours sessions
of trying to get the simplest thing for work, days or (in some cases) months of hunting for solutions, and many, many
hours of repedative OS and app configuartion testing, mostly so you dont have to.. hopefully.
With ARAnyM at least, although I want to test a couple of other configurations, after 6 months, the following is still true:
wanted themes
256 color skins - MiNT/XaAES 1.16 or 1.17
more than 256 colors - MiNT/XaAES 1.16 (NOT 1.17)
gradient color skins - MiNT/XaAES 1.16 (NOT 1.17)
widgets - MiNT/XaAES 1.16 or 1.17
MyAeS will do only 256 colors on an ARAnyM Falcon setup (TOS 4.04), but with MiNT 1.16 or 1.17 it will give you 24bit color.
XaAES under any MiNT version 1.17 on ARAnyM will NOT allow 24bit texture rendering (invalid pixel format). This does NOT affect
applications in any way, just the theme related rendering. This may not be the case
on Milan, Falcon, Hades, or CT6x (or Coldfire), but it is on ARAnyM, and has been for more than 12 months.
XaAES uses an NON-STANDARD 24bit IMG/X-IMG (GEM Paint) format. By "non-standard", I mean programs from the 80's & 90's like
GemView, GrafTool, Smurf can not generate compatible 24bit IMG files. There may be a simple solution, I have yet to find
a legitimate tool that can output a 24bit IMG that XaAES can read. That said, most tools can read the 24bit IMG files that
are (currently?) supplied with XaAES.
The workaround is to create IMG format images with 256 or less colors.
AGAIN, this is not practical with "legitimate"
tool on the GEM/MiNT alone. The secret of my success? 24bit originals, usually TIF, saved out from GIMP as GIF format.
That is to say, 24bit color to UN-DITHERED 256 or 128 color images, then GrafTool from GIF to IMG (having to quit after
each image convertion, because the IMG option disappears from the "Save As" menu options). NOTE that GrafTool can do a
straight image conversion, no palette remapping, or color dithering, to IMG format, as either 8bit (265 colors) or 7bit
(128 colors), BOTH of which XaAES can read (suprisingly), unlike some other tools.
It is possible for GEM View to do 24bit to 256 color "nearest color", ALMOST-UN-DITHERED "img" image, but this takes
an excessive amount of work, and does not give appropriate results when that IMG requires a specific palette. GrafTool
also "sux" where a specific palette is required. At the moment I have resorted to using GIMP with custom palette files,
and doing straight "265 color format conversions" from GIF images. IMG files of this type are required for XaAES's
texture rendering in 256 color mode, which remaps image palettes to the palette currently being used, thankfully it does
not try to dither the images as well, although some of the resulting textures may look that way, they are in fact not, so it is
best to start out (on the Atari/GEM side) with an image that already contains the correct palette. NOTE: they are actually
mapped to the FIRST 16 colors of the current pallete, so you better get those old pixel skills up again.
I have access to both Smurf and Vision source code. Both are a bit
less than "stable" under MiNT on ARAnyM, but usable
if you know what NOT to do (no fill tool in Vision, no multi select menus or option dialogs in Smurf). I also have some
early versions of GIMP in source form. The idea is to get all 3 running stable, add the relative IMG/XIMG format extensions
to all three, and offer the GEM/IMG/XIMG import export modules to the GIMP project for inclusion, along with 2 different
256 color palette files created tonight, one is the AtariST-default (AtariST-default-16)
palette (which contains some
color double-ups, and may or may not be the same as the default Falcon 256 color palette),
while the other is the AtariST-common (AtariST-common-16)
palette
which is the one used by "taskbar.pal", "nvdi.pal", "jinnee.pal" and
(believe it or not) Jinnee's "alternat.pal". I will
double check these again using GIMP this time, but there is no
noticeable difference in these "alternate" palettes, on the desktop
anyway.
The only drawback of using GIMP at the moment, is that modern versions are probably "out of the question" on current
TOS/GEM platforms, and that it really should be added to the AFROS LiveCD as a host OS dev tool, which means more work
needs to be done on the X Server presentation, which is, currently under Slax, limited to running ARAnyM, then shutting down.
However the bonus of using GIMP (source), is that various "must haves" can be added to Smurf and Vision, like
more modern image formats and other modern "extras", and certain parts be crossed over
from other apps, like Smurfs "modules", and Visions color chooser. I will add "paletteing" to both, based on GIMP's palette
format, and include standard ".PAL" format support also. Never again will any person be required to spend a stupid
amount of time in order to get a simple image to be usable on the GEM/AFROS platform, thank god...