Knowing what we know now we can add a property to our shape area where we define a base image to use as a background/base image.
A shape area
This would allow us to generate a compound shape, and use it in a new image as a shape_area background rect, and overlay more shapes on top of it per offset, etc.
This is essentially getting into layer territory, and z-indexes would be the only thing that would distinguish one layer from another and the stacking order is where z-index comes into play.
In our code, it's FIFO order (first in first out)
If we first draw a circle
Then we draw a box
and the two happen to overlap
The box will be on top of the circle
So the z-index is really a human convenience - an abstraction - but all we would really need for this would be a shape area modification again with a zindex property.
This could be useful so let's add it:
A shape area
With these 2 additional properties to a shape area, we have a start of something very powerful.
Having a full on layer object doesn't seem like it makes a lot of sense unless we want to make our code more descriptive and self documenting. That is we declare what we want and QB64 makes it so.
Because QB64 lacks some basic stuff like dictionaries though, we're going to stay procedural.
Think as a designer using a graphics program:
Think as a programmer:
There is a 1:1 with what we're doing in code already so a further layer based approach would be overkill. Shape areas are layers when they are drawn in a sequence or stacking order. Shape areas are images so we can position them wherever we want and draw them WHENEVER we want (the zindex).
A shape area
- shape_image - long - optional handle of the shape image we want to use as a base. and if we have this we should automatically set the shape rect_w, and rect_h to the images width and height.
This would allow us to generate a compound shape, and use it in a new image as a shape_area background rect, and overlay more shapes on top of it per offset, etc.
This is essentially getting into layer territory, and z-indexes would be the only thing that would distinguish one layer from another and the stacking order is where z-index comes into play.
In our code, it's FIFO order (first in first out)
If we first draw a circle
Then we draw a box
and the two happen to overlap
The box will be on top of the circle
So the z-index is really a human convenience - an abstraction - but all we would really need for this would be a shape area modification again with a zindex property.
This could be useful so let's add it:
A shape area
- shape_zindex - integer - optional zindex for a shape area - useful for looping through a collection of shapes and determining order to draw for the stacking order
With these 2 additional properties to a shape area, we have a start of something very powerful.
Having a full on layer object doesn't seem like it makes a lot of sense unless we want to make our code more descriptive and self documenting. That is we declare what we want and QB64 makes it so.
Because QB64 lacks some basic stuff like dictionaries though, we're going to stay procedural.
Think as a designer using a graphics program:
- New Layer
- Draw a box
- Create a new layer (it goes on top)
- Draw a ellipse over the box but let the box under it still peek through
Think as a programmer:
- New image
- Draw a box (x,y)-(w,h), color, etc. BF line
- New image
- Draw a ellipse over the box... etc.
There is a 1:1 with what we're doing in code already so a further layer based approach would be overkill. Shape areas are layers when they are drawn in a sequence or stacking order. Shape areas are images so we can position them wherever we want and draw them WHENEVER we want (the zindex).