Skip to main content

Browse GamesGame JamsUpload GameDeveloper LogsCommunity
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
Kitlith2 years ago

I think I ran into a (documentation?) bug. The very first "program" mentions the following: "@IN (253): Reads a value from input (writes are ignored)"

Writes are not, in-fact, ignored, it is it's use as a second argument to a subleq instruction that is special cased, or so it appears. When used as the first argument, it actually reads and modifies memory, as can be seen in the memory view!

I'm not sure if anyone else's solutions relies on this behavior, but it prevents an optimization I was hoping to try on one level.

Reply
jaredkrinke2 years ago

You're right that there's a bug. Thanks for bringing it to my attention!

My original intent was to have writes to @IN be ignored, but it looks like I never actually implemented that behavior. I'm inclined to fix the bug (someday...), but I want to see if anyone's existing solutions depend on the current behavior.

Reply
Kitlith2 years ago

just to confirm, with the bug fixed, `subleq @IN, something, something` would perform a read from the queue, and branch according to the subtraction result, then discard the result? (that's what my expectation would be, at least)

If you wanted to do something more special/possibly useful, you could make this read not advance the queue, acting as a kind of 'peek' operation. depending on the (theoretical) underlying hardware, this could be either a kludgy special case, or rather elegant to add. just an idea i had because of the current behavior which doesn't actually touch the queue at all (for a while i was wondering if it was acting as a peek for some reason, before realizing it was interacting with memory), meaning that as long as no solution relies on @IN acting as memory, choosing whether to advance the queue or not in this case is a decision left up to the designer (i.e. you).

Reply
jaredkrinke2 years ago

Just published an update that addresses this. "@IN" is now supported in either (or both) of the first two address slots:

  • "subleq @foo, @IN, @bar" is the most common case and works the same as before
  • "subleq @IN, @foo, @bar" will read an input, subtract @foo from it, and then branch if the result is less than or equal to zero (and note that the input is not saved anywhere, obviously, so it basically disappears)
  • "subleq @IN, @IN, @bar" will only read the input once, and it will always branch to @bar because the result of subtracting a number from itself is always zero), and again, the input value is not saved anywhere
Reply
AboutFAQBlogContact us
Copyright © 2025 itch corp · Directory · Terms · Privacy · Cookies