Jump to content
  • Advertisement
Sign in to follow this  
theOcelot

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

This topic is 3498 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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).

Share this post


Link to post
Share on other sites
whoops, forgot about SDL_gfx. But would it take advanatage of the fact that they only need to be rotated in 90 degree increments?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!