I agree about the connecting land making the overhangs more logical, so long as the user is convinced that the size of that connecting land is sturdy/wide-enough looking to support the weight of the size of the floating part. Otherwise you could have 1 pixel supporting a huge chunk of land which would obviously not be convincing.
If you are only going to have 1 screen of land stored in 1 texture and no scrolling it's really not hard to make changes to the backbuffer and grab the results back into the land texture/image each frame. Then you can modify the land and keep the changes, and implement whatever form of land-dropping you think is suitable. The easiest is to do it in columns of pixels. You could, with some kind of drawimagerect thing, draw individual columns from the texture and animate them falling into position.
Perhaps BRL needs to add an UpdateImage() command for GL and DX that copies an area of the backbuffer into an existing image, which is faster than GrabImage which allocates a whole new image. For GL it would call glCopyTexSubImage2D().
If you are only going to have 1 screen of land stored in 1 texture and no scrolling it's really not hard to make changes to the backbuffer and grab the results back into the land texture/image each frame. Then you can modify the land and keep the changes, and implement whatever form of land-dropping you think is suitable. The easiest is to do it in columns of pixels. You could, with some kind of drawimagerect thing, draw individual columns from the texture and animate them falling into position.
Perhaps BRL needs to add an UpdateImage() command for GL and DX that copies an area of the backbuffer into an existing image, which is faster than GrabImage which allocates a whole new image. For GL it would call glCopyTexSubImage2D().