jhigginbotham64/starlight.jl

A greedy game engine for greedy programmers!

starlight.jl's Issues

Utilize Actors.jl?

In theory I like the idea of modeling subystems as interacting agents, but I don't know if it would be worthwhile to migrate Starlight to something like Actors.jl.

I don't know the Actor model/Actor framework myself, so it's hard to assess.

Draw shapes other than rect or sprite?

Hey, this may be a silly question but after reading through the docs, the example, and the source code I haven't been able to figure out how to draw a circle, a triangle, or a polygon using this framework?

Is there something I'm missing?

Notebook integration

I want you to be able to "play" Starlight "apps" in Jupyter/Pluto notebooks, while still having all the advantages of their interactivity.

Lock only once for multiple accesses

As per our previous convo through discord, I have a proposal for reducing the number of times App needs to be locked for access to fields. Here it is:

struct Singleton
    # what's in here doesn't matter
    number::Int
    bool::Bool
    symbol::Symbol
    Singleton(; number::Int=0, bool::Bool=false, symbol::Symbol=:hi) = begin
        if !isassigned(singleton)
            singleton[] = new(number, bool, symbol)
        end
        
        return sng_lock, singleton
    end
end

global const singleton = Ref{Singleton}()
global const sng_lock = ReentrantLock()

# Locked Multiple Field Access Operator
function LMFAO(lk::ReentrantLock, objref::Base.RefValue{T}, fields::Symbol...) where T
    @assert typeof(lk) === ReentrantLock
    @lock lk let obj::T = objref[]
        stuff = NTuple{length(fields), Any}(getfield(obj, f) for f in fields)
    end
end

macro LMFAO(lk::Symbol, objref::Symbol, fields::Symbol...) 
    @info "Variable method"
    quote LMFAO($lk, $objref, $fields...) end
end

macro LMFAO(call::Expr, fields::Symbol...)
    @info "Call method"
    quote LMFAO(eval($call)..., $fields...) end 
end


n, b, sy = @LMFAO Singleton() number bool symbol # these don't have to be in order
@info n b sy

lk, sg = Singleton()
n, b, sy = @LMFAO lk sg number bool symbol
@info lk sg
@info n b sy

In theory this locks once to retrieve the struct and then the fields requested.
If the informality of the macro-acronym (macronym?) is too much I'll think of something else.

Join/create a Julia organization?

Maybe join JuliaMultimedia? Or create JuliaGame? Might offer greater visibility. Pros and cons? Is this something we should be thinking about?

Beautify the docs

Currently there are no cross references and the formatting is both inconsistent and somewhat ugly. Might could use more headers as well. And maybe a few rounds of editing and proofreading.

Multiple Apps/windows

SDL supports multiple windows, there's no reason Starlight shouldn't. This will require corresponding changes to Telescope. It will also mean ditching the singleton App pattern, at least partly.

Better logging

Relying on the debug macro is very limiting. Starlight needs a better logging system, preferably one that supports logging to file/network/etc.

Segfault on PkgEval

Starlight.jl fails tests on PkgEval, specifically, it segfaults: https://s3.amazonaws.com/julialang-reports/nanosoldier/pkgeval/by_date/2022-11/25/Starlight.primary.log

Failed to create window: Failed loading libvulkan.so.1: libvulkan.so.1: cannot open shared object file: No such file or directory

[125] signal (11.1): Segmentation fault
in expression starting at /home/pkgeval/.julia/packages/Starlight/KckNQ/test/runtests.jl:11
unknown function (ip: (nil))
Allocations: 10001195 (Pool: 9993677; Big: 7518); GC: 13

This doesn't seem like a Julia-related crash, as it crashes during libtelescope.so as revealed by the rr trace:

shared memfd open() failed: Function not implemented
ALSA lib conf.c:4499:(snd_config_update_r) Cannot access file /workspace/destdir/share/alsa/alsa.conf
Failed to initialize SDL_image, textures will not load
ALSA lib conf.c:4499:(snd_config_update_r) Cannot access file /workspace/destdir/share/alsa/alsa.conf
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM default
No audio device available, sounds and music will not play.
ALSA: Couldn't open audio device: No such file or directory
Failed to create window: Failed loading libvulkan.so.1: libvulkan.so.1: cannot open shared object file: No such file or directory
[New Thread 125.127]
[New Thread 125.128]
[New Thread 125.130]

Thread 1 received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(rr) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007fe87bdacf9c in TS_VkCreateInstance() () from target:/home/pkgeval/.julia/artifacts/652968b5a5268b98c467f36a5160bcc4db35fbbf/lib/libtelescope.so
#2  0x00007fe87bdb6139 in TS_VkInit() () from target:/home/pkgeval/.julia/artifacts/652968b5a5268b98c467f36a5160bcc4db35fbbf/lib/libtelescope.so
#3  0x00007fe87bdb626e in TS_Init () from target:/home/pkgeval/.julia/artifacts/652968b5a5268b98c467f36a5160bcc4db35fbbf/lib/libtelescope.so

As this crash has been on the top of PkgEval reports for a while, it would be nice to see this fixed. You can easily reproduce the PkgEval environment (on Linux) by installing PkgEval from https://github.com/JuliaCI/PkgEval.jl and doing:

julia> using PkgEval

julia> config = Configuration(julia="nightly")
PkgEval configuration 'unnamed' (
  - julia: nightly
...
)

julia> PkgEval.sandboxed_julia(config)

# this spawns a sandbox where you can install and test Starlight

(@v1.10) pkg> add Starlight

(@v1.10) pkg> test Starlight

[355] signal (11.1): Segmentation fault

In the mean time, I'll disable testing on this package. Please ping me if this gets fixed and released. Thanks!

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

Add CONTRIBUTING.md

Because referring people to a section of the README is not sustainable long-term.

Leverage GeometryBasics.jl?

Might make a good replacement for XYZ.

Pong collision issues

Currently the Pong example has several issues:

• Edge/corner detection sometimes triggers incorrectly near the middle of the paddle, causing the ball to glitch through
• Paddles slide partly into the walls
• Sometimes (not yet sure when/why) the ball will glitch through the wall, miss the goal, and go offscreen, causing the game to become unplayable

The first is likely an issue with the game logic, should be an easy fix. The second and third may require modifications to Telescope, which would be more difficult.

Add logo to README

You know, the one used on the documentation website? The one in docs/src/assets? That I could probably add to the README myself, if I could be bothered to figure out how to

1. link images in GitHub Markdown
2. center it properly
   ...that one?

I want someone else to take care of it.

Finish API documentation

The only reason everything past ECS/Scene is that I haven't gotten around to it.

GitHub Action for unit tests

Running the test suite should be part of our CI/CD setup.

Better error handling

The handleException method is...just barely usable for what it does. It misses the last frame, leaving you to figure it out yourself, doesn't support colorized output, and always closes the App. This is all wrong on many levels.

Set up Open Collective for spending and donations

In our opinion OC is the most versatile, most robust crowdfunding platform. With bug bounties and the possibility of donations, we need to get the financial side of things squared away.

Headless mode

We should be able to run Starlight (especially the unit tests) without a window visible. This was discovered in the context of #14 but is also its own issue. Will require fixes within Telescope.

Tests fail with segmentation fault

Running the tests for Starlight with julia --project=. 'using Pkg; Pkg.test()' fails with the following:

signal (11): Segmentation fault
in expression starting at /home/silver/code/Starlight.jl/test/runtests.jl:11
unknown function (ip: 0x7fc648967ef0)
Allocations: 29808526 (Pool: 29798572; Big: 9954); GC: 35
ERROR: Package Starlight errored during testing (received signal: 11)
Stacktrace:
 [1] pkgerror(msg::String)
   @ Pkg.Types ~/.opt/julia-1.7.2/share/julia/stdlib/v1.7/Pkg/src/Types.jl:68
 [2] test(ctx::Pkg.Types.Context, pkgs::Vector{Pkg.Types.PackageSpec}; coverage::Bool, julia_args::Cmd, test_args::Cmd, test_fn::Nothing, force_latest_compatible_version::Bool, allow_earlier_backwards_compatible_versions::Bool, allow_reresolve::Bool)
   @ Pkg.Operations ~/.opt/julia-1.7.2/share/julia/stdlib/v1.7/Pkg/src/Operations.jl:1672
 [3] test(ctx::Pkg.Types.Context, pkgs::Vector{Pkg.Types.PackageSpec}; coverage::Bool, test_fn::Nothing, julia_args::Cmd, test_args::Cmd, force_latest_compatible_version::Bool, allow_earlier_backwards_compatible_versions::Bool, allow_reresolve::Bool, kwargs::Base.Pairs{Symbol, Base.PipeEndpoint, Tuple{Symbol}, NamedTuple{(:io,), Tuple{Base.PipeEndpoint}}})
   @ Pkg.API ~/.opt/julia-1.7.2/share/julia/stdlib/v1.7/Pkg/src/API.jl:421
 [4] test(pkgs::Vector{Pkg.Types.PackageSpec}; io::Base.PipeEndpoint, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ Pkg.API ~/.opt/julia-1.7.2/share/julia/stdlib/v1.7/Pkg/src/API.jl:149
 [5] test(pkgs::Vector{Pkg.Types.PackageSpec})
   @ Pkg.API ~/.opt/julia-1.7.2/share/julia/stdlib/v1.7/Pkg/src/API.jl:144
 [6] test(; name::Nothing, uuid::Nothing, version::Nothing, url::Nothing, rev::Nothing, path::Nothing, mode::Pkg.Types.PackageMode, subdir::Nothing, kwargs::Base.Pairs{Symbol, Union{}, Tuple{}, NamedTuple{(), Tuple{}}})
   @ Pkg.API ~/.opt/julia-1.7.2/share/julia/stdlib/v1.7/Pkg/src/API.jl:164
 [7] test()
   @ Pkg.API ~/.opt/julia-1.7.2/share/julia/stdlib/v1.7/Pkg/src/API.jl:158
 [8] top-level scope
   @ none:1

The full output with JULIA_DEBUG=Starlight can be found here

OS info

$ lsb_release -d
Description:	Void Linux
$ uname -smr
Linux 5.15.32_1 x86_64

MTK integration

I have received several requests for Starlight to support MTK.

I don't know MTK or what benefit there would be in adding support to Starlight, or what that support would look like, but if someone wants to make a PR I'll more than happily review it, since this really does seem like a cool idea.

Makie backend

Starlight should be available as a backend for Makie, i.e. it should implement all of Makie's abstract plotting functions as well as reexport Makie so that it can be used in the same way as the other backends. This will require deep changes to Telescope.

Improve flexibility of ECS

It would be nice to allow users of Starlight to create their own components in the ECS, so they can make use of component iteration in their own systems.

This would need some way of modifying Starlight.components prior to the creation of the ECS - perhaps a config parameter passed into the App constructor? Or maybe allow directly modifying components and just document that the modifications must occur before the app is created?

I'm not hugely familiar with Julia yet, so there may be a much more elegant solution I'm missing!

Abstract types in structs

The way Starlight.jl's datatypes are currently defined with abstractly-typed fields, e.g. AbstractFloat in

mutable struct Clock
  started::Base.Event
  stopped::Bool
  freq::AbstractFloat
  Clock() = new(Base.Event(), true, 0.01667) # 60 Hz
end

is problematic, as it actually prevents the Julia compiler from working it's performance magic. See this part of the manual.
The problem is that this actually tells the Julia compiler that this field has to be able to hold any subtype of AbstractFloat, so the compiler has to box it, meaning it can't optimize on the actual type of freq at runtime.

The correct way to do this is to use parametric types :

mutable struct Clock{T<:AbstractFloat}
  started::Base.Event
  stopped::Bool
  freq::T
  Clock() = new(Base.Event(), true, 0.01667) # 60 Hz
end

This way, the concrete type of freq is known to the compiler at runtime, so it can optimize on it.

---

As an aside, a better way to define default fields values is to use Parameters.jl :

@with_kw mutable struct Clock{T<:AbstractFloat}
  started::Base.Event = Base.Event()
  stopped::Bool = true
  freq::T = 0.01667 # 60 Hz
end

This has the advantage that it automatically defines constructors with keyword arguments, so the following snippets are all valid,

julia> Clock()
Clock{Float64}
  started: Base.Event
  stopped: Bool true
  freq: Float64 0.01667

julia> Clock(freq=1/30)
Clock{Float64}
  started: Base.Event
  stopped: Bool true
  freq: Float64 0.03333333333333333

julia> Clock(Base.Event(), false, 1/120)
Clock{Float64}
  started: Base.Event
  stopped: Bool false
  freq: Float64 0.008333333333333333

Bullet examples

The Bullet Physics SDK has a healthy examples subdirectory: https://github.com/bulletphysics/bullet3/tree/master/examples

Since Telescope uses Bullet for physics, there's no reason we couldn't migrate their examples and example browser from OpenGL to Starlight.

No reason we couldn't have better documentation for them, too. 😏

Release v0.3.0

Telescope needs updates to correspond with changes made to Starlight. Then the wrapper needs to be updated. Then the kinks need to be ironed out and tests made to pass again. Then we'll be ready for v0.3.0.

Ray Tracer Challenge

I want Starlight/Telescope to support at least the minimal ray tracing functions outlined in http://raytracerchallenge.com/, preferably using Vulkan's hardware ray tracing capabilities. It may not be possible to support all the test cases because of how Vulkan code has to be written, but it's worth a shot anyway.

Cross-reference Telescope docs

There are many places where references to the Telescope documentation would be appropriate. Cross-references should be added.

This issue is stuck pending...the existence of Telescope documentation.

App subsystem composition

Currently all supported subsystems are hardcoded into the App singleton in its constructor. Also there is no elegant way to remove a subsystem from the App's internal dictionary. We need to come up with a proper API for composing Apps out of subsystems, and preferably also a way to model dependencies between subsystems so that startup/shutdown order doesn't have to be hardcoded (as it presently is).

Resize App windows without calling shutdown! first

This is currently disabled. Allowing it will require changes to Telescope (notably the recreation of the Vulkan pipeline). Note that while there will be SDL and Vulkan changes to make, there will also be Julia-side changes, since the App fields will need to be kept up to date (if we choose to even keep them).