#8 Devlog (Sorry; last one is actually #7)
So I finally completed the rewrite my entire project now uses my new overengineered typing. Yay! Finally!! But that also meant that I had to change my library API to use all of those types. What you see below are just the function definitions for that + some minor input validation. And, yes, you could defnitiely make that a lot shorter with macros but it is 1am and I can’t be bothered to go learn how they work.

#5 Devlog
Of course fixing stuff took longer than I thought (as always), but we are almost there. Only 16 more errors to go!

#6 Devlog
You know the rewrite I talked about last time? I am STILL doing that. It changed so much more that I had expected. Now I have changed just about every function signature in the entire project. Also there were a million little problems that also needed attention. I think I am close to completing the rewrite though; the core types are all set, I just have to deal with the downstream effects of changing them. That shouldn’t (I hope) take too long

#5 Devlog
I redesigned my engine (not implemented yet); It makes much more extensive use of generics now and has in general much better type-safety. This eliminates a ton of bounds checks and potential errors, because the compiler can prove at compile-time that the program is valid (or not).

Also kind of crazy that it says 3.5h for designing. I feel like I spent most of my time in the browser explaining my code to ChatGPT to understand it better myself (ChatGPT did little besides saying “Ah, yes, great idea” and explaining my idea back to me)

#4 Devlog
I have been developing a new model for how cards on the “stack” (a zone for cards). This moves a lot of the verification and testing (“Is the card that is reference by this Id, the card I expect?, Is this card really in the correct zone?, …”) to compile-time and the compiler will simply refuse to compile if its wrong. And I am really proud of it, since this is by far the most advanced thing I have ever done with generics and it is beautiful. All these ifs are just gone

#3 Devlog
I created a single method in this hour. I wanted to just have method that creates an Iterator over a collection of objects. But if you have different objects that becomes very messy very fast, because the concrete type of the iterator is also different then. Now the method only claims to return something that is an iterator, so it shouldn’t be a problem, right? Well it is, because the compiler doesn’t know at compile time what type will be returned and thus can’t do monomorphization. The solution: Make the types of all of the objects the same through static polymorphism BEFORE you construct the iterator by putting everything into an enum and implementing an access method.

You could of course avoid all of that and just use dynamic polymorphism, but who needs that. Also sorry for posting so little, I will try to post more often.

#2 Devlog
I reworked how static abilities are applied - now they are (mostly) compliant with MTG comp rules. By far the hardest (and most time-consuming) part was coming up with a design that can actually accommodate all of the requirements the rules have. It’s madness; you can change abilities during resolution, partially apply abilities and the order of application is incredibly complicated. Once I had that figured out the implementation was pretty straightforward. Design is in the image below.

The second big thing is that I started creating a unified iterator interface to access my cards in a structured manner.

#1 Devlog

So originally I didn’t even plan to put this here, it was just me trying some different ideas. But now that I have spent over 20h and the design isn’t complete trash anymore, I should probably put this here as well. It is still far from complete and actually not that much code for 20h due to a million rewrites. Still, it has a working model for spells, permanents and various effects, so some basic cards can already work. What still needs a lot of work is how to cast a spell, but it is so freaking complicated. Also sorry for no image, but it is a lib and far from runnable, so yeah..

Devlog #4: Stack Overflow

After finding that it works last devlog, it didn’t actually work, because all my other roms kept crashing with stack overflow error. I, of course, started searching for an infinite loop (as one does when confronted with a stack overflow), but this was my first EVER stack overflow without an infite loop. Just shouldn’t have put 32 KiB of ROM on the stack. For anyone wondering, the rom I showed used a variable length cartridge and was because of that already on the heap.

I also did some minor refactoring:

• The header utility has now its own crate
• I use anyhow for errors
• Removed tons of obsolete comments and prints
• Header details can now be printed to the console for debugging

Devlog #5: Final upload

After I finally finished uploading everything to the server and fetching all of the 22K products they have, I noticed that the page is kinda laggy if you try displaying all of them at once (who would have thought). So I implemented paging and downloaded everything AGAIN, because idk?. There is db persistence across builds, but I do it on startup anyways.

And all of that with 1s delay between requests to avoid getting rate-limited by their server. It took sooo long. Anyways, it is ready for shipping, I hope you enjoy it!

Devlog #4: Setting up a server

So for the last day or so I’ve been working on setting up an online server. Getting the OCI (Oracle) Free Tier account took forever and then actually aquiring a machine too; They’re always out of resources, unless you upgrade to pay as you go. The one hour logged here is mainly me creating new Dockerfiles, that don’t have any of the build tools in the live server. Idk what to show, here is some screenshot from the server I set up:

Devlog #3: The frontend

I restructured my project a bit, so I could have a simple web UI for my project. Nothing fancy yet, but it proofs that everything works. Still, quite interesting, since I have never used React before and I see why so many people like it (Also got a fair bit of help from AI with the design; that’s not really my cup of tea).

Since all of the base features are implemented now, I think I will ship it soon, but before that, I want to make a few more adjustments (to not get rate-limited) and polish the UI a bit. Below you see the first UI draft

Devlog #2: Data Expansion

After I got everything set up last devlog I now added some real data collection capabilities. We now track:

• name
• brand
• vendor
• price of one unit
• size of one unit (The thing in the image, not necessarily 1 kg/L/etc)
• image URL
• reference price (How much does 1 kg/L/etc cost?)
• tags like “organic”, “gluten-free”, etc

I also restructured some of the code to make it easier to add new vendors, befor we were kinda fixed on SPAR. That’s all for now, I will now go and create a frontend so that next time I can show you more than some db schema.

Deblog #1: New Project

The end goal is to have an app that can compare prices between different grocery stores and can tell you where you can get your items the cheapest. I have set up a basic project in Docker with Rust and Postgres. Current capabilities are loading product data from SPAR deserializing, structuring and storing it in the db. There is no UI yet, but thats the next step.

Devlog #3: I’m back

It’s been a while since my last devlog, I lost interest in this project and was off playing XCOM 2 again (such a good game!). The main reason why I lost motivation is that I spent forever trying to get it to display anything but a blank white screen. Now I wanted to write that I will keep trying, but when generating a image for the devlog it actually worked. I have honestly no idea what changed, but neither do I care. We are so back! Oh, also there is memory inspection for debugging now.

Devlog #2: MBCs and loading ROMs

I finished support for MBC1 and added automatic recognition of the MBC version when loading a ROM. Then I added GitHub Releases (in theory - there aren’t any actual releases yet), as always it was a chore and took way too long. I also added the little label you see in the screenshot to have something to show here.

Devlog #1: An introduction

Since I have started this project before Stardance there is quite a lot to tell: I implemented (almost) all of the cpu instructions, then I added memory, so it can actually run something. Then I added this wonderful UI you can see in the screenshot (my first UI that doesn’t completely suck, Yay!) and added some MBCs - needed to support different cartridges. The next goal is of course to get it to draw some things to the screen. Might have to screw around with GitHub Releases first though, setting that up is always such a pain.

Anyways, that’s it for now, next one will be a bit more detailed. Cheers!