4 ms·
Something has gone terribly wrong with the keyboard-handling, half the time it misses a keystroke, or doubles a keystroke, or has very noticeable delay. This i
by roywiggins 5y ago
Something has gone terribly wrong with the keyboard-handling, half the time it misses a keystroke, or doubles a keystroke, or has very noticeable delay.
This is on Firefox. It doesn't seem to have those problems on Chrome.
- krylon 5y agoSame here on Firefox, I have not tried another browser. Makes me feel all warm and tingly with nostalgia, though.
- James-Livesey 5y agoGlad to hear that despite the weird behaviour with Firefox, you enjoy the nostalgia! If it helps, if you want to write really long programs, it's possible to create .atto files in a text editor and then import them into atto by pressing Ctrl+O. Writing long programs in atto is nice, too (since you get the syntax highlighting), but of course it's somewhat hard in Firefox at the moment. Chrome/Chromium-based browsers work well with atto, though, since that's my primary testing target (Firefox second, then Safari third if I can be bothered with it!). Testing atto myself in Firefox seems to be consistent when I type in sentences, just that there's a bit of rendering delay which may feel a bit unnatural. Of course, it's hard for me to investigate how the problem manifests for you; but is it basically like this for you?
- James-Livesey 5y agoInteresting! I've just loaded it up on my latest Firefox and I see what you mean -- there's quite a lot of input lag going on there. I mainly develop in Chrome but I've tested this in Firefox before and it was alright. I better do a bit of bug fixing tomorrow!
- bcrl 5y agoThe non-display of spaces in Firefox is disconcerting. CTRL-C doesn't work on the quintessential test of 10 print "Hello world" 20 goto 10 Doing that on one list as 10 print "Hello world" ; goto 10 doesn't work as the semicolon seems to be misinterpreted as part of the PRINT statement rather than separating multiple statements as most BASICs did. Edit: my memory was wrong - it should be :. It's been a while... The END keyword seems to be missing. Simple loops using IF don't seem to work, and I'm not sure why.
- carl_dr 5y agoI can't help with the IF without seeing what you're trying, but for your other points, press Escape to interrupt a running program, Semicolons are used as string concatenation but you can use colons to separate statements, and STOP is used to halt execution
- James-Livesey 5y agoThe spaces issue should now be fixed (see GH PR #7)! If you do a hard reload, it should be much easier to edit now. `if`/`end` _should_ work; try out this demo to see it in action: https://jamesl.me/atto/?code=10+num%3D0%0A20+if+num+mod+2%3D0%0A30+print+num%3B+%22+is+even%22%0A40+end%0A50+num%3Dnum%2B1%0A60+goto+20 https://jamesl.me/atto/?code=10+num%3D0%0A20+if+num+mod+2%3D... If you press Esc and then run `list`, you should be able to see the code behind this demo. More info about `if` and many other control flow statements are available under `help` > Command reference > Control flow commands. You can also do some one-liners, too: https://jamesl.me/atto/?code=10%20num%3D0%0A20%20if%20num%20mod%202%3D0%3Aprint%20num%3B%20%22%20is%20even%22%3Aend%0A30%20num%3Dnum%2B1%0A40%20goto%2020 https://jamesl.me/atto/?code=10%20num%3D0%0A20%20if%20num%20... Though not precisely the same as some of the original BASIC syntax, I've made adaptations so that `if` works on multiple lines (instead of having to make multiple `goto` statements), much like modern PLs.
- bcrl 5y agoThanks... The code I was trying was: 10 i = 0 20 print "i =", i 30 i = i + 1 40 if i < 20 then 20 I note that if I use i% to force it to be an integer, then it works. Quite a few BASIC implementation defaulted to floating point back in the '80s if the type wasn't explicitly specified. This has brought back some memories. =-) AmigaBASIC was rather nice as it had primitives for dealing with the creation of windows and dealing with mouse input events. That and QuickBASIC kept me occupied for many, many hours as a kid.
- montroser 5y agoI think it's not lag -- it's that on `keydown`, the value of `hidInput` doesn't yet reflect the new input from the pressed key. Seems like on `input` would do better for that event listener...
- James-Livesey 5y agoShould all be fixed now! See https://github.com/James-Livesey/atto/pull/7 https://github.com/James-Livesey/atto/pull/7 for more details. In the end, using `input` still wasn't sufficient to fix the lag, so instead I 'bodged' the delay before rendering happens by adding a 10 ms wait between keydown and render. But yes, you were right in thinking that `hidInput` wasn't 'ready' for the renderer to get the value of!
- Causality1 5y agoOn Chrome Mobile it's inputting characters right to left instead of left to right. Bizarre.