HP Forums

No....

I think your thinking is much more complicated than my algorithm
Please analyze my algorithm step by step, and you will understand that it is much simpler than you think. The approach I propose requires the use of TEXTOUT_P only once (possibly a second time when bolding is applied). The frame also does not have to be drawn at an angle. Where did you get such a crazy idea? The frame in this case is created using RECT_P regardless of whether it will be drawn in the buffer or on Gx. Tilting the background in the opposite direction before applying the text should be done after drawing the frame (according to the order of points in my algorithm), so the frame will also automatically tilt. I assumed that the transparency level is set by a parameter with values ​​from 0 to 255.

Let's assume that beneath the text, there's a texture as the background. So, I start by copying it to the buffer. At the moment of creating the entire graphic, I don't use transparency at all. This can be done only when finally transferring the formatted text from the buffer to Gx. Therefore, if I provide a background color, the background in the buffer won't be transparent (it will completely cover the texture). But after copying everything to Gx with a transparency level, the effect of the background blending with the texture will be visible. The second case is when you don't select a background color. In that case, the letters will be drawn directly on the texture in the buffer (also without transparency). When you then transfer everything to Gx, setting the transparency level, the background, because it will be the same, will not change at all (transparency by definition changes the colors only of those pixels that are different between the source and the target, and here the source and the target will be the same). The difference will be only in the letters themselves, so the transparency will affect only them.

Hé komame
Comme le disais un célèbre détective Anglais, j'ai regardé sans voir !!
Mon esprit ne semblait pas concevoir que l'on puisse barré ou sous ligné un texte avant de l'afficher, et effectivement là pas de problème pour le cadre si le texte est encadré.
La mise en oeuvre de cet algorithme semble au final assez simple à programmer.
J'ai juste une petite réticence : dans le guide officiel il est écrit que pour BLIT_P si les variables source et destination sont la même et que les zones à copiées se chevauchent, le résultat peut être inattendu.
(ce sera le cas pour l'italique si cette fois j'ai bien compris)
Avez-vous testé ?

Hey komame
As a famous English detective used to say, I looked without seeing!
My mind didn't seem to conceive that you could cross out or underline a text before displaying it, and indeed there's no problem with the frame if the text is framed.
In the end, this algorithm seems fairly simple to program.
I just have one small reservation : in the official guide it is written that for BLIT_P if the source and destination variables are the same and the areas to be copied overlap, the result can be unexpected.
(This will be the case for italics, if I've understood correctly this time).
Have you tested this?

Hi Tyann.

(04-11-2024 10:17 AM)Tyann Wrote: [ -> ]I just have one small reservation : in the official guide it is written that for BLIT_P if the source and destination variables are the same and the areas to be copied overlap, the result can be unexpected.
(This will be the case for italics, if I've understood correctly this time).
Have you tested this?

I wouldn't propose such a solution if I weren't sure it would work
I tested the BLIT_P function a few months ago (I wrote a [post] then about its inconsistency regarding the "alpha" parameter compared to other drawing functions).
In general, the mechanism included in BLIT_P copies pixels sequentially from left to right, so if the source area is on the right side and we move it to the left, the shift will be correct. The problem arises when we try to move pixels to the right. Then, at some point, part of the target area will become the source, and artifacts will appear. In the case of creating an italic effect, we move pixels to the left, so everything will work as it should.

Bonjour komame

Merci à vous pour toutes explications techniques et vôtre aide plus que précieuse.
J'ai achevé l'écriture du code hier soir et procéder à quelques essais, tout semble fonctionner.
Je joint le code pour que vous puissiez vérifier, corriger et améliorer.
Il reste donc à traiter la transparence, j'ai fait un essai en dur dans le code cela fonctionne très bien.
Il faut voir sous quelle forme nous l'intégrons ?
BLIT_P prend cet argument en dernier et nous oblige donc à transmettre une couleur pour les pixels non visibles, il faut donc mettre une valeur par défaut différente des 2 couleurs que nous pouvons fournir à ATEXTOUT_P (je pensais à une liste locale de 3 couleurs : donc forcément dont une différente ou peut être un calcul).
Pour les arguments je suis resté sur une valeur numérique, mais nous pouvons ajouter la possibilité de mettre une chaîne (je pensais ensuite à convertir la chaîne en équivalent numérique pour n'avoir qu'un seul type de test)

Hello komame

Thank you for all the technical explanations and your invaluable help.
I finished writing the code last night and carried out a few tests, and everything seems to be working.
I'm attaching the code so that you can check, correct and improve it.
All that's left is to deal with the transparency, I've done a hard test in the code and it works very well.
We need to see how we integrate it?
BLIT_P takes this argument last and therefore forces us to send a colour for pixels that are not visible, so we need to set a default value that is different from the 2 colours that we can supply to ATEXTOUT_P (I was thinking of a local list of 3 colours: one of which must be different or perhaps a calculation).
For the arguments, I've stuck with a numerical value, but we can add the option of setting a string (I was then thinking of converting the string into a numerical equivalent so as to have just one type of test).

[attachment=13446]

Hi Tyann,

(04-12-2024 05:21 AM)Tyann Wrote: [ -> ]I'm attaching the code so that you can check, correct and improve it.
All that's left is to deal with the transparency, I've done a hard test in the code and it works very well.

I've analyzed your code. It looks pretty good, although a few things need refinement. I've made some optimizations to the code both for simplification and performance improvement.

1. The shortcoming is the too small height of the area copied from the source to the buffer, causing letters for the largest font size (7) with descenders at the bottom, such as "g," to have their last line of pixels cut off.
   To fix this, I changed
   
   BLIT_P("buffer",10,0,g,x,y,x+l,y+h);
   to
   BLIT_P("buffer",10,0,g,x,y,x+l,y+h+1);
   
   But this still needs improvement for italic text.
   ---
2. I moved
   TEXTOUT_P(s,"buffer",10,0,p,c,l);
   inside the REPEAT...UNTIL loop, placing it under the condition i==16 at the beginning of the loop, allowing all formatting cases to be placed into a single common "CASE," which organized the code somewhat.
   ---
3. For italic text, I simplified the code for shifting left. Instead of
   
   h:=h-3;n:=CEILING(h/3);j:=10;
   FOR ii FROM 1 TO n DO
   BLIT_P("buffer",j-1,h-d,"buffer",10,h-d,10+l,h);
   j:=j-1;h:=h-3;d:=MIN(h,3);
   END;
   
   I inserted a shorter and faster version, without unnecessary variables and preliminary calculations:
   
   j:=9;
   FOR ii:=h-6 DOWNTO -2 STEP 3 DO
   BLIT_P("buffer",j,ii,"buffer",10,ii,10+l,ii+3);
   j:=j-1;
   END;
   
   This also allowed removing the variables "n", "d" and "hh" from the program.
   ---
4. Apparently, there is a situation when displaying formatted text in italics on Gx. I replaced:
   
   h:=hh;j:=10;d:=3;
   n:=CEILING(h/3);y:=y+h;
   FOR ii FROM 1 TO n DO
   BLIT_P(g,x,y-d,"buffer",j,h-d,j+l,h);
   j:=j-1;y:=y-3;h:=h-3;d:=MIN(h,3);
   END;
   
   with a faster and simpler version:
   
   h:=hh;j:=10;
   FOR ii:=h-3 DOWNTO -2 STEP 3 DO
   BLIT_P(g,x,y+ii,"buffer",j,ii,j+l,ii+3);
   j:=j-1;
   END;
   
   ---
5. The code doesn't handle displaying letters with accents at the top (such as "Ó" or "É") in the case of very small fonts. The problem arises from the inconsistency of TEXTOUT_P because for larger fonts, the point (x, y) is applied to the upper part of the characters (taking accents into account). However, for small fonts, the point (x, y) is applied to the upper part of uppercase letters (below accents). This causes accents to be positioned higher and invisible if you insert the text at point (x,0). To solve this problem, you need to insert text into the buffer 3 pixels lower and adjust all parts of the program that add formatting accordingly. This is quite a significant change and may also mean enlarging the buffer by a few pixels because applying one common rule to all font sizes will also affect the largest fonts, which after being shifted 3 pixels lower may no longer fit in the buffer.
   ---
6. Among smaller adjustments, I also adjusted the position of the strikethrough and underline because they were incorrectly positioned for small fonts. For example, the underline overlapped the lower part of letters in very small fonts, making the text unreadable

(04-12-2024 05:21 AM)Tyann Wrote: [ -> ]BLIT_P takes this argument last and therefore forces us to send a colour for pixels that are not visible, so we need to set a default value that is different from the 2 colours that we can supply to ATEXTOUT_P (I was thinking of a local list of 3 colours: one of which must be different or perhaps a calculation).

Regarding BLIT_P and the requirement to define the [c] parameter when using transparency, I mentioned this issue in post #59 and in my opinion, this bug cannot be bypassed. The last and penultimate parameters ([a] and [alpha]) should have their order reversed. Otherwise, there is always a risk that one of the colors will not be copied (because one of them may always appear in the source image). So what you proposed may not work because when displaying text, the edges of the letters are smoothed (antialiasing is applied), creating several intermediate colors. Therefore, even if you know the text color and the background color, you never know which color to choose to avoid hitting one of those that will result from the overlap of the text edges with the background, especially when the text is embedded on a texture (where quite a few different colors may occur). Of course, if a background color (solid background) is provided, then the chances of the text being correctly copied are quite high.

(04-12-2024 05:21 AM)Tyann Wrote: [ -> ]For the arguments, I've stuck with a numerical value, but we can add the option of setting a string (I was then thinking of converting the string into a numerical equivalent so as to have just one type of test).

From my point of view, there's no point in introducing two alternative types of arguments regarding text formatting. One is completely sufficient.

Below is the complete code with my corrections (after pasting the code, two spaces (in different places) may appear in the definition of ICON - this is an error related to copying from hpmuseum. Remove these two spaces, and then the program will compile):

I had something else to write, but now I don't remember what... Oh well, maybe I'll remember tomorrow.
Good night.

Bonjour komame

Très belle optimisation, boucler sur la valeur h est une excellente idée et évite de la modifié et donc d'avoir à la sauvegarder : bravo.
En réfléchissant hier, j'ai moi aussi pensé que le fond d'écran pouvais intervenir dans les couleurs pour la transparence.
J'ai également trouvé une optimisation à faire dans ATEXTOUT_P :
après le test if d<8 then, pour ajouter le paramètre de largeur manquant, nous pouvons économiser l'appel à ATEXTSIZE et mettre la largeur maxi, car ensuite dans atextout refait la vérification pour voir si celle ci ne dépassent pas la largeur du texte.
Le code devient donc :

Hello komame

Very nice optimisation, looping on the h value is an excellent idea and avoids modifying it and therefore having to save it: well done.
When I was thinking about it yesterday, I also thought that the screen background could be involved in the colours for transparency.
I also found an optimisation to do in ATEXTOUT_P :
after the if d<8 then test, to add the missing width parameter, we can save the call to ATEXTSIZE and set the max width, because then atextout redoes the check to see if it doesn't exceed the width of the text.
The code therefore becomes :
Concernant la transparence j'ai réfléchi à définir celle ci comme attribut, car comme paramètre il faut revoir ATEXTOUT_P avec 10 paramètres au lieu de 9, puis ensuite atextout, cela me semble compliqué ?
Par contre dans le cas d'un attribut les modifications sont minimes, mais il faut une valeur :
on peut imaginer une valeur fixe ou une variable ou une fonction style SETTRANSP ?
Qu'en pensez-vous ?

Concerning transparency, I've thought about defining it as an attribute, because as a parameter you have to revise ATEXTOUT_P with 10 parameters instead of 9, then atextout, which seems complicated to me?
On the other hand, in the case of an attribute, the changes are minimal, but you need a value:
Can we imagine a fixed value or a variable or a SETTRANSP-style function?
What are your thoughts on this?

EDIT :
Une idée de dernière minute pour la transparence, si nous copions 2 fois le buffer vers Gx avec 2 couleurs différentes pour c,alpha , mettant noir et blanc !
la première fois les pixels noirs ne sont pas copié, mais ils le sont la seconde fois
?
A last minute idea for transparency, if we copy the buffer to Gx 2 times with 2 different colours for c,alpha , putting black and white!
the first time the black pixels are not copied, but they are the second time
?
Translated with DeepL.com (free version)

Good morning Tyann,

I think I've found a solution to the problem with BLIT_P. I conducted several tests, and it seems to be working correctly. To verify this, I drew a smooth gradient bar of a given color, from darkest to lightest. This way, I obtained all possible shades of blue (without any other color additives). Then I applied BLIT_P with the [c] parameter set to 128, which resulted in a blank line in the middle (because I excluded this color from copying) - which is consistent with the assumptions. However, when I added any transparency coefficient to this color (e.g., [c] = {128,255}), all colors were copied correctly. The specified color is irrelevant; what matters is that the transparency coefficient is set within the range of 1 to 255 (for 0, it behaves like a regular color and doesn't copy). I think this approach resolves the inconvenient limitation of BLIT_P.

Here is the program I used for this test:


Regarding managing transparency as the 10th parameter, it doesn't appear complex to me. In fact, it seems quite straightforward. I think it's worth revisiting my idea with a fixed number of parameters (instead of list) for "atextout" (in this case, it will already be 10). I'm convinced that this will simplify the code.

Consider a modification that will allow handling letters with accents for small fonts. To me, it's a rather significant flaw.

Hé komame

Pour BLIT_P c'est une excellente nouvelle .
Pour les petites polices savez vous si TEXTSIZE renvoie la bonne hauteur , ou si nous devons modifier celle-ci dans ATEXTSIZE ?
Ensuite si j'ai bien compris nous devons décrémenter 'y' de 'n' pixels avant la copie dans le buffer et
ensuite afficher le texte 'n' pixels plus bas dans le buffer, ensuite nous recopions le buffer depuis y=0 vers Gx à 'y'-'n' pixels ; les accents seront copiés dans cette zone et le texte à partir de 'y' ?
Mais il faut savoir quelles sont les polices concernées , car pour les autres cela ne fonctionnera pas.
Enfin vous suggérer que ATEXTOUT soit toujours appelé avec 10 paramètres et des valeurs par défaut ?

Hey komame

That's great news for BLIT_P.
For small fonts, do you know if TEXTSIZE returns the correct height, or if we need to modify this in ATEXTSIZE?
Then, if I've understood correctly, we need to decrement 'y' by 'n' pixels before copying it into the buffer and then display the text at 'n' pixels.
then display the text 'n' pixels lower in the buffer, then we copy the buffer back from y=0 to Gx at 'y'-'n' pixels; the accents will be copied into this area and the text from 'y'?
But you need to know which fonts are affected, because it won't work for the others.
Finally, would you suggest that ATEXTOUT should always be called with 10 parameters and default values?

(04-13-2024 09:09 AM)Tyann Wrote: [ -> ]That's great news for BLIT_P.
For small fonts, do you know if TEXTSIZE returns the correct height, or if we need to modify this in ATEXTSIZE?
Then, if I've understood correctly, we need to decrement 'y' by 'n' pixels before copying it into the buffer and then display the text at 'n' pixels.
then display the text 'n' pixels lower in the buffer, then we copy the buffer back from y=0 to Gx at 'y'-'n' pixels; the accents will be copied into this area and the text from 'y'?
But you need to know which fonts are affected, because it won't work for the others.
Finally, would you suggest that ATEXTOUT should always be called with 10 parameters and default values?

Tyann,

you're overthinking it again I've roughly outlined what needs to be done earlier. There's no need to check the font size; the change should be universal and will work the same for all font sizes, but it will improve the situation for small ones without affecting larger ones. There's also no need to change ATEXTSIZE.
To elaborate a bit more, you need to enlarge the buffer by 3 pixels and copy the content of Gx into it, also 3 pixels higher than the given "y". The key is to utilize TEXTOUT_P to insert text into the buffer at position (10,3) rather than (10,0). Accents on letters will naturally appear above (currently, they are being cut off because there is no space in the buffer above). Then, all drawing activities such as frame, underline, or strikethrough should be performed the same way, with the difference that they need to be lowered by 3 pixels. Finally, when calling BLIT_P, you simply execute it for (x, y-3).
That's all It won't change anything for large letters, but it will add accents for small ones. Of course, this may affect the loop that shifts pixels in the buffer for italic, so minor adjustments may be needed.

Quote:Finally, when calling BLIT_P, you simply execute it for (x, y-3).

De cette façon, si vous appelez ATEXTOUT_P avec y=0, vous ne verrez toujours pas les accents des petites polices non ?
Mon idée était de baisser de 3 pixels uniquement les petites polices pour qu'elles apparaissent entières même en y=0.

This way, if you call ATEXTOUT_P with y=0, you still won't see the accents of the small fonts, will you?
My idea was to lower the small fonts by 3 pixels so that they would appear whole even at y=0.

(04-13-2024 04:17 PM)Tyann Wrote: [ -> ]This way, if you call ATEXTOUT_P with y=0, you still won't see the accents of the small fonts, will you?

That's true, but the standard TEXTOUT_P function operates in the same way (it also won't display accents in such a situation). If ATEXTOUT_P is meant to be a replacement for TEXTOUT_P, then the text rendering position cannot be changed; this way, it will be easy to replace TEXTOUT_P with ATEXTOUT_P in any program (that's how I feel, but perhaps you have a different opinion?).
The programmer can decide where to display the text, so it's not a big issue. However, with ATEXTOUT_P, there is currently a problem that completely prevents displaying accents for small fonts, even if the text is centered on the screen.

Oui moi aussi, je voulais clarifier les choses.
Donc si nous sommes d'accord sur le fait que ATEXTOUT remplace TEXTOUT dans un programme, nous sommes d'accord que ATEXTOUT ne peut pas avoir 10 paramètres fixes avec des valeurs par défaut, mais doit avoir un nombre de paramètres variables.
Je songe à utiliser la syntaxe {c,alpha} sur le paramètre 'c' couleur du texte pour la transparence, mais je sais que vous n'aimez pas trop cela.

Yes, I too wanted to clarify things.
So if we agree that ATEXTOUT replaces TEXTOUT in a program, we agree that ATEXTOUT cannot have 10 fixed parameters with default values, but must have a number of variable parameters.
I'm thinking of using the {c,alpha} syntax on the 'c' text colour parameter for transparency, but I know you don't like that too much.

(04-13-2024 06:18 PM)Tyann Wrote: [ -> ]Yes, I too wanted to clarify things.
So if we agree that ATEXTOUT replaces TEXTOUT in a program, we agree that ATEXTOUT cannot have 10 fixed parameters with default values, but must have a number of variable parameters.

I completely agree with you. ATEXTOUT_P cannot have a fixed number of parameters, and I never suggested such a thing. The only place where I wanted to use a fixed number of parameters is in the "atextout" function (the internal one that is called by ATEXTOUT_P), because it currently takes a list, and I think I can optimize the solution much more if it takes a fixed number of parameters. Throughout our discussion, I've always had "atextout" (written in lowercase) in mind; I never meant ATEXTOUT_P.

(04-13-2024 06:18 PM)Tyann Wrote: [ -> ]I'm thinking of using the {c,alpha} syntax on the 'c' text colour parameter for transparency, but I know you don't like that too much.

As for the text color format {c,alpha}, it indeed can contain two different alpha values, so I believe that if part "c" has its own transparency value, and additionally, a second transparency value is defined in the second element of the list, PPL should report an "Invalid input" error, but it doesn't do that. But that's the only thing I have concerns about. In practice, I also use this color format and I'm not opposed to it.

When it comes to your proposal of {c,alpha}, one would have to ask here, what if for "c" (text color) we define the color {255,128} and for "f" (background color) we define the color {128,64} - meaning different transparencies? Would there then be separate transparency for the text and separate for the background? This seems very difficult to achieve, or at least it's not possible using a single buffer. On the other hand, if you assume that the transparency of the text color affects the transparency of the background, you might as well say that the transparency of the background should affect the transparency of the text, right? To avoid such dilemmas, I had the idea of using a 10th parameter, where only the transparency value is passed (without color, similar to how it works in the case of BLIT_P). Then everything is clear, and no one will ask additional questions.

Bonjour komame

Le problème que je vois au 10 éme paramètre est le suivant, nous devons fournir une valeur à 'f' (couleur de fond) par défaut pour dire à atextout qu'il n'y a pas de fond (surement une valeur négative) mais si nous fournissons une valeur négative à TEXTOUT_P pour ce paramètre celle-ci renvoie une erreur.
C'est la raison pour laquelle je voulais une liste pout atextout.


Hello komame

The problem I see with the 10th parameter is the following, we need to provide a value for 'f' (background colour) by default to tell atextout that there is no background (probably a negative value) but if we provide a negative value to TEXTOUT_P for this parameter it returns an error.
This is why I wanted a list for atextout.

(04-14-2024 06:18 AM)Tyann Wrote: [ -> ]The problem I see with the 10th parameter is the following, we need to provide a value for 'f' (background colour) by default to tell atextout that there is no background (probably a negative value) but if we provide a negative value to TEXTOUT_P for this parameter it returns an error.
This is why I wanted a list for atextout.

Tyann,

I'm aware of that, and I've taken it into consideration, but this problem is very easy to solve (actually, this is not a problem at all). Let's assume that the default background value, to prevent it from appearing (no color), is set to -1. ATEXTOUT_P should return an error if someone provides the value -1 for the "f" parameter because that's not a valid color. However, note that -1 will never be passed directly into ATEXTOUT_P because it's a default value that is substituted only when ATEXTOUT_P has only 8 parameters. So, when 8 parameters are recognized, -1 will be substituted for the background color. To implement this, it's enough to add one IF condition in ATEXOUT_P, which will report an error if someone provides -1 as the background color. However, -1 inside atextout will be identified as no background. This way, you can achieve a fixed number of parameters when calling atextout. Additionally, it will be possible to have a single common call to atextout for all cases. This is because once the default variable values are established, the number of parameters will always be the same, allowing atextout to be called directly by substituting values (without using EXPR), and additionally, it will eliminate the need to convert the list into variables, which is currently done at the beginning of atextout. All this requires only a few lines of code modification.

However, if we assume that both the text color and the background color have alpha channels included (in the format {color,alpha}), it would require an additional buffer (or an increase in the size of the current one), but it is also feasible and we could consider such an extension. This would require a slightly more advanced approach, but it is possible to do. In that case, we would still be left with 9 parameters. What do you think about this?

Ha si je comprends bien nous mettons la transparence en paramètre après la couleur du texte et avant les attributs ?
Et si nous ne voulons pas de transparence nous mettons 0 ou 255 du coup je sais plus
laquelle si nous mettons des attributs etc... ?

J'avais boguer sur la transparence en paramètre 10, désolé.


Ha If I understand correctly, we set the transparency parameter after the text colour and before the attributes?
And if we don't want transparency we set it to 0 or 255, so I can't remember which.
Which one if we set attributes etc?

I had a bug with transparency in parameter 10, sorry.

Avez-vous en tête quelque chose de ce genre ?
J'ai tester tous les cas de figure je crois, cela fonctionne.

Do you have something like this in mind?
I've tested every possible scenario, I think, and it works.



EDIT:
Voici une version plus compléte avec le test sur la couleur de fond :

Here is a more complete version with the background color test:

(04-14-2024 01:22 PM)Tyann Wrote: [ -> ]Do you have something like this in mind?
[...]

When it comes to the version with 10 parameters, you're pretty close! However, it can be done even more compactly.
Here's my version:


Maybe it's worth trying to achieve a version with different alpha values for text and background (so ultimately 9 parameters and both colors in the {color,alpha} format)?

Quote:1)For the 10-parameter version (alpha at the end),

2) Maybe it's worth trying to achieve a version with different alpha values for text and background (so ultimately 9 parameters and both colors in the {color,alpha} format)?

1) Non, alpha ne peut pas être en dernier ?

2) Nous aurons donc dans ce cas à vérifier si deux des paramètres sont sous forme de réels ou de listes à 2 éléments, et décider en conséquence ?

1) Can't alpha be last ?

2) In this case, we will have to check whether two of the parameters are in the form of reals or 2-element lists, and decide accordingly?

(04-14-2024 08:06 PM)Tyann Wrote: [ -> ]1) Can't alpha be last ?

I corrected my post a few minutes before your response. Alpha (t) is the 8th parameter, and the last one is the background color (f). My mistake in the description.

(04-14-2024 08:06 PM)Tyann Wrote: [ -> ]2) In this case, we will have to check whether two of the parameters are in the form of reals or 2-element lists, and decide accordingly?

Something like this, but I haven't thought about it yet. Probably we'll also need to consider the possibility of specifying the color using the RGB function, and then the oldest 8 bits of the 32-bit value will be the alpha value.