LoadRGB4 broken under 3.2
Hi
Archon Adept exist in a version that works on all OSes. It uses the gels system.
There is however a problem, the sprite color palette is wrong it contains mostly grey scale colors under 3.1. However running under 1.3 the sprite color palette is right. I have seen that it uses loadrgb4 to set the palette. So I was wondering if there is not a bug in Loadrgb4 under 3.1? The palette data are stored in word and I don’t see why it’s having shades of grey.
Any ideas ?
>Archon Adept exist in a version that works on all OSes.
From your description it sounds like it doesn't work correctly on anything later than OS1.3. Just because it uses OS functions doesn't mean there can't be compatibility issues caused by eg. assuming the system is set up in a particular way. The WHDLoad slave for this game sets up a 1.3 environment for it, presumably for this reason.
I wonder if loadrgb4 under 3.1/3.2 do handle sprite palette correctly. Why all colors ok except for sprite ?
The problem is happening because the Copperlist contains 32 colors if I remove color registers 16 to 32 from the Copperlist it is ok at least this is my current understanding
Hint?
* if Type == 0 then ColorMap is V1.2/V1.3 compatible */
/* if Type != 0 then ColorMap is V38 compatible */
/* the system will never create other than V39 type colormaps when running V39 */
V39 colormap lead to this problem I think.
@ boemann
the issue seems that Archon Adept and probably Archon do not set a ColorMap so the pointer is NULL but why is the OS then create a default one with a color table of 32 colors ?
The game then use LoadRGB4 for 16 colors mostly.
I wonder if 1.3 created a default color table and added it to the Copperlist if CM was null in the viewport.
Ok I fixed the issues. Archon 2 (probably 1 too) call SetRGB4 in many places and there is many times it set the VP to zero. This work fine under 1.x kickstart only. Once I put the VP the colors are fine now under 3.2. I suppose that it worked by chance under 1.x. RKRM ask for a VP so a game bug.
You might want to mention this to the WHDLoad slave author. If this issue was the only reason a 1.3 KS image was used in the slave, that requirement could now be removed and the bad API call patched directly instead.
I need to add some code so the game can start from RTG and I will release the game. It is using DOS functions and not track loading anymore so no need for an ADF just put the file wherever you want and run the game.
Cool :)
I found one issue, the Wraith will not attacking is invisible. I suspect that it is done by setting all colors of that sprite to black. But it is not invisible :( so i will have to Chase another bug :(
Online Status
:Update : I replaced loadrgb4 by 1.3 version and the issue is there so something else is going on I guess. I
I forgot that gfxbase being 3.2 call to other gfx function within 1.4 loadrgb4 will use 3.2 implementation…