The Mana World Forums

I talked about this somewhere (forums or irc, can't remember) and the idea was to use alpha channel instead of pink "channel"

Elven Programmer wrote:

Pajarico wrote:

Rotonen wrote:Using the png alpha channel for tiles is too cpu intensive at least with our current client.

But we will use png alpha channel someday, right?

Yeah probably in 2009 when everyone will have 128 bit processors

I don't mean to be a dick, but 2 things:

First, though rotonen's statement may be true, insofar as your current client is concerned, the png's alpha channel is in no way intrisically slower than using a specific color as the same thing - certainly so if you use a 1-bit alpha channel, rather than an 8-bit alpha channel. In fact, if you use a 1-bit channel, it actually might be faster and easier to extract.

The most that a full alpha channel should add would be one multiply command for each pixel being copied into the unit layer - a command that dictates how much the pixel below is changed by.

Over in planet wesnoth, we use full 8-bit alpha channels in pngs, and I'll be darned but the game does run at >25fps with dozens of sprites concurrently animating - on even a measley 600mhz machine.

It's just a question of decent code - and hey - we're open-source, too, so you can look at our code and see how we do it.

For one thing, if you want decent shadows, you need that alpha composition support anyways, so it's not much of a further stretch to add full PNG support. We didn't have it in the initial versions, and actually used something either at or near black as our transparent color, but by version 0.3, we did.


It's a necessary feature for almost any decent spell effects, and for any smoke, or fog, or shadows, or ghosts, and can also be used to more cleanly define edges by hand-antialiasing them. Because we didn't have our original graphics set in this format, we had to go through the whole thing and convert it by hand. I suggest that you don't make that mistake - we paid for it, hard.



And secondly, the "bit-width" of processors really has nothing to do with speed of graphics composition, since on any decent graphics layer these days, most of the composition is actually performed by the GPU. It could, if you were having the processor do the composition manually, and were coding special instructions in assembly to treat multiple pixels as single double-long words (or whatever the highest size of the processor's width was - on a 64bit chip, it would be a 64-bit value), with special bitwise operations to modify the individual components of the pixel color value according to what the transparency dictated.

But that would be really, really hard, and I wouldn't do it that way.
------

For what it's worth, I am of the opinion that support for PNG alpha channels is an absolute necessity for your game.

Jetryl wrote:I don't mean to be a dick

Don't worry, any critic is welcome. If it makes you feel better, I don't like your avatar

Jetryl wrote:if you use a 1-bit channel, it actually might be faster and easier to extract.

I think the performance difference is in using alpha or not, using 1 or 8 should be pretty the same. (I'd like to say I'm not an alpha expert, I only read something about it when we introduced it in TMW, before that I've always ignored everything regarding alpha channel)

Jetryl wrote:we use full 8-bit alpha channels in pngs, and I'll be darned but the game does run at >25fps with dozens of sprites concurrently animating - on even a measley 600mhz machine.

It's just a question of decent code - and hey - we're open-source, too, so you can look at our code and see how we do it.

Well maybe 25 fps is enough for Wesnoth, but we'd like to have a bit more and our target is to make TMW run on very slow computers where there's no hardware acceleration. The bad thing about current TMW status is that it's a 2D game and it runs as if it was 3D requiring lot of resources. Of course is a matter of code and I think there's a lot of space for improvement. That's why we're looking for an SDL guru to help us reaching a decent framerate. (Ah the old good days when we were using Allegro and the frame rate was over 120 fps ). Looking at your code? Why not, we could give it a try.

Jetryl wrote:It's a necessary feature for almost any decent spell effects, and for any smoke, or fog, or shadows, or ghosts, and can also be used to more cleanly define edges by hand-antialiasing them. Because we didn't have our original graphics set in this format, we had to go through the whole thing and convert it by hand. I suggest that you don't make that mistake - we paid for it, hard

Ok noted down, we will discuss it in the next developers meeting.

Jetryl wrote:And secondly, the "bit-width" of processors really has nothing to do with speed of graphics composition, since on any decent graphics layer these days, most of the composition is actually performed by the GPU. It could, if you were having the processor do the composition manually, and were coding special instructions in assembly to treat multiple pixels as single double-long words (or whatever the highest size of the processor's width was - on a 64bit chip, it would be a 64-bit value), with special bitwise operations to modify the individual components of the pixel color value according to what the transparency dictated.

It was just to emphasize computer's horsepower, don't take that as written law.


Thank you for your suggestions

Elven Programmer wrote:

Jetryl wrote:It's a necessary feature for almost any decent spell effects, and for any smoke, or fog, or shadows, or ghosts, and can also be used to more cleanly define edges by hand-antialiasing them. Because we didn't have our original graphics set in this format, we had to go through the whole thing and convert it by hand. I suggest that you don't make that mistake - we paid for it, hard

Ok noted down, we will discuss it in the next developers meeting.

The client already supports alpha PNGs since quite a while, in specifically since we added that alpha-layered mouse cursor. The alpha layer is however not used for the tiles, because the tiles form most of the drawn area of the screen. Masked drawing is actually faster than using an alpha layer, in particular because there is no need for multiplying and SDL can use run length encoding on the transparent parts.

Now Jetryl is referring to GPU being used, and this would be the case for our OpenGL port. In OpenGL indeed it doesn't make much of a difference wether masked drawing or alpha layered drawing is used.

25 fps on a 600 Mhz machine in 800x600 using alpha blending is fast though. If that is in software we should really be looking into where's the difference. In any case as Elven said, we're still puzzled as to why SDL is quite a bit slower than Allegro on some systems (while on other systems it's faster...).

ElvenProgrammer wrote:

Pajarico wrote:

Rotonen wrote:Using the png alpha channel for tiles is too cpu intensive at least with our current client.

But we will use png alpha channel someday, right?

Yeah probably in 2009 when everyone will have 128 bit processors

I've got a 64bit processor with 2 cores, sums up to 128bit! Will that be enough?

OMG did you bookmark this page and put a reminder in your calendar to post this when it's 2009???

5t3v3 wrote:OMG did you bookmark this page and put a reminder in your calendar to post this when it's 2009???

Rotonen has been going over our old threads in this forum. He found what Elven said funny, linked to it on IRC, and Matt found it that way.

5t3v3 wrote:OMG did you bookmark this page and put a reminder in your calendar to post this when it's 2009???

Yes, of course!

@jaxad0127: Don't lie!

did really surprise me to see Elven trying to do some graphics and then I realize this thread is years old !
sorry for the off topic

Matt: pretty good setup you have

Everyone using 128bit processors in 2009 was a quite outrageous statement in 2005 considering that the 64bit architecture was still quite new and the 32bit architecture was standard for 15 years back. At least in desktop computing. Home gaming systems were a bit strange in this regard in the 90s.

I don't expect a new system architecture to make x86-64 obsolete before 2018 (you may necro this thread then ).