Typically coercion to integer is a truncation, so minISphere's behavior here is indeed a bug.  Easy enough to fix, but yeah, just floor the values first for now.

Hmm more tests show that miniSphere rounds up even if given 0.1.

So looks like Sphere 1.5 floors pixel coordinates and miniSphere ceils them.

@Fat Cerberus if relevant for you - I tested with the chakracore version of miniSphere, so if this is a bug it has persisted into your new jsal.

@Miscreant suggested alternate triangles code for you:

Code: [Select]

   var t_coords = [86, 269];

  Triangle(t_coords[0] + 47, t_coords[1],     t_coords[0],      t_coords[1] + 48, t_coords[0] + 96, t_coords[1] + 48, White);
  Triangle(t_coords[0] + 47, t_coords[1] + 1, t_coords[0] + 2,  t_coords[1] + 47, t_coords[0] + 94, t_coords[1] + 47, Black);
  Triangle(t_coords[0] + 47, t_coords[1] + 8, t_coords[0] + 12, t_coords[1] + 44, t_coords[0] + 84, t_coords[1] + 44, White);
  Triangle(t_coords[0] + 47, t_coords[1] + 9, t_coords[0] + 14, t_coords[1] + 43, t_coords[0] + 82, t_coords[1] + 43, Black);

  if (LVL1C === true){TSE.blit(t_coords[0] + 32, t_coords[1] + 11);}
  if (LVL2C === true){TSW.blit(t_coords[0] + 48, t_coords[1] + 11);}
  if (LVL3C === true){TSE.blit(t_coords[0] + 16, t_coords[1] + 27);}
  if (LVL4C === true){TNW.blit(t_coords[0] + 32, t_coords[1] + 27);}
  if (LVL5C === true){TSE.blit(t_coords[0] + 32, t_coords[1] + 27);}
  if (LVL6C === true){TNW.blit(t_coords[0] + 48, t_coords[1] + 27);}
  if (LVL7C === true){TSE.blit(t_coords[0] + 48, t_coords[1] + 27);}
  if (LVL8C === true){TSW.blit(t_coords[0] + 64, t_coords[1] + 27);}

changes:
1. I've floored the coordinates
2. I've put the coordinates into an array so you only have one variable to remember and update
3. as I assume the dimensions don't change I've used just one coordinate pair then added some known offsets in the drawing function calls.

I'll give that a try. Trying to get these to line up properly has been such a gorram pain.

I'll give that a try. Trying to get these to line up properly has been such a gorram pain.

If you set complex graphical objects out with one set of coordinates and a lot of offsets it's much easier to line things up.

The one time I'd used variables for the offsets is if I wanted the object to be able to change size, but even then it would probably be only 2 variable offsets (width and height).

The other time I'd need more variables for an arrangement like the above would be if I wanted the triangles to slide onto the screen from different sides or something fancy like that - but I assume you just keep them as a unit all the time?

It does slide...

It does slide...

Can't see what you mean from that image - seems to be a still frame?

And when you say it slides do you mean each triangle slides separately, or the set slides together?

What I wrote above was based on the assumption that the set would slide together.

I misunderstood. Obviously, the triforce pieces only appear upon level completion but yes it all scrolls as a unit.

@Miscreant Your animated gifs haven't been playing recently, they just show up as still images.  Not sure if something broke with the forums or what...

oh gorram it, guess i need to find a different way to animate my gifs.

I misunderstood. Obviously, the triforce pieces only appear upon level completion but yes it all scrolls as a unit.

Then with the above code all you'd need to do is update t_coords[0] and t_coords[1] to move it around. functionally it's the same as what you already had just with a lot less variables and with the numbers rounded down so it will draw the same way on minisphere as it was on sphere 1.5.

So it turns out that nothing's wrong with miniSphere's handling of integer coordinates after all, they are indeed rounded down internally.

In the end, nothing I did to the Triangle() function could coax it to render the triangles the same way.  Interestingly, Sphere 1.5 with the OpenGL plugin is broken in a similar way, see screenshot attached.  I think this one is just down to differences between software rendering (Sphere with the standard32 plugin) vs. hardware rendering.  It isn't something I can fix

@Miscreant Your animated gifs haven't been playing recently, they just show up as still images.  Not sure if something broke with the forums or what...

I'm not sure what the issue is, I've check the gifs on 3 different platforms and they all display properly. I don't really know that much about ElkArte, could it possibly be something with the forums??

So it turns out that nothing's wrong with miniSphere's handling of integer coordinates after all, they are indeed rounded down internally.

In the end, nothing I did to the Triangle() function could coax it to render the triangles the same way.  Interestingly, Sphere 1.5 with the OpenGL plugin is broken in a similar way, see screenshot attached.  I think this one is just down to differences between software rendering (Sphere with the standard32 plugin) vs. hardware rendering.  It isn't something I can fix

That's bizarre - simply rounding down before calling the draw functions got the right result for me.

Similarly rounding up before calling them resulted in repeating what miniSphere was already drawing.

So it turns out that nothing's wrong with miniSphere's handling of integer coordinates after all, they are indeed rounded down internally.

In the end, nothing I did to the Triangle() function could coax it to render the triangles the same way.  Interestingly, Sphere 1.5 with the OpenGL plugin is broken in a similar way, see screenshot attached.  I think this one is just down to differences between software rendering (Sphere with the standard32 plugin) vs. hardware rendering.  It isn't something I can fix

That's bizarre - simply rounding down before calling the draw functions got the right result for me.

Similarly rounding up before calling them resulted in repeating what miniSphere was already drawing.

If it's software vs hardware rendering, maybe I should just turn the outling triangles into an image and blit that to the screen instead. That would keep everything aligned properly and shouldn't display those errors as it is drawn.