antirez / load81 Goto Github PK

Since LOAD81 will run on a number of nice Linux-based platforms such as the Open Pandora Console, Beagleboard and RaspberryPI, it would be nice to have command line arguments for specifying screen resolution and window'ing mode. I suggest the following args be added to the project:

-width xx
-height xx
-fullscreen

.. where width and height set the dimensions of the window, and if present on the command line, -fullscreen does what it says: fullscreen (window being default).

It would be very nice to have sound in LOAD81, and following the 8-bit ideology, if it were a synthesis-oriented approach (as opposed to .WAV sample playback) this would be very neat.

What I have in mind is some sort of mini-synth such as the one found in sfxr:

http://www.drpetter.se/project_sfxr.html

A Lua table could be used to set the sound parameters for each synth voice (maybe it can be multi-timbral?):

sound[1].envelope(0,0.5,0.275,1) -- ADSR
sound[1].filterType(LOPASS)
&etc.

.. and then triggered with something like sound[1].play() / sound[2].play() and .stop() and .pause() and so on. This would make it very easy to set up a series of sound effects in tables and trigger them according to programmer needs.

As reported by an early adopter (pmprog) of LOAD81 in the Open Pandora forum here:

http://boards.openpandora.org/index.php?/topic/7405-here-is-a-pnd-for-load81/

"One thing I've just noticed that looks a little weird - in the "fill" command, RGB are 0-255, but alpha seems to be floating point. Am I reading that right? Seems a little bizarre to mix up the parameters."

Perhaps this is a hold-over from Codea compatibility?

Right now the only way to select a file to use in LOAD81 is at the command line. On the Open Pandora, we have the PickleLauncher tool:

http://pandorawiki.org/PickleLauncher

This is a generalized launcher for cmd-line programs which only accept filenames on the arguments, and for now it works very well as an 'outer shell' for LOAD81 - picklelauncher -> [user selects file] -> LOAD81 -> [user ESCAPES LOAD81] -> picklelauncher -> etc. The 'piped-tools' approach could be used for this feature, or LOAD81 could have its own file-selector capability built in as the Editor functionality expands.

Since LOAD81 is targeted at such devices, it would be a great thing indeed to be able to build the Open Pandora PND file directly from the LOAD81 source base, and to this end I suggest a contrib/Pandora/ tree be added to the project that contains the resources necessary to build a PND file.

PND file info: http://pandorawiki.org/Pnd

The idea being that someone functioning in the "distributor/builder" role could simply type "make pnd-file" in contrib/Pandora and LOAD81.pnd would be generated for upload to the various Open Pandora repos, such as repo.openpandora.org. This would greatly assist the effort to get more interested/interesting LOAD81 users in the various communities where it would be useful.

For some reason, LOAD81 doesn't perform very well on the Open Pandora console - its useable, but seems to be very laggy. Normally such an SDL program on OpenPandora/Angstrom performs very, very well, but with LOAD81 there appears to be some performance issue in the inner loop of the app which results in lag. It is very noticeable with the "text.lua" demo, where the text lags behind the mouse cursors as it moves, by a few milliseconds.

It may be related to a build issue (I have built LOAD81 using the CDEV tools, which is an onboard toolchain which runs on the Pandora itself, -i.e. not cross-compiling, but native compiling on the Pandora hardware itself), or it could have something to do with the overall architecture of LOAD81 itself - is the Lua VM somehow being polled too often, or some other unnecessary code-branch being taken during execution of the Lua script, perhaps?

Last night while editing my joystick.lua example in the editor, I had the situation where I had to delete a lot of lines of code. I positioned the cursor at the very end of the file, and held down the Backspace key. Things started to delete when suddenly the entire screen was filled with junk chars, and the editor GUI state was corrupted. The file buffer was okay - I was able to save and re-edit the file, with some chars deleted (no junk in the file, confirmed at the cmd-line with 'cat joystick.lua' before re-starting LOAD81), but the editor state seemed to not like having to deal with a large number of commented-out lines during the delete process.

This was reproducible - I tried again, deleting 4 long lines that had been previously commented out, and the editor GUI state went corrupt again. Seems to be some interaction between key-repeat/Backspace/comment-line color-encoding.

Load81 programs are currently self-contained into a box without the ability to talk with the external world.
Specifically they can't talk with other instances of the same program running in other Load81 instances around the world! What a shame. So what I'm proposing and implementing is a Cloud message service for Load81.

API

A Load81 program listen to channels using the listen() function. Multiple calls to listen are allowed in order to listen to multiple channels, and it is also possible to no longer listen to a given channel using unlisten(). Example:

listen("asteroids")
listen("foo","bar")
unlisten("asteroids")

Every time a message is received the function receive is called. It is important to understand how this works. The normal flow of a Load81 program is to call setup the first time, and then call draw. When the program is listening to one or more channels, the function receive is called before the function draw is called, and is called for all the pending messages currently in the queue, so for instance you may have 5 calls to receive, and finally the call to draw, and so forth.

This is how the function receive is defined in a program:

function receive(sender,channel,msg)
    ....
end

The three arguments are:

• sender: a 40 chars hex string that uniquely identifies the sender instance (this instance ID changes at every run).
• channel: the channel that received the message.
• msg: a Lua object (number, string, table, boolean, ...)

You don't receive messages that are sent by your instance.

In order to send messages you simply use:

send("channel",lua_object)

You can send messages to channels you are not listening without problems if you wish.

Implementation

The implementation using a Redis instance running at pubsub.load81.com, with only PUBLISH and SUBSCRIBE commands enabled. The instance is configured to drop clients that reached an output buffer of a few hundred kbytes so that it is not possible to abuse the instance just listening to channels without actually reading data.

Every Load81 instance creates a random identifier at startup, either reading from /dev/urandom or using a mix of time and rand() if urandom is not available.

Messages are send to Redis as <Instance ID>:<MessagePack representation of the Lua object sent>.

Messages are both sent and received using a non blocking socket. At every iteration we read what's new in the socket, and call a function that will put all the entire messages in the queue, parsing the Redis protocol.

From the point of view of sending, we'll try to send messages every time the user calls the send() function in order to minimize latency, but if there is no room on the kernel socket buffer we'll bufferize the write and send it when possible (at the next iteration of the event processor, that is, by default, 30 times per second).

Abuses

From the outside attacker this is a free message hub, but I think it's fine since for instance an IRC server has the same problem.... and I think no one will try to abuse this stuff, at least I hop.

try'ng to build load 81 on cygwin are ok! but when run it SDL_Init "can't found de video display". Why?

$ make

cc -O2 -Wall -W -Ilua/src pkg-config --cflags sdl SDL_gfx SDL_image -c -o load81.o load81.c
cc -O2 -Wall -W -Ilua/src pkg-config --cflags sdl SDL_gfx SDL_image -c -o editor.o editor.c
cc -O2 -Wall -W -Ilua/src pkg-config --cflags sdl SDL_gfx SDL_image -c -o framebuffer.o framebuffer.c
(cd lua && make ansi)
make[1]: Entering directory '/home/czar/c/load81/lua'
cd src && make ansi
make[2]: Entering directory '/home/czar/c/load81/lua/src'
make all MYCFLAGS=-DLUA_ANSI
make[3]: Entering directory '/home/czar/c/load81/lua/src'
gcc -O2 -Wall -DLUA_ANSI -c -o lapi.o lapi.c
gcc -O2 -Wall -DLUA_ANSI -c -o lcode.o lcode.c
gcc -O2 -Wall -DLUA_ANSI -c -o ldebug.o ldebug.c
gcc -O2 -Wall -DLUA_ANSI -c -o ldo.o ldo.c
gcc -O2 -Wall -DLUA_ANSI -c -o ldump.o ldump.c
gcc -O2 -Wall -DLUA_ANSI -c -o lfunc.o lfunc.c
gcc -O2 -Wall -DLUA_ANSI -c -o lgc.o lgc.c
gcc -O2 -Wall -DLUA_ANSI -c -o llex.o llex.c
gcc -O2 -Wall -DLUA_ANSI -c -o lmem.o lmem.c
gcc -O2 -Wall -DLUA_ANSI -c -o lobject.o lobject.c
gcc -O2 -Wall -DLUA_ANSI -c -o lopcodes.o lopcodes.c
gcc -O2 -Wall -DLUA_ANSI -c -o lparser.o lparser.c
gcc -O2 -Wall -DLUA_ANSI -c -o lstate.o lstate.c
gcc -O2 -Wall -DLUA_ANSI -c -o lstring.o lstring.c
gcc -O2 -Wall -DLUA_ANSI -c -o ltable.o ltable.c
gcc -O2 -Wall -DLUA_ANSI -c -o ltm.o ltm.c
gcc -O2 -Wall -DLUA_ANSI -c -o lundump.o lundump.c
gcc -O2 -Wall -DLUA_ANSI -c -o lvm.o lvm.c
gcc -O2 -Wall -DLUA_ANSI -c -o lzio.o lzio.c
gcc -O2 -Wall -DLUA_ANSI -c -o lauxlib.o lauxlib.c
gcc -O2 -Wall -DLUA_ANSI -c -o lbaselib.o lbaselib.c
gcc -O2 -Wall -DLUA_ANSI -c -o ldblib.o ldblib.c
gcc -O2 -Wall -DLUA_ANSI -c -o liolib.o liolib.c
gcc -O2 -Wall -DLUA_ANSI -c -o lmathlib.o lmathlib.c
gcc -O2 -Wall -DLUA_ANSI -c -o loslib.o loslib.c
gcc -O2 -Wall -DLUA_ANSI -c -o ltablib.o ltablib.c
gcc -O2 -Wall -DLUA_ANSI -c -o lstrlib.o lstrlib.c
gcc -O2 -Wall -DLUA_ANSI -c -o loadlib.o loadlib.c
gcc -O2 -Wall -DLUA_ANSI -c -o linit.o linit.c
ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o # DLL needs all object files
ranlib liblua.a
gcc -O2 -Wall -DLUA_ANSI -c -o lua.o lua.c
gcc -o lua lua.o liblua.a -lm
gcc -O2 -Wall -DLUA_ANSI -c -o luac.o luac.c
gcc -O2 -Wall -DLUA_ANSI -c -o print.o print.c
gcc -o luac luac.o print.o liblua.a -lm
make[3]: Leaving directory '/home/czar/c/load81/lua/src'
make[2]: Leaving directory '/home/czar/c/load81/lua/src'
make[1]: Leaving directory '/home/czar/c/load81/lua'
cc load81.o editor.o framebuffer.o lua/src/liblua.a lua/src/liblua.a -lm pkg-config --libs sdl SDL_gfx SDL_image -o load81

$ ldd load81.exe

    ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x76ce0000)
    kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x76bc0000)
    KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x7fefceb0000)
    cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)
    cygSDL-1-2-0.dll => /usr/bin/cygSDL-1-2-0.dll (0x3f8130000)
    ADVAPI32.dll => /cygdrive/c/Windows/system32/ADVAPI32.dll (0x7fefd240000)
    msvcrt.dll => /cygdrive/c/Windows/system32/msvcrt.dll (0x7fefe660000)
    sechost.dll => /cygdrive/c/Windows/SYSTEM32/sechost.dll (0x7fefd010000)
    RPCRT4.dll => /cygdrive/c/Windows/system32/RPCRT4.dll (0x7fefd560000)
    WINMM.dll => /cygdrive/c/Windows/system32/WINMM.dll (0x7fefac90000)
    USER32.dll => /cygdrive/c/Windows/system32/USER32.dll (0x76ac0000)
    GDI32.dll => /cygdrive/c/Windows/system32/GDI32.dll (0x7fefe420000)
    LPK.dll => /cygdrive/c/Windows/system32/LPK.dll (0x7fefd000000)
    USP10.dll => /cygdrive/c/Windows/system32/USP10.dll (0x7fefebe0000)
    cygSDL_gfx-14.dll => /usr/bin/cygSDL_gfx-14.dll (0x3f7f60000)
    cygSDL_image-1-2-0.dll => /usr/bin/cygSDL_image-1-2-0.dll (0x3f7f30000)
    cygjpeg-8.dll => /usr/bin/cygjpeg-8.dll (0x3e8da0000)
    cygpng16-16.dll => /usr/bin/cygpng16-16.dll (0x3e52f0000)
    cygz.dll => /usr/bin/cygz.dll (0x3e2c60000)
    cygtiff-6.dll => /usr/bin/cygtiff-6.dll (0x3e3a50000)
    cygjbig-2.dll => /usr/bin/cygjbig-2.dll (0x3e8e10000)
    cyglzma-5.dll => /usr/bin/cyglzma-5.dll (0x3e65d0000)
    cygwebp-5.dll => /usr/bin/cygwebp-5.dll (0x3e3090000)

$ ./load81.exe examples/2dsim.lua

SDL Init error: No available video device
Segmentation fault (imagem do núcleo gravada)

One thing that I have left to do with regards to Joystick support for the Pandora is to allow the programmer to set the 'nub' mode of the Open Pandora controls, which can be configured on the fly to act as either joysticks, nub0=mouse/nub1=mouse buttons, buttons, and so on. In order to facilitate this mode switch, however, the Program would have to be reset after the mode switch - one easy, user-friendly way to do this would be to have a "return_to_editor()" function call available that would end the program and, as suggested by the descriptive name, return to the Lua editor. It might also be an interesting way to build apps that encourage continued programming by the user. :)

LOAD81 needs a default Icon file. ;) I have created one from a screenshot of LOAD81 in progress, but perhaps someone with Artistic skills could come up with a branding for LOAD81 that makes it instantly obvious to the casual observer what LOAD81 is all about. :)

It would be great to be using the nubs of the Open Pandora device, which can appear to the system as independent high-res joysticks.

For this reason, I have done the work. :) Please see the pull request: #39

Up to 4 independent joystick devices can be used within LOAD81. For now, button support is not complete, but it should definitely be added as soon as possible (there are no 'joystick buttons' on the Pandora - all buttons are normal keyboard buttons, include A/B/X/Y, and triggers).

Work on adding joystick buttons (and other joystick features, such as 'hats' and 'trackballs' type inputs) should be completed.

A 'make clean' in the main LOAD81 source tree does not clean up the Lua build objects. A 'make clean' at the top level tree should clean up everything that a 'make' on the top-level tree produces (important when the source tree is copied from one architecture to the other ..)

If the nice load81 editor code were factored out into a separate source file then other projects could more easily make use of it while retaining the license. I checked with Salvatore and he was happy to do this...thanks!

It compiles and runs fine, this is just some warnings with GCC 10.2.1 20201203 on Linux ppc64le.
I’m preparing a pull request.

$ make
cc -O2 -Wall -W -Ilua/src `pkg-config --cflags sdl2 SDL2_gfx SDL2_image`   -c -o load81.o load81.c
load81.c: In function 'getpixelBinding':
load81.c:216:12: warning: variable 'pixel' set but not used [-Wunused-but-set-variable]
  216 |     Uint32 pixel;
      |            ^~~~~
cc -O2 -Wall -W -Ilua/src `pkg-config --cflags sdl2 SDL2_gfx SDL2_image`   -c -o editor.o editor.c
cc -O2 -Wall -W -Ilua/src `pkg-config --cflags sdl2 SDL2_gfx SDL2_image`   -c -o framebuffer.o framebuffer.c
(cd lua && make ansi)
make[1]: Entering directory '/tmp/ramdisk/load81/lua'
cd src && make ansi
make[2]: Entering directory '/tmp/ramdisk/load81/lua/src'
make all MYCFLAGS=-DLUA_ANSI
make[3]: Entering directory '/tmp/ramdisk/load81/lua/src'
gcc -O2 -Wall -DLUA_ANSI   -c -o lapi.o lapi.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lcode.o lcode.c
gcc -O2 -Wall -DLUA_ANSI   -c -o ldebug.o ldebug.c
gcc -O2 -Wall -DLUA_ANSI   -c -o ldo.o ldo.c
gcc -O2 -Wall -DLUA_ANSI   -c -o ldump.o ldump.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lfunc.o lfunc.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lgc.o lgc.c
gcc -O2 -Wall -DLUA_ANSI   -c -o llex.o llex.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lmem.o lmem.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lobject.o lobject.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lopcodes.o lopcodes.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lparser.o lparser.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lstate.o lstate.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lstring.o lstring.c
gcc -O2 -Wall -DLUA_ANSI   -c -o ltable.o ltable.c
gcc -O2 -Wall -DLUA_ANSI   -c -o ltm.o ltm.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lundump.o lundump.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lvm.o lvm.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lzio.o lzio.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lauxlib.o lauxlib.c
lauxlib.c: In function 'luaL_loadfile':
lauxlib.c:577:4: warning: this 'while' clause does not guard... [-Wmisleading-indentation]
  577 |    while ((c = getc(lf.f)) != EOF && c != LUA_SIGNATURE[0]) ;
      |    ^~~~~
lauxlib.c:578:5: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'while'
  578 |     lf.extraline = 0;
      |     ^~
gcc -O2 -Wall -DLUA_ANSI   -c -o lbaselib.o lbaselib.c
gcc -O2 -Wall -DLUA_ANSI   -c -o ldblib.o ldblib.c
gcc -O2 -Wall -DLUA_ANSI   -c -o liolib.o liolib.c
gcc -O2 -Wall -DLUA_ANSI   -c -o lmathlib.o lmathlib.c
gcc -O2 -Wall -DLUA_ANSI   -c -o loslib.o loslib.c
gcc -O2 -Wall -DLUA_ANSI   -c -o ltablib.o ltablib.c
ltablib.c: In function 'addfield':
ltablib.c:137:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
  137 |   if (!lua_isstring(L, -1))
      |   ^~
ltablib.c:140:5: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'if'
  140 |     luaL_addvalue(b);
      |     ^~~~~~~~~~~~~
gcc -O2 -Wall -DLUA_ANSI   -c -o lstrlib.o lstrlib.c
gcc -O2 -Wall -DLUA_ANSI   -c -o loadlib.o loadlib.c
gcc -O2 -Wall -DLUA_ANSI   -c -o linit.o linit.c
ar rcu liblua.a lapi.o lcode.o ldebug.o ldo.o ldump.o lfunc.o lgc.o llex.o lmem.o lobject.o lopcodes.o lparser.o lstate.o lstring.o ltable.o ltm.o lundump.o lvm.o lzio.o lauxlib.o lbaselib.o ldblib.o liolib.o lmathlib.o loslib.o ltablib.o lstrlib.o loadlib.o linit.o	# DLL needs all object files
ar: `u' modifier ignored since `D' is the default (see `U')
ranlib liblua.a
gcc -O2 -Wall -DLUA_ANSI   -c -o lua.o lua.c
gcc -o lua  lua.o liblua.a -lm 
/usr/bin/ld: liblua.a(loslib.o): in function `os_tmpname':
loslib.c:(.text+0x4e4): warning: the use of `tmpnam' is dangerous, better use `mkstemp'
gcc -O2 -Wall -DLUA_ANSI   -c -o luac.o luac.c
gcc -O2 -Wall -DLUA_ANSI   -c -o print.o print.c
gcc -o luac  luac.o print.o liblua.a -lm 
make[3]: Leaving directory '/tmp/ramdisk/load81/lua/src'
make[2]: Leaving directory '/tmp/ramdisk/load81/lua/src'
make[1]: Leaving directory '/tmp/ramdisk/load81/lua'
cc   load81.o editor.o framebuffer.o lua/src/liblua.a  lua/src/liblua.a -lm `pkg-config --libs sdl2 SDL2_gfx SDL2_image` -o load81

It would be great if we could host LOAD81 scripts out on the 'net somewhere, something like a LOAD81 cloud where scripts are available. I know this isn't a priority, perhaps, but I'm submitting an issue to track it in the future - the ability to load a LUA script directly off the net by giving a URL, e.g. "http://somesite/CoolLOAD81Demo.lua" in the Editor, somewhere.

Compilation fails with an error:

/usr/bin/ld: lua/src/liblua.a(lvm.o): undefined reference to symbol 'floor@@GLIBC_2.2.5'
/usr/bin/ld: note: 'floor@@GLIBC_2.2.5' is defined in DSO /lib/libm.so.6 so try adding it to the linker command line
/lib/libm.so.6: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [codakido] Error 1

If I explicitly add -lm to the Makefile it works just fine:

diff --git i/Makefile w/Makefile
index b6be8ab..9b08f7a 100644
--- i/Makefile
+++ w/Makefile
@@ -1,7 +1,7 @@
 all: codakido

 codakido: codakido.c lua/src/liblua.a
-   $(CC) -O2 -Wall -W $< `sdl-config --cflags` `sdl-config --libs` lua/src/liblua.a -o $@
+   $(CC) -O2 -Wall -W -lm $< `sdl-config --cflags` `sdl-config --libs` lua/src/liblua.a -o $@

 lua/src/liblua.a:
    -(cd lua && $(MAKE) ansi)

Quitting doesn't seem to work on MacOSX (10.6.8)

Either closing the window, or doing Cmd-Q have no effect.

When compiling the latest git version, I get this error:

```cc -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu load81.o editor.o framebuffer.o lua/src/liblua.a lua/src/liblua.a -lmpkg-config --libs sdl SDL_gfx-o load81
editor.o: In function`editorUpdateSyntax':
editor.c:(.text+0x1bd): undefined reference to `isnumber'
collect2: ld returned 1 exit status
make: *** [load81] Error 1
==> ERROR: A failure occurred in build().

Fully updated 64-bit Arch Linux. Here's the AUR package:
https://aur.archlinux.org/packages.php?ID=57322

Thanks.

Redirecting drawing operations to another SDL surface is useful for postprocessing effects, procedurally generated sprites, etc.

Proposed API:

canvas = createCanvas(width, height)
canvas = loadImage(filename)
previous = selectCanvas(canvas)
drawCanvas(canvas, x, y)
canvas = rotozoomCanvas(srcCanvas, angle, zoom, smooth)

The implementation would mostly be a renaming of the existing sprite code and adding more bindings. The sprite() function could be reimplemented in Lua in terms of the canvas functions.

Let me know what you think of this API. I'll implement it in the next couple of days.