Author Topic: [Cancelled, rewritten] Old Bloom Engine  (Read 6975 times)

Dark Kitsune

  • Code Fox
[Cancelled, rewritten] Old Bloom Engine
« on: July 28, 2015, 05:40:04 AM »
Bloom Engine 4
Bloom 4 is partial reboot of Bloom 3, which is a complete reboot of Bloom 2 from the ground up in GameMaker:Studio. It takes the best features from Bloom 2 and features from Danmakufu and the official Touhou scripts and combines them in a faster and much more versatile engine than legacy versions of Bloom.
The engine is far from completion or even release for public use but I have produced a few short demos in it.
(Bloom 3 is mostly complete but may not be suitable for public release as it requires a paid copy of GameMaker:Studio for YoYoCompiler otherwise it can get a little slow).

Features:
- Event-based scripting
- Shots, loose lasers, straight lasers, curve lasers
- Movement and pattern functions
- Seamless control over display aspect such as resolution and playing field size/depth
- Scripting should (eventually) feel familiar to DNH users
- Shots can also move along a Z dimension, allowing seamless 3D patterns
- Many built-in common effects that be easily customized
- Will eventually be multi-platform
- Joints for shot/object skeletal systems (maybe; might be a little too useless)
- Building pattern shapes from images (maybe; might be a little too useless)

Demo projects using Bloom 4:
None yet.

Demo projects using Bloom 3:
Tokyo Sky Wars - http://gmc.yoyogames.com/index.php?showtopic=670889
Phantasy of Abandoned Hell - https://www.shrinemaiden.org/forum/index.php/topic,18639.msg1202425.html#msg1202425

Images, Video, & Code:
First pattern in the new scripting language [B4]
Code for above
Tokyo Sky War [B3]
Phantasy of Abandoned Hell [B3]
« Last Edit: November 12, 2016, 07:54:56 AM by Dark Kitsune »

Re: Bloom Engine 3
« Reply #1 on: July 28, 2015, 08:55:10 PM »
This looks interesting! I'll keep an eye on it. :)!

If you want to see the code for any features in my engine I'll be happy to share, my code is shocking though.  :blush:

https://www.shrinemaiden.org/forum/index.php/topic,18145.0.html

Dark Kitsune

  • Code Fox
Re: Bloom Engine 3
« Reply #2 on: July 28, 2015, 09:01:23 PM »
I've been keeping an eye on your engine for a little while myself :P

Re: Bloom Engine 3
« Reply #3 on: July 30, 2015, 05:10:48 PM »
Nice to see you continue on Bloom Engine !

Dark Kitsune

  • Code Fox
Re: Bloom Engine 3
« Reply #4 on: July 31, 2015, 08:54:55 AM »
The interpreter is starting to take shape~
Currently valid example syntax: http://pastebin.com/T0AGxn0y
« Last Edit: July 31, 2015, 08:58:20 AM by Ran Yakumo »

Kaze_Senshi

  • Ehhhhh...
  • Pale Apple
    • My youtube channel
Re: Bloom Engine 3
« Reply #5 on: July 31, 2015, 03:04:01 PM »
dat infinite loop  :3
My youtube channel with my creations: https://www.youtube.com/user/KazeSenshi2929
( ゆっくりしていってね)>

Uruwi

  • Nightmare of Torrential Precipitation
  • 478 million goober
Re: Bloom Engine 3
« Reply #6 on: July 31, 2015, 04:43:17 PM »
Why a dollar sign when using a variable in an expression, but not when declaring a variable?

Also, remember to make arrays random access.
foo = foldl $ flip ($)
Highest difficulty 1CCed for each game, by shot type in the original order. (-: never 1CCed on any difficulty, or never used; E: easy, N: normal, H: hard, L / U: lunatic / unreal.)
EoSD [NNNE] PCB [EE--N-] IN [NEEE + Ex Border] PoFV [Mystia N, Mystia E no charge] MoF [EN--H- + Ex Marisa B] SA [N-----] UFO [----EN] TD [NENE] DDC [EE-EHE + Ex Marisa B & Sakuya A] LoLK [PD --N- Legacy ---N] EE [N- + Ex Yabusame] EMS [N-- + Ex Yabusame] RMI [NHN + Ex YaoSuku]
Avelantis (demo) Easy YuukiB 426,077,200

Dark Kitsune

  • Code Fox
Re: Bloom Engine 3
« Reply #7 on: July 31, 2015, 04:49:05 PM »
Why a dollar sign when using a variable in an expression, but not when declaring a variable?
The dollar sign tells it to use the value, rather than the reference.

Uruwi

  • Nightmare of Torrential Precipitation
  • 478 million goober
Re: Bloom Engine 3
« Reply #8 on: July 31, 2015, 04:54:55 PM »
The dollar sign tells it to use the value, rather than the reference.

So there's both pass-by-value and pass-by-reference?

Few other languages are that inconsistent with variables, though.
foo = foldl $ flip ($)
Highest difficulty 1CCed for each game, by shot type in the original order. (-: never 1CCed on any difficulty, or never used; E: easy, N: normal, H: hard, L / U: lunatic / unreal.)
EoSD [NNNE] PCB [EE--N-] IN [NEEE + Ex Border] PoFV [Mystia N, Mystia E no charge] MoF [EN--H- + Ex Marisa B] SA [N-----] UFO [----EN] TD [NENE] DDC [EE-EHE + Ex Marisa B & Sakuya A] LoLK [PD --N- Legacy ---N] EE [N- + Ex Yabusame] EMS [N-- + Ex Yabusame] RMI [NHN + Ex YaoSuku]
Avelantis (demo) Easy YuukiB 426,077,200

Dark Kitsune

  • Code Fox
Re: Bloom Engine 3
« Reply #9 on: July 31, 2015, 04:58:17 PM »
So there's both pass-by-value and pass-by-reference?

Few other languages are that inconsistent with variables, though.
It also serves to make it super easy for the interpreter to parse it and makes it much faster than without it. Rather than searching for probable variables and checking if they exist, it can simply jump to the next $ then read after it.

Uruwi

  • Nightmare of Torrential Precipitation
  • 478 million goober
Re: Bloom Engine 3
« Reply #10 on: July 31, 2015, 08:31:15 PM »
It also serves to make it super easy for the interpreter to parse it and makes it much faster than without it. Rather than searching for probable variables and checking if they exist, it can simply jump to the next $ then read after it.

Irrelevant; you should be parsing source code to an intermediate format anyway.
foo = foldl $ flip ($)
Highest difficulty 1CCed for each game, by shot type in the original order. (-: never 1CCed on any difficulty, or never used; E: easy, N: normal, H: hard, L / U: lunatic / unreal.)
EoSD [NNNE] PCB [EE--N-] IN [NEEE + Ex Border] PoFV [Mystia N, Mystia E no charge] MoF [EN--H- + Ex Marisa B] SA [N-----] UFO [----EN] TD [NENE] DDC [EE-EHE + Ex Marisa B & Sakuya A] LoLK [PD --N- Legacy ---N] EE [N- + Ex Yabusame] EMS [N-- + Ex Yabusame] RMI [NHN + Ex YaoSuku]
Avelantis (demo) Easy YuukiB 426,077,200

Dark Kitsune

  • Code Fox
Re: Bloom Engine 3
« Reply #11 on: August 02, 2015, 08:34:11 PM »
Alright, I will look into avoiding the use of symbols, but this could cause the interpreter to be much more likely to become buggy as it will have to figure out whether to use the value or reference from context or what functions require. I am not confident in my ability to do that properly so I won't try too hard to attempt it in case it endangers the current stability and bugless-ness of the whole thing. Also this is only a single symbol, it's not that hard to use. I can also change to a different symbol that will be on more keyboards.
« Last Edit: August 02, 2015, 08:44:27 PM by Ran Yakumo »

Uruwi

  • Nightmare of Torrential Precipitation
  • 478 million goober
Re: Bloom Engine 3
« Reply #12 on: August 02, 2015, 09:04:31 PM »
I think you missed the point. You should be doing what Oracle did and create an interpreter for a virtual machine, then have source code compiled to VM bytecode.
foo = foldl $ flip ($)
Highest difficulty 1CCed for each game, by shot type in the original order. (-: never 1CCed on any difficulty, or never used; E: easy, N: normal, H: hard, L / U: lunatic / unreal.)
EoSD [NNNE] PCB [EE--N-] IN [NEEE + Ex Border] PoFV [Mystia N, Mystia E no charge] MoF [EN--H- + Ex Marisa B] SA [N-----] UFO [----EN] TD [NENE] DDC [EE-EHE + Ex Marisa B & Sakuya A] LoLK [PD --N- Legacy ---N] EE [N- + Ex Yabusame] EMS [N-- + Ex Yabusame] RMI [NHN + Ex YaoSuku]
Avelantis (demo) Easy YuukiB 426,077,200

Dark Kitsune

  • Code Fox
Re: Bloom Engine 3
« Reply #13 on: August 02, 2015, 09:05:52 PM »
No, no, I got that and did contemplate it before but it still has to interpret first to create the bytecode, so it can still use things like that to make it easier to interpret.
It already does some pre-compiling to a simpler form but not quite to bytecode yet.

Uruwi

  • Nightmare of Torrential Precipitation
  • 478 million goober
Re: Bloom Engine 3
« Reply #14 on: August 02, 2015, 09:10:11 PM »
No, no, I got that and did contemplate it before but it still has to interpret first to create the bytecode, so it can still use things like that to make it easier to interpret.
It already does some pre-compiling to a simpler form but not quite to bytecode yet.

By the way, how the hell are you parsing source code? I'd like to assess how difficult making variable declaration and reference consistent is.

Alternatively, you could use something like let x = 0; for assignment, so you wouldn't need any lookahead.
foo = foldl $ flip ($)
Highest difficulty 1CCed for each game, by shot type in the original order. (-: never 1CCed on any difficulty, or never used; E: easy, N: normal, H: hard, L / U: lunatic / unreal.)
EoSD [NNNE] PCB [EE--N-] IN [NEEE + Ex Border] PoFV [Mystia N, Mystia E no charge] MoF [EN--H- + Ex Marisa B] SA [N-----] UFO [----EN] TD [NENE] DDC [EE-EHE + Ex Marisa B & Sakuya A] LoLK [PD --N- Legacy ---N] EE [N- + Ex Yabusame] EMS [N-- + Ex Yabusame] RMI [NHN + Ex YaoSuku]
Avelantis (demo) Easy YuukiB 426,077,200

Dark Kitsune

  • Code Fox
Re: Bloom Engine 3
« Reply #15 on: August 02, 2015, 09:16:28 PM »
Basically, at the moment, the interpreter first finds any variables and replaces those with their values/reference IDs. Then it finds functions, and expressions (ones in parentheses are done separately in order from the highest depth to the lowest), and then executes itself recursively on those. And for each expression it starts at the top of the usual C order of precedence, and for each level, it finds the operators in that level from left to right and expands out to the left and/or right to find the operands then it replaces those with the result.
So the result is always the same as in C. For example, "(3 * 6) / (2 + 4 - (1 % 1))" results in 3

Also, the "real" or "string" before defining the variable is purely to tell it how to parse any expression after the = because it cannot tell the difference between strings and numbers from context at the moment.
« Last Edit: August 02, 2015, 09:22:45 PM by Ran Yakumo »

Dark Kitsune

  • Code Fox
Re: Bloom Engine 4 (and 3)
« Reply #16 on: November 21, 2015, 06:57:21 PM »
Decided to branch the version of Bloom 3 with scripting off into its own project and leave Bloom 3 as a fast and purely in-GM thing.
Also did tons of work on the interpreter over the last few days; you can find a new pattern code sample in the OP.

Delfigamer

  • * Merry, bride, absolute (HR)
  • of course the best girl never wins
Re: Bloom Engine 4 (and 3)
« Reply #17 on: November 28, 2015, 09:08:10 PM »
I rarely look in RaNGE, so my reply here is exceptionally late.

I've made a couple of attempts to implement a scripting language with static typing that would be translated to Lua scripts (which are dynamically typed) fed to LuaJIT VM.
At first, I've made a parsing library specifically to make sense of the sources. It's based on Parsing expression grammar concept, though optimized more for building abstract trees with use of some additional operators and structures.
This time, I've decided to instead implement a concrete parser directly, to make it a little faster and allow it to skip errors, though on similar basic principles.

There, the distinction between many kinds of tokens, including names and values, is made based on the first symbol. If it's a "letter", the sequence is determined to be a "word", which may be either a "keyword", if it belongs to a specified set, or an "identifier" otherwise. If it's a "digit", then number rules are invoked: the lexer checks if "0x" is present, and depending on that the sequence is interpreted as either a decimal or a hexadecimal number. If it's a quote symbol, the lexer reads a string literal. If it's the equality sign, we check for "==" digraph and yield either equality or assignment operator.
As it's a statically typed language, many decisions are made at compile-time based on the types of the values. For your case, it may be as simple as comparing actual argument types with the function definition, and probably checking if the value being called is indeed a function. I myself plan to have complex types, operator overloading and other pluses, so I go with a harder way of actual operator resolution.

As the language is intended to be translated to another scripting language, the bytecode produced is probably closer to register-based RISK instructions than to stack-based VM bytecode, and is designed to be very easily converted to Lua, though it shouldn't be very hard to choose another target which supports either multiple-return or pass-by-reference, for example Python. Though I have no idea which one is used by GM.

The Jealous Witch did nothing wrong.

Dark Kitsune

  • Code Fox
Re: Bloom Engine 4 (and 3)
« Reply #18 on: November 29, 2015, 07:33:06 AM »
As the language is intended to be translated to another scripting language, the bytecode produced is probably closer to register-based RISK instructions than to stack-based VM bytecode, and is designed to be very easily converted to Lua, though it shouldn't be very hard to choose another target which supports either multiple-return or pass-by-reference, for example Python. Though I have no idea which one is used by GM.
GM SORTA has pass-by-reference (the only "real" pass-by-reference is with arrays, in which case i think it's literally always pass-by-reference).
Since all variables can only be set to a number, array, or string, creating something such as an instance of an object type or a list returns the numerical "ID" of it. For example the first list created would be 0 then the next would be 1, etc. Then you can pass that ID to any function that takes a list ID, effectively passing it by its reference. But there's no way to reference simple numbers or strings, it's always done by copying.