Split `korge` into `korge-render` and `korge`

[soywiz]

korge-render won't have views, but will have batcher, events, etc.

[jobe-m]

That move makes much sense in my eyes :) Does that mean that Korge-render will "just" provide a batcher to chain drawing calls like in renderInternal() in the View class?

I would then base Korge-fleks on top of Korge-render since I am writing my custom render views currently to draw the sprites, parallax background, etc.

[soywiz]

I'm Back after a long break.

Regarding this I have plans to create -core versions of all the libraries, then make that korge-render will use that. Korge base will still provide the view system as it is for compatibility. Then we can evolve the other part differently.

I would like to have a system that could be used to render both views and anything renderable not using views. I also want to make a spike for a container supporting querying objects, with game objects in an oct-tree, then raycasting, querying objects in a range, by type, tag, shapes for raycasting, working with tilemaps and both sprite-based animations and skeletal-based animations etc. I would also like to explore actors like the old DIV game studio, but being able to switch between behaviours, being behaviours kotlin coroutines. And still be able to use views and scenes as controllers or Composables in some cases where thoseparadigm works better.

Maybe we could make something more official using fleks, and your work too at that layer. Maybe we can make a call when I get up to date with everything to discuss these things and do something that makes sense?

[jobe-m]

The DIV game studio sounds interesting. It looks like to be something more high level to create games with like Pico8? I haven't used anything of that kind yet. I think it would make sense to base such a specialized game engine on an ECS. It would be at least a stand-out-of-the-masses critera for a Korge based high level game engine. :)

I am currently quite happy how the (custom) ParallaxRenderView implementation looks and works in Korge-fleks. It makes things much easier than having to deal with Views for every single texture which needs to be controlled independently as I did it before. The next thing would be to implement a SpriteAnimationSystem as an extension of my already existing SpriteRenderView in Korge-fleks.

[soywiz]

Cool. I also had an experiment I wanted to do called GameView, that would handle tilemaps, sprites and skeleton animations, while having all the entities there queryable using BVH. So raycasting, getting items inside a rectangle, culled rendering etc. would work. and that could be implemented as ECS and work on top of korge views seamlesly. I still don't know but those are areas I would want to explore at some point.

In any case first I want to do the libraries split into core variants and make korge-render just depend on the core while being able to use full variants if wanted. Let's see how it goes.

[Gidroshvandel]

Hello! Are there any updates in this direction?

Do I understand correctly that this will allow using objects for rendering more natively in ecs systems than is currently the case?

Will we be able to access something like a RenderContext outside of the View inheritance hierarchy?

[jobe-m]

From my side there are no news about this topic. I concentrate more on the "top-level" features which I usually add to korge-fleks while I develop my game.