[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] XaAES sources for FreeMiNT 1.16.3



I looked into this myself. For some reason the aranym pixel format signature is different than XaAES is expecting. I would suspect this has something to do with fvdi. My attempts to fix the issue with different fvdi color combinations proved fruitless. But yeah I noticed this problem. What I didn't know is that it ever worked before.

Thanks,
Mark


Paul Wratt wrote:
:)

OK, I am presuming it is ARAnyM related (in some way), because it
would be unthinkable for what I see (and dont see) to have not been
fixed let alone reported, if it were the same for other platforms
(CT6x, Milan, Hades, etc)

It is not ARAnyM related, or fVDI, or EmuTOS, as these can be swapped
and the results are the same. The only difference I can find is that
anything after 1.16.3 (ie 1-17-cur) causes XaAES to have "invalid
pixel format" in >256 color video modes under ARAnyM. Like I said, it
is not ARAnyM, fVDI, or EmuTOS, as changing versions does not affect
the results of either 1.16, or 1.17. It however might be the ARAnyM
MiNT loader, the XaAES loader or kernel module, or it may even be the
way ARAnyM runs the BOOTSTRAP, or uses the BOOTSTRAPARGS.

I only know this, because I "accidently" saw gradients and texturing
when I put 1.16.3 from Pack 3D on the AFROS 8.12 LiveCD. The results
are reproducible on a standard ARAnyM using AFROS style boot. I am not
100% sure what the difference in an EasyMint setup might be, except
that it looks to use the AUTO folder as its primary boot, NOT the
ARAnyM MiNT image, ie MiNT gets loaded after SET_MMU and CLOCKY,
unlike AFROS which load the MiNT.PRG first, then uses the .CNF to
autoload certain file "before MiNT"

This is also the only difference I can see the "may" affect the CAT
issue already mentioned elsewhere, but then it would be a quirk, which
may or may not be related to ARAnyM (use of BOOTSTRAP). This is only a
guess atm.. I have yet to test any 1.17 on EasyMiNT ARAnyM
installation (from the EasyMiNT download page)

OK, so why 1.16.3 source?

Fork, definitely no need for that, yet... To me its simple. I dont
know what has changed since 1.16.3, according to XaAES's about dialog,
its exactly the same version 0.9.9.8 alpha, but I know that something
in how the pixel format is recognised HAS changed, and since it was OK
in 1.16.3, I can then do a simple compare of code to see what has
changed. This makes "fixing" XaAES to an unbroken level, a simple
thing.

It may also show why the latest kernel builds are absolutely unusable
on ARAnyM. To see what I mean, grab the latest kernel cvs builds from
freemint.org, and replace the respective files in a AFROS booting
ARAynM, and you will see the system is totally unusable.

My understanding of code is that its (probably) a small "thing" that
has caused this problem, or it maybe a couple of "small things". But I
have noticed only a lack of comment about its results, except for a
few comments by "one off" AFROS users on the ARAnyM mail-list, "it has
ugly shadows around the icons". Thats it, nothing else.. what the user
didn't know, was that gradients AND texturing were also missing..

Unfortunately I neither know enough C, C algorithms, or TOS
programming to be able to just jump into the code (or a debugger) and
"iron it out by hand", like say Vincent can. But I do know enough to
read C, understand what its trying to do, compare it to some other
code, and make adjustments, or "cut and paste" some new code which
does achieve "the right results". (this is a legacy of web
development, but it does mean I can read ANY code, and get working
results, based on working examples).

As for the rest of the XaAES issues, and for that matter the current
load of 68000 FreeMiNT ones, if I can get this sorted, then I can
start looking at using a debugger to help fix other problems that are
not so simple, especially since the only ST I have are emu's, they are
recommended for hardware compatibility, so they will do fine.

One last thing, I'm guessing here, but I think that the redraw problem
on the Milan, is the same "redraw quirks" that happen on EasyMiNT.
These "quirks" are NOT present on an AFROS setup running 1.16.3 (from
PACK3D), or 1.17 (from AFROS 8.12). (now that seems to make perfect
sense???)

If peeps need screen shots to better understand what is and isn't
happening, I can provide a catalog. If someone else wants to "fix"
XaAES, I would be happy for them to do so.. but I need things sorted
asap, which is why I'm willing to do it. Its taken me 12 months to put
what I have together, and I was hoping to have a "good" point release
of both 1.17 (XaAES) and HighWire out by Christmas, for an initial
AFROS 9.12.. but hey, one thing at a time..

Hope that clears up any possibilities..

BTW Alan, cheers on the CVS info, do you know the command off the top
of your head? Also, I have already logged the main issue under the
XaAES bugtracker on Mantis.. As I side note, while I'm doing all these
version tests, I thought I might as well go through and confirm some
of the other issues logged, like the "rpm tetex-fonts" issue, to give
them up-to-date status

Cheers peeps

Paul