Maidens of the Kaleidoscope
~Hakurei Shrine~ => Rika and Nitori's Garage Experiments => Topic started by: Dark Kitsune 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] (https://i.gyazo.com/ef0aa5c53fed3ad272170235b4a5340d.mp4)
Code for above (http://pastebin.com/4hLVhUDM)
Tokyo Sky War [B3] (http://puu.sh/j5onl/f090bb4c5a.png)
Phantasy of Abandoned Hell [B3] (http://puu.sh/jfMQz/c59d300014.png)
-
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
-
I've been keeping an eye on your engine for a little while myself :P
-
Nice to see you continue on Bloom Engine !
-
The interpreter is starting to take shape~
Currently valid example syntax: http://pastebin.com/T0AGxn0y
-
dat infinite loop :3
-
Why a dollar sign when using a variable in an expression, but not when declaring a variable?
Also, remember to make arrays random access.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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 (https://github.com/delfigamer/mist/tree/master/output/scripts/peg) specifically to make sense of the sources. It's based on Parsing expression grammar (https://en.wikipedia.org/wiki/Parsing_expression_grammar) concept, though optimized more for building abstract trees (https://en.wikipedia.org/wiki/Abstract_syntax_tree) with use of some additional operators and structures.
This time, I've decided to instead implement a concrete parser directly (https://github.com/delfigamer/mist/tree/master/output/scripts/exl/parser), 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.
-
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.