Here you are. There is no functionality/demo project included as I grabbed this out of an existing customer project. Please let me know if you need assistance.
https://we.tl/t-yFZuxh8xfY
Received a warning you did not download the files yet. Do you want me to put them on a different place?
Here in case a re-upload: https://we.tl/t-XWXyQNtXif
I’ve updated the framework to version 1.2.x. Most of the major refactoring is done, but since I’m developing the framework in conjunction with two apps (a utility and a game), I sometimes encounter real-world design issue that require refactoring, and I’m always making sure the foundation is solid.
In the next round, with @Ulrich_Bogun’s contributions, I hope to remove the macOS/iOS dependencies.
4 Likes
Great work yet again John.
I continue to make progress and will have some important bug fixes pushed to the public repo soon. And in addition to my “Photo Tape” app, I’m working on a game:
Video: http://cargobay.tinrocket.com/public/xojo/123_gameplay.mov
TestFlight:
The above TestFlight build still uses CoreGraphics as the renderer. Performance is good enough for a minimal game, but I’ve been itching to get some sort of GPU rendering working. With a few new delegate classes and a new class interface, I’ve extended my framework to work with any render you want. My framework doesn’t need to know what you’re using—it just sends the renderer delegate the appropriate methods. In my case, I’m using the MBS SceneKit wrapper, but you could easily use something else.
Here’s a link to a stress test comparison between CoreGraphics and SceneKit:
The beauty is that you don’t need to go very deep into your renderer of choice. I’m just doing the bare minimum with SceneKit — making nodes and applying textures — since my sprite framework already takes care of the scene graph and everything else. All you need to do is handle object creation, update, and rendering. So for SpriteKit:
For every NextFrame event the sprites run, they also call a NextFrame method on an optional RenderDelegate object, which, in this case, is an instance of my SceneKit.
In SceneKit I keep a dictionary pool of SCNNodes, and if a new native sprite is encountered, an equivalent SCNNode is created and added to the scene. Then, I copy the native sprite’s world transform, transparency, etc to the SCNNode. That’s basically it.
1 Like
Amazing work John!
Hello,
with the normal XOJO functions a sprite emulation can be displayed without much effort
example:
Mac
Yes, it can! And that’s what my sprite framework does, via Canvas and Graphics, but at a higher level. However, drawing speed with many sprites is slow, so that’s why the GPU is needed.
Just a preview of the next release of the framework:
Support for other renderers is almost complete. My framework has been extended to artibrary renderers via a new class interface, and sprites within my framework support drawing themselves to picture objects. In the instance of SceneKit, SceneKit is getting back images to use as textures on planes. It makes things much, much simpler and ensures that the output looks identical (there are some slight color differences between the renderers.)
Below, I’m running my game with the native Graphics renderer (Left) and with SceneKit (Right). The text objects are rendered to images for SceneKit, as is the path sprite that’s the button background. Also, since XOJO’s GraphicsPath objects are opaque, SceneKit doesn’t need to deal with them because it will asked for the prerendered version.
3 Likes