aboutsummaryrefslogtreecommitdiff

Daw

Daw is yet another hobby WIP game engine.

It is written in C99 and can be compiled and linked to easily in any CMake project.

Currently it supports a very limited set of features:

  • Layer based input handling,
  • Window creation & 3D rendering,
  • Hot reloading
  • Resource handling
  • Memory handling
  • UI
  • Logging

As well as a limited set of 2D grid-based game utilities:

  • Pathfinding
  • FOV calculations using shadowcasting

The engine is build around states. This means the developer needs to provide initialize, update, and cleanup functions for each game state (states such as "title screen", "game running", and such). The whole project is made to be easily managed using CMake (yes, I too wonder why sometimes).

Currently the only "supported" platform is linux. I do plan on adding windows support in the future.

I plan on documenting how to use the engine as soon as I stop modifying the API, and plan out a more solid organizational strategy for the project as a whole.

See this CMakeLists.txt to get an idea of how to use this project.

Building

At the moment building with statically linking is borked.

Dependencies

These are the dependencies that you likely need to install yourself.

  • assimp
  • glad
  • glfw
  • stb

Other dependencies are pulled automatically.

Compiling

Generate the build files by running

cmake -S . -B build

And build the project with

cmake --build build

This should, in theory, build the engine as a shared library and run without any warnings nor errors.

The way the engine is designed, it is very useless as a shared library, and does nothing if it is not configured as a subproject of the "game" itself. See tools/cmake/DawAddState.cmake for more information.

Planned features

This is an incomplete list of features that are either under development or planned to implement.

  • Audio
  • GLFW & OpenGL
  • Better cross platform support (ie. windows)

TODO

This section exists to provide an overview of the tasks that needs to be done

  • Enable the user to automatically generate IBO, by exposing some API call.
  • Should make a "renderbatch_update_renderobject" API function, that uploads all the changed vertex data, possibly by using a .dirty flag.
  • Merge textures from RenderObjects into texture atlas
  • automatically generate Index buffers
    • Missing IBO generation, should be easy,
      vertices[n][3]f32 |> sort (
        \original_idx pos_vec3 -> ({x,y,z}, original_idx) /* or possibly by morton codes/z-ordering */
      ) vertices |> sort-by-original_idx
      
    • Should also be possible with assimp
  • Model loading of some sort
    • Should also be possible with assimp
  • Revise rendering pipeline.
    • We should not rely on a single global drawcalls variable, instead we should render to textures and present those instead.
      • These should be resized with the window
    • Should be passed as parameter. we want to completely get rid of GLOBAL_PLATFORM
  • Get rid of CMake?