魔法++通过 SDL 像素数据生成动画
我正在尝试从 ImageMagick 图像。 wikipedia.org/wiki/Simple_DirectMedia_Layer" rel="nofollow noreferrer">SDL 像素数据。这是到目前为止 GIF 的样子。 （此 GIF 故意比下面的慢。）
http://www.starlon.net /images/combo.gif
这是它应该看起来的样子。请注意，在上图中，像素似乎覆盖在其他像素之上。
http://www.starlon.net/images/combo2.gif
这是GIF实际上是创建的。
void DrvSDL::WriteGif() {
std::list<Magick::Image> gif;
for(std::list<Magick::Blob>::iterator it = image_.begin(); it != image_.end(); it++) {
Magick::Geometry geo(cols_ * pixels.x, rows_ * pixels.y);
Magick::Image image(*it, geo, 32, "RGB");
gif.push_back(image);
LCDError("image");
}
for_each(gif.begin(), gif.end(), Magick::animationDelayImage(ani_speed_));
Magick::writeImages(gif.begin(), gif.end(), gif_file_);
}
这就是 Blob 所在的地方。
image_.push_back(Magick::Blob(surface_->pixels, rows_ * pixels.y * surface_->pitch));
以下是我初始化 SDL 表面的方法。
surface_ = SDL_SetVideoMode(cols_ * pixels.x, rows_ * pixels.y, 32, SDL_SWSURFACE);
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
顶部图像通常是由未对齐的缓冲区引起的。 SDL 缓冲区可能不是 DWORD 对齐的，ImageMagick 例程期望缓冲区在双字。这在位图处理中很常见。流行的图像处理库 - Leadtools 通常需要 DWORD 对齐数据。这主要是单色和 32 位颜色的情况，但也可能是任何颜色深度的情况。
您需要做的是从 SDL 缓冲区中写出 DWORD 对齐的位图，或者至少创建一个 DWORD 对齐的缓冲区。
ImageMagick API 文档可能能够帮助进一步阐明这一点。
The top image is normally caused by a misaligned buffer. The SDL buffer is probably not DWORD aligned and the ImageMagick routines expect the buffer to be aligned on a DWORD. This is very common in bitmap processing. The popular image processing library - Leadtools, commonly, requires DWORD aligned data. This is mostly case with monochrome and 32 bit color but can be the case for any color depth.
What you need to do is write out a DWORD aligned bitmap from your SDL buffer or at least create a buffer that is DWORD aligned.
The ImageMagick API documentation may be able to help clarify this further.
您可能想要尝试的另一件事是清除缓冲区以确保其中没有任何数据。我不太了解 IM 的 API，但是覆盖在其他像素之上的像素通常表示缓冲区脏了。
Another thing you might want to try is to clear the buffers to make sure there isn't any data already there. I don't really know IM's API, but pixels overlayed on top of other pixels usually indicates a dirty buffer.