Elysian Shadows

Why don't you instead just use transparency and use SDL Image and use IMG_Load?

LeonBlade wrote:Why don't you instead just use transparency and use SDL Image and use IMG_Load?

FUCKIN' LIBRARIES, HOW DO THEY WORK?


I guess it has something to do with speed. Although I would think that reading in an image, removing the keyed color, and then displaying takes more time than just loading an image and displaying it without removing keyed colors (alpha pixels) unless there's some sort of surface merging going on (probably is).

xiphirx wrote:

LeonBlade wrote:Why don't you instead just use transparency and use SDL Image and use IMG_Load?

FUCKIN' LIBRARIES, HOW DO THEY WORK?


I guess it has something to do with speed. Although I would think that reading in an image, removing the keyed color, and then displaying takes more time than just loading an image and displaying it without removing keyed colors (alpha pixels) unless there's some sort of surface merging going on (probably is).

I don't even...

I just use IMG_Load myself... too much hassle with the whole color key bull shit.

Why not just load it as a texture with alpha support? That is afaik not slow as hell. And 3D isn't that much harder.

omg, you guys have problems I did not even know about

PNG + SFML = No artifacts + Hardware Acceleration

K-Bal wrote:omg, you guys have problems I did not even know about

PNG + SFML = No artifacts + Hardware Acceleration

lol. I just use SDL for image loading & padding, then render with OpenGL, but I guess I'm okay with a fanboy =P

Loading a texture with alpha support is absolutely not "slow as hell." I'm not sure how exactly SDL handles it (without hardware acceleration). I will have to look into whether it's emulating the transparency or using the hardware, but it's a waaaaaaaaaay cleaner solution than color masking. That shit is soooo outdated.

In the hardware accelerated world, you never see that. Textures are just saved with transparency, and it's way less hassle.

So far as the hardware is concerned, it's merely an additional operation that involves a few lerps or simple accumulation depending on the blend mode. The only thing you SHOULD be sacrificing here is the 1 to 32 bits of space (depending on image format) to store the alpha. You DO take a small hit from even enabling alpha blending for hardware accelerated API's but it's nothing to shake a stick at.

If its ridiculously slow, then SDL would be emulating it in software in which you must do this for every pixel that passes any scissoring or depth/backface culling, for every primitive for every pass and it would involve a read from the destination buffer. In this case...absolutely yes, it would be just retardedly slow without any optimization.

LeonBlade wrote:Why don't you instead just use transparency and use SDL Image and use IMG_Load?

This... this is what I suggested...

qpHalcy0n wrote:If its ridiculously slow, then SDL would be emulating it in software in which you must do this for every pixel that passes any scissoring or depth/backface culling, for every primitive for every pass and it would involve a read from the destination buffer. In this case...absolutely yes, it would be just retardedly slow without any optimization.

Yeah, that's along the lines of what I was thinking.

If I recall correctly (from my teenage days of dicking with SDL), one of the results returned from the SDL hardware checks is alpha blending support. I'm fairly certain it is hardware accelerated--but I'm pretty sure that if this is not available, SDL definitely emulates.

...In this day and age though... if somebody's hardware doesn't support alpha blending, they can deal with shitty CPU emulation, imo.