Irrlicht with Software Render Mode

[irrcode]

What is required for the software renderer? I am curious about the c/c++ libraries or OS calls. Does this use SDL, as is implied by "All platforms using SDL" under the "Platforms" section at http://irrlicht.sourceforge.net/features/ ? Also, is it posible to render to a pure wxWidget form without SDL use? I realize that there is no accelleration in this case. I am aware of http://irrlicht3d.org/wiki/index.php?n= ... nWxWidgets but I think that is only for handling the form with the user's windowmanager, not as the drawing method, unless I am missunderstanding.

[hybrid]

The software renderers (we have two actually) don't rely on any external library. SDL is just another window platform, which allows us to support embedded devices with special framebuffers. The software renderers really do the whole rendering in software, i.e. both result in an internal backbuffer image in memory, which is then blit into the main framebuffer, e.g. by SDL, X11, or the Windows window support.
WxWidgets is, just like SDL, just a window provision platform. You can render to a wxwidget with any driver available in Irrlicht, and you can choose any underlying device. Just make sure that your wxwidget supports the chosen driver.

[irrcode]

both result in an internal backbuffer image in memory, which is then blit into the main framebuffer, e.g. by SDL, X11, or the Windows window support.

Where is this image in memory stored? Can I access it as a multidimensional array or a dynamic linked list?

[teto]

Look in CSoftwareDriver.h
You will find video::CImage* BackBuffer and IZBuffer* ZBuffer.

You could use CSoftwareDriver::createScreenShot but it creates a copy of the backbuffer.
You could access to window handle via getExposedVideoData and act according to platform to get back what's displayed.

There might be a 3rd way but I can't think of anything.

[hybrid]

Why do you want to access the image?

[irrcode]

I am assuming that the pitch object in the virtual class IImage is dot-pitch. Is this for sub-pixel data being averaged onto the physical display limitations?

Look in CSoftwareDriver.h
You will find video::CImage* BackBuffer and IZBuffer* ZBuffer.

You could use CSoftwareDriver::createScreenShot but it creates a copy of the backbuffer.
You could access to window handle via getExposedVideoData and act according to platform to get back what's displayed.

There might be a 3rd way but I can't think of anything.

Does this work if there are no current display working? I have looked through the irrlicht source-code, and the *data object of CImage is what I am looking for I believe. It seems that I can get the data I want via BackBuffer.lock() which would return the address start for the 2D buffer. Does this seem correct?

Why do you want to access the image?

I want the option, plus wxWidgets are on many platforms that pure irrlicht is not. Or other reasons, there is a lot of cool stuff that can be done.

[EDIT #1] Also, does the lock() method prevent the data from being updated until unlock? I ask since I didn't see any check in the setPixel-type functions. I don't want half-updated image data when I issue a call for lock().

[hybrid]

No, pitch is the full width of an image line in bytes. This includes additional space at the end of the line, which is outside the visible range.
The lock method does not prevent anything, for IImage classes it's a no-op.
Cool things are a rather vague idea of what should happen, this makes it pretty impossible to give any help.

[irrcode]

No, pitch is the full width of an image line in bytes. This includes additional space at the end of the line, which is outside the visible range.

Ok, so it should never be any larger than (Width*bits_per_pixel+32bits). Where the 32bits are the max left over after whatever is used per pixel less than R8G8B8A8?

The lock method does not prevent anything, for IImage classes it's a no-op.
Cool things are a rather vague idea of what should happen, this makes it pretty impossible to give any help.

Among other reasons, I am working on a game and I want to be able to port it to some random unsupported hardware in addition to the supported Linux & Mac. A FreeDOS port might also be neat.

[hybrid]

No, pitch can any size. Some (hardware) images, such as framebuffers of embedded devices, can be aligned to huge sizes, such as 1024 byte. So you'd get up to 1020 bytes additional in that case. Just use pitch and width as you need and don't assume anything else.
For porting you don't need the low-level access in the app. Instead, create a new device for your platform. There you will find the software driver render method which copies the backbuffer to some device specific memory address. That's the only thing you need.