Status: Fixed version of ONML has been uploaded: http://www.neolemmix.com/old/neolemmix/OhNoMoreLemmings.nxp
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Show posts MenuQuote from: SimonScreen starting position will be determined automatically. I will drop support for setting a screen starting position per level. That wouldn't give a consistent view anyway, because the game can run in arbitrary resolutions.
Quote from: SimonThat wouldn't give a consistent view anyway, because the game can run in arbitrary resolutions.
Quote<geoo> SimonN: do you actually support semi-transparent graphics right now?
<SimonN> geoo: not in the mask in any way
<SimonN> eventually, I want to beef up terrain tiles on loading, mask in RAM, graphic in VRAM. That makes them faster to draw (currently must get crap back out of VRAM)
<SimonN> when I make that, maybe instead of mask of bool, it can be mask of unsigned byte
<SimonN> and store alpha
<namida42> alpha blending is something i want to support eventually too, but i'm very undecided on how it should work in terms of solidity
<geoo> well the logical mask should be bool, but for drawing alpha can be convenient. Especially for objects it'd get rid of antialiasing issues
<namida42> graphic set format (although that's to be replaced eventually anyway) has supported storing alpha data since the current format was introduced, the graphic set tool also supports loading / saving images with alpha data, but currently NeoLemmix itself does not support anything other than 0 or 255
<SimonN> do you still want the threshold, where the alpha is combined in some ways I forgot, and only afterwards soliditiy is decided?
<geoo> Generate the level bitmap, and anything that has alpha < 0x80 (say) gets turned to alpha = 0 and non-solid, to ensure it's easy to distinguish between solid and non-solid
<geoo> Well I think it's important that there is no ambiguity between what's solid and what isn't
<geoo> but alpha blending is useful for making stuff look nice, and graphic set designers don't have to worry about what color to alias against
<namida42> indeed. this is something i've found to be a problem in designing all graphic sets since RGB color support was implemented; antialiasing against black works well in most cases.... until overlap between pieces occurs
<namida42> this really is something i should sort out before designing any more graphic sets, i think
<SimonN> geoo: do you know by rote how alpha combines on additive blit?
<SimonN> not additive, overwriting
<SimonN> and what properties it has etc.
<geoo> not sure, intuitively I'd say something like alpha * [new pixel] + (1-alpha) * [pixel drawn onto]
<namida42> i believe that's used for simple, quick drawing; i believe there's a more complex algorithm used for nicer results
<SimonN> divided by some normalization depending on the alphas, yeah
<SimonN> the problem eventually is to decide anyway whether this should be used or not for solid
<SimonN> I'd very much like to crop all almost-transparent pixels and make them fully transp
<namida42> my initial thought would be to blend the terrain layout normally, then determine based on the overall output what is or isn't solid. perhaps (i would most likely make this a user option) erase any pixels altogether if they're below the cutoff threshold, to avoid confusion
<geoo> yeah, that's what I suggested