Page 3 of 3

Re: What I expect on Update3

Posted: Fri Jul 08, 2011 7:06 pm
by CygnusEd
ssolie wrote:There is some bug in the PIP support but CygnusEd (the author) has not yet managed to contact any of us to record the bug so it remains unsolved. We need a simple test program at aminimum to reproduce the issue.
Hi Steven,

yes I know, I should have reported the bug already, but I was working on so much other things.

Maybe it is too late, but here is a short description of the problem:

In my display driver I open an overlay window with the desired pixel format "R5G6B5" this way (incomplete and simplified source):


screen = IIntuition->LockPubScreen("Workbench");

win = IP96->p96PIP_OpenTags(
P96PIP_SourceFormat, RGBFB_R5G6B5, /* Pixel format of overlay */
P96PIP_SourceWidth, 800, /* Width of overlay surface */
P96PIP_SourceHeight, 600, /* Height of overlay surface */
WA_Left, 10,
WA_Top, 10,
WA_CustomScreen, (LONG) screen,
WA_NoCareRefresh, TRUE,
WA_DragBar, TRUE,
WA_CloseGadget, TRUE,
WA_DepthGadget, TRUE,
WA_Activate, TRUE,
WA_Title, "AmiCygnix Window",
WA_NewLookMenus, TRUE,
TAG_DONE);

IP96->p96PIP_GetTags(win, P96PIP_SourceBitMap, (ULONG) &bitmap, TAG_END);

lockhandle = IP96->p96LockBitMap((struct BitMap *) bitmap, (UBYTE *) &rinfo, sizeof(struct RenderInfo));

videomem = rinfo.Memory;


Afterwards I write the gfx data in R5G6B5 format directly into the video memory. This worked in the first release of OS 4.1, but not in update 1 and 2.

I can write an example program an post a link to it here - if it makes sense.

Re: What I expect on Update3

Posted: Fri Jul 08, 2011 7:40 pm
by ssolie
CygnusEd wrote:Afterwards I write the gfx data in R5G6B5 format directly into the video memory. This worked in the first release of OS 4.1, but not in update 1 and 2.

I can write an example program an post a link to it here - if it makes sense.
Yes please! Just even a rectangle drawn into the PIP window would be enough.

P.S. Welcome to the new support forum. 99% troll free :mrgreen:

Re: What I expect on Update3

Posted: Fri Jul 08, 2011 8:52 pm
by CygnusEd
ssolie wrote:Yes please! Just even a rectangle drawn into the PIP window would be enough.

P.S. Welcome to the new support forum. 99% troll free :mrgreen:
Hi to all non trolls!! (But: 99%? Why not 100% ?? ;-))


O.K., here it is:
The source file: overlay-bug.c
The binary: overlay-bug

The program opens a PIP window, renders a white background, then from left to right a black, a red, a green and a blue rectangle.
But on update 1 + 2 the background is pink and the rectangles are dark green, dark red, light green and blue.
I get the same results with pixel format "Y4U2V2"!!

Re: What I expect on Update3

Posted: Sat Jul 09, 2011 2:16 am
by Slayer
CygnusEd wrote: (But: 99%? Why not 100% ?? ;-))
Because if it was considered 100% that would probably just be too much for someone to take and want to topple it, the desire to go from 99% to 98% I think is a lot more subdued? ;)

Re: What I expect on Update3

Posted: Sat Jul 09, 2011 5:09 am
by Raziel
CygnusEd wrote:
ssolie wrote:Yes please! Just even a rectangle drawn into the PIP window would be enough.

P.S. Welcome to the new support forum. 99% troll free :mrgreen:
Hi to all non trolls!! (But: 99%? Why not 100% ?? ;-))


O.K., here it is:
The source file: overlay-bug.c
The binary: overlay-bug

The program opens a PIP window, renders a white background, then from left to right a black, a red, a green and a blue rectangle.
But on update 1 + 2 the background is pink and the rectangles are dark green, dark red, light green and blue.
I get the same results with pixel format "Y4U2V2"!!
Oooh, that would be great to have fixed :-)
I got the same problem using sdl/minigl ports producing wrong colors.

One of the devs of such a program pointed out a possible bug in minigl:
I can not reproduce this on my Mac mini PPC, I guess your graphics driver /
OpenGL implementation does not support the overlay color format as texture
color format.
Will wait impatiently for a fix :-)

Re: What I expect on Update3

Posted: Sat Jul 09, 2011 8:41 am
by tonyw
Edgar, this bug really deserves a thread of its own.

Re: What I expect on Update3

Posted: Sat Jul 09, 2011 1:50 pm
by JosDuchIt
I would be glad if more preferences could be set using Arexx, Notepad and other standard applications (Find, UnArc) settings idem.
In general Arexx ports was one of the features that made the Amiga your 'own' personal computer, allowing to program easily workflows you did use.
Hopefully third party developers too will take this suggestion up.

An arexx port for the shell would be especially usefull, when and if it will be possible to save the shell's content.
A replacement for Scripit, not working anymore under OS4, would be nice too, allowing control of applications that don't have an arexx port.
You now can use use WTF (Window to Front CLI command) and stringins (writing to an active window).
Both should be standard shell commands as thery are very usefull in scripting.
A Filenote CLI command that reads a filenote by default would also be very usefull in scripting.

Re: What I expect on Update3

Posted: Mon Jul 11, 2011 5:58 pm
by ssolie
CygnusEd wrote:O.K., here it is:
The source file: overlay-bug.c
The binary: overlay-bug

The program opens a PIP window, renders a white background, then from left to right a black, a red, a green and a blue rectangle.
But on update 1 + 2 the background is pink and the rectangles are dark green, dark red, light green and blue.
I get the same results with pixel format "Y4U2V2"!!
I just filed a bug report for this issue.

Big thanks for the test program!