Maidens of the Kaleidoscope

~Hakurei Shrine~ => Rika and Nitori's Garage Experiments => Topic started by: Dark Kitsune on November 11, 2016, 10:55:48 pm

Title: Bloom Engine - Now (finally) in OpenGL [WIP]
Post by: Dark Kitsune on November 11, 2016, 10:55:48 pm
Bloom Engine
A *WIP* multi-platform and simplicity-oriented engine written in C#. The engine's main goal is to require a relatively low amount of code while still being flexible.

This is the (hopefully) final rewrite of Bloom Engine, an engine I've been working on for a sadly long time.
It's getting somewhat to ready for the first early release, but I still need to add a lot of planned features, create a demo game, and write up a lot of documentation before I can call it anywhere near done.
An early playable demo will come soon.

Some features of Bloom Engine: (Outdated at the moment but mostly accurate)
 - Uses Lua as its scripting language.
 - Pattern scripting based on ZUN's design, where a pattern is defined as an object, which controls the bullets itself. Bullets are not required to be manipulated themselves for most complex pattern designs, though they can be directly manipulated too if it's necessary..
 - Uses a layer system instead of render priority/depth for deciding drawing and updating order. Layers can also be moved, rotated, manipulated for neat effects or (in the future) be used as textures.
 - Built in animation handling.
 - Tweened movement and transformations which, for example, allow an object to reach a specific position over a specific number of frames with acceleration at the beginning of the movement and deceleration at the end of the movement.
 - Dedicated object types for players and enemies that handle common tasks automatically such as life, states, and state-based animation.
 - Movement and effect patterns that can be scripted and applied to game objects to make them perform them complicated movements and effects.

Videos:
Basic stage https://www.youtube.com/watch?v=4Rv2RXxv5B4
Title: Re: Bloom Engine
Post by: Trung0246 on November 22, 2016, 05:17:00 pm
Is the source code available for everyone to view? :(
Title: Re: Bloom Engine
Post by: Dark Kitsune on November 23, 2016, 05:07:19 am
I was hoping to clean it up a bit first as the code is ridiculously messy from rewriting several classes multiple times and changing how I approach problems over time (I'm still fairly new to C# and previously used GML and C++ instead, so I find new ways to improve things all the time). I'll create a github soon but the code won't be very readable.


I'll also have to figure out how to rename the project files without breaking things because they are still using the old name of the project.
Title: Re: Bloom Engine
Post by: Trung0246 on November 23, 2016, 06:22:26 pm
The code won't be very readable

Well it's ok, I just want to view the core part that do heavy math like 3D with Magic Matrix (still don't know how to do it), and also what data type you used to hold bullets ? Array or dictionary or something else?

And btw how did you handle over 9000 bullets (or just maybe around ~1000 :V ) on screen at the time without lag at all?  :( (like try to multi-thread for processing every separate pattern, or few code to fast loop optimization? And also prevent memory leak?) for stable ~60FPS

My engine: https://github.com/Trung0246/Shmup/tree/master (https://github.com/Trung0246/Shmup/tree/master), wrote in Javascript, pretty lag on my laptop with 1GB RAM, while that (for example), on DDC 14 stage 4, lots of bullet fired from second spellcard without lagging me at all and still stable at ~30 FPS (I think maybe Javascript is natively slow, I don't know)
Title: Re: Bloom Engine
Post by: Dark Kitsune on November 24, 2016, 01:03:54 am
Since adding some extra processes it's more like 7000-8000 at once at 60 FPS now on my laptop (in videos it might lag a bit more because the recording software makes it so it lags above 4000 or so). Patterned bullets are slightly slower though.

First off, I'm using Monogame which has a pretty decent sprite batch system.
All game objects are handled in lists, with one list for each layer. There's no depth sorting, instead you put them on the different layers to sort them. With the built in Monogame depth sorting the rendering time doubled so that's why I took this faster approach instead.
For bullets going in a straight line at a constant speed the engine refrains from doing extra calculations and only uses sine and cosine when the angle actually changes.
Bullet (or other objects) deletions and layer changes are batched together so that at the start of the next frame they're handled in the update loop which prevents a lot of extra lookups in the list.
There's no multi threading in the engine at all because it's not necessary at the moment.

As for the 3D plane thing, it's sort of an abstracted matrix and when you add objects to it, it generates a matrix for each object and then transforms the object matrices with the plane matrix and then the objects are moved based on the result matrices from the transformations. The video for that is outdated and you might notice that the angles are all messed up, but that's fixed now. The objects' angles are converted to normals and transformed on the plane then converted back so they are rotated correctly on their Z axis to give the illusion that they're 3D.
Title: Re: Bloom Engine
Post by: Trung0246 on November 24, 2016, 08:05:10 am
7000-8000 at once at 60 FPS now on my laptop
Well btw how much RAM your laptop have? (for best comparison with my old and sh*tty laptop :( )

As for the 3D plane thing, it's sort of an abstracted matrix and when you add objects to it, it generates a matrix for each object and then transforms the object matrices with the plane matrix and then the objects are moved based on the result matrices from the transformations. The video for that is outdated and you might notice that the angles are all messed up, but that's fixed now. The objects' angles are converted to normals and transformed on the plane then converted back so they are rotated correctly on their Z axis to give the illusion that they're 3D.
Well still too complex for me to understand, I guess maybe best way to understand it is to view code, so I will wait for you to publish it to github :), good luck !!  :D

Btw what did you think about my engine ? Much same as your?
Title: Re: Bloom Engine
Post by: Dark Kitsune on November 24, 2016, 09:28:53 am
Well btw how much RAM your laptop have? (for best comparison with my old and sh*tty laptop :( )
8 gigabytes. I've never had any tests go above 30 or 40 megabytes, though.

Btw what did you think about my engine ? Much same as your?
I don't know Javascript at all, but it looks pretty different.
Title: Re: Bloom Engine
Post by: Dark Kitsune on December 21, 2016, 12:28:17 am
Made some pretty large changes the last couple of days.

Most events now run as tasks meaning wait() now works in them. Some events such as OnShotBounce/OnShotWrap are not by default though, as they can often be triggered in large amounts at once. I may make this optional.

Objects can now hold data, accessed with obj:Set(key, value) and obj:Get(key), where obj is any object and both key and value can be of any type. A default value can be used with Get if the key doesn't exist by adding another parameter: obj:Get(key, default).
Some examples:
Code: [Select]
obj:Set("Stamina", 100)

for i = 1, 10 do
    obj:Set(i, 100)
end
for i = 1, 10 do
    print(obj:Get(i))
end

obj:Set("func", function() print("foo") end)
obj:Get("func")()

local worth = obj:Get("worth", 100)

The built in stats system is now removed in favor of using object data or global variables to do the same thing, as the engine is supposed to support multiple players at once.


Also, I am beginning to prepare a demo release of some sort.
Title: Re: Bloom Engine
Post by: Trung0246 on December 26, 2016, 02:58:37 am
So... demo... cool, I also made some major improvement on my engine, (basically rewrite code structure) but still after for months can't still figure out the way you did 3d transform matrix, any resource for that? Also, when you will publish your engine on github? :( (Btw the curve laser one you did with multiple node connect together, right?)
Title: Re: Bloom Engine
Post by: Dark Kitsune on December 30, 2016, 07:57:03 am
I actually probably won't do the Github thing. I don't really feel like doing a bunch of cleaning up to make it so the code can actually be read by others and stuff.

For the 3D transformations, here's the class file contents for it if that helps at all. http://pastebin.com/5EJhbjMx You'll have to understand how matrices work and maybe a bit of XNA knowledge. GameObject is my own base class for all moving and rendered objects in the engine, Mathx.FixAngle is a function that wraps an angle to stay in the 0 - 360 range, and Mathx.DCos/Mathx.DSin/Mathx.DAtan2 are cos/sin/atan2 functions that use degrees instead of radians.

As for curved lasers, there's a class in the engine called Bend which is a primitive made up of a strip of triangles mapped to a list of points and angles. The curved lasers each have their own Bend object and records a list of its own positions and angles and passes that to its Bend object. Bends can also be used on their own for effects like trails and lightning and magic circles.
Title: Re: Bloom Engine
Post by: Trung0246 on December 31, 2016, 04:05:36 am
I actually probably won't do the Github thing. I don't really feel like doing a bunch of cleaning up to make it so the code can actually be read by others and stuff.

:( (Or maybe compress all of them to one ZIP file then just publish it somewhere, idk, I don't even care about cleaning code (mine too is messy  :V ), just want to learn more stuff)

For the 3D transformations, here's the class file contents for it if that helps at all. http://pastebin.com/5EJhbjMx You'll have to understand how matrices work and maybe a bit of XNA knowledge. GameObject is my own base class for all moving and rendered objects in the engine, Mathx.FixAngle is a function that wraps an angle to stay in the 0 - 360 range, and Mathx.DCos/Mathx.DSin/Mathx.DAtan2 are cos/sin/atan2 functions that use degrees instead of radians.

That helped me a lot seriously, thx much :)

Btw what do you think about this? (http://codepen.io/Trung0246/pen/vgBLdB?editors=0010) Using shot spritesheet from you and modified danmakufu script a little bit from snow's

Render pretty fast now, stress test showed that it can handle 4000+ bullets on my weak laptop using PIXI.js (thank those guys who made it so much) and these:

http://pastebin.com/3rpe5giR

(P.S: For Helepolis, those code above is not C# :V )

Copy and paste those code on console multiple time for fun (and change maxProjectile to 10000 just in case)

To terminate all task paste Shmup.advanced.temp().task = []; on console

As for curved lasers, there's a class in the engine called Bend which is a primitive made up of a strip of triangles mapped to a list of points and angles. The curved lasers each have their own Bend object and records a list of its own positions and angles and passes that to its Bend object. Bends can also be used on their own for effects like trails and lightning and magic circles.

Hm... pretty different from mine tho...

Btw this may help you a little bit (https://www.shrinemaiden.org/forum/index.php/topic,11868.msg877337.html)
Title: Re: Bloom Engine
Post by: mew77 on January 04, 2017, 04:31:36 pm
I have to say, I am rather impressed with your project. I feel I am trying to achieve similar things with my own, though the way I am going the engine is now specialized towards completing my thesis in Adaptive AI for a Bullet Hell game. In any case, it would be nice to have some help in improving my Warlockery Engine for future work. Also I have a XML data-driven set up for scripting my bullets, bullet patterns and enemies. I am curious if you were planning anything similar for Bloom Engine. In that regard, I am wondering about the "ZUN design" you mentioned in the original post.

A few things I am curious about as a fellow developer.

Last time I stress tested my system it started dropping below 60 fps at around 2500 bullets. I have yet to multi thread my system either. I'm curious if you've used an object pool to help with the system having to allocate/deallocate tons of bullets.

If it helps anyone my setup for storing bullets is like this:
Code: [Select]
//from my source code
typedef std::map<StringID, Bullets*> DanmakuPoolMap;
typedef std::map<StringID, Bullets*>::iterator DanmakuPoolMapIterator;
typedef std::pair<StringID, Bullets*> DanmakuPoolMapEntry;

typedef std::map<StringID, MeshRenderer*> DanmakuPoolRendererMap;
typedef std::map<StringID, MeshRenderer*>::iterator DanmakuPoolRendererMapIterator;
typedef std::pair<StringID, MeshRenderer*> DanmakuPoolRendererMapEntry;

I use the StringID with a string table, this way bullets with the same texture can be rendered together. But I think that Monogame thing can be helpful to me as well. What is monogame exactly? Is it a dll or something for sprite batching?

I particularly want to know a bit more how you did the Bend class for the curved lasers. I did a cubic hermite spline for the enemy flight paths, is that similar to how you use points and angles to set paths for your curvy lasers?Given that, how do you handle the collision. Sorry if I'm imposing here. I am simply a fellow developer hoping to learn how the heck to do curvy lasers.

Anyways thanks for indulging my curiosity, I wish you luck in developing this further, and hope we can be friends.  :P

mew77


Title: Re: Bloom Engine
Post by: Sage Ω (Ultima) on January 04, 2017, 05:12:10 pm
Last time I stress tested my system it started dropping below 60 fps at around 2500 bullets. I have yet to multi thread my system either. I'm curious if you've used an object pool to help with the system having to allocate/deallocate tons of bullets.

If it helps anyone my setup for storing bullets is like this:

//from my source code
typedef std::map<StringID, Bullets*> DanmakuPoolMap;
typedef std::map<StringID, Bullets*>::iterator DanmakuPoolMapIterator;
typedef std::pair<StringID, Bullets*> DanmakuPoolMapEntry;

typedef std::map<StringID, MeshRenderer*> DanmakuPoolRendererMap;
typedef std::map<StringID, MeshRenderer*>::iterator DanmakuPoolRendererMapIterator;
typedef std::pair<StringID, MeshRenderer*> DanmakuPoolRendererMapEntry;

I use the StringID with a string table, this way bullets with the same texture can be rendered together. But I think that Monogame thing can be helpful to me as well. What is monogame exactly? Is it a dll or something for sprite batching?


While I'm not the person you are looking for obviously I can definitely shed some light on your questions as a fellow developer and one who has made multiple engines before.

Monogame is a free to use game development framework. It is a lib that wraps OpenGL and DirectX to make it easier for programmers to use. It also includes helper classes for things like sprite rendering, model rendering, etc... It is written for .NET languages like C#, from the look of that source code you posted you're obviously using C++ so you can't really use Monogame. (Unless you want to use C++ CLI which would be a horrible idea)

Frame drops at 2500 seems somewhat reasonable but remember that a stress test is variable based on how far your engine has progressed. If all you have is bullet rendering and barely anything else you'll get inaccurate results. Also, your PC is a big factor in speed. If you have a really old PC that isn't very fast, you won't be able to get much from your own hardware and frame drops at 2500 seems reasonable. In a realistic game setting you never actually get anywhere near that amount though. Atleast not in Touhou.

I don't know what rendering api you use but in addition to grouping objects of the same texture you can also save performance by using the same render states, culling states, vertex and index buffer as well and anything that is not likely to change across a wide mass of bullets.

In my engine I use DirectX 11, I have a single vertex and index buffer for sprites. When rendering any 2D assets I set those first, and I use an instance buffer to handle drawing copies. The less calls to the rendering API you have to make, the less you have to worry about performance issues (atleast in DX this is the case, not sure about OpenGL).

Also multithreading is not the first thing you should look for with performance. Multithreading is a last resort and very situational thing. A danmaku engine doesn't need it, not big enough to see the benefits of having one. Not to mention multithreading is extremely difficult to manage and creates several problems that a normal synchronized game loop does not. Do you have super complex AI code? Heavy high production 3D rendering? Complex physics engine? If you answered no to any of these then you don't need multithreading so save yourself the heartache.



Title: Re: Bloom Engine
Post by: mew77 on January 04, 2017, 05:28:27 pm
Thanks for clearing that up Sage, and it's fine, I am just happy to discover a number of fellow programmers working with danmaku engines.

Admittedly I did that test on the current build which has all the game logic, Adaptive AI, effect, and jazz running so it's not a true stress test. The last time I truly stress tested my particle system (3d particles, drawing only a single colored point per particle)I had at least 10000+ before the framerate dropped. Come to think of it, what makes  "C++ CLI" a horrible idea.

Quote
In my engine I use DirectX 11, I have a single vertex and index buffer for sprites. When rendering any 2D assets I set those first, and I use an instance buffer to handle drawing copies. The less calls to the rendering API you have to make, the less you have to worry about performance issues (atleast in DX this is the case, not sure about OpenGL).

Tell me more about these instance buffers you mention. I use OpenGL rendering btw. My Mesh Renderer wraps a Material which is a GL sampler and linked shader program. My mesh class wraps a vertex and index buffer. My biggest mistake when making it was not wrapping the render state or culling state with the meshrenderer. Would you suggest putting that as data in the material class for the render system to sort through and optimize?

Quote
Also multithreading is not the first thing you should look for with performance. Multithreading is a last resort and very situational thing. A danmaku engine doesn't need it, not big enough to see the benefits of having one. Not to mention multithreading is extremely difficult to manage and creates several problems that a normal synchronized game loop does not. Do you have super complex AI code? Heavy high production 3D rendering? Complex physics engine? If you answered no to any of these then you don't need multithreading so save yourself the heartache.

The more I think about multithreading, the more I realize that what you've told me is true. Warlockery does have a Job Manager for multithreading, but it's use has been mostly educational. Anyway glad to hear the same advice from you as most people have been telling me.

In the end, thanks for your prompt reply. Glad to know there are like-minded people around.

Title: Re: Bloom Engine
Post by: Sage Ω (Ultima) on January 04, 2017, 08:18:35 pm
Thanks for clearing that up Sage, and it's fine, I am just happy to discover a number of fellow programmers working with danmaku engines.

Admittedly I did that test on the current build which has all the game logic, Adaptive AI, effect, and jazz running so it's not a true stress test. The last time I truly stress tested my particle system (3d particles, drawing only a single colored point per particle)I had at least 10000+ before the framerate dropped. Come to think of it, what makes  "C++ CLI" a horrible idea.

C++ CLI is basically a hybrid of C++ and Microsoft's .NET Framework which is what languages like C# and Visual Basic are built on top of. The reason it isn't a good idea is because much of it is not compatible with unmanaged native C++ code without going through disgusting conversion libs provided by Microsoft. In the end, you would be better off with C# and or VB. This is why Microsoft really doesn't even support that anymore lol.

Tell me more about these instance buffers you mention. I use OpenGL rendering btw. My Mesh Renderer wraps a Material which is a GL sampler and linked shader program. My mesh class wraps a vertex and index buffer. My biggest mistake when making it was not wrapping the render state or culling state with the meshrenderer. Would you suggest putting that as data in the material class for the render system to sort through and optimize?

Instance buffers are known as the second vertex buffer. The reason why we call it "instance" is because OpenGL (3.2 I believe) and DirectX 10 and up support a mechanism to change the data sent to the vertex shader every draw call. The difference is that the APIs use only one draw call and you tell it how many instances or copies you want.

As for render states, I kept my render states in a sub class that controls 2D sprites and 3D models. I use material systems to draw all of those sub classes together. The sprite sub class contains the instance buffer for sprites. It contains a matrix for transforms, texture coords for each of the 4 vertices, and a color to tint the sprite with or change it's alpha value which is sent to the pixel/fragment shader. The sprite sub class contains all of the copies as well as information about how the material system should render all of these sprites. Render states, culling, depth states etc... The 3D sub-class does pretty much the same thing. I do it to add just a little flexibility with how I render things.

Also, Texture Arrays might be something to look into. They allow you to assemble multiple separate textures and send them to the pixel shader as a single texture. Not sure how much of it is a performance increase though but I have used it a few times for flexibility.


The more I think about multithreading, the more I realize that what you've told me is true. Warlockery does have a Job Manager for multithreading, but it's use has been mostly educational. Anyway glad to hear the same advice from you as most people have been telling me.



In the end, thanks for your prompt reply. Glad to know there are like-minded people around.

Yeah multithreading is scary, especially in C++. Anyway, something that I generally tell people when giving advice about performance is to just make your engine. Code smart and do reasonable things. Don't pre-optimize. You only need to optimize when you aren't hitting your target framerate consistently. Optimizing for situational things doesn't really help. Are you realistically going to have 2.5K bullets on screen at all times? If not then don't worry about it until you finish everything.

When you finish everything you need for your game and you still see bottlenecks and obvious frame drops then check and see what can you change or improve. That way you don't end up wasting time doing something you probably didn't need to do. Good luck.
Title: Re: Bloom Engine
Post by: Lishy1 on January 04, 2017, 11:28:08 pm
Will this have the capability to develop non-danmakufu style games?
Title: Re: Bloom Engine
Post by: Dark Kitsune on January 05, 2017, 12:46:24 am
I have to say, I am rather impressed with your project. I feel I am trying to achieve similar things with my own, though the way I am going the engine is now specialized towards completing my thesis in Adaptive AI for a Bullet Hell game. In any case, it would be nice to have some help in improving my Warlockery Engine for future work. Also I have a XML data-driven set up for scripting my bullets, bullet patterns and enemies. I am curious if you were planning anything similar for Bloom Engine. In that regard, I am wondering about the "ZUN design" you mentioned in the original post.

I considered it but didn't think it would be too necessary given that there's a live sandbox mode and it's easy to script bullet patterns without using many loops and wait()s.
It shouldn't be too hard to add and I can work it into the resource system so that patterns can be referred to by name and be automatically guarded from unnecessary repeated loading.



A few things I am curious about as a fellow developer.

Last time I stress tested my system it started dropping below 60 fps at around 2500 bullets. I have yet to multi thread my system either. I'm curious if you've used an object pool to help with the system having to allocate/deallocate tons of bullets.

I use simple global objects list (System.Collection.Generic.List) and when an object is deleted it has a flag set and then at the end of the update all objects with that flag set are removed from the list in a loop. Not exactly fast if you, say, delete thousands of objects per second, though.
Most of time when a game lags in the engine it's from too much rendering. I use the MonoGame built in spritebatch to do rendering of objects, with depth sorting disabled and opting for multiple "layers" instead. It doesn't sound like this would help too much but it made all the difference in handling a lot of bullets at once.

Yes, as I've developed and tested more and more things going on at once I have seen a decline; before I estimated around 8000-9000 bullets at 60 FPS but that has since dropped to about 6000-7000 at normal operation with some effects and basic 3D backgrounds thrown in (specifically the demo in the main screenshot I have up right now.)

As for my computer I have an AMD FX 6300 GPU and an AMD A8-5557M CPU, and I'm running Linux. I can't play anything anywhere near modern games on minimum but it's an okay setup.



I particularly want to know a bit more how you did the Bend class for the curved lasers. I did a cubic hermite spline for the enemy flight paths, is that similar to how you use points and angles to set paths for your curvy lasers?Given that, how do you handle the collision. Sorry if I'm imposing here. I am simply a fellow developer hoping to learn how the heck to do curvy lasers.

It's just a simple primitive with the vertices placed at each point, offset with cos and sin using the angle of that point.
Visual example: http://pix.toile-libre.org/upload/original/1483577102.png

At the moment the hitboxes are placed at each point (generally they're closer together than in that example) but with really fast lasers this could lead to not getting hit when you should, so I might change how I do it.



Will this have the capability to develop non-danmakufu style games?

Do you mean scrolling shooter games in general? It could be used to make something like Dodonpachi or Gradius though it's made to be easiest to do 2hu style games.
It could theoretically be used to make mainly 2D non-scrolling-shooter games too such as RPGs and platformers but I'm not sure I recommend it. You'd probably be better off using an engine designed for the type of game you want to make, or making your own engine.

Reasons being that it has no built in tile rendering system, grid-based collision checking, or many other features that are great for genres outside scrolling shooter/bullet hell games.


I'm extremely sick right now so I won't be doing updates for a while and I might be late to answer questions.
Title: Re: Bloom Engine
Post by: Dark Kitsune on February 04, 2017, 10:31:28 pm
Time for a quick update on the project status!

I'm currently doing a rewrite of some of the parts to better match how i want to design Bloom Engine, as well as adding more automated processes to reduce the amount of code needed to do common things:

- Tasks are now started with the function task(function, arg1, arg2, arg3, ...) rather than the old method of using task(function) to create a task object which is then called like a function at any point. This makes it faster and easier to use tasks where you only need to call them on one line, and reduces a lot of the previous clutter of {}s and ()s.
- Objects now contain offset position, angle, render angle, scale, and speed parameters which are added onto the equivalent base parameters when used in the engine. This makes it very very easy to do stuff like a hover effect on bosses and shots that wiggle on their flight path, without affecting their actual position, speed, angle, etc.
- Options now have unfocused and focused position parameters and automatically use them based on whether the player is focused or not, if the options have their parent parameter set to a player.
- Options can also have their parent parameter set to other objects too but will always used their unfocused position if the object is not a player.
- Player shots can now be fired from options by supplying the option in place of the X and Y (still works with other object types besides options too though).
- Player shots can also be set to automatically home on nearest enemies now.

I'll be adding more changes to the above list as I work on it. Working on a demo still as well... I just took a long hiatus for sickness and stuff, didn't cancel all this.
Title: Re: Bloom Engine
Post by: Dark Kitsune on March 13, 2017, 06:41:27 pm
I've begun a lot of major changes. Mainly, I'm now porting the engine to use SFML instead of MonoGame and changing Lua implementation from NLua to MoonSharp.

The reason for me changing to SFML is that I hit two major roadblocks with MonoGame:
 1. The sound system does not appear to work correctly on all platforms.
 2. MonoGame does not allow you to compile shaders at runtime.
Both of these things are essential for the engine, and SFML provides both. It's also potentially more powerful overall anyway, since you can do raw OpenGL calls in it.
Along with using SFML I'm massively improving the layer system by allowing them to be added, removed, moved, rotated, scaled, set to invisible, have their update loop paused, have shaders attached to them, and be used as textures.

The reason for switching to MoonSharp over NLua is because NLua uses heavier reflection and as a result is quite a bit slower than Lua implementations should be. Calls to .NET code from scripts are really bad performance-wise in NLua so it's not a great option. Additionally, MoonSharp has much better exception handling than NLua so I can provide much better error messages.

I'll also be switching to an integer pointer system for object references rather than userdata (what was used before) and so method syntax will no longer be possible but in return the engine will be able to handle nonexistant objects better and it might be faster too.


It will be a little while before a demo is out because I'm essentially rewriting half the engine again. But this will be much better in the long run.
Title: Updates
Post by: Dark Kitsune on April 20, 2017, 06:45:17 am
Bloom Engine is now mostly usable again! Example scripts are in progress right now.

There's been a lot of changes since switching to SFML, and some of the less important things (such as skeletons and particles) still need to be ported over.
I'll also be producing some new videos to reflect the changes.

One thing to note is that in exchange for everything being more stable than before, everything is also a bit slower than before. The engine can't quite reach the number of bullets that it could previously, but it's still fast enough for anything on a normal Touhou-ish level and no longer breaks if you simply try to play a sound or use a method on a nil value :V
Title: Re: Bloom Engine
Post by: Dark Kitsune on July 12, 2017, 05:13:54 am
Alright, I know this has been happening a lot, but Bloom Engine has gone through one last big rewrite!
I finally gave up on trying to find simpler and lazy solutions and just wrote my own rendering and audio playing code from the ground up.
It took a lot of work and time but now it's real fast, supports shaders, has no issues playing sound, and supports hardware 3D properly now! In other words, there's no more need to rewrite stuff anymore.

A little example video combining 3D and 2D graphics in the new engine https://www.youtube.com/watch?v=4Rv2RXxv5B4

I'll likely do a performance demo too once i optimize a few things that are bottlenecking the render loop.