I obviously didn't explain myself properly, because both you and DDRM seem to have misunderstood the point I was trying to make. The relevant performance comparison I was drawing attention to is between sending multiple small objects in the arrays passed to PROC_render() and sending fewer, larger, objects which represent the identical 'scene'. My assumption is that the total number of vertices and faces, and therefore the work that GPU has to do, is exactly the same in the two cases. What isn't the same is the work that BBC BASIC has to do in d3dlib/ogllib, which is related to the number of individual objects, not to the complexity of the 3D scene.
I was not advocating combining multiple objects, some of which might have been pruned, into larger objects that can't be pruned. This increases the overall complexity of what the GPU is being asked to render, which clearly isn't desirable and could well outweigh any advantage gained by passing fewer objects to PROC_render().
Yes of course, and I was never suggesting anything different. But it still seems to me quite likely that there might be several objects in relatively close physical proximity that you would treat as a group from the point of view of whether they are switched off (pruned) or switched on - perhaps they are all in the same 'room'. Because these objects probably have different texture maps (assuming they are textured) it is natural to treat them independently in the program, and pass them to PROC_render() in separate array elements, but my point is that performance can be improved by combining them into one large FVF file, sharing one tiled texture map, and using the UV coordinates to isolate the different textures for the different objects.So the visible cells get switched on, all the others get switched off so that the GPU doesn't process them.
If there is no opportunity for grouping objects in this way in your program, then my suggestion isn't relevant, but more generally I still think it is worthwhile to point out the potential. Although I made the comment in a thread about your Maizie Bones games it was never intended to be directed specifically at you.
I don't think I'll be able to help with that, since it's not something I have attempted. You are of course correct in thinking that 'multiple windows' is not something that can be achieved in Android or iOS, they really don't have the concept of 'windows' at all. However I would point out that my BBCSDL adaptation of 'Treasure Tower' uses the 3D renderer to wrap the 2D maze around a cylinder, and this appears to be in a separate 'window' (the 'TV screen') but it really isn't. I'll be releasing it with the next version of BBCSDL (assuming you have no objection) but here's a sneak preview - 100% BASIC, one window:You might remember that with the 'Blue Monster Hunter' subgame in Maizie Bones, the 3D graphics were rendered via Direct3D inside a 'static box'. I will probably need to figure out how to do that with BBCSDL. I will of course read the SDL2.0 docs, but I might need to tap you for assistance with this if I stumble!