User Tag List

Results 1 to 7 of 7

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

  1. #1
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%

    [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();
    		}
    	}
    }


    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?

  2. #2
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    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);
            }
        }
    }

  3. #3
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    What is the purpose of the check w>128 || h>128? Why not write directly to prim_bmp in all cases?
    Last edited by ZoriaRPG; 01-11-2017 at 03:31 PM.

  4. #4
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by DarkDragon View Post
    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.

  5. #5
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%
    Quote Originally Posted by ZoriaRPG View Post
    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.

  6. #6
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    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'.

    Quote Originally Posted by DarkDragon View Post
    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.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  7. #7
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    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'.

    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.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social