I guess the biggest issues are the lack of multi-dimensional arrays, the ability to create and store images (sprites) in memory, and the ability to read image files.
If SC could read image files then I could load a heightmap to render rather than generating one with my fake multi-dimensional array system. If I could create a sprite based on pixel data and then store it then I could set up a double-buffering system where all the pixels in a scene are stored in a sprite and then rendered at once, rather than the current situation where the scene is displayed pixel by pixel.
I understand that adding features like those wouldn't be in keeping with SC's design.
Multi-dimensional arrays have always been planned - I don't think that's outside of SC's design. They're an optional construct.
The ability to create and draw into off-screen images is also useful - but we would need to implement some kind of graphics port idea to specify the destination for drawing commands.
Open Event:
CREATEIMAGE 1, width, height, depth
SETGRAPHICS 1
DRAWLINE 0, 0, 50, 50
CREATEIMAGE 2, width, height, depth
SETGRAPHICS 2
DRAWRECT 20, 20, 100, 100
Paint Event:
DRAWIMAGE 1, 100, 100, (optional scaling etc)
DRAWIMAGE 2, 50, 100, (optional scaling etc)
Paint event/main screen would be port 0, but the Paint event would automatically set the port to 0 for you.
Reading image files could be as simple as:
LOADIMAGE 1, "filename", (optional scaling etc)
Convert an IMAGE into a sprite:
IMAGESPRITE spriteNum, imageNum
Basically, you would have images, and you would have sprites, they would be separate, but with different abilities. Eventually if we go to OpenGL then the act of converting an image to a sprite would be converting it from a regular picture into a texture for fast drawing.
None of this is outside the realm of possibilities for SilverCreator.
