GithubHelp home page GithubHelp logo

shinyblink / sled Goto Github PK

View Code? Open in Web Editor NEW
121.0 121.0 25.0 2.71 MB

Satanic/Sexy/Stupid/Silly/Shiny LED matrix controller

Home Page: https://shinyblink.github.io/sled/

License: ISC License

Makefile 1.02% C 87.51% Shell 0.82% Meson 0.31% Roff 0.11% HTML 8.60% C++ 1.52% Nix 0.10%
34c3 3ds 3ds-homebrew c card10 freebsd hacktoberfest hub75 led-controller led-matrix-displays linux raspberry-pi sdl2 ws2812b

sled's People

Contributors

20kdc avatar basxto avatar br-olf avatar cherouvim avatar cyriax0 avatar draradech avatar ds84182 avatar esden avatar fridtjof avatar gitter-badger avatar m4gnv5 avatar marenz2569 avatar mattvenn avatar myigel avatar orithena avatar q3k avatar rainerd avatar stary2001 avatar vifino avatar xermicus avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sled's Issues

Add /now to FISh

Add /now <module name> <parameters> to FISh.
If <module name> is not the name of the currently running module, this command should be ignored.

bgm_opc seems to deadlock on deinit

Seems to be more likely on some platforms than others. Easily reproducable on OSX, seems to happen quite often on BSD, but not always on Linux?

  • Temporary hotfix with a "panic" handler, 3 ^C = instant exit!
  • Fix the deadlock in bgm_opc.

@20kdc You should take a look at this.

Update Documentation

Dear Peeps,

could you please provide a better docu for features and/or better commandline-helptext like: what is filter and how i use ?

:-)

Segfault with small matrix sizes

sled crashes with segfault when using small matrix sizes like 10x10.
In this case I used out_sdl2 with scaling factor 1.
The version I am using is master as of now. (f558241)

Initializing modules...
    - sinematrix... Done.
    - candyflow... Done.
    - clock... Ignored by request of plugin.

Program received signal SIGSEGV, Segmentation fault.
──────────────────────────────────────────────────────────────────────────────────────────────────────────────[ registers ]────
$rax   : 0x000055555575e3c0  →  0x000000726f727265 ("error"?)
$rbx   : 0x0000000000000002
$rcx   : 0x0000000000000000
$rdx   : 0x00007fffffffdde0  →  0x00007fffffffdec0  →  0x00000000ffffffff
$rsp   : 0x00007fffffffe308  →  0x00005555555573b0  →  <matrix_getx+17> add rsp, 0x8
$rbp   : 0x0000000000000002
$rsi   : 0x0000000000000000
$rdi   : 0x0000000000000002
$rip   : 0x0000000000000000
$r8    : 0x0000000000000005
$r9    : 0x000055555575d5b0  →  0x000000736c6c6162 ("balls"?)
$r10   : 0x0000000000000058
$r11   : 0x000055555555739f  →  <matrix_getx+0> sub rsp, 0x8
$r12   : 0x000055555575d5b0  →  0x000000736c6c6162 ("balls"?)
$r13   : 0x0000000000000001
$r14   : 0x0000000000000000
$r15   : 0x0000000000000000
$cs    : 0x0000000000000033
$ss    : 0x000000000000002b
$ds    : 0x0000000000000000
$es    : 0x0000000000000000
$fs    : 0x0000000000000000
$gs    : 0x0000000000000000
$eflags: [zero carry parity adjust sign trap INTERRUPT direction overflow RESUME virtualx86 identification]
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ stack ]────
0x00007fffffffe308│+0x00: 0x00005555555573b0  →  <matrix_getx+17> add rsp, 0x8   ← $rsp
0x00007fffffffe310│+0x08: 0x0000000000000008
0x00007fffffffe318│+0x10: 0x00007ffff6a5dad7  →  <init+13> mov ebx, eax
0x00007fffffffe320│+0x18: 0x0000000000000002
0x00007fffffffe328│+0x20: 0x0000000000000002
0x00007fffffffe330│+0x28: 0x00007fffffffe3a8  →  0x000000000000000b
0x00007fffffffe338│+0x30: 0x0000555555558f11  →  <modules_init+345> mov r13d, eax
0x00007fffffffe340│+0x38: 0x00000000ffffffff
───────────────────────────────────────────────────────────────────────────────────────────────────────[ code:i386:x86-64 ]────
[!] Cannot disassemble from $PC
────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ threads ]────
[#0] Id 1, Name: "sled", stopped, reason: SIGSEGV
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────[ trace ]────
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
0x0000000000000000 in ?? ()
gef➤  bt
#0  0x0000000000000000 in ?? ()
#1  0x00005555555573b0 in matrix_getx () at src/matrix.c:37
#2  0x00007ffff6a5dad7 in init (moduleno=0x2, argstr=<optimized out>) at src/modules/gfx_balls.c:32
#3  0x0000555555558f11 in modules_init (outmodno=outmodno@entry=0x7fffffffe3a8) at src/modloader.c:179
#4  0x0000555555557070 in sled_main (argc=<optimized out>, argv=<optimized out>) at src/main.c:234
#5  0x00005555555590b9 in main (argc=<optimized out>, argv=<optimized out>) at src/os/os_unix.c:22

out_sacn/artnet: Streaming ACN and ArtNet output

Outputting sACN frames would be great, as there are many matrix setups in the lighting industry that accept sACN or ArtNet.

  • ArtNet
    • Wasn't it license encumbered? Need to check.
  • sACN

The MateLight at GPN 2018 had sACN ArtNet support, hopefully they'll add this output module. :)

out_rpi_ws2812b: RGBW support

There are basically two types of ws2812b strips: RGB and RGBW, the latter having a seperate white LED.

The former we support, the second we should support as well.
There are two stages to support this:

  • Make it use RGB only, padding the fourth byte.
  • Extrapolate the white byte by the RGB values, trying to mix it as best as possible.
    • Need to make sure the brightness is correct.

Build system's include order is a bit messy

setting STATIC and DEFAULT_OUTMOD currently only works if done in sledconf. If set elsewhere (e.g. in a platform Makefile), the build breaks.

However, for many platforms, there is only one value that makes sense for those settings, so they would be better set in the platform's Makefile.

gfx_sort1D: out of matrix bounds set

While running sort1D as the only effect, I've found that it fails an assertion.
This manifests on a real matrix as a cut off screen.

This happens with every* run of algo 16, merge_sort_inplace, any draw/highlight style combination.

>> Now drawing sort1D (algo 16, draw style 0)...................................
................................................................................
.....................................Assertion failed: x < matx (src/modules/out_sdl2.c: set: 93)

Failed to load out_mpsse_spi: libmpsse.so: cannot open shared object file: No such file or directory

Beim starten von sled mit mpsee als output bekomme ich folgenden Fehler:
Failed to load out_mpsse_spi: libmpsse.so: cannot open shared object file: No such file or directory

Die Installation von mpsee sieht okay aus:

sudo make install       
install -D -m644 pylibmpsse.py  //usr/local/lib/python2.7/dist-packages/pylibmpsse.py
install -D -m644 _pylibmpsse.so //usr/local/lib/python2.7/dist-packages/_pylibmpsse.so
install -D -m644 mpsse.py       //usr/local/lib/python2.7/dist-packages/mpsse.py
install -D -m644 libmpsse.so //usr/local/lib/libmpsse.so
install -D -m644 libmpsse.a  //usr/local/lib/libmpsse.a
install -D -m644 mpsse.h     //usr/local/include/mpsse.h

Wo erwartet sled den die libmpsse.so ?

Rename SDL_SCALE_FACTOR

and merge it with out_ctru's SCREEN_SCALE.

That way we have a generic mechanism to scale output.

return 1 after timer_add(...) breaks modules

Reproducing:

In an gfx_* module (e.g. gfx_rainbow)

int draw(int argc, char* argv[]) {
    [...]
    frame++;
    nexttick += FRAMETIME;
    timer_add(nexttick, modno, 0, NULL);
    if (frame > 100) return 1;
    return 0;
}

What happens

After returning 1 modules the timers are broken and modules start a switch loop in which the last two modules are switched rapidly without waiting for timers or fininshing. The output is erratic. No modules run normally.

Possible solutions

clear timer for that module after a module returns 1

gfx_sort1 takes way too long on big matrices

It should probably try to finish in a fixed time - or at least similar times - when running on a different matrix size.

On my X200's display, it takes a long time, probably over a minute.

Improvement: Readme: Initial setup

  • Document the required touch sledconf
  • Add a list of required Software to build the project (for example make and libsdl2-dev on debian)
  • HowTo: Only run given animations (delete the other .so files from /modules/)
  • HowTo: Configure project

flt_scale and out_sdl2 do not work together

The problem is that out_sdl2 refers to getx() and gety() without knowing if they are really calling the function of this shared library.
This results in scaled up matrices, but out_sdl2 only shows a part in the top left corner.
Every module must call its own functions like this:

module *this = NULL;

int init(int modno, char *argstr) {
  // this cannot fail, no error parsing is required
  // if this would fail something is seriously wrong
  this = modules_get(modno);

  // and so one
}

int getx(void) {
  return MATRIX_X;
}

int set(int x, int y, RGB *color) {
  if (x<0 || y<0)
    return 1;
  if (x >= this->getx() || y >= this->gety())
    return 2;

  // and so one
}

this->getx() is only getx() in the current version.

Furthermore asserts should be avoided as these will cause people writing animations reimplementing said behaviour of the function int set(...) over and over.

bgm_pixelflut performance improvements

We might wanna improve the pixelflut performance.
Once #33 is fixed, we can implement a multithreaded pixelflut server like Pixel.

This would allow us to run probably quite a bit faster.
If we implement some network abstractions, it'll be portable as well.

After we get the taskpool working and merged, I'll comb through the pixelflut server and try to make it as fast as I can.

Multithreading/Multitasking

Since f991962 we got a thread/task abstraction.
So, the next natural step is to parallelize things.

I believe this should be done in a rather generic fashion, rather than hardcode things. Focussing on reusability is quite important.

  • Mutex abstraction
  • Task abstraction
  • Worker pool
    • Start tasks on startup, add jobs (ie function and ctx) to queue when needed, wait.
  • Add little wrappers for pixel setting for loops.
    • The wrapper function can be easily reused this way, it'll be in the core so the compiler might be able to inline some functions.

Request for exemplary part list

Hi,
can you write down a exemplary list of parts on needs for sled or for your original configuration so that hard- and software are working together?

Thanks in advance,

gfx_ip heap-buffer-overflow

-fsanitize=address found this.

>> Now drawing ip=================================================================
==14656==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6060000888c0 at pc 0x0001038fe258 bp 0x7ffeedb2f030 sp 0x7ffeedb2f028
WRITE of size 8 at 0x6060000888c0 thread T0
    #0 0x1038fe257 in reset (gfx_ip.so:x86_64+0x1257)
    #1 0x1020d1db3 in sled_main main.c:271
    #2 0x7fff707b0114 in start (libdyld.dylib:x86_64+0x1114)

0x6060000888c0 is located 0 bytes to the right of 64-byte region [0x606000088880,0x6060000888c0)
allocated by thread T0 here:
    #0 0x10214be27 in wrap_calloc (libclang_rt.asan_osx_dynamic.dylib:x86_64+0x56e27)
    #1 0x1038fdd9e in init (gfx_ip.so:x86_64+0xd9e)
    #2 0x1020d63fc in modules_init modloader.c:180
    #3 0x1020d1a8b in sled_main main.c:238
    #4 0x7fff707b0114 in start (libdyld.dylib:x86_64+0x1114)

SUMMARY: AddressSanitizer: heap-buffer-overflow (gfx_ip.so:x86_64+0x1257) in reset
Shadow bytes around the buggy address:
  0x1c0c000110c0: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa
  0x1c0c000110d0: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
  0x1c0c000110e0: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
  0x1c0c000110f0: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 00
  0x1c0c00011100: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa
=>0x1c0c00011110: 00 00 00 00 00 00 00 00[fa]fa fa fa 00 00 00 00
  0x1c0c00011120: 00 00 04 fa fa fa fa fa fd fd fd fd fd fd fd fa
  0x1c0c00011130: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
  0x1c0c00011140: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
  0x1c0c00011150: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa
  0x1c0c00011160: fa fa fa fa 00 00 00 00 00 00 00 fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==14656==ABORTING
zsh: abort      ./sled

RFC: Supporting Inputs

Nice library you got there, planning on building a matrix myself and want to use sled :)

Was wondering (and I hope I didn't miss anything, I only had a quick read-through of the README), but is there any (planned) support for input devices? I mean like joysticks, gamepads, keyboards, mice.

I think having support would open a whole new world of possibilities, you could have interactive menus, games, etc.

The actual technical solution for supporting those is secondary I think, first would have to decide if it's a good idea ;)

compile/run issue out_rpi_ws2812b

sled on raspberry pi give me following failure:

./sled -o rpi_ws2812b
Failed to find symbol 'get' in out_rpi_ws2812b: ▒$▒

Is there something special for build the libws2811.a?

Detect Hangs

We need to handle plugins crashing, one major example is out_mpsse_spi, which seems to like to crash randomly. :V

sled tries to draw output module if it's the only loaded module

From @20kdc:

$ SLED_SCOPE_INPUT="none" ./sled -m tm
Loading modules...
        - gfx_scope.so... Done.
        - out_sdl2.so... Done.
Loaded 2 modules.
Initializing modules...
ALSA lib pcm.c:2565:(snd_pcm_open_noupdate) Unknown PCM none
        - scope...Couldn't open stream: -2
 Ignored by request of plugin.

Done.
>> Now drawing sdl2Segmentation fault (core dumped)

Ignoring the fact that it's about the oscilloscope module, sled tries to draw sdl2. wat.

Compile/Run issues

Hi, I can't get this project to run on my laptop...

First attempt to compile didn't work out:

dave@squeak:~/Development/sled$ make
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/asl.c	-o src/asl.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/modloader.c	-o src/modloader.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/color.c	-o src/color.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/matrix.c	-o src/matrix.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/timers.c	-o src/timers.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/random.c	-o src/random.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/mathey.c	-o src/mathey.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/graphics.c	-o src/graphics.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/util.c	-o src/util.o
cc -c -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -Isrc 	-DPLATFORM_SDL2 -DMATRIX_X=16 -DMATRIX_Y=8 -DMATRIX_ORDER_SNAKE -DSDL_SCALE_FACTOR=8	src/main.c	-o src/main.o
cc -std=gnu99 -O2 -Wall -Wno-unused-command-line-argument  -Og -ggdb -rdynamic  -lm -ldl -o sled	src/asl.o src/modloader.o src/color.o src/matrix.o src/timers.o src/random.o src/mathey.o src/graphics.o src/util.o src/main.o 
src/modloader.o: In function `dlookup':
/home/dave/Development/sled/src/modloader.c:34: undefined reference to `dlsym'
/home/dave/Development/sled/src/modloader.c:35: undefined reference to `dlerror'
/home/dave/Development/sled/src/modloader.c:37: undefined reference to `dlclose'
src/modloader.o: In function `modules_loadmod':
/home/dave/Development/sled/src/modloader.c:74: undefined reference to `dlerror'
/home/dave/Development/sled/src/modloader.c:75: undefined reference to `dlopen'
/home/dave/Development/sled/src/modloader.c:77: undefined reference to `dlerror'
src/modloader.o: In function `modules_init':
/home/dave/Development/sled/src/modloader.c:216: undefined reference to `dlclose'
src/matrix.o: In function `matrix_deinit':
/home/dave/Development/sled/src/matrix.c:82: undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
GNUmakefile:57: recipe for target 'sled' failed
make: *** [sled] Error 1

I solved that by adding another $(LIBS) at the end of line 57 of the GNUmakefile.

With that, and installing libsdl2-dev:i386, I got it to compile. But then it borked out with a segmentation fault:

dave@squeak:~/Development/sled$ gdb sled
GNU gdb (Ubuntu 7.12.50.20170314-0ubuntu1.1) 7.12.50.20170314-git
[..]
Reading symbols from sled...done.
(gdb) r
Starting program: /home/dave/Development/sled/sled 
Loading modules...
	- out_sdl2.so... Done.
	- gfx_plasma.so... Done.
	- flt_debug.so... Skipping unused filter modules.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
	- bgm_fish.so... Done.
	- gfx_twinkle.so... Done.
	- gfx_gol.so... Done.
	- gfx_rainbow.so... Done.
	- gfx_balls.so... Done.
	- gfx_sinematrix.so... Done.
	- gfx_text.so... Done.
	- gfx_random_static.so... Done.
	- gfx_clock.so... Done.
	- gfx_checkerboard.so... Done.
	- flt_gamma_correct.so... Skipping unused filter modules.
	- gfx_math_sinpi.so... Done.
	- gfx_random_rects.so... Done.
Loaded 14 modules.

Program received signal SIGSEGV, Segmentation fault.
_dl_signal_error (errcode=0, objname=0x805a460 "./modules/out_sdl2.so", occation=<optimized out>, 
    errstring=0xbfffed50 "undefined symbol: SDL_Init") at dl-error.c:94
94	dl-error.c: No such file or directory.
(gdb) 

Data about the system and libraries, maybe this info is useful:

dave@squeak:~/Development/sled$ uname -a
Linux squeak 4.10.0-42-generic #46-Ubuntu SMP Mon Dec 4 14:36:05 UTC 2017 i686 i686 i686 GNU/Linux
dave@squeak:~/Development/sled$ dpkg -l "libsdl2*" | grep ii
ii  libsdl2-2.0-0:i386     2.0.5+dfsg1-2ubuntu3 i386         Simple DirectMedia Layer
ii  libsdl2-dev            2.0.5+dfsg1-2ubuntu3 i386         Simple DirectMedia Layer development files
ii  libsdl2-gfx-1.0-0:i386 1.0.1+dfsg-4         i386         drawing and graphical effects extension for SDL2
ii  libsdl2-gfx-dev:i386   1.0.1+dfsg-4         i386         development files for SDL2_gfx
dave@squeak:~/Development/sled$ file sled
sled: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=022bf925c5a5029e3d06f7eaef9e724b041d57df, not stripped

As I'm not quite used to debugging this, I'm at a loss here. Any ideas?

Buildsystem improvements

While I don't want cmake or anything of that sort, writing better Makefiles is something that should be done.

  • Get rid of the multiple makefiles, merge them.
  • Support cross-compiling.
  • Support different dynamic library file extensions.
  • Split modules in portable/unportable sections.
  • CI for 3ds port.
  • CI for card10 port.

Argparsing for output modules

Arguments should be passed to output modules to get rid of the defines, i.e. in out_sdl2.
When simply just -[any character] would be enough then 20h's arg.h could be used.
I have some code ready to use if this adequate.

CI/CD for sled

Having a service such as Travis continuously build and test sled on each commit would be quite handy.

Checklist to full testing:

  • Build on each commit.
  • Implement a sled dummy benchmark backend, where wait_until does nothing.
  • Implement a sled mode where, instead of randomly queuing modules, every module gets run sequentially, then deinit after a few rounds.
  • Report status back to GitHub, including errors and warnings.
  • ASAN.

Portability

Most of sled is already portable by design.
However, we have some platform specific code. Thanks to @20kdc, this is now mostly abstracted away.

We still need to abstract some stuff away..

  • Threading
    • We got mutexes but no threading, wtf?
  • Output
    • Not every platform has a working printf.

So, time for some platforms!

  • os_unix: Unix-likes. The OG platform.
  • os_dummy: A stub, should run barebones, maybe.
  • os_3ds: A Nintendo 3DS platform. Uses service calls for sleep and such.
  • os_freertos: FreeRTOS support. With this, we can work on some MCU's.
    • Notably: ESP8266, ESP32. See #26.

bgm_pixelflut: random stutter

Pixelflut experiences some strange lag every now and then.
I don't think it's related to mutexes of the module, there is some other lag.
Might be the threadpool? Might be other bgm modules?

out_sdl2 improvements

List of improvements to out_sdl2, the SDL debug frontend for sled:

  • Adaptive scaling
    • Resizing the window, etc... Quite important.
  • FPS counter
    • Useful for debugging and finding issues with too high/low refresh rate.
  • vsync option.
    • While it doesn't matter for most things, this can help writing adaptive code, that runs at the maximum speed possible.

Should we enforce unsignedness more strictly?

There are various places (example: matrix_getx, matrix_gety, sdl_event_break in out_sdl2.c) where an int is used instead of a uint.
Should we make variables strictly unsigned where it makes sense, or is allowed by all uses of that variable?
Of course, I'm only suggesting this because CLion told me to. :D

Abstraction for networking modules

define and implement minimal API that provides send, select, ... so various networking modules can be implemented using the OS networking API (bsd sockets, freertos+tcp, ...).
we should also have a clear udp api.

Feature request: Global FPS variable

I think it is useful if a global FPS variable would be introduced and all animations would use it, well except the ones which do not update the screen for a certain amount of time, like gfx_error.

RFC: Scripting

Not just scripting, but rather loading modules of different types.

My plan is to implement another module type, mod. It's basically a module loader, as as module.
The idea is that we can implement a really bare-bones modloader in the core, add perhaps missing APIs and not only outsource the complex loading, but also allow the addition other loaders that aren't loading dynamic objects for example, but Lua or Scheme scripts.
This could make the effect prototyping phase even faster, which is already something we're pretty good at.

Ideally, with this rework, we'd also support dynamic module loading and unloading, probably invoked via FISh.

  • Introduce mod module type: Module loaders.
  • Introduce mod_native for loading existing sled-native modules.
    • This can have quite some complexity, maybe introducing search paths and other goodies?
    • With this, feature parity to the existing master is reached.

  • Introduce mod_lua for Lua(JIT) based scripting. Same methods, but Lua.
    • Should be beginner-friendly, heh.
  • Introduce mod_chicken for CHICKEN scheme.
    • While Scheme's not everybody's favourite, it's pretty great.

Packaging

So, as sled is progressing more and more each day, it actually becomes more useful to have it packaged for distributions.

Order is as follows:

  • Make sled's headers follow a more library-esqe pattern. (sled/plugin.h, etc..)
  • Package for Gentoo.
    • USE flags for module selection!
  • Package for Arch's AUR.
    • Split into multiple packages.
  • Docker images
    • we can build everything for a certain arch there, then supply sled as the entrypoint.

  • Version sled. Not sure I like that.
  • Package for Alpine.
  • Package for FreeBSD.
  • Package for OpenBSD(?).
  • Package for Ubuntu and Debian.

Make gfx_sinematrix size-independent

Hi, since you asked on twitter about size independence of gfx_sinematrix...

This code here for src/modules/gfx_sinematrix.c:draw() pretty much does it. The size_factor does not have to be PI, it just fitted when I tried it ^^

        matrix_clear();

        const int mx = matrix_getx();
        const int my = matrix_gety();
        const float size_factor = M_PI;
        const float fx = mx / size_factor;
        const float fy = my / size_factor;

        pangle = addmodpi( pangle, (0.00937) + (angle/256) );
        angle = cosf(pangle) * M_PI;
        sx = addmodpi( sx, 0.00673 );
        sy = addmodpi( sy, 0.00437 );
        tx = addmodpi( tx, 0.0239/mx );
        ty = addmodpi( ty, 0.0293/my );
        cx = addmodpi( cx, 0.00197 );
        cy = addmodpi( cy, 0.00227 );
        rcx = (mx/2) + (sinf(cx) * mx);
        rcy = (my/2) + (sinf(cy) * my);
        basecol = addmod( basecol, 1.0, 0.007 );

        matrix rotate = {
          .v1_1 = cosf(angle),
          .v1_2 = -sinf(angle),
          .v2_1 = sinf(angle),
          .v2_2 = cosf(angle),
        };
        matrix scale = {
          .v1_1 = (sinf(sx) + 0.35)/fx,
          .v1_2 = 0,
          .v2_1 = 0,
          .v2_2 = (cosf(sy) + 0.35)/fy,
        };
        vector translate = {
          .x = sinf(tx) * mx,
          .y = sinf(ty) * my,
        };

Timer overflow issues?

I found a reason for lockup after letting sled run for over an hour on a 32-bit linux machine. Looks like a timer/counter overflow issue to me, because sled locks up (a.k.a. sleeps for waay too long) after roughly an hour (running gfx_candyflow with out_sdl2), which is consistent with 2^32 microseconds (= 4292s = 71.5m = 1.19h).

Here is the full gdb backtrace full output. I did not dive into the timer code, so I do not fully understand what is going on here, but tnow, sleeptime and desired_usec looks wrong to me.

#0  0xb7fd9cf9 in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7e5221d in ___newselect_nocancel () at ../sysdeps/unix/syscall-template.S:84
No locals.
#2  0x0804d1d5 in oscore_event_wait_until (ev=0x805c498, desired_usec=4294960122) at src/os/os_unix.c:39
        tnow = 1803
        sleeptime = 4294958319
        oei = 0x805c498
        timeout = {tv_sec = 2845, tv_usec = 623426}
        set = {__fds_bits = {8, 0 <repeats 31 times>}}
#3  0x0804af6a in wait_until_core (desired_usec=4294960122) at src/timers.c:40
No locals.
#4  0xb7fd101b in wait_until (desired_usec=4294960122) at src/modules/out_sdl2.c:121
        tnow = 4294958964
        sleeptimems = 1
        ev = {type = 0, common = {type = 0, timestamp = 0}, window = {type = 0, timestamp = 0, windowID = 134534271, event = 0 '\000', 
            padding1 = 0 '\000', padding2 = 128 '\200', padding3 = 63 '?', data1 = 1065353216, data2 = 0}, key = {type = 0, timestamp = 0, 
            windowID = 134534271, state = 0 '\000', repeat = 0 '\000', padding2 = 128 '\200', padding3 = 63 '?', keysym = {
              scancode = 1065353216, sym = 0, mod = 17472, unused = 0}}, edit = {type = 0, timestamp = 0, windowID = 134534271, 
            text = "\000\000\200?\000\000\200?\000\000\000\000@D\005\b\000\000\000\000\000\000\005\b\370\355\377\277\243\262\004\b", 
            start = 134562880, length = 134545840}, text = {type = 0, timestamp = 0, windowID = 134534271, 
            text = "\000\000\200?\000\000\200?\000\000\000\000@D\005\b\000\000\000\000\000\000\005\b\370\355\377\277\243\262\004\b"}, 
          motion = {type = 0, timestamp = 0, windowID = 134534271, which = 1065353216, state = 1065353216, x = 0, y = 134562880, xrel = 0, 
            yrel = 134545408}, button = {type = 0, timestamp = 0, windowID = 134534271, which = 1065353216, button = 0 '\000', 
            state = 0 '\000', clicks = 128 '\200', padding1 = 63 '?', x = 0, y = 134562880}, wheel = {type = 0, timestamp = 0, 
            windowID = 134534271, which = 1065353216, x = 1065353216, y = 0, direction = 134562880}, jaxis = {type = 0, timestamp = 0, 
            which = 134534271, axis = 0 '\000', padding1 = 0 '\000', padding2 = 128 '\200', padding3 = 63 '?', value = 0, padding4 = 16256}, 
          jball = {type = 0, timestamp = 0, which = 134534271, ball = 0 '\000', padding1 = 0 '\000', padding2 = 128 '\200', 
            padding3 = 63 '?', xrel = 0, yrel = 16256}, jhat = {type = 0, timestamp = 0, which = 134534271, hat = 0 '\000', value = 0 '\000', 
            padding1 = 128 '\200', padding2 = 63 '?'}, jbutton = {type = 0, timestamp = 0, which = 134534271, button = 0 '\000', 
            state = 0 '\000', padding1 = 128 '\200', padding2 = 63 '?'}, jdevice = {type = 0, timestamp = 0, which = 134534271}, caxis = {
            type = 0, timestamp = 0, which = 134534271, axis = 0 '\000', padding1 = 0 '\000', padding2 = 128 '\200', padding3 = 63 '?', 
            value = 0, padding4 = 16256}, cbutton = {type = 0, timestamp = 0, which = 134534271, button = 0 '\000', state = 0 '\000', 
            padding1 = 128 '\200', padding2 = 63 '?'}, cdevice = {type = 0, timestamp = 0, which = 134534271}, adevice = {type = 0, 
            timestamp = 0, which = 134534271, iscapture = 0 '\000', padding1 = 0 '\000', padding2 = 128 '\200', padding3 = 63 '?'}, quit = {
            type = 0, timestamp = 0}, user = {type = 0, timestamp = 0, windowID = 134534271, code = 1065353216, data1 = 0x3f800000, 
            data2 = 0x0}, syswm = {type = 0, timestamp = 0, msg = 0x804d47f <oscore_mutex_unlock+12>}, tfinger = {type = 0, timestamp = 0, 
            touchId = 4575657221542958207, fingerId = 1065353216, x = 4.01034591e-34, y = 0, dx = 4.00232317e-34, dy = -1.99944973, 
            pressure = 3.99322916e-34}, mgesture = {type = 0, timestamp = 0, touchId = 4575657221542958207, dTheta = 1, dDist = 0, 
            x = 4.01034591e-34, y = 0, numFingers = 0, padding = 2053}, dgesture = {type = 0, timestamp = 0, touchId = 4575657221542958207, 
            gestureId = 1065353216, numFingers = 134562880, error = 0, x = 4.00232317e-34, y = -1.99944973}, drop = {type = 0, timestamp = 0, 
            file = 0x804d47f <oscore_mutex_unlock+12> "\005\201+", windowID = 1065353216}, 
          padding = "\000\000\000\000\000\000\000\000\177\324\004\b\000\000\200?\000\000\200?\000\000\000\000@D\005\b\000\000\000\000\000\000\005\b\370\355\377\277\243\262\004\b@D\005\b\260\001\005\b\000\000\000"}
#5  0x0804affe in wait_until (desired_usec=4294960122) at src/timers.c:55
No locals.
#6  0x0804a9a2 in sled_main (argc=0, argv=0xbffff168) at src/main.c:254
        tnext = {moduleno = 1, time = 4294960122, argc = 0, argv = 0x0}
        ch = -1
        outmod = "sdl2", '\000' <repeats 251 times>
        filternames = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10000004 <error: Cannot access memory at address 0x10000004>, 
          0xb7ff2029 <calloc+73> "\203\304\020[^_\303VS\350\362'", 0x756e694c <error: Cannot access memory at address 0x756e694c>, 
          0x78 <error: Cannot access memory at address 0x78>, 0x0, 0x0, 0x0, 0x0, 0x0, 
          0xb7fe3eb0 <check_match+304> "\203\304\020\205\300\213T$\f\017\205v\377\377\377넍\264&", 0xb7fd9241 "LINUX_2.6", 
          0xb7ecf298 "LINUX_2.6", 0x0, 0x0, 0x0, 0x0, 0x0, 0x3ae75f6 <error: Cannot access memory at address 0x3ae75f6>, 
          0x75717300 <error: Cannot access memory at address 0x75717300>, 0x6b6165 <error: Cannot access memory at address 0x6b6165>, 
          0xb7fe3d89 <check_match+9> "\201\303w\262\001", 0xb7fd9128 "\031\243Cn\213*\306&", 
          0x7 <error: Cannot access memory at address 0x7>, 0xb7fffc08 "", 0x6e43a318 <error: Cannot access memory at address 0x6e43a318>}
        filterargs = {0xb7fe45a9 <do_lookup_x+1689> "\203\304 \205\300\017\205\233\373\377\377\213\003또\215\264&", 0x0, 0x0, 
          0xb7fd91a0 "\001", 0x7 <error: Cannot access memory at address 0x7>, 0xb7fd91c0 "", 0xb7fffc08 "", 
          0xbfffef6c "\230`\375\267.N=\366\251E\376\267\001", 0xbfffef68 "\356\b", 0x1 <error: Cannot access memory at address 0x1>, 0x0, 
          0xb7fff000 "<?\002", 0xb7ecf2a2 "__vdso_clock_gettime", 0xb7fd91a0 "\001", 
          0xb7fe3eb0 <check_match+304> "\203\304\020\205\300\213T$\f\017\205v\377\377\377넍\264&", 0xb7d8334c "GLIBC_2.0", 
          0x8049484 "GLIBC_2.0", 0x3721d18 <error: Cannot access memory at address 0x3721d18>, 0xbfffef68 "\356\b", 0xbfffeff8 "", 
          0x7 <error: Cannot access memory at address 0x7>, 0x0, 0xd696910 <error: Cannot access memory at address 0xd696910>, 0x0, 0x0, 
          0xb7fe3d89 <check_match+9> "\201\303w\262\001", 
          0xb7d73d24 "/N=\366\370\304-\327\317\030L\017$\301\324\361\370ԏӄ\"\233|\205\"\233|8\307\031u\354\373\300=\376\001\304\022\261\"\225\303\311BY\020\334\317쵶w\035\rG\336\315%\265V1\375\307r1\035\a;\372L\b~\222\034\215\t)\020\004\\H\261ԡ\034\240\070\265\357\060\002\352\331\017j\335\371{9\265\357\060\030\034s\354X?\227|T\200\314sقc\002;H\205\033\062v\340բ\230\313\362\250\247K\341\066\rf\375\326\036h\233\275\234#\217\274\350e\235\234\002Y1\v\264\006\337J\032\223\250P\265\250\020()\031΅)%~\016|\030\271\321\070\a\221\222\376\206\357\360I\265$\247:Vӂ\241", <incomplete sequence \344>..., 0x8ee <error: Cannot access memory at address 0x8ee>, 0xb7fd6098 "", 
          0xf63d4e2e <error: Cannot access memory at address 0xf63d4e2e>, 
          0xb7fe45a9 <do_lookup_x+1689> "\203\304 \205\300\017\205\233\373\377\377\213\003또\215\264&", 
          0x1 <error: Cannot access memory at address 0x1>}
        filterno = 0
        outarg = 0x0
        ret = 0
        filters = 0x0
        outmodno = 0
        lastmod = 1
#7  0x0804d094 in main (argc=1, argv=0xbffff164) at src/os/os_unix.c:17
No locals.
(gdb) 

The timer was set in the module using

        frame++;
        nexttick += FRAMETIME;
        timer_add(nexttick, modno, 0, NULL);

gfx_candyflow crash on macOS.

When run on macOS, it complains about the lack of the symbol _perf_start.

Error:

>> Now drawing candyflowdyld: lazy symbol binding failed: Symbol not found: _perf_start
  Referenced from: /Users/vifino/src/sled/./modules/gfx_candyflow.so
  Expected in: flat namespace

dyld: Symbol not found: _perf_start
  Referenced from: /Users/vifino/src/sled/./modules/gfx_candyflow.so
  Expected in: flat namespace

zsh: abort      ./sled

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.