What I did today

Miscellaneous Topics
#5861

The last couple days, I added global variable support and while loops to a compiler I’ve been working on. It compiles a “miniC” language to mips32. So, this code:

// Declare and assign variables
my_var = 2;
counter = 10;
// Perform some operations
while(counter = counter - 1) {
    my_var = 2 * my_var;
}
// Print it out
print my_var;

compiles to this:

.data
counter: .word 0
my_var: .word 0
.text
li $t1 2
la $s1 my_var
sw $t1 0($s1)
li $t2 10
la $s2 counter
sw $t2 0($s2)
while_top_1:
lw $t3 0($s2)
li $t4 1
sub $t3 $t3 $t4
sw $t3 0($s2)
beq $t3 $zero while_end_1
addi $sp $sp -4
sw $t4 0($sp)
li $t4 2
lw $t5 0($s1)
mul $t4 $t4 $t5
sw $t4 0($s1)
j while_top_1
while_end_1:
addi $sp $sp -4
sw $t5 0($sp)
lw $t5 0($s1)
li $v0 1
add $a0 $zero $t5
syscall
li $v0 11
li $a0 10
syscall

and prints [icode]1024[/icode]
This has been a really exciting project so far. If you want to view the code, here is the github.

#5862

Had my last uni exam today. Now I only have one more left this summer and I’m done with uni.

Decided to have some fun and coded a super simple ok, maybe not that simple Falcon 9 FT rocket launch simulator in 2D. I’ve inputted the following data in SI units:

  • Earth’s radius and mass

  • Earth’s rotation and the “bonus” horizontal velocity gotten by launching from Cape Canaveral

  • Earth’s atmospheric density approximated with an exponential function of height over ground

  • Target orbit altitude (400 000m Low Earth Orbit, just under the ISS) and the exact velocity needed to maintain that orbit

  • Rocket drag area (circle of radius 2.6315m) and approximated drag coefficient (0.25)

  • The following parameters for the two Falcon 9 FT stages:

    • Weight without fuel (22 tons, 4 tons)
    • Weight of fuel (410.9 tons, 107.5 tons)
    • Thrust (~8 000 000 N (actually 7 607 000 to 8 227 000 depending on altitude), 934 000 N
    • Burn time (162 sec, 397 sec)

The rocket is then assumed to rotate from 0 to 90 degrees over the course of the flight (you never want to point a rocket downwards or you will not go to space today), and this rotation is controlled using a Taylor series controlling the rotation. This allows the rocket to rotate at different rates at different parts of the flight. Basically, this allows the first stage to go more straight up to quickly get out of the thickest part of the atmosphere, and then quickly rotate over to the side to gain orbital speed as efficiently as possible. The Taylor constants are decided using a simple learning algorithm that tries to get rid of the error in altitude and orbital speed/direction. However, if the thrust is simply too high, the rocket will get a too high orbital velocity, so I also added the payload weight as a parameter, so if the rocket overshoots, I just add more weight to it. Also, the rotation of the Earth is taken into consideration, and the drag is calculated (approximately) based on the idea that the atmosphere rotates with the planet (so the rocket starts out travelling at around 408m/s together with the surface, but has zero drag since the air is rotating too).

The learning algorithm just tries random modifications to the taylor constants and the payload weight and checks if the result is a better end orbit than before (= lower error in altitude and orbital speed/direction), and given time it converges on the perfect settings for launching the rocket. After running the program for around 10 minutes and changing the learning rate as it went, I got the calculated error down:

  • -9.909272E-7 meter error in altitude
  • 6.1378614E-8 m/s error in velocity away from the Earth
  • -1.3683348E-8 m/s error in orbital velocity

In other words, the resulting orbit is off by less than a micrometer, and the velocity is off by even less than that. The maximum payload was determined to be 21843.23 kg, which is a bit lower than the payload the Falcon 9 FT is rated for, 22 800kg payload (possibly plus 1 700 kg, not sure if those 1.7 tons are included in the 22 800 number), but at least close enough to be in the same ballpark. Considering it’s a 2D simulation I made with information I could Google in a couple of minutes, it’s pretty cool.

Image of the trajectory:

1020×1014 9.57 KB

The curve at the start comes from the fact that the planet is rotating, so the rocket starts with a high speed to the left but accelerates upwards. The color of the trajectory shows the two stages and how they deplete their fuel (which of course causes the rocket to get MUCH lighter over the course of the flight). Once the first stage is depleted, it instantly switches to stage 2 at which point stage 1 is jettisoned and no longer adding weight to the rocket. It would be possible to add a zero-thrust stage inbetween to add some time for the stage separation. No, the first stage doesn’t fly back and land. =P

Some people go out drinking to celebrate, I write rocket simulations…

#5863

Ah, but that would be quite fun to watch the simulation calculate the first stage’s trajectory!

Also, how many terms are in your Taylor expansion? And do you just evaluate it with a time since launch or some other variable?

#5864

I used 8 coefficients there, but even 3 can sometimes suffice; it depends on the parameters of the simulation. Yeah, I calculate x = (1 - currentTime/totalTime), use x, x^2, x^3, etc with the taylor coefficients and finally do angle = (1.0 - sum) * Math.PI/2 to get the thrust angle. Since my only real requirement is that the sum is 0 at the start and 1 at the end, I just make sure that the coefficients sum up to 1.0 and that handles it.

#5865

I got an isometric tilemap working. I dunno why the camera cuts off the bottom sometimes but I’ll figure it out.

RCvznbMR41w

#5866

Well, strictly speaking yesterday’s fun hack - decided the Electron framework wasn’t bloated enough so added a JVM into the mix! ;D

Apache NetBeans HTML4J and Dukescript examples running on the JVM and rendering in an Electron Chromium window.

960×540 156 KB

#5867

First ever receipt of a donation for software I posted on GitHub, this morning!

#5868

It’s been a really long time since I’ve returned to this site. Always good to see familiar faces while browsing around!

I guess for what I did today, I released v3.8.0 of the Rhythm Heaven Remix Editor. Nothing much; it’s just a side project I work on using Kotlin and libGDX. (Many people have told me how bad of an idea it was to use libGDX for a UI-heavy program, and I fully agree with them! ;D)

Anyways, I hope to poke around again sometime. If I ever get back into game dev I’ll be sure to help out where I can!

#5869

Looks great! Good seeing projects shipping with libraries I wrote too. Not that you seem to be using them! :wink:

#5870

After many months of redoing and reworking systems to make them easier to use, I have finally got resource nodes (points on the level where resources are inputted or outputted) and block templates working. The result is a way of creating block templates that I personally love:

970×298 15.8 KB

God I love Kotlin.
Here’s what the now functional miners and tubes look like:

1200×672 261 KB

I also fixed a lot of bugs with resource nodes and began work on crafter blocks.

#5871

Been getting slowly back into Vangard. As a first step I am cleaning up the old code for the TreeML asset file markup language and adding a ton of test cases to it. I have a single test class that iterates through a bunch of test files which have tags showing what is expected from the test: whether parsing is expected to fail or succeed, what the expected node structure is post-parse, and then a bunch of xpath-like expressions that have to evaluate to true for the parsed document.

A typical test file looks like this (the structure string is a list of indentDepth:typeOfValue; groups):


#result::ok
#structure::1:1;1:2;1:1;2:1;2:1;3:1;3:1;2:0;1:1;
#eval::e1(2)='v12'
#eval::*[1](2)=e1(2)
#eval::*[:'v2'].f1.*[1]='vg1'
{
    e0 : v0
    e1 : v10, v11, v12, v13, v14
    e2 : v2 {
        f0 : vf0
        f1 : vf1 {
            g0 : vg0
            //comment
            g1 : vg1
        }
        f2 : null
    }
    e3 : v3
}

After I have got TreeML better than JSON I will flip to a new method to make the behaviors of Vangardians more deterministic and debuggable. Currently their heads are filled with a free-for-all cloud of competing behaviors, but now I will structure and classify the behaviors to help them pick the most sensible options. I will build a no-GUI sim of the new of the new logic then backport it into the game.

#5872

You should have a go with my thjson library, ags1 :slight_smile:

Cas :slight_smile:

#5873

@princec I like your idea to include binary data values. Will copy that shamelessly. :slight_smile:

#5874

Rewrote the threading system from scratch with new 2-2 threads (main - background, render - background) and 2 extra when more control is need over the task. It became unstable as hell because some code doesn’t like the thread where it runs now, the good side is that there is little to no input lag and assets can be loaded in the background.

#5875

Yep, threading is fun. Found a race condition in our asset loader thread yesterday, which happened occasionally to the other coder on the project. I’ve never been able to reproduce on Windows or Mac OS. Tried to test and debug an unrelated feature on Ubuntu, and lo and behold, bug triggered every other run.

#5876

Put my cleaned up version of TreeML on GitHub, including schema language and validation.

#5877

Started porting the engine to OpenGL ES, implemented a simple abstraction layer to use the same code regardless of the api and got the ui and resource loader fully working. Also changed the compositor rendering, instead of a double-buffer effect accumulator now uses per-effect buffer, this fixes issues with effect passes not working correctly.

    Old                           New

https://puu.sh/zUzlp/1146803707.png

https://puu.sh/zUzvY/3a605884be.png

                       Old                                                                        New

https://puu.sh/zUzEX/2a6b93a817.png

https://puu.sh/zUzKo/9711f3bbba.png

#5878

Played a bit with implementing 2D shadow mapping in OpenGL using an approach I could not find elsewhere, which came to my mind before doing research on existing approaches, but after I read about the “analytical” solutions such as this one:

  • create four 1D depth textures as array texture (width is something like 512 texels)
  • render the depth of the four sides of an omnidirectional point light into these four depth textures with a single draw call by using layered rendering
  • use standard depth comparison in the final shadow mapping shader, selecting the correct 1D depth texture to use based on the quadrant of the light direction
    Result:

1202×846 51.2 KB

#5879

Finished off a blog post I started weeks ago about simple weapon movement; a gun that looks at the mouse and flips right/left:

#5880

Not today, but lately was working on adding some “volume” to the game… Going to focus now on fixing some glitches and might be releasing another alpha version before advancing with better graphics.

1276×796 239 KB