I was making a game (I don't want to spoil it) but I'm sspring a 16x16 sprite on to the screen;
But when it's drawn to the screen it shows up as:
It has weird brown and blue pixels in it's gobbler...
But if I replace one of the pixels;
It dosen't anymore...?
I'm on ver 0.2.0 so maybe that's it? If anyone knows why this is happening please tell me, thanks!
Oh yea; here's the code as well
-- talking iftalk=false smoothslidein=0 function coversation() taint(0) uitoggle=false if (smoothslidein<18) smoothslidein+=.5 nicebox(camx,camy,128+camx,128+camy,▥,1,0) --sspr(0,96,16,16, camx,96+camy, 32,32 ) sspr(talkinfo.id*16,96,16,16, 96+camx,96+camy, 32,32 ) --taint(1) end |
I ran into this problem again, It happened after I moved stuff around on the sprite sheet and you can see it here with the weird gray/tea pixels in the eyes, Has this been fixed in newer versions? because it's driving me crazy and I hate it. here's the cart so you can see it for your self (all though maybe it's fixed in newer vers?)
this seems like a bug...I didn't think sspr would ever add colors when scaling...that doesn't make sense to me
EDIT: hmmm I actually cannot reproduce this with the cart you uploaded. I can draw the sprite scaled to 32x32 and the colors look correct
load #pigsnortz sspr(48,96, 16,16, 0,0, 32,32) sspr(48,96, 16,16, 32,0, 16,16) |
Are you running the latest version? v0.2.0i ?
I'm on ver 0.2.0d and the problem with the eyes happened because I move sprites around the sheet like this;
(before)
(after)
I'm going to try to update to see if that works
I updated to 0.2.0i and the weird gray/tea pixels in the eyes are still there,
Here's the sprite sheet where the eyes are drawn from:
Here's the code that draws the eyes:
-- eyes sspr(s*4,108+c*4,4,4,x,y ,8,8 ,f,false)
I don't get it
PS: in the reply you sent me your sspr call sprite is missing red in his gobler, in the cart I uploaded that isen't the case?
I made the background of the eyes orange instead of black and then
palt orange to true,
draw the eyes,
and the palt orange to false.
This fixed the problem but I still don't understand why having the background be black in the first place would be a problem, and why it would just show up out of seemingly out of nowhere when I change the sprite sheet.., but IDK.
If this is a bug please fix it for a offical release or maybe I'm just a idoit and this is intended? IDK
This is a bug in your code, not in Pico-8. In the mapplacement function, where you're doing a bunch of mset() calls, you need to change the line to this:
for i2=0,31 do --in your code, it's this: for i2=0,63 do |
The graphics data for tabs 3 and 4 is stored in the lower half of the map's memory. Because of this, mget and mset work with that 0-63 range, but they end up changing sprite data instead of map tiles, with bizarre results. Map animations on art become weird colors, because the data just happens to be stored as the same binary number.
I found the culprit line of code by searching for anything messing with pal() or set() functions, and just deleting whole for loops until I found the one that was causing the problem. You're using a lot of interesting and weird graphics effects, so bugs like this one will probably show up again. Please try to look over your own code before blaming the built-in functions, most of them have been tested for years and bugs like this shouldn't be happening there. tline() is the only new function that had some recent weirdness, everything else should be working as intended.
I had the same problem while testing tline() yesterday.
Notice that I use ctrl+click to swap c1 to c2, but some pixels are not changed.
I used a lot of commands and tools while doing it the first time (1 and 2 to navigate between colors, V and to flip, Ctrl+click to swap colors, ctrl+C, ctrl+V, copied sprites to map). I didn't use the new shape tool...
I tried to reproduce the bug with many combinations of the mentioned commands and tools with no success.
Here is a Ctlr+Y of the steps that introduced the bug (no bugs prior to that).
Notice that the grey pixels that only appear when running the cart aren't on the same pixels I drew, but 1 pixel to the right.
This is all I found.
@BoneVolt, your problem is very different, so you should post a separate bug issue. @SmellyFishstiks can fix their bug by changing one line of lua code -- it was due to msetting graphics data.
I've tested and confirmed that my patch works on 0.2.0e for them, at the very least. But I'd be very confused if tline bugs are also in sspr, in both 0.2.0d and 0.2.0i, but not 0.2.0e.
@shy That was it I’m pretty sure, just was a little reckless with changing map values where I shouldn’t of. Thanks for looking into it and helping me. That makes a lot more since than sspr breaking because of somthing else.
Thanks again for looking at my amateur cart work and helping
You're welcome! It looks like you're adding a lot to this game for a so-called amateur cart, so best of luck getting all of the effects and animations to play nice with each other. :)
[Please log in to post a comment]
