On Wednesday 03 November 2010, at 14.37.48, Marcos Marin <amcmr2003 <at> yahoo.com.br> wrote:
> Hello good people!
> Could anyone please point me to a previous thread or wiki article, or
> tutorial etc, that talks about direct pixel manipulation with SDL?
All you should need to get started is the documentation for SDL_Surface and SDL_PixelFormat. The rest is just good old low level computer graphics!
The easiest way is to just ask for 24 or 32 bpp software surfaces. SDL will usually be able to push that directly to the screen, and if not, it'll convert on the fly, possibly quick enough that your time is better spent optimizing your 24/32 bpp code than supporting multiple pixel formats.
> I mean, how easy or is SDL even the best approach to, say, the Demo
> Scene, for example.. instead of "simply" copying and pasting a bitmap on
> top of each other, like we all do =) how would you proceed on a lower
> level of control over your images and animations, and would that be
Short version: PC hardware (since the 486 or so) is not designed for software rendering.
Slightly longer version:
Since the PC architecture and video cards are designed for hardware accelerated rendering, CPU access to VRAM is about as far from optimal as it gets. The CPU will slow down to a crawl when doing it, no matter how fast it is, or what video card you have.
That said, with the CPU power available these days, software rendering is actually quite interesting, though the only realistic chances of getting the output to the streen at a usable frame rate is through OpenGL or Direct3D.
And, unless you need scalability to ancient hardware as well, maybe it's a better idea to just implement your software rendering as pixel shaders under OpenGL or Direct3D? That way, the work is done in the right place, by cost-effective hardware specifically designed for that kind of work. (You'd need an insanely fast CPU to come anywhere near the performance of an old budget 3D accelerator.)
That said, ZeeSpace is all software, and it'll probably stay that way for now. Then again, I'm not planning on using it for any massive real time rendering; only incremental background rendering and the occasional procedural texture.
> For example, another problem is the bitmap itself, I dont think we would
> be able to use any other image format to do this, since they're mostly
> compressed, making it harder to access individual pixels.. hence we would
> probably have to intercept SDL after it extracts it to memory anyway, thus
> it might not be so hard but, on the other hand, it perhaps might break
There is no need to intercept! As long as you're not using RLE encoding/acceleration, the SDL surface is in precisely the format indicated by it's pixelformat field. That's all there is to it, pretty much.
> Sorry if this question is somehow inappropriate, I find it interesting
> though =) and seems seldom discussed, couldn't find much on the subject..
> =( so, any pointers in the right direction?
It's certainly interesting, and it's absolutely something you should try if you're serious about learning about graphics programming.
However, keep in mind that many of the methods and algorithms used for "traditional" software rendering, and the related optimization tricks, aren't really up to date with how modern CPUs and computers work. And, hardware accelerated rendering via high level APIs is a different beast entirely - except for the pixel shader bit.
//David Olofson - Consultant, Developer, Artist, Open Source Advocate
.--- Games, examples, libraries, scripting, sound, music, graphics ---.
| http://olofson.net http://olofsonarcade.com http://kobodeluxe.com |