User Tag List

Results 1 to 7 of 7

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

  1. #1
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    792
    Mentioned
    71 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    3,003
    Level
    17
    vBActivity - Bars
    Lv. Percent
    74.74%
    Daily Activity
    0%
    Weekly Activity
    108.6%
    Monthly Activity
    97.06%

    [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?
    Last edited by ZoriaRPG; 01-10-2017 at 07:59 PM.


    Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
    ZScript & ZC-Related Pastebin | Quests and ZScript Repository | ZC Dev & Betas | Latest ZC 2.54 Beta | YouTube Channel
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable..

  2. #2
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    792
    Mentioned
    71 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    3,003
    Level
    17
    vBActivity - Bars
    Lv. Percent
    74.74%
    Daily Activity
    0%
    Weekly Activity
    108.6%
    Monthly Activity
    97.06%
    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);
            }
        }
    }
    Last edited by ZoriaRPG; 01-10-2017 at 09:22 PM.


    Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
    ZScript & ZC-Related Pastebin | Quests and ZScript Repository | ZC Dev & Betas | Latest ZC 2.54 Beta | YouTube Channel
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable..

  3. #3
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,119
    Mentioned
    44 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,542
    Level
    30
    vBActivity - Bars
    Lv. Percent
    49.51%
    Daily Activity
    0%
    Weekly Activity
    1.13%
    Monthly Activity
    13.41%
    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
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    792
    Mentioned
    71 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    3,003
    Level
    17
    vBActivity - Bars
    Lv. Percent
    74.74%
    Daily Activity
    0%
    Weekly Activity
    108.6%
    Monthly Activity
    97.06%
    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.


    Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
    ZScript & ZC-Related Pastebin | Quests and ZScript Repository | ZC Dev & Betas | Latest ZC 2.54 Beta | YouTube Channel
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable..

  5. #5
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,119
    Mentioned
    44 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    10,542
    Level
    30
    vBActivity - Bars
    Lv. Percent
    49.51%
    Daily Activity
    0%
    Weekly Activity
    1.13%
    Monthly Activity
    13.41%
    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
    Developer ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,626
    Mentioned
    213 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,179
    Level
    32
    vBActivity - Bars
    Lv. Percent
    40.72%
    Daily Activity
    0%
    Weekly Activity
    29.41%
    Monthly Activity
    47.25%
    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
    Mad, Mad, Author ZoriaRPG's Avatar
    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    792
    Mentioned
    71 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    3,003
    Level
    17
    vBActivity - Bars
    Lv. Percent
    74.74%
    Daily Activity
    0%
    Weekly Activity
    108.6%
    Monthly Activity
    97.06%
    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.
    Last edited by ZoriaRPG; 01-12-2017 at 08:40 AM.


    Featured Scripts & Headers: RPG.zh ( v. a0.97.1 ) ( RPG.zh Thread ) | Zelda 3 Thief's Town Treasure Chest Minigame (ffc) | Bobomb (enemy)
    ZScript & ZC-Related Pastebin | Quests and ZScript Repository | ZC Dev & Betas | Latest ZC 2.54 Beta | YouTube Channel
    All of the code that I create and publish here is free for use, modification and distribution under the GPL v2.0, or v3.0 where applicable..

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