|
Wanted to get in on this, so I made Chip2048 http://johnearnest.github.io/Octo/index.html?gist=b1fa3c3cd504195823ae WASD tilts the board as usual, 1 starts a new game. Octo syntax is great, but it feels far enough removed from a bare list of mnemonics that I've got one kind of dumb request. Can you make commas read as whitespace to the tokenizer? I found it easier to deal with the structure of things when I could group commands together on one line that formed one logical unit. Like indexing a table is a least three commands but I liked treating it as one indivisible thing like code:Lime fucked around with this message at 02:20 on May 24, 2014 |
#
¿
May 24, 2014 01:49
|
|
|
|
| # ¿ May 10, 2024 14:11 |
|
|
Internet Janitor posted:Minor note: I corrected an error in the subtraction opcodes of my interpreter. I've updated all the affected example programs. Jusion's "Thom8s Was Alone" was broken by this fix, so I repaired it. The version linked in the OP should work now. I was fixing up something I did before to work with this change, and I noticed Octo is treating a zero result from a subtraction as underflow. If you do v0 := 3 v1 := 3 v0 -= v1 then vf == 0 even though there was no underflow / borrow. Is this the correct behavior?
|
|
#
¿
Oct 5, 2014 10:00
|
|
|
Cool, fast work. My Bresenhams line drawing algorithm now needs a couple less instructions. Related, I was thinking about your compression problem and not getting anywhere, but I know drawings things programmatically was popular in old adventure games, so I tried a dead simple list of lines representation for your scenes. Here's the geometric one. 25 lines at 3 bytes each = 75 bytes, a bit better than RLE. The unpacker and the line drawing take up another 157 bytes. I didn't work up the whole Myst-like scene but what I started suggests maybe 60 lines total, so 180 bytes. Adding a two byte form for very short, 'touch-up' lines might shave off another ~20 bytes. Other possibilities are commands to start connected line sequences or to do sprite drawing, handling for example the four trees at right. 100 bytes per scene might really be workable this way, and with some cheap 20-30 byte interstitial scenes, you could get a pretty full feeling world. Lime fucked around with this message at 17:30 on Oct 5, 2014 |
|
#
¿
Oct 5, 2014 17:26
|
|
|
31 bytes based off Buffis's one pipe per iteration http://johnearnest.github.io/Octo/index.html?gist=449ca18529419160d9bae705bc7d5538 I changed how the physics work: instead of increasing velocity every iteration and then dividing by 4 before adding to position, I overflow a different register roughly once every 4 iterations and then simply add the overflow flag vF to velocity and velocity directly to position. This eliminates one shift-right, saving 2 bytes. The old bounce velocity of -6 doesn't divide by 4 so I had to round up for this new scheme. This makes the bounce roughly the same as using -8 instead of -6 in previous versions. This maybe doesn't feel as good to play and it's harder to break out of the initial death loop, so it's arguable that this qualifies. EDIT: Here's an especially lovely 30 bytes version. Use X to flap: http://johnearnest.github.io/Octo/index.html?gist=2536074e89cefada3523bda78a5340c5 By using the first half of the code to initialize all the registers and the second half for graphics, I only have to set i once. I lost a byte from rearranging the loop so I could get a 0x3f in a register. EDIT: I have to stop. 29 bytes, nigh unplayable: http://johnearnest.github.io/Octo/index.html?gist=3d9790399e1fd973ca4b45ed85f054bb I got the padding as address trick back by using v3 for pillar sprite y to make the 0x3f I needed. Lime fucked around with this message at 07:56 on Jul 30, 2016 |
|
#
¿
Jul 30, 2016 00:53
|
|