@HfduKhgu67717@HypeHypeInc yes current system is a step towards flexible streaming direction! we could select LODs or mips based on scenario specific heuristics and stream only those needed.
600 mb Bistro scene with KTX2 texture payloads loaded within couple seconds on your browser running on WebGPU! Part of something I've been cooking at @HypeHypeInc . KTX2 payloads from a custom cook format are decoded on an asynchronous worker thread & replaced when they are ready.
Internal test game created by a single (senior) developer in 5 days using our new tools and engine. Uses WASM mini-engine (ECS, rendering, animations and physics). 100% AI generated assets using our new asset pipeline. Custom character controller. Slop or not?
Software Engineering is neither Computer Science nor Software Development. People don’t seem to get this.
Software Engineering is requirements gathering, writing an SRS, identifying quality attributes and designing a software architecture around them, creating a work breakdown structure, identifying cost estimates for development, implementing, creating a test plan, and rigorously testing everything to ensure both functional and nonfunctional requirements are satisfied, solving the customer’s problem on schedule, at a low cost, and at a sufficient enough quality.
What is not solved is producing high quality software at a low cost and timeframe. Software Engineering is not “mostly” solved. People are just hacking slop together, everything is fragilely bandaged together and barely works, and it costs a fortune to develop. Reusable software is largely a failure and everything is slow and lags like crazy, using an absurd amount of system resources in the process. Memory leaks, errors, and crashes aren’t uncommon.
There is a ton of work to do still.
An underrated use of physics engines is as a spatial "database" for game objects, even ones that aren't part of the physics sim.
Currently using Jolt for this - get high-perf spatial queries of various types, both broad-phase and narrow-phase, multithreaded updates, etc.
I’ve been AI-coding a lot the past couple of months, and it’s amazing how quickly you can implement features.
The issues I keep running into are non-functional requirements (NFRs). The generated code is often sub-optimal in performance and memory, and it’s not well structured for maintenance. You can debate maintenance if you think AI will keep doing the bulk of the work, but performance and memory are critical NFRs for software that users actually enjoy using.
The development speed is alluring, and skipping code review can be very tempting because of volume and velocity. But if you only validate the functional part, it feels like the frog-in-boiling-water problem with today’s AI-generated code. The codebase gradually deteriorates, and later it’s very difficult to recover because the issues aren’t just a few hotspots but spread everywhere. Death by a thousand paper cuts.
I’m not sure how to keep the development speed benefits while avoiding the NFR hit. For prototypes it’s usually fine, but for production code the quality bar needs to be higher.
its a wrap for #GGJ26 , we made a game on my custom engine #stakeforge. It has definitely-not-Max-Payne protagonist, bullet time and quite a lot of saunas, check out the video! https://t.co/DXRdSZlwHG
#gamedev#cpp#indiegame#indiedev
gpu particle system in my engine, running 5 compute dispatches, N particles per visible-active system. emission and material properties are hot-reloadable! currently only billboard rendering, thinking of what to do next, maybe trails/stretching particles. #indiedev#gamedev
getting ready for #GGJ26, added a prefab system to my engine. you can export an entity hierarchy (and data) as a template and import back anywhere. in-scene templates are locked and kept as reference only unless unlocked, supports nesting! #gamedev#indiedev
@sgt3v no lods yet! there will be definitely some mesh lods contributing to render time seperately. for bones, if needed I plan to do LOD like system where we process only couple bones like hip, spine and thighs only for very far away characters.
further optimizing this, better data layout, animation culling and throttled sampling rate based on distance to view (exaggerated for demo). 1.42 ms for ticking 1024 machines with 50K+ joints in total. you can just do things. code below. #gamedev#indiedev
my engine's take on the fast animation processing discussion, but with a twist: 54272> joints calculated into final poses every frame. 1024 state machines, 53 joints per character, multiple states, transitions, 1d/2d blend spaces. 4.21 ms without parallelization. #gamedev
https://t.co/L1WypicA31, animation_graph.hpp for the relevant system. i think i am mostly done with animations for now, will focus more on optimizing transformation storage for entities. once thats there, i plan to work on IK.
@anilcanglk12 thats very good! if your pose calculation is fast enough you can easily make room for more stuff, layering, masking, IK, blend spaces etc. i only got IK implementation left, then optimizing more on anim sampling trying to squeeze everything more.
my engine's take on the fast animation processing discussion, but with a twist: 54272> joints calculated into final poses every frame. 1024 state machines, 53 joints per character, multiple states, transitions, 1d/2d blend spaces. 4.21 ms without parallelization. #gamedev
@anilcanglk12 instancing is good, I dont prefer it as I am keeping the animation system general purpose, no need to limit the cpu code (all my entities are one ssbo, like my bones, and lights etc.). how many joints per skeleton you are animating?
i reckon could optimize a lot further, but then we'll be getting into user-land optimizations. if game doesn't need it, i won't be taking this any further :).
btw animations are from @quaternius, epic samples 🔥.
rendering is doing it's own thing, multiple passes irrelevant to this discussion, but no significant optimizations on that side other than good enough data layout and simple visibility culling.