Skip to main content
GameDev.net gamedev.net
🔒 Locked 🎮 Unity

Boost.Gil, SDL, and what does 'interleaved view' mean?

Unity
Started by theOcelot May 19, 2009 at 6:11 PM 8 replies 5.1k views
Original Post
theOcelot
theOcelot
Edit: Should this be in the Alternative Libraries forum or something? I put it here because I'm not sure it fits anywhere else, but almost as much because this is where I spend most of my time on GDNet. A few of you may remember a thread a while back where I was asking for help on rotating SDL_Surface's. My game structure has changed enough that I can't re-use the old code. I was gearing up to re-implement it when I stumbled on Boost.Gil, and realized that it was perfect for what I want. In particular, it seems that it's rotated views will do all the work for me. All I have to do is hook it up. That, of course, is proving to be the hard part. The trouble with these generic libraries is that nothing actually does anything until you hook up a bunch of stuff with a lot of different types and very long template parameter lists (I'm not bitter, really). Anyway, after reading the above-linked page a couple times, I've come up with a rough template of what my transformation function will look like, or at least the testbed function:
void Transform(SDL_Surface* src, SDL_Surface* dst){
    //lock surfaces
    //make boost.gil view of surfaces, possibly with transformations already applied
    //apply transformations, if they haven't been applied already
    //copy the transformed src view to the dest view
    //unlock surfaces
}
Obviously, I'm still using SDL. The main thing that's bugging me is that in the tutorial, an interleaved_view is used when getting a view of raw pixel data. What does that mean, and do I actually want a planar view, whatever that means? I googled "interleaved pixel data", and didn't find anything useful. Here are my questions: What view types do I need to use in my particular case (32-bit SDL_Surface's)? What do "interleaved" and "planar" mean as far as pixel data go, and is there anything else I need to know to understand what the crud I'm doing?
Seoushi
Seoushi
I'm not sure what you are looking for exactly but if you just want to rotate SDL surfaces SDL_gfx would most likely be a better fit (see Rotozoomer).
loufoque
loufoque
Quote:
Obviously, I'm still using SDL. The main thing that's bugging me is that in the tutorial, an interleaved_view is used when getting a view of raw pixel data. What does that mean, and do I actually want a planar view, whatever that means? I googled "interleaved pixel data", and didn't find anything useful.

An interleaved view is a view where the components of the image (R, G, B, A) are interleaved.
That means R1 G1 B1 A1 R2 G2 B2 A2, while planar means R1 R2 G1 G2 B1 B2 A1 A2.

Interfacing GIL with SDL only requires you to know how pixels are stored in a SDL_Surface.
theOcelot
theOcelot
Ok, this works:
void Transform(SDL_Surface* src, SDL_Surface* dest){    //lock the surfaces    SDL_LockSurface(src);    SDL_LockSurface(dest);    //create views of the raw data,possibly with transformations already    boost::gil::rgb32c_view_t src_view  = boost::gil::interleaved_view(src->w, src->h, (const boost::gil::rgb32_pixel_t*)src->pixels, src->pitch);    boost::gil::rgb32_view_t dest_view = boost::gil::interleaved_view(dest->w, dest->h, (boost::gil::rgb32_pixel_t*)dest->pixels, dest->pitch);    //copy the views    boost::gil::copy_pixels(src_view, dest_view);    //unlock the surfaces    SDL_UnlockSurface(src);    SDL_UnlockSurface(dest);}


But when I replace src_view with, say, rotated90cw_view(src_view), I get funny corruptions in the output. It might be something to do with the pitch, as they. Both src and dest are 64*64. I'd post screenshots, but I don't have a good place to host pictures at the moment. Does anything about my code jump out as being wrong?
Seoushi
Seoushi
Quote:
Original post by theOcelot
whoops, forgot about SDL_gfx. But would it take advanatage of the fact that they only need to be rotated in 90 degree increments?


To tell you the truth I don't know. You would have to look at the source code however I would think that it would special case things like rotating by 90 degree and flipping surfaces and not use a standard arbitrary rotation for those operations.
theOcelot
theOcelot
finally went and downloaded SDL_Gfx. From the time I downloaded it to the time I was successfully using it was less than 20 minutes, and it felt like less than 10. That's including building the thing. It turns out it has a function just for 90 degree turns.

There's just one thing I'm not sure about. The rotozoomer functions return a surface, presumably allocated just for me. Am I supposed to free this surface myself? And making a memory allocation for each rotation can't be the most efficient way to do things.

I'd still like to solve the problem with Boost.Gil. It seems to be corrupting memory, as calls to SDL_Free fail after the boost::gil::copy_pixels call. I think I'll take it to Alternative Libraries if I can't figure it out. Maybe SDL surfaces are planar after all?
Kylotan
Kylotan
Quote:
Original post by theOcelot
The rotozoomer functions return a surface, presumably allocated just for me. Am I supposed to free this surface myself? And making a memory allocation for each rotation can't be the most efficient way to do things.

Generally people use these rotation libraries to pregenerate rotated copies and just draw the ones they need. So yes, it gives you new surfaces and you then own them, deleting them later. Memory is cheap whereas real-time rotations are expensive. Obviously 90-degree rotations are cheaper but not doing them at all after initialisation is cheaper still.
theOcelot
theOcelot
Curiouser and curiouser. When I create views, it seems to be quadrupling the width parameters I pass in. When I create and copy the views like this:
w = 4; h = 16;boost::gil::rgba32c_view_t src_view = boost::gil::interleaved_view(w, h, (const boost::gil::rgba32_pixel_t*)src->pixels,  src->pitch);boost::gil::rgba32_view_t dest_view = boost::gil::interleaved_view(w, h, (boost::gil::rgba32_pixel_t*)      dest->pixels, dest->pitch);boost::gil::copy_pixels(src_view, dest_view);


I get a perfect little 16 pixel square of the source image. When I use w=16 and h=64 (to include the whole 64*64 surface), it copies the whole image. w=h=64=crash. w=h=16= a 64*16 bar at the top of the output image.

When I do the copy like this:
boost::gil::copy_pixels(rotated180_view(src_view), dest_view);
to rotate the image, it seems to be broken into 4-pixel vertical columns, which are not properly re-arranged, like they're inverted individually instead of being rotated across the image. A 90-degree turn crashes.

Any ideas on what's causing this?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.