A simple answer would be an Io loop calling C++ primitives. It will
likely involve less message sends and block activations.
On 14-Jun-09, at 12:10 PM, dennisf486 wrote:
> For the game I'm working on, I have a very complicated data
> structure for storing the terrain (it works directly with compressed
> terrain data in memory without needing to decompressing it first!).
> I have some C++ code already finished that abstracts away the
> details of the data structure so that the code displaying the
> terrain only needs to implement a callback function that accepts the
> 3-d coordinates to draw. Something like:
>
> void draw_callback(const Box& draw_this_box)
> {
> ThreeDEngine.DrawBox(draw_this_box);
> }
>
> Obviously it gets called back thousands of times to draw a frame.
> The calling loop looks a little like this:
>
> void draw_terrain(FUNC_PTR callback)
> {
> for (i=bytestream.begin(); i != bytestream.end(); i++)
> {
> Box b = decompress_box_at(i);
> (*callback)(b);
> }
> }
>
> If this were calling Io it would be going from C++ to Io to C++ to
> Io to C++, etc.
>
> With a little bit of work I could rewrite the C++ portion of the
> code to work with a Cursor object (like cursors in database
> programming). The Cursor object would store where in the bytestream
> the decompression routine is at, and the extra housekeeping data it
> needs at each point to decompress that box. The interpretation of
> each next byte in this compressed stream depends on the box you
> decompressed last time, so you have to know what the last box is.
> It isn't shown in the pseudocode, but this is actually also a tree
> structure, so the Cursor object will have to maintain its own
> internal Stack object too!
>
> If I did this then the Io code wouldn't run out of a callback;
> instead it would look like this:
>
> cursor := Cursor clone
> while (cursor hasBoxes,
> DisplayOpenGLCube(cursor next_box)
> )
>
> Now it's just an Io routine calling a C routine (next_box) over and
> over. The C routine should be fairly fast, but I will have to do a
> lot of work to make it maintain its place in the datastructure on a
> custom stack object, instead of implicitly remembering where it was
> using recursive functions as it does now.
>
> So my question is, is the second version likely to perform better
> than the first version, and is it worth doing?
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
Regards,
Jeremy Tregunna
jeremy.tregunna@...