Mix_LoadMUS_RW checks if the first two bytes of a file match the
pattern 0xFF 0xFX to determine if it is an MP3. MP3s with ID3 tags are
not detected because they have a different header (‘ID3’).
Mix_LoadMUS_RW checks if the first two bytes of a file match the
pattern 0xFF 0xFX to determine if it is an MP3. MP3s with ID3 tags are
not detected because they have a different header (‘ID3’).
A simple check for both cases would fix this, so here is a patch.
On Sat, Jul 12, 2008 at 5:13 PM, Forrest Voight <@Forrest_Voight> wrote:
Any comments?On Sun, Jul 13, 2008 at 2:02 AM, Forrest Voight <@Forrest_Voight> wrote:
On Sat, Jul 12, 2008 at 5:13 PM, Forrest Voight <@Forrest_Voight> wrote:
Mix_LoadMUS_RW checks if the first two bytes of a file match the
pattern 0xFF 0xFX to determine if it is an MP3. MP3s with ID3 tags are
not detected because they have a different header (‘ID3’).
A simple check for both cases would fix this, so here is a patch.
Is there a really good way to replace a color on a non-palettized bitmap with another bitmap (besides using a bitmap flood-fill)?
I’ve decided to try to implement something like this in Sprig’s blitter. You would specify the blitting mode (probably with a flag like SPG_REPLACE_COLORKEY), and the blitter would check the dest surface for a colorkey (sounds backwards, huh?) and replace pixels of that color with the source surface’s pixels. It’s really useful for getting some of the same functionality as palette-swapping.
You know, in the past I used a loop to go through all the pixels and test
for pixel color and replace them individually. Problem was that depending on
how I wrote the loop, it would not swap more than 3 colors per function
call. Rewrote it and finally got it working better and I limited it to 256
colors per function call. Problem was that every time I rewrote it, it would
always throw exceptions. I figured it had something to do with the real low
level code that may have been buggy or just worked in a different way than I
was expecting.
Anyways, you got me thinking of a better way to do it(or more simple for the
programmer I would think). Have another surface beneath it filled with the
destination color and set the top surface with a COLORKEY so it will be
transparent and the combined surfaces will create a surface with the swapped
color. This is similar to a trick I use in MSPaint to swap all pixels of one
color in a single image in 3 easy steps. Now making that into a function
that could swap 256(or whatever) colors in one function pass would be
possible, but most likely pretty CPU intensive. Then again my old per pixel
color swapping function was too on my old Pentium 3. I take it that this
won’t neccessarily be used for “on the fly” swapping?
I’m curious as to what exactly you are attempting to do here Could you
explain it a bit more?On Wed, Jul 16, 2008 at 4:17 PM, Jonathan Dearborn wrote:
Hey,
Is there a really good way to replace a color on a non-palettized bitmap
with another bitmap (besides using a bitmap flood-fill)?
I’ve decided to try to implement something like this in Sprig’s blitter.
You would specify the blitting mode (probably with a flag like
SPG_REPLACE_COLORKEY), and the blitter would check the dest surface for a
colorkey (sounds backwards, huh?) and replace pixels of that color with the
source surface’s pixels. It’s really useful for getting some of the same
functionality as palette-swapping.
Spiffy trick I picked up in mobile game development. Take a paletted
(indexed color) PNG file. Do NOT convert it to a surface yet.
Tweak the PLTE chunk, adjusting/tinting colors the way you want them.
Recalculate the CRC. Now render it. Voila. A differently-colored image.
I’m sure this’d be trivial with SDL_image, using a memory block as input,
rather than a file on disk.
(This is especially useful for bitmapped fonts, for example. Just have
one PNG in your app, but render it multiple times to get the different
font colors.)
Good luck!On Thu, Jul 17, 2008 at 08:58:25PM -0500, Jonathan Greig wrote:
You know, in the past I used a loop to go through all the pixels and test
for pixel color and replace them individually. Problem was that depending
on how I wrote the loop, it would not swap more than 3 colors per function
call. Rewrote it and finally got it working better and I limited it to 256
colors per function call. Problem was that every time I rewrote it, it
would always throw exceptions. I figured it had something to do with the
real low level code that may have been buggy or just worked in a different
way than I was expecting.
–
-bill!
“Tux Paint” - free children’s drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/
also, you can change the masks, and shifts around… so then SDL will
blit them differently.
eg. you can make the image from RGBA to BGRA Making your red things
blue, and your blue things red.On Fri, Jul 18, 2008 at 2:51 PM, Bill Kendrick wrote:
On Thu, Jul 17, 2008 at 08:58:25PM -0500, Jonathan Greig wrote:
You know, in the past I used a loop to go through all the pixels and test
for pixel color and replace them individually. Problem was that depending
on how I wrote the loop, it would not swap more than 3 colors per function
call. Rewrote it and finally got it working better and I limited it to 256
colors per function call. Problem was that every time I rewrote it, it
would always throw exceptions. I figured it had something to do with the
real low level code that may have been buggy or just worked in a different
way than I was expecting.
Spiffy trick I picked up in mobile game development. Take a paletted
(indexed color) PNG file. Do NOT convert it to a surface yet.
Tweak the PLTE chunk, adjusting/tinting colors the way you want them.
Recalculate the CRC. Now render it. Voila. A differently-colored image.
I’m sure this’d be trivial with SDL_image, using a memory block as input,
rather than a file on disk.
(This is especially useful for bitmapped fonts, for example. Just have
one PNG in your app, but render it multiple times to get the different
font colors.)
Good luck!
–
-bill!
“Tux Paint” - free children’s drawing software for Windows / Mac OS X / Linux!
Download it today! http://www.tuxpaint.org/
Spiffy trick I picked up in mobile game development. Take a paletted
(indexed color) PNG file. Do NOT convert it to a surface yet.
Tweak the PLTE chunk, adjusting/tinting colors the way you want them.
Recalculate the CRC. Now render it. Voila. A differently-colored image.
He specifically mentioned non-paletted, unfortunately, that’s (more or
less) the first thing I thought about. Note that you can do the same
with SDL by playing with the (logical) palette of the source surface
before blitting it, no need to play tricks with PNG. But the source
surface does need to be paletted (the destination can be whatever, in
fact it is much simpler if the destination is non-paletted, doesn’t
require to be too clever to avoid approximations).
What he’s looking for is pretty interesting, actually, it reminds me
of chromakeying in 80’s video clips.
Note that this effect does work the other way, at the cost of an extra
blit (but you’ll probably need it anyway, since the destination will
be not be reusable, once the colorkey has been replaced?). You blit
the “source” (it doesn’t really matter with transparency what’s on
top) to a final surface, then you blit the “destination” (with
colorkey!) to the same final surface. Done.On Thu, Jul 17, 2008 at 9:51 PM, Bill Kendrick wrote:
I take it that this won’t neccessarily be used for “on the fly” swapping?
I’m curious as to what exactly you are attempting to do here Could you explain it a bit more?
Yeah, I got it working in like three minutes. It uses my custom blitter, so it’s not at all fast enough for doing things on the fly. I’m trying to replace arbitrary sections of an image with the appropriate sections of another image. The application for me is in my video game, where there are multiple teams, each with a different color. I’d make a gradient image of a team’s color, then do this special blit onto (say) the colorkeyed image of a flag. If all of the colored part of the flag is colorkeyed, it would replace it all with my team’s gradient. This is an effect that a lot of games have, particularly the old 8-bit ones through palette-swapping (Bubble Bobble, Final Fantasy, etc.) except that they only did flat colors (with dithering, maybe).
– Pierre Phaneuf
Note that this effect does work the other way, at the cost of an extra
blit (but you’ll probably need it anyway, since the destination will
be not be reusable, once the colorkey has been replaced?). You blit
the “source” (it doesn’t really matter with transparency what’s on
top) to a final surface, then you blit the “destination” (with
colorkey!) to the same final surface. Done.
Yep, this is what I was hoping to hear: A better way that I didn’t think of. I was only thinking about two surfaces. I do indeed have to copy the surface first (essentially a blit if not actually one deep down). I think this merits a new function in Sprig. Any name suggestions? I’ll still keep the functionality I already added, since it also works for primitives. You can draw lines and shapes across your dest image, only affecting the colorkeyed parts.
Thanks for the discussion so far, everyone.
Jonny D
Could you