petal - simple game/app framework

[covert flint]

wheel #15. this is a framework that's .... essentially Kha but one or two steps up the abstraction ladder. more accurately, an envisioning of love2d for haxe. (even though i jokingly called it wheel #15, i can't seem to find any library similar to this which is why i figured I should work on this.)

planned targets

• love2d with the love haxelib (that i made)
• Lime?
• hashlink (sdl2 + opengl / dx11? (i don't actually know d3d11 though lol, but i can probably figure it out))
• html5 (could also be done through lime?)
• hxcpp with ... sokol? (although sokol doesn't allow invalidating buffer data before frame present, will have to investigate workarounds or other libraries. raylib?, though only supports opengl)

on love2d target:

love2d target is a bit of an experimental choice, but it is the first target i've decided to implement since it allows me to spend more time early on designing the api rather than implementing stuff. and also because i use love2d api as inspiration for this project. and also because with less implementation code it seems to compile faster for smaller projects at least. and also because it's a target that runs natively, doesn't have an intermediate compilation step, and works on mac (i need to code on a mac sometimes)

project structure

petal projects will need a specific project directory structure:

petal  [file - petal project configuration]
[one or more source directories]
[one or more shader directories, containing .psh files]
[one or more asset directories]
build/  [haxe build files]
out/    [actual generated target project]

.psh file is a collection of shader "modules", either vertex, fragment, or headers to be included by other modules.

here is a sample of a project in the current state of this library:
(this is just a test of mesh api)

this is what it looks like (the rainbow grid spins about the center of the screen)

and this is an example .psh file (though i haven't completed parsing of them)

oh

Word1 Word2 Test!!    jjj

// psh - Petal SHader

// namespace test_namespace;
// or namespace test_namespace {}

@no_guard // this will remove the include guard in the preprocessed output
module test_module {
    // modules can define ins, outs, uniforms, varyings
    // any functions defined in the module can be used by other modules
    // that include it.
    
    // how to include a module:
    // $include path.to.module
}

vertex basic_vs {
    // $in vec2 pos : position;
    // $in vec2 tex : texcoord0;
    $in vec2 a_position;
    $in vec2 a_texcoord0;
    $in vec4 a_color0;

    $uniform matrix4 u_transform;
    $varying vec4 v_color;
    $varying vec4 v_texcoord;

    vec4 main() {
        v_color = a_color0;
        v_texcoord = a_texcoord0;

        return u_transform * vec4(a_position, 0.0, 0.0); 
    }
}

fragment basic_fs {
    $varying vec4 v_color;
    $varying vec4 v_texcoord;

    $uniform matrix4 u_color0;
    $uniform texture2D u_texture0;

    vec4 main() {
        return texture(u_texture0, v_texcoord) * v_color * u_color0;
    }
}

i should mention the reason shaders are like this is to make shader compilation across different graphics api a bit easier

shader source code is just glsl but with some preprocessor stuff added to it

it will just take the given shader source, convert the $ stuff to the proper attributes, uniforms, varyings, etc

well i suppose the uniforms don't need to be preprocessed but i just allow that for consistency

AND ALSO, right now petal project config is a json file but i plan on making it something like this format:

haxelib "echoes"
haxelib "hscript"

classPath "src", "src2"
shaderPath "shaders", "shaders2"
assetPath "assets"
main = "TestApp"

# maybe something to directly inject args would be nice
# arg "--macro MyMacro.func()"

# i think conditional compilation stuff may be useful?
if defined("define1") then
  define("define2")
end

oh almost forgot, i am also planning for the graphics api to have basic shape drawing.
here's a project that makes a red circle positioned at the mouse:

[silent crow]

Why sokol for the hxcpp? SDL3 seems like the most logical thing if you liked love2d. Love2d itself was built on SDL2 so you will find it shares a lot.

Also, you can write the engine in C and use it for both hashlink and cpp. It's also doable in c++ but that adds some unnecessary steps to export functions. (though you would argue that c++ may be worth it depending on how high-level your engine gets)

One more thing, instead of learning directx, SDL_gpu (which is included in sdl3) may be worth looking into (code once and run metal, vulkan, directx12)

[covert flint]

there's sdl3 bindings?
well now that i think about it, i'd have to write bindings for sokol too. lol.

also if I wrote it in C, then it wouldn't work on js target, or it would require compiling to wasm with emscripten

or having two implementations of the same library

thanks for the suggestions