jakubg1 / OpenSMCE

Game engine which allows creating a broad range of marble popper games.
MIT License
14 stars 11 forks source link

Rewrite the renderer #115

Open jakubg1 opened 1 year ago

jakubg1 commented 1 year ago

This is a very big maintenance project, and a very big task which will be performed after #1, #39 and #95 have been implemented.

This issue will solve #108.

Right now, the ordering of various sprites is janky. Some bad habits have been introduced as a result of trying to patchwork the code so everything is rendered in the correct order. For example, the ball shadows and spheres in general are being rendered using shadow and hidden parameters which are being passed along, a very not elegant solution at all. And not flexible.

What's the solution?

The solution is to move all rendering to layers. The rendering order inside one layer does not matter at all. Right now, a similar system is being used by UI, but this system will be superseded by this new global layer system.

How is it going to work?

All primary objects which have a graphical representation (Sprites, Particles, Fonts, etc.) will take a mandatory layer parameter. This parameter will be, obviously, the layer name a particular object is going to be rendered on. Because Particles use Sprites to render themselves, the layer will be forwarded to all Sprites being rendered as part of that Particle. The Sprite class, on the other hand, will make a call to a new Renderer class to actually "draw" itself with given parameters. The object will be rendered onto a Canvas of a given layer. Once the main drawing pipeline finishes, the Renderer will render all layers (Canvases, one canvas per layer) onto the actual screen and clear the canvases in preparation for the next frame.

Example benefits

With ultimate flexibility when it comes to what is drawn on which layer, some extra flexibility will be possible to be added to some config files:

jakubg1 commented 9 months ago

A list of problems to overcome: