kyjor / julgame.jl Goto Github PK

This module would rely on a few flags that determine the level of logging (info, debug, trace for example) that can be set as an environment variable. https://trello.com/c/hwwVMxbo/27-debug-mode

I've created a list of features in the engine, but it definitely doesn't cover a lot of things that should and will be added. This could also be viewed as a chance to request features for the engine

It provides the most widely compatible vs powerful backend for writing GPU shaders at the moment.
I'll try looking into this at some point.

Currently, much of the logic is stored in anonymous functions within struct definitions by overloading getproperty. This does allow OOP style code with scene.method() calls but it has two drawbacks:

1. Stack traces contain anonymous functions with uninformative names. It would be nice to see init(::Main) in the stacktrace instead of a gensymed string of characters.
2. Julia is designed for a more functional style so you're probably going to see a performance penalty for always having to go through the if s == :init ... elseif.. elseif... on every get property call. Using normal method calls allows multiple dispatch to do its thing and resolve the correct function, inline where appropriate, etc.

You could solve the first problem by just pulling these anonymous functions out, giving them names, and then still using get_property to dispatch to the correct function. Or you could go all the way and remove the OOP style and mayb see a performance benefit.

Anyway, I'm happy to do the work, but I wouldn't want to do such a major refactor without checking on the direction you'd like to go.

So I tried opening the editor by downloading the JulGame repo and going to here JulGame.jl-main\src\editor\Editor\src\ and then running julia Editor.jl and I get this

Are you planning to implement an entity component system (like the one in Bevy)? :)

Hi Kyle,
Just wondering if you'd be planning on doing some game development "tools/utility" for the Linux plateforms anytime in the future ?
Cheers,
/Terii

From discourse... https://discourse.julialang.org/t/im-creating-a-2d-platformer-using-julia/108057/10

Hopefully these help!

Profiling

It would be good to use ProfileView.jl on some running code if possible to find the hot spots. Is there a basic demo game we can use for benchmarking that can e.g. run for 10 seconds then stop? Something that showcases a bunch of commonly used things so we can see where the real costs are.

The rest of my comments might be a bit random because I'm not sure what the hot paths are exactly, but they should roughly be helpful!

Use concrete types in struct fields as much as possible

I fell like this is the biggest room for improvement. Unstable struct field propagate type instability through all of your code. For example here you have Array{SomeType} in a lot of places, but that isn't type-stable because the dimensionality of the array is not known. So the value will be boxed and julia will need to inspect it at runtime to see if its a matrix or vector.

Vector{SomeType} will be stable, as will Array{SomeType,3}. Obviously Any and Array{Any} are also not stable. Knowing if its at lease a small union helps a lot ::Union{Nothing,Int} is much faster to access than ::Any because julia has optimizations for "small unions"

Here you use Integer which is and abstract type, when Int would be concrete and many times faster to access and use

Put types on vectors

This gives a Vector{Any}

A = []

But if you Know exactly what will go in it, you can instead do:

A = Int[]
# Or a small union
A = Union{Int,Missing}[]

Try to use regular struct rather than mutable struct in your really hot paths. (this might be only 1% of type instability tho)

Julia can optimize the hell out of struct but mutable struct has state the compiler can't track - so they have to exist on the heap as actual constructed objects. Often regular struct never actually exist - they get optimized away to just a few values in registers.

You can also mark some fields of mutable struct with const so the compiler knows they don't change.

Also a comment more than something I'm at all sure is an actual problem!
You are writing some of the most OOP style julia I have ever seen! It makes sense for game dev where things really are object-like. But leaning on getpropery might have some performance and compilation costs too (this is an unproven hunch) because probably compiler people are not targeting this coding style, and julia has a few performance gotchas with variables in closures being boxed or unstable. See:

https://discourse.julialang.org/t/closures-over-types-are-type-unstable/82337
https://discourse.julialang.org/t/documenting-when-the-closure-bug-15276-binds-and-how-to-avoid-it-for-introductory-users/12642

When trying to load a sound in the editor, we are getting an error. We should be able to use either the "Load Sound" or "Load Music" to set the sound as one or the other. Instead, we get an error: