HELP : compatibility of new console.device OS4.1FE

A forum for general AmigaOS 4.x support questions that are not platform-specific
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1479
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: HELP : compatibility of new console.device OS4.1FE

Post by tonyw »

And is the console the only system component that has changed? What about graphics.library?
cheers
tony
User avatar
Spektro
Beta Tester
Beta Tester
Posts: 122
Joined: Sat Jun 18, 2011 6:55 am
Location: Finland
Contact:

Re: HELP : compatibility of new console.device OS4.1FE

Post by Spektro »

tonyw wrote:And is the console the only system component that has changed? What about graphics.library?
Yes, that's the only one. I was using graphics.library version 54.148 (26.9.14) in both test cases.
- Janne Peräaho
User avatar
gdridi
Posts: 64
Joined: Sat Aug 11, 2012 10:17 am

Re: HELP : compatibility of new console.device OS4.1FE

Post by gdridi »

Hello Spektro,
Hi! Tony

Here is the code that displays Arabic that fails to display correctly.

The only problem, I think may be, is the Move() and perhaps new console makes it own move() after mine so the I cannot take control. This works well with old console device.
A matter of compatibility, hope this code will help.

There's no problem with ASCII letters because I use the Text() graphics
But here at the end , I make a CMD_WRITE to the underlying console device to display character c, not a Text() to gain of font attributes saved in console device that're : bold, italics, underline or inverse video, when I display a char.

Variable c is a

UBYTE c; // contains a ArabSCII code, see display at the end.

// calculate xcur0, ycur0
ULONG y0 = ( (((struct mu *)io->io_Unit)->ycur + ((struct mu *)io->io_Unit)->ma_fonte_arabe->tf_YSize - ((struct mu *)io->io_Unit)->ma_fonte_arabe->tf_Baseline + 1) / ((struct mu *)io->io_Unit)->ma_fonte_arabe->tf_YSize )
ULONG ycur0 = ((struct mu *)io->io_Unit)->win->BorderTop + ((struct mu *)io->io_Unit)->ma_fonte_arabe->tf_Baseline + (y0-1) * ((struct mu *)io->io_Unit)->ma_fonte_arabe->tf_YSize;
ULONG x0 = ( (((struct mu *)io->io_Unit)->xcur + 1 ) / ((struct mu *)io->io_Unit)->ma_fonte_arabe->tf_XSize );
ULONG xcur0 = ((struct mu *)io->io_Unit)->win->BorderLeft + x0 * ((struct mu *)io->io_Unit)->ma_fonte_arabe->tf_XSize - 1; // - 1 pour retrouver Witdh-1

SetFont(((struct mu *)io->io_Unit)->win->RPort, ((struct mu *)io->io_Unit)->ma_fonte_arabe);

SNPrintf(((struct mu *)io->io_Unit)->ansi, 64, "\033[%ld;%ldf\000",
y0, // x et y are inverse par SNprintf?
x0+1
)
;
((struct mu *)io->io_Unit)->cio->io_Command = CMD_WRITE;
((struct mu *)io->io_Unit)->cio->io_Data = ((struct mu *)io->io_Unit)->ansi;
((struct mu *)io->io_Unit)->cio->io_Length = -1;
DoIO((struct IORequest *)(((struct mu *)io->io_Unit)->cio)); // cursor posionning command

// DO THE MOVE() !
Move(((struct mu *)io->io_Unit)->win->RPort, ((struct mu *)io->io_Unit)->xcur = xcur0, ((struct mu *)io->io_Unit)->ycur = ycur0);

// DO the WRITE
((struct mu *)io->io_Unit)->cio->io_Command = CMD_WRITE;
((struct mu *)io->io_Unit)->cio->io_Data = &c; // write character c, Now!
((struct mu *)io->io_Unit)->cio->io_Length = 1;
DoIO((struct IORequest *)(((struct mu *)io->io_Unit)->cio));

BEST REGARDS Spektro and Tony.
It is difficult to retrieve compatibility _issue_ with just two images wrong and right of display, I hope this code will HELP.
Hope I will feel happy that we'll find a workaround together.
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1479
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: HELP : compatibility of new console.device OS4.1FE

Post by tonyw »

OK, I'm beginning to understand the problem now. I would have to load up a debug version of the console and print out lots of debug information to find out what's happening and I don't have the time at the moment.

There may be an issue with trying to do the IGraphics->Move() on the RastPort at the same time as the console is doing the same thing. The new console works slightly differently from the older version, and processes some I/O requests asynchronously. If the console is calling IGraphics() at the same time as your program, that might cause a problem.

You are using two separate I/O calls (one to the console, one to graphics.lib) to move the cursor, then a third I/O call to write a single character:

Code: Select all

SNPrintf (dest, size, "\033[%ld;%ldf\000", y0, (x0 + 1));          // Use "[CSI]y;xH" instead. Also you don't need the "\000" on the end of the string.
[...]
[IGraphics->]Move (x, y);      // Why is this necessary? Why not use the console itself?
[...]
(write singe character).
Why are you calling IGraphics->Move() at all? Why not simply use the console SetCharacterPosition sequence?

I would suggest changing the calls to a single call like this:
"Set cursor position", "print character", "move cursor".

Code: Select all

SNPrintf (dest, size, "%lc%ld;%ldH" "%lc" "%lc2D", CSI, y, x, c, CSI);
where "CSI" is #defined as 0x9B. I have split the string into three parts so that you can see them.
cheers
tony
User avatar
gdridi
Posts: 64
Joined: Sat Aug 11, 2012 10:17 am

Re: HELP : compatibility of new console.device OS4.1FE

Post by gdridi »

Hi! Tony

We've got it , the bug. Cool to know that. A big thank because it seems to be difficult to find.

I use Text() for ASCII because of , some support bilingual , to prepare to the next Text() which needs to be at some position thanks to Move(), I've dropped this move()... BUT IT IS THE SAME UGLY DISPLAY.
Some other Move, I can't dropped, needs some investigation...

Thank you, also to Spectro for your time , both.

Postscriptum : I was surprise that my program don't catch the HELP ANSI key sequence which I used to swap between Arabic and ASCII modes. And pop up WB amigaguide help page. Could you investigate too.
Last and least I hope :
Furthermore, I have to open two(2) keymaps and swap between them with the old (obsolete) CMD_SETKEYMAP because the new SETKMAP_POINTERS free the memory from one of two another. So I had bug when quitting my program. Dreally it's not a bug , even if old SET_KEYMAP command is stamped obsolete.

Bye, bye.. Amiga makes me a multilinguism specialist...
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1479
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: HELP : compatibility of new console.device OS4.1FE

Post by tonyw »

What is "the bit" that you found described in the RKM? Please tell me so that I can look it up.
cheers
tony
User avatar
gdridi
Posts: 64
Joined: Sat Aug 11, 2012 10:17 am

Re: HELP : compatibility of new console.device OS4.1FE

Post by gdridi »

tonyw wrote:What is "the bit" that you found described in the RKM? Please tell me so that I can look it up.
Don't forget :

1. Repair the console so that internal AsYNC and move() graphics library function is ok.
If it is not possible -- replace "hyperspace" , Luck!
2. HELP ANSI report compatibility as previous version console device ;
3. Keep cool with older bug of freed memory with old console device are not bug!

Now, buy a RKM Revised&Updated 1990,
Reference Manual -- Libraries&Devices
Page 411, Graphics: Text, FPF_REVPATH ...(for example, Hebrew).
(NOTE The actual rendering drection is determined by kern and space tables)

I restate, if you respect the NOTE page 411 , you just have to "signal" that it is a rev_path flag/bit set to display from the rightmost column/border respectively (console/graphics).

Keep in touch , for professional development and improvement of console.device and compatibility!
... And multilinguism?

DGilles
User avatar
broadblues
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 600
Joined: Sat Jun 18, 2011 2:40 am
Location: Portsmouth, UK
Contact:

Re: HELP : compatibility of new console.device OS4.1FE

Post by broadblues »

FPF_REVPATH
I guess he means the flags for choosing the font as described here.

http://wiki.amigaos.net/wiki/Graphics_L ... g_the_Font

As far as I understand it that only aids in choosing the correct font for givenset of criteria it doesn't affect how gfx library renders it.
User avatar
gdridi
Posts: 64
Joined: Sat Aug 11, 2012 10:17 am

Re: HELP : compatibility of new console.device OS4.1FE

Post by gdridi »

broadblues wrote:
FPF_REVPATH
I guess he means the flags for choosing the font as described here.

http://wiki.amigaos.net/wiki/Graphics_L ... g_the_Font

As far as I understand it that only aids in choosing the correct font for givenset of criteria it doesn't affect how gfx library renders it.
That's right, but as I said in the thread, it may alter the side where a pixel is displayed for bolding a font, italizing too (underline ok, inverse video ok).

And also, the flag will be used to say to graphics library how to deal with and operate with TextFit() and TextLength().

DGilles
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1479
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: HELP : compatibility of new console.device OS4.1FE

Post by tonyw »

Your point (1);
Let's just summarise the facts as I see them:

1. Graphics.library does not support displaying R-L fonts. The FPF_REVPATH bit in a font structure only helps it calculate the width of a string (TextExtent).
2. You have made a clever console replacement that acts as a "wrapper" around the existing console, to write a font from R-L on the screen.
3. The existing console interacts with graphics.library in ways that are not published, have changed since V53.1 and may change again in the future.
4. You are calling console.device and the lower graphics.library in quick succession, upsetting the relationship between them. The result is not what you want.

The only safe way to make your project work reliably is to use only console calls or only graphics.library calls. You must not mix them. I suggested a means to do this (by sending all the calls through the console), but it will be very slow and remains a "hack". R-L display can only be done properly by updating graphics.library to support R-L fonts.

There is nothing wrong with the existing console, only the way you are tricking it by calling graphics.library "behind the console's back". I don't intend to change anything in the console.

Point (2):
I don't see a problem in the console, as I said above. Leave the cursor positioning to the console, don't touch graphics.library and it will be fine.

Point (3):
I don't know what you are referring to here, but if you free something twice, it is likely to cause a crash. You might be lucky and get away with it for a while, but it is a bad fault and should be fixed.
cheers
tony
Post Reply