Issue with draw_sprite_part.

D

deciduous

Guest
Hello all!

I'm currently working on an android project that involves some use of the draw_sprite_part method. It's all working really great on my computer, but I have a small annoying issue when I run it on my android tablet or phone.

Some Context: The game involves usable inventory items that charge over time, and I'm using draw_sprite_part to draw the selected inventory item sprite over the character. In order to display the charging effect I draw the first sprite with 0.25 alpha and the other with a value of 1. Over time the 0.25 alpha image shrinks and the other grows until it's fully charged and you have a full, non-transparent sprite hovering over your player.

The Problem: When this is run on my android device I get a strange effect where, below the inventory sprite and over the player object, is a piece of a totally separate instance sprite that disappears at the same rate as the inventory sprite charges. Again, this is a non-issue on my PC.

Here are images of the issue in game:

PC version doing just great.
castle_defense_pc.JPG

Android version struggling with life.
castle_defense_android.png

Here is the code in which I draw the sprites:
Code:
draw_self();

if(current_item == "rock")
{
    if(!charged)
    {
        current_cool = alarm[0];
        image_mult = current_cool / cooldowns["rock"];
        charge_line = sprite_get_height(spr_rock) * image_mult;

        draw_set_alpha(0.25);
        draw_sprite_part(spr_rock, 1, 0, 0, sprite_get_width(spr_rock),
            charge_line, x - sprite_get_width(spr_rock) / 2,
            y - sprite_height - sprite_get_height(spr_rock) / 2);
  
        draw_set_alpha(1);
        draw_sprite_part(spr_rock, 1, 0, charge_line, sprite_get_width(spr_rock),
            sprite_get_height(spr_rock), x - sprite_get_width(spr_rock) / 2,
            y - sprite_height - sprite_get_height(spr_rock) / 2 + charge_line);
    }
    else
    {
        draw_set_alpha(1);
        draw_sprite(spr_rock, 1, x, y - sprite_height);
    }
}
else if(current_item == "bear trap")
{
    if(!charged)
    {
        current_cool = alarm[0];
        image_mult = current_cool / cooldowns["bear trap"];
        charge_line = sprite_get_height(spr_bear_trap) * image_mult;

        draw_set_alpha(0.25);
        draw_sprite_part(spr_bear_trap, 1, 0, 0, sprite_get_width(spr_bear_trap),
            charge_line, x - sprite_get_width(spr_bear_trap) / 2,
            y - sprite_height - sprite_get_height(spr_bear_trap) / 2);
  
        draw_set_alpha(1);
        draw_sprite_part(spr_bear_trap, 1, 0, charge_line, sprite_get_width(spr_bear_trap),
            sprite_get_height(spr_bear_trap), x - sprite_get_width(spr_bear_trap) / 2,
            y - sprite_height - sprite_get_height(spr_bear_trap) / 2 + charge_line);
    }
    else
    {
        draw_set_alpha(1);
        draw_sprite(spr_bear_trap, 1, x, y - sprite_height);
    }
}

draw_set_alpha(1);
I have tried cleaning the asset cache, restarting GM, reconnecting my tablet, and testing on a different device. Nothing has working so far.

Has anyone had an issue that sounds at all like this? Any help would be appreciated.

Thanks!
 
Last edited by a moderator:

Phil Strahl

Member
In the texture group settings of the Game Settings dialog, activate "No cropping" and see if it resolves your issue...
 
D

deciduous

Guest
@Phil Strahl, thanks much for the response!

Activated "No Cropping" and got an unexpected result. Whereas before only when the "rock" item was selected I was getting the cropping issue, I am now getting basically the same issue only when the "bear trap" item is selected.

Settings:
castle_defense_image_settings.JPG

In game image:
Screenshot_20160712-150548.png

Do you have any more suggestions?

Thanks again!

UPDATE:
In the Global Game Settings under the Android tab I changed the Texture Pages size to 2048x2048, and the issue is currently (probably temporarily) solved. However, looking at the current texture page I see that there are no longer images under the ones that had issues, and I'm worried that as I add more sprites this will fill up again and produce the same problem.
 
Last edited by a moderator:

Phil Strahl

Member
I see. So it definitely got to do with the textures. Have you tried putting only the objects you cut with draw_sprite_part on their own texture page and just set that one to "No Cropping"?
 

FrostyCat

Redemption Seeker
Is this a typo or the actual code?
Code:
image_mult = current_cool / cooldowns["rock"];
Arrays don't have string indexes, maps do.
 
D

deciduous

Guest
@FrostyCat, good catch. They've been changed to integer values, but interestingly enough even with string indexes the array behaved the same way. Thanks for the tip!

@Phil Strahl, okay now I'm really confused. I put each sprite that is drawn this way onto its own texture page, but now the "rock" sprite just has a solid vertical line being drawn below it in the same way. I tried setting it to a different empty texture page and got the same problem. I tried just putting the "rock" and "bear trap" together on 1 page, but the "bear trap" accosted the "rock"... AND as an added bonus the solid vertical line under the "rock" is included on the PC version. I'm at a bit of a loss.

Individual Texture Pages:
Screenshot_20160712-154155.png


"rock" and "bear trap" grouped together:
Screenshot_20160712-154415.png
 

Phil Strahl

Member
Ah, I see. The line is there because the black pixels that touch the lower boundary in your sprite image get repeated. They disappear if nothing touches borders of the image. Have a border of 1 transparent pixel around it.
 
D

deciduous

Guest
@Phil Strahl you solved it! Thank you so much. Do you mind explaining why that is an issue? I've never had a problem like that before.
 
Last edited by a moderator:

Phil Strahl

Member
@Phil Strahl you solved it! Thanks you so much. Do you mind explaining why that is an issue? I've never had a problem like that before.
I don't know exactly why this happens, but it seems that the pixels on the bounding edges of sprite images get doubled when put on a texture page, probably to avoid "cut-off"-looking images when they are drawn scaled up and bilinearly filtered (see image). At least, that's my guess.
 

Attachments

Top