More API Docs and functions!

I improved the API docs and also added the following functions to the tile rendering system:

• CLEAR.tiles.clearTileSystem()
  • clears the initialized tile system
• CLEAR.tiles.hideTile(tx, ty, value)
  • sets the hidden value for the tile at tx, ty to value (a boolean)
• CLEAR.tiles.isHidden(tx, ty)
  • returns the hidden value for the tile at tx, ty as a boolean
• CLEAR.tiles.removeTile(tx, ty)
  • removes the tile at tx, ty from the tile system

I also added a simple check to all the CLEAR.tiles functions to make sure the tilesystem is initialized before they run to prevent errors.

BASICALLY READY TO SHIP!!!
I whipped up a quick demo that generates a 5x5 random room that you can spin around with the crank!
I also implemented some basic docs using markdown to explain the basic usage of the API! (the docs are very simple rn, but I encourage you to actually read some of the source code and modify it to suit your needs if you feel you need a special feature out of it or just want more understanding to how it works)
I just gotta make the README actually READable, Make a demo video, and clean up the documentation a little more and then profit!

PREPARING FOR FIRST SHIP!!!

I’m gonna ship the first part of CLEAR-ENGINE, the rendering engine!
After thinking about this for a while, I decided I want to ship my beautiful framework in multiple parts, with multiple stages of completion, and the first part is basically done!
The rendering engine consists of a bunch of math to render all tiles relative to eachother in a cool way to make it look 3D, complete with a simple API to interface with it and full 360 Degree rotation support!
To be fully ready for the ship, I need to do the following:

• expand the API a bit more
• make and render a couple more demo tiles
• make a simple demo project to show off the awesome functionality I made!
• make some docs

I also do currently have my character and action systems in the works, but I will remove those from the demo and will not include those in the docs for now since those are goals for the next two ships I’ll do.

“oh my god he’s actually being productive…”
- the random person in the mirror

CLEAR ENGINE Devlog #3

wait… what happened to CLEAR?
So CLEAR was going to be a turn-based strategy game based on Ready Or Not combined with Tactical Breach Wizards, but I realized two things:

1. I can’t make good art. period.
2. The scope of this project is way more than something doable in the duration remaining of Stardance.

Luckily there’s some good news!

I am a pretty skilled coder, so I decided to just take everything I have so far and turn it into a framework that anyone can use to make their cool 3D-ish turn-based games for the playdate! (I know, very mainstream right?)
so that’s the new goal:

• I need to unify all of my different APIs into one usable API
• I need to make docs 😭
• I need to add some features like

  • A working state system with a planning, action, and response phase.

  • Better art importing systems

  • An easy character making system via custom lua files

  • A demo for the ship

  • more stuff I don’t really want to do!

CLEAR Devlog #2

The Tile Rendering Engine is DONE!*

*hopefully
Now, tiles can render next to each other with no issues, and with 8 tiles in the scene while spinning it manages a SOLID 30FPS!!! The best part is, that’s with the FPS cap set to 30, so I bet I can push 40, or maybe even optimize it enough to get 50!
I also added distance sorting, so the tiles that are the farthest away from the “camera” get drawn first and so forth so that everything appears normal when overlapping.
Finally, I also completely restructured the entire game so far and moved all the tile stuff to it’s own file, to declutter my main.lua script.

CLEAR Devlog #1!

so what actually is CLEAR?

CLEAR is an isometric (ish) turn-based action strategy game that is essentially a cross between Ready Or Not and Tactical Breach Wizards (would 10/10 recommend). The game flow is something like this:

• Your turn! you can:
  • Move any of your teammates
  • Do any of your characters’ actions that you can do based on their mana and turn levels
• Then you end your turn and the enemy plays:
  • They will move, attack, and use abilities to try to defeat your team
• Repeat! (until either your team is wiped out, the objective is complete, or all enemies are defeated)

Features:

• Fog of war! You can’t see anything your characters can’t actively see.
• Multiple missions
• multiple selectable characters to build your team
• Arco inspired skill tree
• Cool 1-Bit artstyle
• Oh, and did I mention it’s (for now) EXCLUSIVELY for the https://play.date!
  Right now I have spent my time working on the rendering engine, that should be done by the next one! (optimization sucks… sigh)

Devlog #1: PROGRESS!

To sum it up: the firmware mod is almost done, and I am going to start on the homebrew menu!
since the last devlog, I went through 4 iterations on the homebrew loader design:

• It. 1: The OG design, a patched update loop that runs my homebrew before the update loop begins, with a file open func to read payloads
• It. 2: same design, but using lower-level uC-fs file IO funcs since the regular ones didnt seem to work when elevated
• It. 3: New design, this time I patched the LoadPDX() function that loads games/apps to elevate permissions if a system app was being ran (there is an unpatched exploit to install any app as a system app so this route made sense)
• It. 4: New design a function is placed at the end of the firmware that just contains a single svc #2, which is the assembly instruction that elevates your permissions and then returns, so that the caller gets elevated (this works because the CPU only will run elevation/permission change functions from firmware code, not loaded code like a game)

Iteration #4 is the current iteration and I am actively working to get it… well… working. The current issue right now is for some reason it seems to crash when I run the homebrew app, but the firmware itself is fine so I am going to try a couple of things.

WE DID IT!!! - WINDOWS BUILDING WORKS!

super quick summery:

• I added the –Name (or -n) option to specify a game name!
• I made windows building work (Duh)

How windows building works:

in a nutshell you essentially just need to zip the entire game directory with main.lua and friends into a game.love file. then you just copy paste it onto the love.exe file present in the zip downloads of love2D for windows and zip the whole thing up into a game!

ofc tho other things needed to be done like:

• figuring out where to download the love2d version from and also extracting it
• setting up the build environment
• staying sane

it works tho! maybe you could test it and then tell me why it broke because we all know it only works on my machine :)

Made a basic game.love build system!

the python script can copy your game dir, zip it, and then rename it to make a game.love file!

also:

• we now have 3 arguments!
  • -h, or –help (duh)
  • -b, or –build to signal the build target
  • -o or –output for signaling the output dir (like build/)

Devlog 0 - The Overview

Hello! Welcome to the first CMPHONE 4 devlog! It means a lot to me that you are reading this!

so what is the CMPHONE 4?

The CMPHONE 4 is a fully open source (eventually) phone powered by a RPI CM4 module. It will run a modified linux distro and will block out social media and use a SHARP MEMORY lcd to minimize addiction while still having support for all the necessities like native 4G calling/texting, Signal through an android container, and a modified discord client.

Roadmap!

• firstly I have to find all the components that I’m gonna use:
  • CM4, Duh.
  • Some 4G cellular chip W/ volte support
  • mental help
  • IP5356 for power management
  • matrix keyboard array (still need to decide the size)
  • some other small parts
• Next, I have to build it… :(
• Then once it works (hopefully) I can start the software development side!
  • Make a modified barebones linux distro that has a custom interface that shows up on the display for launching apps, managing contacts, and ofc settings
  • somehow get signal to display on a screen over I2C, possibly i gotta make a custom client or an android container :(
  • port an ARM discord client to function on the screen (maybe)

Outro

The scope of this project is HUGE and is gonna require me spending hours of time in both hardware and software development and therapy, but I feel that it is achievable.
That’s all for this one,
Elio

(the image for this devlog is just a stock CM4 module because I don’t really have anything to show rn…)

Devlog #0 - A quick Recap

This is my first devlog for PlayBrew, my Playdate Homebrew, and it is mostly focused on explaining what I have thus far.

What is PlayBrew?

Playbrew is a homebrew for the playdate game console that enables the user of the device (YOU!) to unlock your console’s true potential! You can code payloads, which are C scripts compiled into binary files, and then run them on-device with full low level firmware access (no sandboxing!!!). Possible payloads could be one that enables the bluetooth functionality, one that allows you to set a custom lock screen, and even one for game modding! (I have a whole list of cool ideas that I may share later)

The state of things

Sooo sadly right now PlayBrew is unfunctional 😭…
So far I have been able to modify the firmware to allow for ACE (arbitrary code execution (also don’t worry the games can’t access it so no worry of malware :D)) of some C code that gets compiled and appended to the firmware, but I am having issues with the filesystem and am unable to read the actual payloads. The way the arbitrary code runs is by modifying a function pointer to the main FW update loop to run my code, and then at the end of PlayBrew’s code it just returns into the FW update loop and the firmware runs as normal.

sooo now what’s next?

There’s a couple things I have planned, kinda ranked in order of importance:

• Getting the FS to work (I am making progress on that rn)
• Making the payload build system (gonna need help with that lol… I hate the C compiler)
• expanding the API before the full v1 release (I have to manually expose all of the functions from the FW since their addresses can change…)
• Get sleep (so basically I havzzzzzzzzzzzzzzzzzzzz)
• make a way to dump the unlock code (it’s your FW decryption key)
• make an installer
• don’t get DMCA takedown’ed

Sign me up!

hold up there… even If you own a playdate, there are a few different things you need to know ahead of time, and in short, you can’t install it.
this is because:

• firmware for the device (specifically the pdfw file in a PlaydateOS.pdos (which is just a zip) file) is encrypted, so you gotta get your device specific key and write or find a tool to decrypt it, and I can’t legally share one because of the really dumb law called the DMCA :(
• PlayBrew is ONLY compatable with rev. B devices (the newer ones) at this time. I don’t have a rev. A to test it on but it is possible to port it, I just can’t rn
• You need your unlock code, as required in the first point. The unlock code is a special decryption key used for decrypting FW, and it is not accessable AT ALL unless you are on a FW version below 2.5.0 (maybe 2.6.0???), in which case you can use Crank2Unlock to read your code. Otherwise you gotta wait for the exploit I be cooking (or write your own lol).

Finally, If you ever wanna install this on your device, either stay on 3.0.2 which is the latest fully-stable version, or jump to 3.1.0 when It comes out since I’m not releasing my exploit till after that so It won’t be patched :)

also here’s a pic of the current header file, its super broken (Ill star one of your repo’s if you can spot the issues!) but it used to work and it will, and really that’s all that matters.