Devlog #21

MERGING

I’ve been rewriting a lot of the physics engine for XPBD (eXtended Position Based Dynamics) since the last ship, but on a separate branch so that if I broke anything too bad it wouldn’t show up on the website, but today I finally merged the xpbd branch into main. Sadly, it is a fair bit slower than the previous verlet integration (at least for my simple demos), but it’s a far more flexible integration and constraint scheme and I think the tradeoff is worth it.
(I am a bit disappointed with the performance on the website though, I swear it was faster before I merged it! It’s a lot faster natively!)

Devlog #20

Another constraint, and another failed side project.

Boundary constraint

I added a constraint that I named a “boundary constraint”, that confines a particle to being on the specific side of a line e.g. making four lines around the edges of the screen and making sure the particle is on the side which is visible on screen. This is different from a wall because walls have two sides (and also zero thickness) which can cause a particle that’s going super fast to completely pass through to the other side of the wall in a single physics step, whereas with a boundary it will always snap it back to the correct side of the line. (If this was a bad explanation, I’m sorry).

Failed lua integration

I suppose the word ‘failed’ is a bit harsh in this scenario, I was just dipping my toes into integrating a little lua shell into the demos that would let you spawn particles and stuff programatically, but I decided it wasn’t worth it for small demos that aren’t meant to be super duper flexible anyway because they’re just meant to show off cool features the engine can do.

throwing balls very quickly at the wall, which don’t clip through VVV

Devlog #19

Optimization and Interaction

I’ve optimized the triangle collision code to use the spatial partitioning I implemented before for collisions. It goes through each triangle and checks what balls are in its bounding box with the collision grid, and completely skips any balls that aren’t close. This allows for about a thousand balls in a scene (at least on my computer), which is a lot better than the hundred or so you’d get with just bounding box checks and the tens or so you would get with a naive approach. Sadly, this change is only on the XPBD branch for now, meaning it won’t reflect on the website, but you’d still probably have to be spawning balls for a while for that to slow down, depending on the computer.

I’ve also added far better interaction to the cloth, using some matrix multiplication and some raycast tests, you can now drag the cloth around with your mouse! This change was on the main branch too, so this is right on the website, right now!

I did try to implement a system for having the cloth tear when it was under stress, but it would have required me to rework a lot of stuff and it didn’t quite work out. :(

Devlog #18

Fluid simulation

For a couple days I’ve been researching and trying to implement a PBF (position based fluid) fluid simulation, but there are barely any resources on the topic that I’ve been able to find, and the ones I have found are very math oriented with evil cryptic symbols that take a while to wrap my head around.

The fluid simulation does work, but it’s much laggier, a lot finickier, and not a lot better (if at all better) than just chucking a couple thousand balls together and having them collide normally.

Devlog #17

OpenGL integration

I spend the last couple days integrating OpenGL rendering into a couple of the projects, meaning the graphics will be a lot better and rendered on the GPU instead of being rendered on the CPU, as well as speeding up the demos because even with the added visual complexity, the GPU is just so much faster at rendering!

I made these changes of the main branch so that they would reflect on the website sooner, but git’s merge system is actually super good and it took no more than 15 minutes to merge the OpenGL rendering to the XPBD branch.

I’ve only migrated over the cloth and fluid demos, but they’re the ones that needed it the most, and it’s not too hard to add it to more demos after I’ve had most of the OpenGL boilerplate implemented.

Devlog #16

I migrated the XPBD stuff to 3D and moved all the demos to work with it as well, not much interesting to talk about though. Here’s a demo of it working though

Miscellaneous stuff

Devlog #7

I added input buffering, centered the screen, and added an end animation. I don’t really remember if I added anything else because I haven’t worked on this project in about a month and reading assembly is kinda hard.

Devlog #15: Rebuilding because why not

A bit before shipping, I heard about another physics method called XPBD (extended position based dynamics) that’s a lot more powerful and flexible, and I decided, after I would ship, I would try to convert my engine to that. I kinda have to remake almost all of the physics stuff I already made, but I can recycle a lot of the older code, just making it fit the new framework, and being a lot more educated about physics simulation stuff than when I started this project, it wasn’t too hard to rewrite some new stuff. Right now I have ported over my ball pit thingy, not a lot to show that’s different from old devlogs, but hey, it’s the inside that counts, right?

Devlog #15: shipping!

Super small devlog, just editing the website and the README and stuff like that, really want to ship now!
It just took a while to add messages to all the different demos and I may have tried a little bit of engine stuff but it just didn’t work out.

Devlog #14

I added edge detection for 3D triangles and other miscellaneous stuff, like improving the website, adding VSync to the demos, but that stuff’s boring so I’m just going to show off the new demo!

It might be the coolest one so far, but it was one of the easiest to make.

I’m planning on shipping real soon though, just wanna add a few things to the website and readme!

Devlog #13

I added triangle-walls which vertices are 3 dynamic spheres, which can collide with other particles and have all 4 particles update with their own velocities!
This makes the engine a lot more flexible, so you don’t have to make big grids of spheres if you want to be able to have walls that can move, instead of being static. And it makes rigidbodies (probably) possible!

(Press enter to spawn balls)
Demo!

This devlog is a bit long, sorry! I didn’t want to go too far over 10 hours like a did a couple devlogs ago.

2D

2D is, of course, simpler than 3D, and the length of the function for these walls definitely show that (~40 lines). I used the same algorithm to find the closest position on a line to another position as I used for detecting collisions on the edges of the static 3D walls a while ago. It gives you a lerpable value from from the first point to the second point of the line, and you can use that to find the point you are looking for. Comparing it to the circle you’re checking against, will give the distance and the normal of the collision. You can use that information to move the circle out of the wall, and push the wall away, using the value to lerp between as the ratio to push each of the points that the wall is made of away.

3D

This function is a bit more complicated, being about 80 lines long, but a lot of the information in the 2D version is applicable here too.

Here, instead of trying to find the closest point, we are trying to find the barycentric coordinates of the point, which is similar to the value to lerp between the two points in 2D, but for 3D (It’s basically just 3 numbers which tell you how close you are to each vertex of a triangle, and can describe any point on the triangle). This involves find the triangle’s area that you are checking against using the cross product, getting the distance of the point inward to the triangle for each edge, and calculating some inverse areas, which magically (not really) give you the barycentric coordinates. We then use these coordinates, as long as the distance to the triangle face using the dot product, to figure out whether the ball is colliding with the face, and if so, moving the ball outside of the triangle and moving the 3 vertices away as well, of course using each barycentric coordinate as a weight for how much to move each individual vertex.
I haven’t implemented detections with the edges of the triangles exactly yet though, only the faces, but I will try to implement it soon!

Devlog #12

I improved the website to include multiple demos, and I made a couple improvements to the performance of the spatial partitioning detection, but I’ve mostly just been doing tinkering and testing with the engine some more.

t h i n s n a k e

Devlog #6

Thin Snake!

Finally made the snake thin so it doesn’t turn into a blob.

It should NOT have taken 9 hours, but it really does take a long time to program in assembly. In order to figure out how to bend the snake, it checks the segment in front of the snake, packs the info into 2 bits, and then does the same thing for the segment behind the snake. Then, it does a switch statement (At least, the closest thing to a switch statement in assembly) of the 16 possible values from those 4 bits packed together and then hardcodes drawing the segment. This implementation is definitely a bit strange and not the best way to do it, but it was the first one that worked and I didn’t want to keep trying different methods (doing anything in assembly isn’t very pleasant)

(If the video looks super blurry, that’s because I recorded it at the original 320*240 resolution)

Nearly Finished!

Devlog #5

Apples!

The snake now has some food that appears on the screen. Not much to say here about the feature, it’s snake! But the implementation is a little bit more interesting. In computers, random numbers aren’t much of a thing, so you’ll usually have to settle for pseudo random numbers, but, CPUs today have an RDRAND instruction for generating random numbers from thermal noise and whatnot inside the CPU. but even though it’s on practically every chip today, I still opted not to use it, because

1. Unseeded, so you can’t make a game seed or stuff like that, and
2. They aren’t present on processors before 2012!

And we want this snake to be able to run on the original i386, don’t we?

So instead I decided to use a simple pseudo random number generator I just whipped up on the spot by multiply the seed by some big numbers and xor’ing it with itself a couple times. it’s definitely not cryptographically secure, but it’s snake, so whatever.

What next?

Now that the game is done, I’m gonna add a couple more features just so the game is a bit more more comfortable to play. I plan on adding:

• Centering the game screen (For obvious reasons)
• Restart button (so you don’t have to reboot the emulator) (Or if anyone runs this bare metal for some reason, the computer)
• Choosing colors (Because fun!)
• Button queuing (for convenience)
• Maybe some visual flair (like drawing the snake as thin, some sprites if I can figure those out, and stuff like that)

Hungry snake :(

Devlog #4

Sadly there’s no apple yet so the snake is getting pretty hungry.

The snake moves!

I made the snake finally able to get longer than 1 segment through a circular style array for keeping track of the head. This means that there is an array for all the segments that store the X and Y, and the head slithers through the array overwriting the tail segment so that you don’t need to copy the whole array forward every time the snake moves.

Copy problems

With this way of implementing the snake, you need to shift forward all the segments in front of the snake’s head in memory so that it creates a free space in front of the head, and so the head can move into the free space instead of overwriting the tail.

It’s a pretty simple concept, but I had a lot of trouble enacting this in assembly. Having to think about individual bytes isn’t something I’m used to from having data types handled automatically by higher level languages like C.

This snake is devouring disk space

Devlog #3

Reading more sectors

As I was writing more assembly, I noticed a moment when whenever I added any more instructions, the screen would just go black. I knew I might be scooching up to the 512 byte limit, so I ndisasm’d the binary and found out that, sure enough, I only had 2 more bytes left!

I was preparing to have use more than 512 bytes for my program, so I knew roughly what I needed to do.
You just need one bios interrupt to read a couple sectors (512 byte chunks) into memory, and moved some code around, and now I have practically unlimited (a couple thousand bytes) to work with!

New Snake Habitats near You

Devlog #2

Drawing the grid

I drew a grid for the snake to move on.
The code for the nested loop is not readable at all, but then again, it’s in assembly, no matter how you write it it’s unreadable.

CAUTION: Please do not touch or feed snakes, or the DX register.

I had an issue with the rectangle size being 0, because the size is passed to the drawing function through the DX register and I forgot that the MUL instruction doesn’t just store the result in AX, but also the DX register. This part sounds a bit weird but the stardance devlog guide says to “Include the friction”

Dull Devlogs

I know these devlogs may seem uneventful or dull, but writing anything in assembly is a hard task. It took me over an hour to draw a grid!

I have a rectangle and I’m not afraid to use it

Devlog #1

Introduction

This is my first devlog of making (or at least trying to make) snake without an operating system using BIOS interrupts and 16 bit x86 real mode assembly.

I’ve made my functions for clearing the screen and drawing a rectangle, and it only took 5 hours to do! A lot of was also researching calling conventions, which registers can do what, and wondering why you can’t access memory with the stack pointer register (???? why cant you it LITERALLY has the word pointer in its name)

Devlog #11:

Not a huge devlog, I’ve mostly been having fun with this little parachute demo I made!

I definitely spent too much time just playing with it.

I’ve also been experimenting a bit with multithreading, but it’s not in a stable or performant enough state right now to showcase.

mp4 compression will hate this