[2.50.3] DrawInteger() Graphical Error when Setting scale arg.

When using 2.50.3/2.50.x branch build code of any sort, calling DrawInteger and setting scale to 16 the bitmap of the integer is improperly truncated. What appears to be happening, is that instead of scaling the font to the specified size, the full bitmap overlay is truncated to the size in pixels.

Here is a side-by-side of 2.50.2, and 2.50.3 running the same code:

Code:

---

import "std.zh"

int p=2000;

global script a{
        void run(){
                while(true){
                        Screen->DrawInteger(3,50,50,1,0x01, -1, 16, 16, p, 0, 128);
                        Waitdraw(); Waitframe();
                }
        }
}

---

http://timelord.insomnia247.nl/zc/zc_dev/drawintbug.png

I see only one change from 2.50.1, and it should not be causing this. What in the name of heaven???!

Unless maybe something changed in GetSmallTextureBitmap?

I see the issue. int width and int height are set up the same way as draw character, and they only expect a single digit value for the actual integer. It works when this is true, but not otherwise.

This was also a bug in 2.50.2, and probably earlier.

Here is my fix for it, if you wish to review, modify, or integrate it:

Code:

---


void do_drawintr(BITMAP *bmp, int *sdci, int xoffset, int yoffset)
{
    //sdci[1]=layer
    //sdci[2]=x
    //sdci[3]=y
    //sdci[4]=font
    //sdci[5]=color
    //sdci[6]=bg color
    //sdci[7]=strech x (width)
    //sdci[8]=stretch y (height)
    //sdci[9]=integer
    //sdci[10]=num decimal places
    //sdci[11]=opacity
   
    int x=sdci[2]/10000;
    int y=sdci[3]/10000;
    int font_index=sdci[4]/10000;
    int color=sdci[5]/10000;
    int bg_color=sdci[6]/10000; //-1 = transparent
    int w=sdci[7]/10000;
    int h=sdci[8]/10000;
    float number=static_cast<float>(sdci[9])/10000.0f;
    int decplace=sdci[10]/10000;
    int opacity=sdci[11]/10000;
   
    //safe check
    if(bg_color < -1) bg_color = -1;
   
    if(w>512) w=512; //w=vbound(w,0,512);
   
    if(h>512) h=512; //h=vbound(h,0,512);
   
    char numbuf[15];
   
    switch(decplace)
    {
    default:
    case 0:
        sprintf(numbuf,"%d",int(number));
        break;
       
    case 1:
        sprintf(numbuf,"%.01f",number);
        break;
       
    case 2:
        sprintf(numbuf,"%.02f",number);
        break;
       
    case 3:
        sprintf(numbuf,"%.03f",number);
        break;
       
    case 4:
        sprintf(numbuf,"%.04f",number);
        break;
    }
   
    //FONT* font=get_zc_font(sdci[4]/10000);
   
    if(w>0&&h>0)//stretch
    {
        BITMAP *pbmp = create_sub_bitmap(prim_bmp, 0, 0, text_length(get_zc_font(font_index), numbuf)+1, text_height(get_zc_font(font_index)));
        clear_bitmap(pbmp);
            //script_drawing_commands.GetSmallTextureBitmap(1,1);
       
        if(opacity < 128)
        {
            if(w>128||h>128)
            {
                clear_bitmap(prim_bmp);
               
                textout_ex(pbmp, get_zc_font(font_index), numbuf, 0, 0, color, bg_color);
                stretch_sprite(prim_bmp, pbmp, 0, 0, w, h);
                draw_trans_sprite(bmp, prim_bmp, x+xoffset, y+yoffset);
            }
            else
            {
                BITMAP *pbmp2 = create_sub_bitmap(prim_bmp,0,0,w,h);
                clear_bitmap(pbmp2);
               
                textout_ex(pbmp, get_zc_font(font_index), numbuf, 0, 0, color, bg_color);
                stretch_sprite(pbmp2, pbmp, 0, 0, w, h);
                draw_trans_sprite(bmp, pbmp2, x+xoffset, y+yoffset);
               
                destroy_bitmap(pbmp2);
            }
        }
        else // no opacity
        {
            textout_ex(pbmp, get_zc_font(font_index), numbuf, 0, 0, color, bg_color);
            stretch_sprite(bmp, pbmp, x+xoffset, y+yoffset, w, h);
        }
       
    }
    else //no stretch
    {
        if(opacity < 128)
        {
            FONT* font = get_zc_font(font_index);
            BITMAP *pbmp = create_sub_bitmap(prim_bmp, 0, 0, text_length(font, numbuf), text_height(font));
            clear_bitmap(pbmp);
           
            textout_ex(pbmp, font, numbuf, 0, 0, color, bg_color);
            draw_trans_sprite(bmp, pbmp, x+xoffset, y+yoffset);
           
            destroy_bitmap(pbmp);
        }
        else // no opacity
        {
            textout_ex(bmp, get_zc_font(font_index), numbuf, x+xoffset, y+yoffset, color, bg_color);
        }
    }
}

---

What is the purpose of the check w>128 || h>128? Why not write directly to prim_bmp in all cases?

Quote:

---

Originally Posted by DarkDragon

What is the purpose of the check w>128 || h>128? Why not write directly to prim_bmp in all cases?

---

I'm not sure. That has always been there, and was never commented. I expected it was some safety check, and I didn't touch it because of that. It could be related to the zcfont sizes, or something, or it could be a copy/paste carryover from draw_character.

The weird part is that this has been undocumented for so long. Surely someone bust have tried to draw a number with more than one digit, that had the size args set. I don;t know if 2.50.0 did this, and I mean to check, as if it does not, then we need to look back at the function as it was then, and see what happened.
I may have run into this in the past, and forgotten...not sure. I usually use string.zh itoa() to convert numbers into text, and plug them into strings that I render with drawstring, or similar.

I'm rather certain that these were more recently rewritten by Gleeok anyway, and that we will need to use those that are designed to interact with the new bitmap buffers. I know that he reworked draw_string.

I fixed this because a user brought it to my attention, it was silly, and I could clearly see the problem. I didn't want to marry it in the process though.and I didn't try to change its behaviour, other than making it draw properly. Setting the initial size to the precise size of the font, clipped it, hence the +1, and that tells me that we aren't reading the text buffer properly, or that our routines to clip the decimals are wrong.

Quote:

---

Originally Posted by ZoriaRPG

I'm not sure. That has always been there, and was never commented. I expected it was some safety check, and I didn't touch it because of that. It could be related to the zcfont sizes, or something, or it could be a copy/paste carryover from draw_character.

The weird part is that this has been undocumented for so long. Surely someone bust have tried to draw a number with more than one digit, that had the size args set. I don;t know if 2.50.0 did this, and I mean to check, as if it does not, then we need to look back at the function as it was then, and see what happened.
I may have run into this in the past, and forgotten...not sure. I usually use string.zh itoa() to convert numbers into text, and plug them into strings that I render with drawstring, or similar.

I'm rather certain that these were more recently rewritten by Gleeok anyway, and that we will need to use those that are designed to interact with the new bitmap buffers. I know that he reworked draw_string.

I fixed this because a user brought it to my attention, it was silly, and I could clearly see the problem. I didn't want to marry it in the process though.and I didn't try to change its behaviour, other than making it draw properly. Setting the initial size to the precise size of the font, clipped it, hence the +1, and that tells me that we aren't reading the text buffer properly, or that our routines to clip the decimals are wrong.

---

Ok. I'm absolutely hammered at work for the next week and a half, but I will investigate and incorporate this before too long.

Looks like some clean-up couldn't hurt. I honestly don't remember any of that, but I'm guessing it was just never finished or impossible to get right at all with allegro which is why all the text rendering functions look like hacks. Software rendering with allegro is a PITA because you don't want to allocate and clear random memory every function call, and there are no useful font routines other than draw it on some BMP.

Don't know why the bug suddenly popped up in 2.50.3 but I think those constraints could be calculated better than just '128'. :P

Quote:

---

Originally Posted by DarkDragon

Ok. I'm absolutely hammered at work for the next week and a half, but I will investigate and incorporate this before too long.

---

Probably my fault anyway; I'll look at it.

Quote:

---

Originally Posted by Gleeok

Looks like some clean-up couldn't hurt. I honestly don't remember any of that, but I'm guessing it was just never finished or impossible to get right at all with allegro which is why all the text rendering functions look like hacks. Software rendering with allegro is a PITA because you don't want to allocate and clear random memory every function call, and there are no useful font routines other than draw it on some BMP.

Don't know why the bug suddenly popped up in 2.50.3 but I think those constraints could be calculated better than just '128'. :P

Probably my fault anyway; I'll look at it.

---

I checked it back to 2.50.1. I think it may have been there for a very long time, and went unnoticed, because no-one reported it until now.

I'm probably going to add DrawStringEx() at some point, so don;t worry overmuch about it. We can itoa the numbers internally, and allow DrawStringEx() to handle it all at one time, if we want. I would do the same with drawinteger before calculating the font size in pixels, because something weird is happening with it as-is.

Hmm...Allegro 4 has no font scaling, at all. We might want to consider implementing alfont.