For my scenery area stuff in First Plague, I figured I would need to use convex polygons to represent the area and the scenery bits to fit inside; I didn't have real convex polygon handling with collision test, but I already had convex polyhedrons that I already use a lot for my 3D stuff, which share almost all of the same concepts, so I pretty much only had to adapt the code to 2D.
After weeks of coder's block, the way scenery chunks are added is satisfying to me. In the first video, the pink marked tiles represent the tiles seen by the actual in-game camera, chunks are added only if an empty tile becomes visible. A tile "prefab" is picked randomly, depending on the available space. Tile "prefabs" can have varying size (to allow big chunks that contains big monuments and pyramids or complex arrangements, or small bits of forest or town). The heuristic gives a good enough result for me for now, would be better if it could do several passes. https://streamable.com/1y2ta7 The second video shows how it actually looks in game (no empty tile, there's still some popping sometimes because tile visibility doesn't take the chunk's height into account yet). https://streamable.com/6ei8v3 Now I need to be able to fill these chunks with stuff (palm trees, monuments, cities, groups of crocodiles...)
Finally a bit of progress on First Plague: tracks don't have to be strictly on a straight line, and scenery chunks try to follow that. To ease that, the chunks must now fit on a tile grid. There is still a long way to go (the amount of scenery would ideally depend on the camera angle, the camera would smoothly follow the track, and there is not yet objects (trees, houses...) in the scenery tiles). Here is a debug view, way above, that shows track parts and scenery appearing and disappearing. https://streamable.com/t62vwd
Since I wanted to rethink the way scenery is done to make the levels allow freeer layouts, and since by default it's an infinite runner with an infinite procedurally generated level, I figured the less headache-inducing solution would require snapping everything to a grid, so I added a grid visualization in my editor; the way it's drawn is not pretty, but at least it does the job.
I'm several years late to the party, but now I can auto-reload assets by watching modifications on directories/files It currently works with textures, shaders (both shown here), and meshes, and is easy enough to watch game-specific assets (here, chunks created with Trenchbroom for First Plague) https://streamable.com/a20vpn
The water surface is now part of the chunk instead of drawing a single big patch of water, which may allow later to have chunk with water at different heights, or have a pond of water in the scenery that looks different from the river's water. Also, now the chunks don't have to all be the same size. https://streamable.com/zmsf52
Got pretty much all the features I need for a primitive editor for First Plague =>Load/Save/Compile levels =>Edit possible chunk combinations, import new chunks =>Edit the series of chunks that appear mandatorily at the start of each run https://streamable.com/n2aa7e
The sprites and the trigger's translucent meshes are now all drawn in the correct order. The difference is subtle from what I had previously - palm trees were already sorted offline, which was hiding most of the issues - , now for 2D elements it looks always correct, even when turning the camera all around in editor mode. For the trigger's mesh it's an approximation and sometimes some trees close to the limits get drawn in front or behind depending on the camera's position, but I'm going to stick with it, at least for now.
First primitive version of the tool that allows you to choose which chunks are "compatible" with each other for first plague. Also allows to drop new chunks, save, load, and compile the level into a flat-loadable file for the actual game. https://streamable.com/9wxmko
Started the embedded editing tools in First Plague, added a toggleable free camera https://streamable.com/z9c1x0
D3D12 doesn't offer an equivalent to glGenerateMipMap(), so for a while my engine was doing a slow mipmapping process on the CPU. Since I'm a complete noob in compute shader and didn't know where to start, it stuck for a while. (The "GenerateMips()" in Microsoft's MiniEngine was hard to extract because of all the layers.) Then someone on the Discord posted this tutorial: https://www.3dgep.com/learning-directx-12-4 But it was still using a layer on top of D3D12 and d3dx12.h, which makes it hard to port to my existing engine. And I didn't go in-depth with D3D12 for a while, so I forgot how some things worked :p Then I found this one: https://slindev.com/d3d12-texture-mipmap-generation/ Which is not as complete, but at least more readable. In the end, I started something by mixing Microsoft's "D3D12HelloTexture" (loads and display a textured triangle) and "D3D12nBodyGravity" (runs a compute shader) samples (https://github.com/microsoft/DirectX-Graphics-Samples/tree/master/Samples/Desktop) and the 2 tutorials above still helped me, and this is where I am so far. The right set of quads is drawn without mipmaps, for reference.
Just released a new version of First Plague, the jam game I started in the beginning of September, with the improvement of the triggers' visuals and the chunks' assets reorganized: https://lhuillia.iiens.net/wejv10/WEJV10.zip
Made a small effect around trigger, and since I draw them as brushes, it was easy to make them prettier by rounding them a bit. I had to fix an issue with the effect's reflection in the water, fixed it by adding a blend mode that just erases the target color/alpha with the source's (I had the issue in DX, where render textures are drawn upside-down compared to OpenGL, so I add a step when I redraw it upside-down to get it right...)
Among other internal changes to make the game's content more flat-loadable and easily moddable, I made the area where you can pick up people in First Plague more readable. Requires some more work to make it prettier.
The blood stream is now better integrated into my water
A game jam game I made during the week-end, using my same engine as usual, tried to recycle as many things from previous/unfinished projects as I needed https://www.developpez.net/forums/d2090844/applications/developpement-2d-3d-jeux/projets/we-jv10-first-plague/ https://s1.gifyu.com/images/familiarfaces.gif https://s8.gifyu.com/images/losing.gif https://lhuillia.iiens.net/wejv10/WEJV10.zip
I can now place smoke cloud tiles on the map in Fire Exit, and therefore the map's borders don't have to look straight anymore. I also changed the cloud shader I use because the other one wasn't working fast enough on older computers, the new one is based on this: https://www.shadertoy.com/view/lslXRS
The ugliest and most impractical 2D mesh editor you'll see today, embedded in one of my games' editor. All I needed was to make some tile types for clouds and output them as a C struct, and it ended up like this.
I finally made some visual progress on one of my games: with the help of my girlfriend Biiscuit, we decided that the map would be surrounded by the smoke caused by the fires going on all around the planet. I based the smoke on this cloud shader: https://www.shadertoy.com/view/tlBXD3 Enjoy the Twitter compression: https://twitter.com/Guntha_en/status/1264671905589665792 (Before it looked like that:)
Made some small glsl and hlsl syntax highlighters for @rxi 's lite to help myself; since I need to edit both HLSL and GLSL shaders for my games, in each syntax highlighters I added a list of keywords, types and built-in functions from the other language that don't exist in the current language and display them in flashy bright red when used, to avoid common mistakes. In the gif below, copy-pasting a line from an HLSL file to a GLSL file (I know glsl files don't really have standard extensions, that's the one I use in my project...) quickly shows what needs to be adapted.
...And there on a 10-year-old WIndows 7 laptop where it falls back to OpenGL3.0
Here I tested it on Windows 10, where it links to the D3D12 backend by default...
Something that took me weeks to finish in my engine/games: have 1 executable that selects the most adapted rendering backend at launch. For years, I supported both OpenGL3.0 and D3D12, but in separate executables, so the user had to select the right one. Now the implementation of the rendering backends is separated into dlls, and the executable choses the most adapted one at launch (except if the user overriden the "most adapted" one with another one in the options screen) I'm still keeping the ability to build with the renderer embedded in the executable, mostly for the case where, for consoles for example, there is only 1 backend available and it wouldn't make sense to still have the overhead of calling functions from a runtime library. And for easier debug when I want to add a feature to my renderer.
https://store.steampowered.com/app/1202970/Mad_Tracks/ A PC game from 2006 that is getting released again soon on Steam, with some updates (Steam overlay/Steam Cloud, Xbox controller support, a little bit of graphical updates... I was the one who worked on it, and I had about a month to do it