Ship
Added cats
I have added my friend’s cat, Mumuy, into the game as an enemy which follows the player around and attacks if she gets close. This took such an incredible amount of pain and debugging with the memory buffer that I’m almost ready to call this project done. In the next devlog I’d like to polish up some things and then finally release the project.
I knew this would take a long time but uh…..
oh.
I have now created a functioning inventory pickup system, and opening doors will now check to make sure the player is holding the corresponding colored key before it opens.
To do this, I had to store an array of colors of the keys in the program memory for the player’s inventory. But since I can’t always guarantee that the array doesn’t have gaps in it, each frame also generates a list of positions of the colors addresses (I guess in a really cursed way you could call these pointers?) so I don’t have to sample the entire inventory list for every pixel in the rendering passes and can instead read the pointers list to know what inventory index to render.
Added spinning keys as placeable objects in the map image
I modeled this key in blender and rendered out eight frames of it spinning to create this texture atlas. The atlas is pulled from based on the GameTime.
Loading keys into memory from the map proved to be quite a challenge. When initializing the map, the shader reads the map texture for any pixels with opacity 150 and treats them as keys, loading them and their data into a few rows in memory. The data stored and updated along with them is: Their coordinates on the map, their colors, their distance offset from the player, and their rotational offset from the player. Using this data, I created a render pass after the map renderer that adds these in.
Next will be a pickup system so they can be used to unlock doors. The player inventory system is probably gonna suuuuuuck to make.
Map units can now be destroyed in real time by pressing the space bar.
Listening for the player jump predicate and treating it like an “action” input allows me to make the map destructible. This will be used later to make doors that require keys to open.
Additionally, inputs are now polled independently of one another, as shown later in the video. Each input set (movement, rotation, action) has its own text display associated with it, and now the shader samples from three points on the screen to get all the inputs at once.
Wall textures are now sampled from texture images
using the raycast positions, I can determine the x coordinate to sample
from on the texture just by modding the larger coordinate by one (making
the texture repeat every unit.) The Y coordinate is based on the
current calculated wall height (determined by the distance between the
raycast and the player.)
Next I will make textures loaded on an atlas instead of a single image
so I can make multiple different types of wall.
Spent a huge amount of time refactoring my entire fragment shader pipeline, splitting it into more than two render passes.
Before, there was one pass to update data, and one to render the data. Now there are six:
Player input -> Update Map -> Update Player -> Collect Raycast Data -> Render Map -> Update Global Data
All these passes share one 512x512 persistent render target to store/load data, which gives me about one megabyte of “ram” given that each pixel stores 32 bits. This should be more than enough for what I need. Currently, I don’t even use half of it, with the largest chunk storing the 256x256 game level that can now be affected by the player.
As an added bonus to this new render target storage method, I now store the coordinates of where each camera raycast hits, so I can map textures to the walls. I think I’ll work on a system to do this next.
4th Devlog,
Rewritten the raycasting system.
Now the map is gridlocked to its texture, with each pixel representing one unit. The raycast only has to
check the status of each pixel it passes through on the map image rather than sampling at a defined distance interval that could potentially pass through the corners of units.
I also fixed the previous fisheye effect by multiplying the caculated ray distance by the cosine of its angle offset from the center
Next I would like to work on texture mapping to the walls, but with what I plan to add in the future I think I might spend some time refactoring the way I store the program’s memory so I can fit more data in it and organize it better.
Beginnings of player input
Because shader code is run entirely on the GPU, I can’t just directly listen for keyboard input. The only thing that the shader code actually reads is the colors rendered to the screen by minecraft, so I needed to make a sort of “translation layer” that listens for player input in minecraft and outputs a color on the screen so it can be read and interpreted by the shader code.
My really jank test rig
As shown in the video, the color of the square updates depending on the pressed keys. The inputs are gathered using minecraft’s “predicate” system and are translated to the background color of a text display entity. The player is mounted to an armor stand to stop them from moving away, keeping the text display in the center of the screen always.
How I keep track of data in code that can’t store variables
If a shader can only read colors, how does it remember where the player is?
This question was one that I had until I discovered minecraft’s support for the persistent render target. This allows the shader to sample from the pixels it renders in the current frame in the next frame. A floating point number is stored using thirty two bits. Each pixel’s color is stored with eight bits of precision each for red, green, blue, and alpha channels, which also happens to total 32 bits.
So I wrote what is possibly the strangest utility I have ever written, that can translate a float to an rgba color and an rgba color to a float. Now, using a persistent render target that is simply never rendered to the screen, I can store the player’s x, y, and camera position in colors, and update them based on the color in the middle of the screen from the minecraft render.
I suppose the persistent render target sorta counts as the game’s “RAM.” I’ll be using it to store a lot more data in the future, but next I’ll be fixing up some issues I found with rendering and player control.
I finally got some actual visual output!! After fixing many compiler errors, and then another few that kept causing the loaded data to reset, I got this output. The current system renders walls based on the pixel’s distance from a wall defined by a texture (visualized in the picture). This created a sort of fisheye distortion that I’ll try and work out later, but I’m happy with my progress for now, and would like to focus on getting player movement functional
Minecraft has in recent snapshots greatly improved the capabilities of its shader system, now allowing postprocessing shaders “post effects” to be applied using commands. This has wildly changed what is now possible in vanilla minecraft and I immediately was overcome with excitement about what was now possible. After playing around with it for a while and discovering the “persistent” mode on custom render targets, I realized that even more than expected was now possible, and found a way to make posteffects that have fade-in animations by updating the value in a persistent render target over the course of a few frames. To make it consistent across different frame rates, I had to figure out a way to get a deltatime (time between frames), which I was able to do using the GameTime uniform in minecraft.
Having gotten a deltatime, I began wondering about the possibilities of creating a fully functional game contained entirely in a minecraft postprocessing shader…
