Each can be a separate task for each existing sample, or a new one:

• Better visuals, audio etc.
• Cleaner, better and more descriptive code
• Easier usage from browsers, with or without mobile

More ideas welcome.

Investigate how to do this in glfw.

This will help with input configuration UIs in games. Let's say you want to move from WASD to ESDF for navigation. This is currently quite difficult with lyte2d.

Main reason for this is the design decision to not use/expose events as first class. This is the right choice for Lyte2D, but it means that we need the right polling functions to cover the features required.

The API here will only deal with keyboard. I have some thoughts of unifying gamepad/mouse buttons with the keyboard in the future.

"Indexing" concept doesn't work well with Lua. Also, currently indexes start with 0.

Some options I thought about:

• A gamepad object, maybe. You get these and use them. Not very friendly to functional style.
• Perhaps a "default/main" gamepad with basic API (without index) and a secondary API for other gamepads if any (similar to indexed, but perhaps they have "ids" or something like that.)

All the APIs need to be tested. Probably a mixture of automated and manual testing.

Surely there're more bugs in the less used APIs. Dark corners of Lyte2D

Also document it, maybe?

VSCode lua extension is pretty cool and the experience getting code completion with types is pretty amazing.

I'm having a strange crash when playing music, it plays fine for a while but at a certain moment it stops, the game continues working for a couple of seconds until it crashes with no error message.

When I only play the music file and don't do anything else there's no crash, so there's nothing wrong with the music file. I tried ogg and wav but it doesn't make a difference.

The music is this one (the full version). I'm on Windows using the latest desktop binary.

Looking at the core_audio.c file there doesn't seem to be anything strange, except for this:

Is there any particular reason the Music object is updated 4 times? All of my games that use raylib's audio module the music stream is updated only once and it works fine on desktop and the web, so why it's different here?
I'm not entirely sure whether or not this is the cause of the crash but it would be worth testing.

lyte show=license or something can display the license.

We can then remove it from the zip file.

Not sure if to do this on the native side or keep it on lua side.

Similar to #45, but for shapes, text, etc.

Design needed. This is separate from networking. This is about making HTTP requests.

One area of investigation is libcurl. Others surely exists.

Currently drawing images requires using matrices for transformations like rotation, scaling, etc. This is probably the most robust way to draw things in Lyte, but there is still room for some extra versions of common functions to allow quickly drawing an image with rotation/scale on the fly.

One way to do this would be to have a simple version of each function as well as a complex one that takes additional parameters, then the user can pick based on the situation.

For example:

function draw_image(image: Image, dest_x: number, dest_y: number): void
function draw_image(image: Image, dest_x: number, dest_y: number, scale_x: number, scale_y: number, origin_x: number, origin_y: number, angle: number): void

function draw_image_rect(image: Image, dest_x: number, dest_y: number, src_x: number, src_y: number, rect_width: number, rect_height: number): void
function draw_image_rect(image: Image, dest_x: number, dest_y: number, src_x: number, src_y: number, rect_width: number, rect_height: number, scale_x: number, scale_y: number, origin_x: number, origin_y: number, angle: number): void


function add_imagebatch_rect(imagebatch: ImageBatch, dest_x: number, dest_y: number, src_x: number, src_y: number, rect_width: number, rect_height: number): void
function add_imagebatch_rect(imagebatch: ImageBatch, dest_x: number, dest_y: number, dest_width: number, dest_height: number, src_x: number, src_y: number, src_width: number, src_height: number, scale_x: number, scale_y: number, origin_x: number, origin_y: number, angle: number): void

(I'm not sure if sokol_gp will allow us to implement an angle parameter for add_imagebatch_rect)

Design needed

@morew4rd, you mentioned on your twitter feed that there were more Wasm downloads then Windows probably due to increased security. I'd like to continue to make a plug for Wasm also being a better cross-platform solution: for instance, I can run lyte2d on my iPad easily by hosting my own local server on my iPad but otherwise wouldn't be able to use lyte2d :-). Keep up the great work!

(Sorry couldn't respond directly on twitter, I discontinued my twitter subscription a little while ago).

Lyte2D native API handles error conditions via API return value, an integer. 0 means "no errors", and non-zero, currently signifies both errors and warnings.

We need to identify for each failure mode whether it's an error (can't find the file the user required) vs a warning (API call is expected to fail sometimes. don't kill the app, or force it to use pcall)

Requires some design

TLDR

A great addition (and a very important one in my opinion) is to make Lyte2D able to read an external configuration file like conf.lua for pre-load settings such as window_width, window_height.

Problem

I started playing with Lyte2D and while making my game I noticed that the window always pops on the top-left side of the screen with it's default size even when I change it on the app.lua file. The same occurs on Love2D if you put stuff on love.load and their solution for that is by handling a configuration file before the game startup.

My app.lua file:

lyte.set_window_size(640, 360)
lyte.set_default_filtermode("nearest")

-- Rest of the code...

config.lua could be something like this:

return {
  window_width = 640,
  window_height = 360,
  loading_screen_enabled = false,
  default_filtermode = "nearest",

  -- Rest of the code...
}

Also I would love to disable the rotating "wood plank" loading screen (make it white or loading_screen_color).

Decided to try using your framework to see how far along it was and came across a few issues:

1. Errors only show the error line but no stack traceback to see where the error came from, this makes finding out what's wrong significantly more difficult.

2. Errors only output to console and the game window closes immediately. This forces you to run the game from an already open console window, otherwise you won't be able to see what the error was, as any console window opened from running the game from a command (i.e. I normally run it from a run.bat file) also closes when the main game window closes. LÖVE shows the error on screen and doesn't close the game's window, so you can still see what's sent to the console (on top of seeing the error + stack traceback on screen). GameMaker closes the window but opens a new one that shows you the stack traceback I think.

Hope you don't mind me creating a few issues over the next few days as I try making something with your framework.

It's ignored, currently

Capturing this so that it's not forgotten.

• System clipboard access
• Native file dialogs
• "Drop" item to window support

Before this, I should find/fix most of the existing perf issues on PUC lua (mostly memory related) which are sometimes related to the API design. Otherwise, those would stay "hidden" after the JIT gains. We don't have detailed perf testing as of yet but based on my and a couple other folks experience, it's decently performant and usable. Still, some known issues (like enum string caching, batching draws, etc.) exists.

Once ready, this will be just another codegen target next to the existing ones. Create all API boiler plate in the language of luajit instead of PUC's C API. (Of course there's always hidden devils in the details..)

ODE was investigated and prototyped as a backend physics engine. It works well.

However, API design around a physics feature is difficult. This was postponed to after 1.0

Add 0.7.x:

• Triangle (0.7.4)
• Polygon
• Arcs
• Ellipse

Add later:

• LineBatch (all "line" APIs can be done with this single batch)
• ShapeBatch (any order of shapes?)

Remove:

• draw_point. It's really pointless 😅

There are issues with this mostly related to various artifacts of clamping to pixels two times. (Nearest-neighbor filter first, and "scaling" next)

• Vector representation details get lost, and freetype's anti-alias pixels get the focus at places
• Width changes over longer text lines (See example -- blue is the correct rendering, red is the current scaled with nearest neighbor,)

Need design/decision.

At least for mobile devices that would make it easy to program with lyte2D directly on the mobile device. The amulet browser IDE even lets one export the code as .wasm directly from the IDE in the browser:

https://www.amulet.xyz/editor.html

Fyi, and thanks for considering.

Lyte2D's current "keyboard input" API (is_key_(down/pressed/released/repeat)) is great for games, but it makes it very hard to implement text entry (think filling fields, or even text editors)

A possible way to solve this would be exposing corresponding tables with an API like get_(down/pressed/released/repeat)_keys.

Another would be following LOVE2D (in spirit, as Lyte2D does not favor events): start_textinput, stop_textinput, get_textinput_string, reset_textinput_string.

Related: #4

• Red boxes are 64x64 pixels and 64 pixels apart
• Font is loaded with 64 pix height

lyte2d code:

local font = lyte.load_font("assets/DroidSansMono.ttf", 64)

lyte.set_font(font)

function lyte.tick()
    lyte.cls(0, 0, 0, 0)

    lyte.set_color(1,0,0,1)
    lyte.draw_rect(10, 10, 64, 64)
    lyte.draw_rect(10, 10+128, 64, 64)

    lyte.set_color(1,1,1,1)
    lyte.draw_text("Hello, wow 1", 10, 10)
end

love2d core:

local font = love.graphics.newFont("assets/DroidSansMono.ttf", 64)

love.graphics.setFont(font)

function love.draw()
    love.graphics.setColor(1,0, 0, 1)
    love.graphics.rectangle("fill", 10, 10, 64, 64)
    love.graphics.rectangle("fill", 10, 10+128, 64, 64)

    love.graphics.setColor(1,1,1,1)
    love.graphics.print("Hello, wow " .. love.graphics.getDPIScale( ), 10, 10)

end

Needs investigation for the differences in size.

Also, LOVE2D's anti-alias pixels look somewhat nicer. Why?

Background

Lyte2D excepts as a first parameter the working directory of the game in development. I.e. lyte mycode/games/coolgame1 sets that dir as the working dir and runs the app.lua file there. This includes making that folder writeable, in case the game wants to write some local files. (The dev can also choose a non app.lua file with app=mymain.lua parameter.

This is mostly a dev time feature, perhaps could also used by "power" gamers.

However just yesterday I found a serious issue with this

Issue

Due to a bug in an underlying library (PHYSFS) + a misuse of it on the Lyte2D side, lyte myfile.lua usage deletes the contents of myfile.lua file.

This usage is not supported and expected usage is to do lyte app=myfile for this case, but it's an easy mistake to do. I hit it myself!

Contributing factors:

• PHYSFS: PHYSFS_setWriteDir function expects a dir path to be passed as an argument. Apparently if an existing file is passed, the call fails as expected but also clears the contents of the file
• Lyte2D initialization: sends the first parameter to this function without checking if it's an existing dir (as expected) and bail if not.

Attention for users

If you're using 0.5 or any or the 0.6 prereleases please be cognizant of this bug. Do not do lyte myfile.lua or lyte folder/otherfolder/file.lua.

Next steps

I'm preparing a fix for this, and will do a 0.6 release once it is ready. This shifts the plans for the version numbers, as 0.7 will now contain planned 0.6 features.

Sincere apologies to everyone who may have hit this.

Goal: make it so easy that folks can compile their own versions of Lyte2D if they like. Extend/change.

And most importantly for the project, contribute :)

Need to investigate and design.

See https://luasteam.readthedocs.io for a Love2D library. Perhaps something like this. Perhaps direct integration with steam's own libraries.

This apparently makes running X64 apps on Arm64 Windows emulation layer easier.

I should look into this and if it doesn't add much to the file size and doesn't take away performance, this should be enabled. If anything, this should help people running Arm based Windows 11 games on Parallels on Arm based Macs.

https://learn.microsoft.com/en-us/windows/arm/arm64ec

The default one in Lua 5.1 is not very good. A nice native API would be cool.

For example image:draw(), etc.

"Fit and finish."

Most monitors have high DPI capacity these days. Even on my older machine, Windows recommends I scale to 150%. (Though I prefer 125%)

Lyte2D should detect this and scale the content as needed.

(Note: make sure to test on Win10/11, X11 and MacOS with different monitors)

Currently we're not statically linking against any libc on linux and specifically pick an older version of Ubuntu (18.04) so that the executable stays compatible with as many systems as possible.

However, there are two main issues:

1. We have to stick with an older linux, and its dev support is slowly fading. We have to use older clang, older linker etc. Some of the dev tools that would help a lot can't even be installed (like node.js)
2. It's not as compatible as I'd like.

Enter 'musl' which is an open source runtime library solving the problem of statically linking libcs on Linux.

I don't know how it works at all, so filing this issue to track this for the future.

Or perhaps someone interested can do a bit of investigation/protoype/testing/implementation :)

Assume you have mylibrary with init.lua inside it. require "mylibrary" should load it (unless there's also a mylibrary.lua file.)

This is not implemented.

Workaround: require "mylibrary.init"

• lyte.load_image non-existing path
• Shader compilation failures
• lyte.is_key_pressed/is_key_down/etc with invalid value crashes
• Syntax errors

Need to catch these and display them in the window instead of closing the window. Reporting on the console is a workaround but not all folks care about or want to use console.

Handled

• lua assert failures

(I'll keep updating this list as I test/hit issues.)

I'm having trouble to require modules installed via luarocks; using the lates release binary, linux

luarocks install luafilesystem

# in app.lua
local lfs = require("lfs")

lyte .

Warning: could not load file 'config/init.lua', error: 'not found'
Warning: could not load file 'config.fnl', error: 'not found'
Warning: could not load file 'config/init.fnl', error: 'not found'
Warning: could not load file 'config.tl', error: 'not found'
Warning: could not load file 'config/init.tl', error: 'not found'
Failed to mount zip './lyte' APP_EXE / (fetched async): PHYSFS: 0 6, unsupported
Warning: could not load file 'lfs.lua', error: 'not found'
Warning: could not load file 'lfs/init.lua', error: 'not found'
Warning: could not load file 'lfs.fnl', error: 'not found'
Warning: could not load file 'lfs/init.fnl', error: 'not found'
Warning: could not load file 'lfs.tl', error: 'not found'
Warning: could not load file 'lfs/init.tl', error: 'not found'
Error: lyte_boot.lua:199: attempt to concatenate local 'lang' (a nil value)

is there a way or some env to be put up in place?

thanks

• Remove __gc methods
• Remove cleanup_ functions
• Identify and remove other unnecessary functions
• Cleanup top-level (_G)

Easy workaround but will fix.