[motherhamster] SVN: james/243 Display dirt using a png sprite.

[Bob the Hamster]

On Wed, Apr 11, 2007 at 11:39:13AM -0700, Brian Fisher wrote:
> On 4/11/07, Bob the Hamster <Bob at hamsterrepublic.com> wrote:
> > Is that the blend_mode member of the ImageAsset? I tried all three of
> > alpha_blend, additive, and lighting. That isn't it, is it?
> >
> No, I don't have the code in front of my, but there is some opengl
> call that is like "polygon_smooth" or something like that - if set to
> true, it antialiases edges, which can mess up tiling if things don't
> tile exactly on pixel boundries
> 
> It's a tradeoff thing - if your art goes all the way to the edge, and
> you are either always tiling on pixel boundries, or you never tile,
> the antiliasing can be nice.
> 
> If you are tiling on non-pixel boundries, and all non-tiling art
> doesn't go all the way to the edge, then antialiasing is a bad thing

The thing is, I am pretty sure I am correctly tiling on pixel 
boundaries. My tile image is exactly 16x16 and exactly 40x30 of them fit 
in a 640x480 screen.

> ...another possible cause of something like this could be when art is
> scaled, and the video card filters the edges dumbly (it may filter a
> colored opaque pixel with a transparent black one and get a half-black
> half-transparent pixel, instead of getting a full colored
> half-transparent pixel) but if you can fix things by increasing the
> scale or overlapping a bit, then this is definitely not the problem.
> 
> Finally, careful tiling with unscaled art that is well positioned on
> pixel boundaries is good in all cases, so maybe I just have some
> sloppy positioning code...

I noticed that when I was drawing 16x16 brown rectangles with 
display.rect() they were tiling together perfectly.

And now that I think about it, I was getting some odd problems with 
drawing an unflled box with display.line() I ended up moving two of my 
box corners in by one pixel to slant the  lines, which then at least 
made all sides of the box visible.

> > By the way, lighting sounds interesting. How is it intended to be used?
> >
> The alpha of each source pixel will say how much of the destination
> pixel color is retained, while the rgb color of the source pixel says
> how much of the rgb of the destination pixel color should be added in.
> It's only interesting when it's rendered on top of existing stuff
> 
> So like say you have some image that is fully opaque black, with an
> opaque red fuzzy circle in the middle. The fully opaque black means
> leave the pixels alone, while the opaque red means leave the existing
> color (opaque) but add in some multiple of the red. So if you render
> that with lighting blend, it would be like a red spotlight being shone
> - where red things pick up the red light.

Interesting!

> Now say you've got some image that is fully transparent black, with an
> opaque black circle in the center. Where it is fully transparent
> black, it means remove all the original color and add nothing in (like
> fully shadowed). Where it is opaque black, it means retain some
> percentage of the original color (based on the alpha) and add nothing
> back in (the black). So it's basically like turning off the lights,
> but leaving a white spotlight on.

Would the light image have to be bigger than the screen?

> Makes sense?

Mostly!

---
James