sbalaji07

i’ve added working commands that also output to the terminal. i decided to just create an accesible ship struct that i’m editing within different files. it seemed to be easier than the more proper solution, which would probably be to create a function that changes the speed and use that wherever i need it, but oh well. and right now i’ve just got a terrible if chain to register the commands, though i think the way i parse it is pretty rad if i say so myself. the if chain just won’t do however, and i am absolutely just going to have to find a better way.

good day, i am back, having successfully fixed one rendering bug and spending the rest of my time writing a terminal, for what is supposed to be a physics simulator. i decided (for some reason) it should have a full terminal, within the simulation, so i’m just simulating a rudimentary terminal.

i won’t lie though i’m quite proud of the terminal i think its rather good if i say so myself. oh and i changed the font also so it isn’t an squarish eyesore. the terminal works with another camera instance because i finally learned what they even are, but this isn’t a cameras are my hammers so all problems are nails i promise, i stole this technique (among others) from the raylib example scripts.

hello all, turns out that whole grid structure i made is a bit useless and makes everything more complicated so i just got rid of it and started drawing lines. is this what they wanted? this is what they have done.

the ship itself is me drawing two triangles, so the idea that it is one inclusive entity is a lie, just a trick of the cameras, edited in post, if you will. i’m almost certain the problem with the rendering is to do with converting between world coordinates and screen coordinates, but i just can’t prove it. because i don’t know how world coordinates work. i’ve been putting off learning the camera2D function for a while, which is partly responsible for the lack of progress, but im going to have to do it eventually so it may as well be now (or maybe in an hour or two, although at that point i might as well call it tomorrow, or the day after).

Hello friends, I will admit I slightly lost the plot trying to pursue the excessively complex constructions. They don’t even fit into what I wanted this to be because they’re far too lengthy to reasonably fit cleanly into a short animation period.

I decided to pivot and start working on the actual gear mechanism, and then figure things out from there. I’ve now been on the figure things out stage for quite some time and I think I’m starting to lose the will.

For now, we’re sticking simple with a test of the gear system by just drawing a circle. I spent an hour searching for why it wouldn’t work before spotting I forgot to type the word ‘break’, and so I made up for it by breaking my keyboard into small pieces, all the easier to type with, as grandma says.

I’m pretty sure the answers will come to me naturally as long as I search within myself, or maybe that wasn’t the moral of the third and final kung fu panda movie, I really don’t know anymore just watch the circle get drawn okay?

huge updates my avid viewers (there was one comment on the last post so this is a milestone). to begin with i remade the colour system to be able to change the colours for all constructions since inputting values for each construction became a headache very quickly. that isn’t to say that the headache is gone however, because it remains.

i have made a serious and continuous lapse in my judgement and I don’t expect it to ever be resolved, because my modular design to input only points into each of these constructions has made it an absolute pain to accurately tell which point is what, because each point becomes renamed relative to the construction it is immediately a part of. it also means that tracking which lines to draw, which lines to fade, which lines shouldn’t even exist, all becomes like a twenty mile hike without boots up a mountain of legos.

anyway i’ve gotten equal angle constructions working, so that’s neat. and as i spoiled earlier i’ve added a fade function, which may be even worse since its basically a guessing game what is and isn’t going to disappear, however it has resulted in Massive improvements to the visuals of the equal angle construction (it was so much worse before)

added angle bisection. i’ve been quite carelessly balling with the trigonometry and somehow it continues to work, in truth there is a fair chance that the moment i try some of these constructions on different points the entire thing combusts, but that is a risk i am willing to take.

i edited the equilateral construction to include a parameter that configures the direction of the triangle (given a point it should be facing away from). this is because as can be seen, there are always two potential triangles that can be formed, and aesthetically, in cases such as in this angle bisection, it is far cleaner if the triangle is facing away from the point we are bisecting. its a bit of a pain to include a random vector if a particular direction is unnecessary, however for now this solution seems to work, and the design of the bisection is worth the extra input.

added equal line construction. this required rethinking the phase system since I needed constructions to begin one after the other. the best way seemed to be to move the update function for each subsidiary construction into its own phase within the update loop and simply check for completion there.

i also standardised the progress to be from 0 to 1, meaning all construction meaning all phases of each construction will take the same amount of time, it may be worthwhile looking to configure custom speeds for each since the vectorLerp i’m using seems sedated.

i then had the problem of hiding certain lines that were being drawn within my constituent constructions. i was thinking about ways of controlling the hidden and shown segments, but wanted it controlled via a single parameter, so i opted for a bitmask which i can configure within my update function.

fixed enigma machine, should have working cli operation. switched characters to being 0 index to fix the issue with the mod.

also planned out the graphical layout and started rendering the keyboard.

added reverse rotor functionality, this is getting trippy. the reverse enciphering is definitely broken since it may output a negative number if the wheel rotates too much but I’ll just have to fix that later. for the most part, or rather, for at least a couple inputs (I’ve only tested a couple) it seems to be working correctly

separated modular functions into individual files and switched to the three rotors of Enigma I. now utilising an initialiser function to install all three rotors, allowing for changes in the ordering.

one key concept that took some time to understand is that the wiring of each rotor was exclusively within itself. That means, when a rotor rotates, functionally, the input is shifted by one, the mappings themselves never change, as is often easy to visualise. the implication this returns when simulating a compartmentalised process is that both inputs and outputs have to be shifted in accordance with rotation. a rotor shifted one place takes the input ‘A’ into the ‘B’ wiring, and the ‘B’ connection is what is activated on the other side of the rotor. Significantly, if ‘B’ corresponds to a ‘D’, then the next rotor does NOT receive an input of ‘D’, but rather an input of ‘C’, since the first rotor has been shifted by one position.

implemented a single rotor to test out the system. uses the 1924 commercial enigma cipher from https://en.wikipedia.org/wiki/Enigma_rotor_details

I wanted a system to be able to work with regular coordinates, since like usual raylib renders taking the top left as (0,0). for that reason I’ve made a grid struct which I can use as regular coordinates, and simply use the stored values to convert back when I’m wanting to render anything.

I’ve also added a box for where the terminal will be. All tools should be accessible via commands, and this will be the panel with which anything in the simulation can be configured.

I spent a while going through some of the basics I’ll need to implement what will follow, and I’ll include an overview below for my own edification and also in case I ever return to look over it.

Firstly, some basic linear algebra to confirm that pythag holds up only in a perfectly euclidean space, and if any non-orthogonal base units are introduced, we get the wrong answers. The real way to calculate distances without fail is by taking the square root of the dot product of a vector with itself, which I’ve proved below since I hadn’t encountered it before. This forms the basis of the justification behind the metric tensor, which defines the curvature of spacetime by simply presenting a formula with which we can calculate the distances between points (in space and time). Currently just focusing on the Minkowski Metric, the values in the lead diagonal which correspond to the spatial dimensions are simply all set to one, which makes sense since it describes the curvature without any gravity, that is, no curvature at all.

What follows is a recap of the lorentz factor, which I’ve found is easier to understand if the photon clock thought experiment is used to derive time dilation. However, it isn’t exactly mathematically rigorous to go backwards to the original transformations, but oh well, it does the job for what I need. The inverse transformations in particular is the first step towards the spacetime interval.

cleaned up the perpendicular bisector a little more by using a separate function to draw the final line itself. also, added equilateral triangle construction, the repertoire grows

cleaned up the heretical bisector construction code. turns out I was actually right the first time and my ultimate solution was just to employ the use of switch cases but cycling through phases of construction with an enum.

it also turns out that raylib has a function to draw arcs in particular, so my incredible method for manually drawing them with hundreds of lines was unnecessary (i’m so glad that function was in a separate section of the docs, and i’m also so glad that it takes degrees rather than radians like everything else for some reason)

basic raylib grid (matrix transformations already??)

fully animated the perpendicular bisector construction, just please don’t ask how. though, the basic idea was just to split up the total construction progress into each half arc and cycle through the necessary drawings, allowing me to configure each stretch individually. that being said, this may just be the worst possible implementation possible, and I will have to return and fix the yandere sim excerpts (please don’t look at the code)

employed the previously created circle construction method to draw bisectors. the arcs are purely for visual purposes however, the coordinates bisector itself is drawn through some amount of trigonometric shenanigans.

Created a system to construct basic circles using raylib