The Shrine

Terrorist threat law prevents me from filling in the black (kidding anyway), but I'm starting to hate BREW. The spec designers wouldn't have passed their first semester sophomore computer science courses at Stanford. There is just some stupid, stupid shit going on with BREW. As an example, they offer .PNG file support, but it remains compressed in memory and gets decoded each time it's drawn, making it too slow to draw more than two or three of them on the screen at the same time, so it's useless for game design. I understand it saves space in memory, but they had to have imagined someone might want to make a game with this at some point. What's funny is that the BREW-specific image format (.BCI) is even slower.

And my new bank card to replace the one I lost hasn't come yet, I thought it would be here by now, and I didn't make it to the bank today so I have nothing to eat tonight except a box of cereal. Good times.

At least I have the fighting homeless guys on the corner to amuse me. I love the part on the latest Chris Rock album (from the new HBO special a few weeks ago) where he talks about bringing a single crackhead along whenever he goes out to dinner with married couples. "Come on, tell us some more of yo' cracky tales!"

You could probably make it to a test market for the fiber lines in San Antonio, but which would you prefer, the crackhead or the yo's essy?

We got cholos down here too, dude. And I have no doubt that San Antonio has its drug problems, though my guess is it's more crazy tweakers (meth addicts) than crackheads.

(For those living further away from the Mexican border, a cholo is a Latino gang member, often Mexican, and "Yo, essé!", the formal spelling for what Barret is talking about, is a common greeting between them.)

Thought about using jpg instead? Better compression ratios than PNG...I think. However, it's lossy...

Well, one of the other stupid things BREW did is that they pick a color value for transparency instead of using image transparency. Whatever is bright pink (255, 0, 255 RGB) is transparent. I believe one of the side effects of JPEG compression is that it changes color values slightly, so I might end up with bright pink blotches all over the place. Besides which, it wouldn't solve the problem, which is that BREW decodes images at drawing-time, not loading-time, so it would still be decoding every time it drew, and slowing the game down like mad. I could probably write a JPEG decoder, but I'm concerned about the artifacts...don't want to do all the work, then find out that my sprite is sprinkled with pink dots. I could use their decoder to see if the artifacts are there, then if it works, write my own, but my guess is it's not going to work.

Yeah, jpeg decoders don't decompress the images precisely. Might not be an acceptable side effect.

Hmm. Might be better to decode the PNG images ahead of time, draw them to offscreen buffers, and use page flipping between the two.

....at least that's what I might try on a PC. In the crazy world of cell phones, who knows.

It's the damn PNG decoder I don't want to write. I looked at the spec, and I can tell that ain't fun.

Mental wrote:It's the damn PNG decoder I don't want to write. I looked at the spec, and I can tell that ain't fun.

Woops. I said decode, but I meant decompress. So decompress images ahead of time in an offscreen buffer and do page flipping. But I'm pretty much talking out of my ass since I've never developed a video game on a cellphone or any other embedded device. Caveat emptor.

It's fine...I knew what you meant. The way I was talking about it, decompression is about half of the decoding phase.

PNG encoders do filtering on an image to improve its compressability (apply an predictable algorithm to each scanline based on criteria which alters the data in a way that's reversible, but which rearranges the data so that it's in a pattern more likely to be smaller when compressed) before they encode, and that's the other major half, though there are a lot of other minor steps that get done too.