Michael Abrash: Here’s how you reprogram the PC’s timer, but be warned! It will fuck with your system clock until it reboots! Here’s exactly what happens for this particular application and why
André LaMothe: yolo just chain your ISRs and shit will probably work out? Don’t worry about it, paste the code in, I don’t have time to explain and you don’t care. Also let’s just run all of your game logic in the timer interrupt handler, this is how multitasking works, what could go wrong
Oof! Got it. Two bugs conspired to cause a stack overflow:
* if a task was set to have its output ignored, it was leaving each character on the parameter stack. So the silent loading of the base definitions would leave a bunch of junk on the stack if there was any output. Usually there isn’t, so I didn’t notice.
* I added a definition that contained a comment before I defined the word that interprets comments, so the interpreter dumped a bunch of errors on the stack trying to figure THAT out
went to implement simple text drawing yesterday but ended up writing Jorth code to do animation lerps
managed to successfully write a word that takes five parameters on the stack, so I assume I'll be receiving some sort of Forth Programmer Certificate of Achievement in the mail soon
(Jorth still has no words that can touch anything on the stack beyond the top three values)
I implemented map saving and loading in Jorth and MAN was it slow, almost 5 seconds to load a 100x100 tilemap. So I implemented words to bulk read/write and now it’s very fast. (I am streaming off a compact flash disk, it should be!)
I’ve been noticing startup was slow, as all my Jorth source got loaded and compiled, and assumed it was the interpreter’s fault. But now I realize it’s probably actually because I’m doing unbuffered byte-at-a-time reads. Ooops.
Implemented map resizing at the Jorth console, so I can design spaces that aren’t 100x100. Unexpected side benefit of integrating a live scripting language over the serial port: I don’t have to code a UI for anything in my map editor if I don’t want to. As soon as I implement the word to do the thing, I can just type it into the console.
I also drew a few new tiles.
Uhhhhh my map loading code is slightly broken because there appears to be a weird corner case where it’s reading two bytes at the beginning of the file but then it increments the stream by three bytes? Both fread and fgetc are doing this??
Ohhh I’m not specifying the “b” flag in fopen, and the map height happened to be the carriage return character :/
so remember when I was like “oh the source of all my startup performance problems is definitely byte-at-a-time unbuffered file reads”? https://mastodon.social/@SpindleyQ/101648207901180365
So I implemented a file cache and startup speed stayed pretty much the same. Turns out the problem is actually that tight Jorth loops over thousands of items are Not Fast :/
Hmm, interestingly the interpreter I defined in C is no faster at compiling all my Jorth code than my bootstrapped interpreter written in Jorth, which I guess makes sense given how little code it is
So it’s really the general VM overhead that’s killing me, and to solve that I’ve really only got two options:
* start rewriting the VM in assembly
* precompile code into an image that can be directly loaded into memory
Implemented image saving / loading! Startup time has gone from 27 seconds to, like, 3. When attempting to load game.jor it checks to see if game.jim exists and is newer than game.jor, and if so, loads it straight into RAM. If not, it compiles game.jor and then saves out the image to game.jim. Image loading has a basic sanity check to ensure it’s loading into RAM at the expected address.
For the record, Jorth source files have the extension .JOR, while precompiled image files have the extension .JIM (jean image)
Implemented traveling between areas! Each area unloads its code before loading the next, which should allow me to ensure that I don't run out of RAM to hold text. (I think I've got about 6kb left which _should_ be plenty, I hope...)
Definitely need to design a little helper DSL for defining reactions to the player bumping into areas without sprites, that code is already getting ugly...
Built my DSL - all my player collision code is much cleaner now.
Basically I have N things I need to check before I move the player - is it bumping into an object? Is the terrain walkable? Am I leaving the bounds of the map? - and if one of those questions is true, it needs to optionally perform an action and bail early on the rest. "else if" is not really a workable concept in Forth, so I needed to find another way to simplify this.
Oh no I have completely run out of fun tech to build and now I have to make maps and write and draw stuff. Haaaaaaalp
I’ve made some progress with this but I don’t wanna post a constant stream of screenshots of everything I map out because then y’all won’t have any surprises when you eventually play the game.
Found a fun tech project this evening: create a git repository with a reasonably complete commit history and back it up somewhere. So you can download and play my WIP game now (I kept the EXEs in the repo on purpose), peek at the source code, repurpose my unoptimized Forth implementation for your own ends, whatever. Why not. https://bitbucket.org/SpindleyQ/pete286/src/master/
Slowly realized that the speed of Jorth’s interpreter is likely bottlenecked by symbol lookup. Implemented an easy standard optimization I hadn’t bothered with (don’t do a string comparison if the lengths don’t match!) and suddenly cold startup goes from almost 30 seconds to 20 seconds.
Still glad I built precompiled image support but that’s a significant win
So my game loop was calling "tick" and "draw" by looking up the words in the dictionary every frame. Decided to cache the lookup; not as a serious optimization, just as a little cleanup.
Did I mention symbol lookup is by far the slowest thing in my Jorth interpreter? HOLY SHIT the game runs SO much smoother now. I couldn't believe it, I just started wandering around in-game, marvelling at how the animation wasn't stuttering, with a huge grin on my face.
PLUS, there was initially a bug where my C->Jorth code couldn't handle calling "tick" and "draw", and in trying to fix that, I realized I could get rid of a bunch of ugly special cases and substantially clean up my VM loop. All my core VM functions are now, like, 3 lines of code, I removed a bunch of overhead, and my code can correctly do MORE things than it could before. I finally feel like I have a real Forth implementation on my hands.
* completely nonworking Dexxa mouse, in box
* brandless 3 button mouse, unrecognized by CuteMouse
* unusably flaky 3 button Genius mouse (button would click randomly while moving)
* Microsoft EasyBall trackball, which, while ridiculous, worked, except no right mouse button
* 3-button QuickShot trackball, sticky when moving left iirc
* 2-button Logitech trackball. My sole usable pointing device until today.
Been slowly poking at writing an EGA sprite / tile editor. Started writing it in Jorth using my existing graphics engine but that got complicated way too fast (partly just because EGA is complicated!) so I’m writing specialized graphics code in C again and it’s Good. Jorth still drives the high level logic because why not, that way I get a REPL.
"Hey Jeremy why are you writing your own sprite editor" I mean, besides the obvious "building everything myself the hard way" reason, see this toot from February? https://mastodon.social/@SpindleyQ/101661425411468111
I realized that I was trying fruitlessly to design the finished game without drawing any more tiles or sprites because my NeoPaint workflow was so miserable. And that's ridiculous because I enjoy drawing _way_ more than writing and there were a bunch of elements I wanted to put in that I haven't drawn yet!
@68kmentat Thanks! I am kind of flailing in the dark right now in terms of what to put into it but I'm trying to keep the faith that if I commit to keep adding things, it will eventually become something substantial
@six it's actually a really good trackball! You can be very precise with it! I really wish they'd added another button!
Hell I might even make it my daily driver again now that I'm writing my own graphic editor...
@SpindleyQ I had no idea I wanted an easyball, but woah
are these things robust (as in "can survive an interactive exhibition with a lot of kids" robust)? I've been looking for weird controllers for arduino synths and that might be just the thing
@emptyfortress oops, I meant to reply to this! It seems fairly robust, if only because it’s still working well after >20 years when so many other mice and trackballs I’ve collected are failing. It was also apparently designed specifically for very young children, so I would assume it’s made to take a bit of a beating. https://news.microsoft.com/1996/07/01/microsoft-easyball-wins-1996-idea-gold-award-capping-year-of-widespread-critical-acclaim-for-kids-input-device/
@SpindleyQ thanks! This could be an interesting project, I like the idea of using vintage tech with a modern microcontroller.
@SpindleyQ for some reason the only way i can read this is as Chuck harassing Pete at every step
"where are we going"
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!