To aid me in making games, I decided that I wanted to make some a library with code that I would otherwise have to write multiple times across different projects.

So, I'm going to call it "Janus," because that's the Greek god of all beginnings [of my game projects ].

Right now, its features include:
► Simple key debouncing
► Quick way to get frame delta time
► A system for positional easing with the following eases: LINEAR, QUAD_IN, QUAD_OUT, and QUAD_IN_OUT
► A system for drawing animated sprites with variable frame lengths
► A system for updating and drawing a "QuickUI" for rapid prototyping.
► A method for quick and easy screen-shakes.
► A limited physics system

I'll add more features as I use it in more projects, but these features are the sorts of things that I'd like to start off with.

Demo (Animated PNG):


Github (Demo Code & Program + Library): https://github.com/slimeenergyreal/janus

This was fun to make, and I'm excited to add more features that I think up while I use it.

Latest Screenshot:



In the future, I want to create a quick-start guide for using various features of Janus in games, though until then the documented janus.h header file will have to do.

Well, it's time to add more useful things to this.

Today, I've added:

► Quick UIs (A very quick way to get an interface running for a prototype)
► Screenshake (What calculators lack for audio, they make up for in shacking the screen!)

Here are those eye-candy screenshots that you expect .

UI with 3 options:


QuickUIs have an enum called "QuickUILayoutStyle" which determines the way the second column of options falls into place (if applicable). The options are...

UI Style: Uniform


UI Style: Stack


UI Style: Elastic


Now, how quick are these Quick UIs?

Pretty quick. For the demo file, these were the lines needed for the UI:

Code:

Animation is the hot topic of today's update.

What's the goal? First, I'm going to make an animation:

Now, the goal is to put this animation onto my calculator, and I want the ability to have variable frame lengths, so I will not need to duplicate frames and waste extra space on the calculator.

Thankfully, Janus already has a quick way to get the delta time, or time since the last frame, so this process of enabling animation in the library will be quick.

Previously, there was a struct named "janus_Animation" which animated eases, so that and any code related to it have had "animation" changed with "ease" or "easing."

Now that I can create an animation struct and its respective functions with name duplicates out of the way, I will first create a structure with all the things I need:

Code:


Then, all I need to do is create a simple implementation for updating it.

I can define the animation like this:

Code:

...which says there are 12 frames and points to all of those frames, says to use variable frame lengths and defines all of those frame lengths per frame, sets the non-variable frame length to zero as it's not using it, sets "loop" to true so the animation loops, and sets the initial time elapsed and frame to zero as that will work best for most cases.

Then, I acquire the elapsed time since the previous frame by calling this at the top of my update function and update the animation, and after that I can render it:
(Full demo program here)

Code:


So, this is the resulting animation with custom timings:

---

This is what the animation would look like without custom timings (a lot worse, in my opinion):

---

And this is what the entire demo program looks like:


P.S.
If needed, the user can increase the maximum number of frames in the janus.h header file; I couldn't find a way to make it easy for the user to set up while also allowing them to use as many frames as they might be able to fit.

Looking good You should avoid using floats wherever possible -- they are quite slow!

Also, I'm pretty sure janus_GetElapsedTime could be replaced by the clock() function.

EDIT: as for your maximum frames issue, have you considered just proving a pointer? Then the user can have as many as they want.

Time for buggy Physics

This time around I've added a simple, limited physics system to Janus. I may re-make this in the future because it's not exactly where I want it to be at, but that will probably be when I use this engine and find I need a certain functionality.

Overall, it works well enough for simple platforming, however when more than three objects are colliding, it starts to act undesirably.

To start, I created three important structures:

Code:

These are what the physics system uses to run.

There's a lot under the hood, but let's just take a look at how the demo implements physics using Janus. Note that object1 is the player object that can move and jump.

Here's the demo's result:


Now, you likely noticed the one ~~bug~~ feature in the physics system: collisions involving three objects do not properly resolve themselves.


If I find a reason to, I'll try to fix this, however I don't mind the bug yet because the system already does quite a lot that I needed it to. The hard part will probably be maintaining reasonable performance while supporting a robust-enough physics system to not have this ~~bug~~ feature.

---

How does the demo accomplish this using Janus?

First, it defines two physics objects and two static walls to collide with.

Code:


Then, each frame it updates the physics.

Step by step, it:

Applies the previous frame's physics object velocities to the objects' positions,

Code:


Adds gravity to each physics object's velocity,

Code:


Uncollides each physics object from the static walls (note: if handleObject returns true, that means the first object passed is pushing down on the other),

Code:


Uncollides each physics object from each other,

Code:


Allows the player to move and jump,

Code:


And dampens the velocities of the objects so they don't slide forever.

Code:


Here's a link to the update function code for physics in the demo

---

Thank you a lot for the tips! I've completely removed floats from the code and now measure delta time in milliseconds. The clock function definitely simplified the janus_GetDeltaTime function a lot and it's a lot neater now.

I considered using a pointer for animation frames, however initializing the frames when they are a static array is easier and doesn't require the user to allocate any memory themselves like a pointer seems to. I think it's worth having an array for the quicker and easier setup.


Also, thanks to calc84maniac as well for providing tips and answers to my questions regarding pointers and arrays.

---

I'm really itching for a good reason to pull out this library. Right now I have a few projects going, but none of them are calculator-related aside from this one. A Cemetech Contest would be a perfect reason to pull out this library, so it's time to pray to the multitude of calculator gods that we get one 🙏.

First let me say that I think this is a spectacular project. Props, kudos, well done,... you pick the phrase. I'm blown away by what you've pulled off.


I do believe that with contests, it cannot be a project you started or worked on before the contest was announced.

Thank you a lot!

For the contests, it should be fine to use libraries, should it not? Otherwise the clibs would be off the table. I don’t mean to submit the library demo but rather use it to create a game.

I'm pretty sure that last I heard it was okay to use libraries, provided that they were fully available to the public before the contest.