I worked heavily on my previous pico 8 game whenever SB had the previous “let’s make some games” thread and I didn’t finish until the end of that year so keep working imo!
4 Likes
Yes, but lets officially extend the Bakedown till 2022.
5 Likes
bakeup,
4 Likes
I’m tempted to host another ZZT thing within the next couple months (hopefully without some life-upending event rudely interrupting me).
2 Likes
baked on & on
still slowly picking away at mine and there’s just one problem stopping me from getting the enemy to do what i want.
random doesn’t work. it spits out the same result each cycle as if the seed somehow resets everytime? at least i think that’s what’s going on.
to test it i just decided to print a random number, randomizing it on print. the number doesn’t change. if i print two in a row, the numbers are different, but remain the same in the same order for each cycle. is there something essential i’m not understanding?
1 Like
You’re sure you’re not calling srand() anywhere?
I have a little tile utility running on my stack now.
Even though the bakedown is on all year now, here is the status update for the month.
In January I wrote a mostly complete, algebraic-style pattern matcher for Chez Scheme, a simple prototype object system, an entity-component-system framework, and some minimal bindings to sdl extension libraries. So I’m more or less ready to start doing 2d game development on top of Chez.
In the process I’ve learned a lot about R6RS Scheme and I’ve come to feel a great deal of frustration about R7RS.
6 Likes
just to be doubly sure i ctrl+f searched for it in every tab, nah. to be sure it’s not somehow my system i tried making a blank project and doing the same, and sure enough, rnd gives new values every cycle, so i guess there’s something about my project stopping it.
i figured out what’s causing it. been running reset() before drawing hud on screen to make it independent of camera and missed the part where it resets a bunch of other stuff including rnd()
1 Like
Oh interesting – didn’t even know about the reset() function. My only other guess was that you accidentally wrote to the memory location that stores the current random state in pico8.
It is amazing to me how hellish setting up a developer environment is in every language unless you want to be saddled with a horrible IDE.
The only programming system I’ve ever used which “just worked” is developing for the browser with Node managing dependencies.
any environment in which I am reminded JavaScript exists is a hellish development environment
I don’t know. Javascript feels like one of the most productive environments for me and I’m a smug lisp weenie. Two years ago I made the Ghost Game in like 3 weeks. I know of no other environment in which I could code so quickly and distribute the results so fast.
I love the fact that I can develop on Linux and I don’t have to think at all, in any way, about running the code on OSX or Windows.
1 Like
Yeah I think JS is fine as long as I don’t have to deal with maintaining other peoples’ JS code. The language has a lot of uh pitfalls but is pretty pleasant once you know how to avoid them.
Java, otoh, is entirely unpleasant regardless of how well you know it.
1 Like
Definitely. Also, I can write Lispy-JS if I want to.
Yeah, I have no qualms with the JVM itself! Just Java as a language.
1 Like
I actually hate the fact that the JVM makes it difficult to support efficient tail call optimization in general but Kawa does a few tricks that work in probably 80% of the cases I’m likely to encounter (they claim).
For those who aren’t in the know about this feature it works like this: any function call in the “tail” position of another function call in Scheme is “tail called” which means that the enclosing activation record in the call stack is freed before the call occurs.
Consider this implementation of map:
(define rest-of-list cdr)
(define first-element-of-list car)
(define put-on-front-of-list cons)
(define (map-helper f lst accumulator)
(if (eq? '() lst) (reverse accumulator)
(map-helper f (rest-of-list lst) (put-on-front-of-list (first-element-of-list lst) accumulator)))
(define (map f lst)
(map-helper f lst ()))
Inside map-helper the recursive call to map-helper is in “tail position,” which is to say its the last thing the function needs to do before finishing. So instead of keeping the enclosing activation record on the call stack, Schemes are required to eliminate it. Thus, a conforming scheme can execute map helper indefinitely without blowing the call stack, no matter how long the list is. In most languages, such a recursive implementation would blow the stack at around 1000 or so elements.
This is why you almost never see explicit looping in Scheme - Scheme conditions you to think and implement recursively. Corpse Wizard, for instance, had no loops at all in it until I hand eliminated them in an attempt to improve performance which didn’t even work. In many Schemes the imperative loop construct (somewhat obscurely called just “do” compiles to a recursive function call which a lower level part of the compiler transforms into a simple iteration. I programmed in Scheme for years before learning the syntax for “do” which is somewhat incondite compared to the simplicity of recursive function calls.
This kind of recursive solution is so common that Scheme has a special form for it. The so called named let.
An ordinary let is like this:
(let ((x 10) (y 11)) (+ x y))
Let introduces a lexical context and the bindings it contains and its result is the body expression (here (+ x y)). Named let looks like this:
(let loop ((x 0)
(acc '()))
(if (< x 10)
(loop (+ x 1) (cons x acc))
(reverse acc))))
A named-let introduces a function into the body of the let expression which recurses into it. My brain is so scheme fried at this point that I find it very difficult to write for loops in other languages especially when the iteration expresses some complicated recursive algorithm. Programming recursively in Scheme is so much easier and natural for me!
Schemes are required by the standard to implement tail call elimination. However, something about the design of the JVM makes doing this efficiently in general very difficult and so Kawa doesn’t guarantee it. I can foresee problems but solving them is also pretty easy to imagine. Almost all loops are ultimately expressible as either maps, for-eaches or reductions, all of which can encapsulate iteration in a way that Kawa can optimize.
well, as the only person (i think?) to produce something by the 1st, i was going to declare myself the winner but it seems like now it’s an all year bakedown (???)
more importantly tho’, i need to free myself from the psychic burden of running the bakedown even tho’ i didn’t actually have to do anything… so congratulations to everyone who made something, even if it was for a few minutes or just an idea!
well done everyone and see you all next year!
9 Likes