bauxitedev / bitmapflow Goto Github PK

Caused by this Godot issue:
godotengine/godot#45822

It will gobble up RAM until it crashes. This is an issue in opencv-rust so there is not much to do about this, except maybe adding a minimum sprite size.

But for some reason I can build main branch

It fails building bitmapflow-rust specifically

OS: Fedora 33 x86_64
Bitmapflow version: 1.0.2 official

After extracting all files from the archive and adding the +x executable permission to bitmapflow.x86_64 (which is missing by default), I get this in the terminal:

Godot Engine v3.2.3.stable.official - https://godotengine.org
OpenGL ES 3.0 Renderer: GeForce GTX 1080/PCIe/SSE2
 
ERROR: open_dynamic_library: Condition "!p_library_handle" is true. Returned: ERR_CANT_OPEN
   At: drivers/unix/os_unix.cpp:426.
ERROR: get_symbol: No valid library handle, can't get symbol from GDNative object
   At: modules/gdnative/gdnative.cpp:501.
ERROR: init_library: No nativescript_init in "res://libbitmapflow_rust.so" found
   At: modules/gdnative/nativescript/nativescript.cpp:1506.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
ERROR: start: Condition "!valid_type" is true. Continuing.
   At: main/main.cpp:1766.
zsh: segmentation fault (core dumped)  ./bitmapflow.x86_64

gdb full backtrace:

#0  0x000000000044a984 in Variant::call_ptr(StringName const&, Variant const**, int, Variant*, Variant::CallError&) [clone .cold.492] ()
No symbol table info available.
#1  0x0000000000000000 in ?? ()
No symbol table info available.

The vergen crate used for version information seems to require a nightly compiler (as of version 1.50), and when everything using it was commented out it builds fine on stable Rust. Just wanted to mention it in case anyone faces the same issue :)

I haven't tested it with 1.51 yet, but maybe a mention about this in the README would help?

(Tested on Linux)

Hello, I thought I'd try to build the project on Mac, and I got through the dependencies and all that, however when trying to run cargo build --release I can't seem to get it past the open-cv step.

Not sure if this is a failure on my part of not setting up the open-cv dependencies correctly or what, but the log doesn't really seem to tell me anything clear.. would love some input if you have an idea of how to fix it 😄

bitmapflow_osx_build.log

I had tried to document my steps here as well:

https://gist.github.com/corjohnson/49d77b9f3e14478c29d8b30d6e9f9814

Hello,

I'm amazed by how good this technology is and I see massive potential in an area that leaves creative freedom in designing animations to the user: animation transitions.

In games, 2D animations stutter from one action to the other, where sudden stops in movement can look unnatural when there is no blending or inbetweening happening on the pixel level. Since blending can't really be done in 2D (at least what I know of), a good approach would be to let the computer calculate the inbetween frames (between finished animations, not the animations themselves) to "supplement" the sprite sheet instead of replacing what is in it, already. The final step would be to seemlessly integrate this as a datastructure into existing engines, where you don't even have to do the bookkeeping of which frames should go between what actions.

That way you don't go against the principles of animation (scale, stretch, tension, suspense) and leave the necessary control to the artist.

What do you think about this idea?