SanguineBrah I may be wrong, but I think INKEY() reads the keyboard, and returns "0" if no key is pressed or the key value if a key is pressed. So, in theory, the loop continues as long as no key is pressed, and breaks when any key is pressed. I checked it with a simple program like this:

10 DO
20 k=INKEY()
30 LOOP WHILE k=0
40 PRINT k

I run it, and it worked, but it didn't work in the dots program. So maybe I'm missing something.
And yes, I tried CTRL+C (the first thing I usually go to), and many other usual execution breaking combinations like CTRL+Backspace, ESC, CTRL+ESC, etc., and nothing seemed to work, except for the (highly appreciated!) Reset button.
I'll keep checking to see if I missed something.

      Dmian You're right, I'm misreading the reference entry for INKEY. I thought it was something to do with converting characters to keycodes.

        I just tried the starfield with both 1920x1080 (HDMI) and 1280x1024 (DVI), and it works perfectly fine, VSYNC and Ctrl-C included.

        Could you do me a favor and try this with basicengine-firmware-h3-v0.89-167-g730c.zip as well as with a current build and see if there is any difference?

        I have recently changed the LCD interrupt to use vblank instead of the scan line trigger because that gives more time for rendering the next frame. I have no idea why Charlie used the scan line instead of vblank; who knows, maybe there is something broken with it.

        That said, in Engine BASIC pretty much everything is timed off the LCD controller interrupt, and if there were a problem with it, it would break the entire system, not just a few select features...

        [BTW, the reset button stopped working for me all of a sudden because the system failed to boot off the SD card after a reset. It worked perfectly fine just days ago, with the same SD cards and the same board. Anyway, updating the SPL to v2017.05 fixed it for me, and I have therefore pushed a new SPL binary to the allwinner-bare-metal repository. There won't be a nightly build until I commit some change to the basicengine-firmware repo, though.]

          Dmian
          I tried your code on the H3 and it ran as expected, exiting when a key is pressed. I also tried on the original hardware and it worked as well, all I did was remove the screen commands from line 10 and line 70. I'll try again on the H3 after I update the firmware.

          uli
          I love the starfield program. The last time I tried using local variables with an array in a procedure it gave me a ton of issues. I assumed it was just not doable based on the warning I saw in the manual but it looks like I'll have to play around with it more.

              uli Before trying build 167 I saw there was a newer one (build 184). I thought that I could try that first, since I was using build 182: everything worked as expected! šŸ˜®
              So I think the problem was with build 182. Just in case, I also tried flashing build 167: worked. Re-flashed 182: didn't work. So the problem must be there.
              Now everything works, and I'm really happy! šŸ˜Š
              Thanks!

                Btw, I wanted to try to replicate the famous 1 line maze program of the C64, and here you have it:

                10 FONT 2:DO:PRINT CHR$(141.5+RND(1));:WAIT 10:LOOP

                Turns out it runs so fast without a wait that you can barely see a thing! šŸ˜†
                But basically, it works as you remembered from the C64, only the character code is changed, and the FONT 2 is selected.

                Did I put the one for the lines? Well, the family wouldn't be complete without it, right? šŸ˜†

                10 SCREEN 15:CLS
20 x=PSIZE(0):y=PSIZE(1)
30 DO
40 col=INT(RND(1)*255)
50 LINE INT(RND(1)*x),INT(RND(1)*y), INT(RND(1)*x),INT(RND(1)*y), col
60 k=INKEY()
70 LOOP WHILE k=0
80 SCREEN 1:CLS
90 END

                And that's it for these simple tests. Now onto something that resembles more a game... šŸ˜Š

                8 days later

                I adapted this program from one I saw on the BASIC-256 site:

                10 n=1
20 cls
30 r=PSIZE(1)/2-60
40 cx=PSIZE(0)/2:cy=PSIZE(1)/2
50 rm=30
60 do
70 ccolor=rgb(int(rnd(255)), int(rnd(255)), int(rnd(255)))
80 for t = 0 to 6.28 step .002
90 x=r*sin(t)+cx
100 y=r*cos(t)+cy
110 xm=rm*sin(-t*3*n)+x
120 ym=rm*cos(-t*3*n)+y
130 circle xm,ym,1,ccolor,ccolor
140 wait 1
150 next t
160 n=n+1:if n>6 then n=1: CLS
170 loop

                It's a simple spirograph.

                12 days later

                Ok, I need a little help of you, if you can...
                I'm trying to move a sprite in the screen, but I must be doing something wrong or forgetting something really silly, because I can't, for the love of me, make the sprite move.
                I have this code:

                CLS: SCREEN 11 '320x256

posX = 151
posY = 122

LOAD PCX "char.pcx" AS SPRITE 0 TO posX,posY KEY rgb(255,255,255)
SPRITE 0 ON

DO
  p=PAD(0)
  IF p AND UP AND posY > 0 THEN
    posY = posY - 1
  ENDIF
  IF p AND DOWN AND posY < PSIZE(1) THEN
    posY = posY + 1
  ENDIF
  IF p AND LEFT AND posX > 0 THEN
    posX = posX - 1
  ENDIF
  IF p AND RIGHT AND posX < PSIZE(0) THEN
    posX = posX + 1
  ENDIF
  MOVE SPRITE 0 TO posX,poxY
  f = FRAME()
  VSYNC f+1
LOOP

                And this little character: http://damianvila.com/basicengine/char.pcx
                I'm using build 427, just in case.
                Can you tell me what I'm missing?
                Thanks a lot.

                  Dmian AND in basic is a bitwise operation, so: "IF p (being 8 if pressing up) AND UP (which is a synonym for 8)" should return 8 if they match. The "<" operator will return either -1 or 0, but if you AND that with the 8, you would get 0. You need to convert the first part to a boolean to be able to AND them in the way you want, so something like "IF p AND UP <> 0..."

                      SanguineBrah Thanks! I guess Iā€™m too used to Javascript, that has very peculiar ways of using logic.
                      Edit: Just to be clear, I was expecting the first part to be TRUE, hence evaluate with the second part, in classical short-circuit evaluation. šŸ˜

                        Ok, I just checked, and there must be something else happening here...
                        I did a couple tests, but the logic seems to work. I even checked if the position of the sprite was being modified (it is).
                        I used this code:

                        CLS: SCREEN 11 '320x256

positionX = PSIZE(0) / 2
positionY = PSIZE(1) / 2

LOAD PCX "char.pcx" AS SPRITE 0 TO positionX,positionY KEY rgb(255,255,255)
SPRITE 0 ON

DO
  p=PAD(0)
  IF p AND UP AND positionY > 0 THEN
    positionY = positionY - 1
  ENDIF
  IF p AND DOWN AND positionY < PSIZE(1) THEN
    positionY = positionY + 1
  ENDIF
  IF p AND LEFT AND positionX > 0 THEN
    positionX = positionX - 1
  ENDIF
  IF p AND RIGHT AND positionX < PSIZE(0) THEN
    positionX = positionX + 1
  ENDIF
  MOVE SPRITE 0 TO positionX,positionY
  f = FRAME()
  VSYNC f+1
  chx = SPRX(0)
  chy = SPRY(0)
  GPRINT 10,10,STR$(chx);":";STR$(chy)
LOOP

                        And the GPRINT statement shows that the position of the sprite is being recalculated, but I see the sprite always at the same position. Weird. I'll try with another build, just in case there's a bug or something.

                          Dmian
                          In the reference manual for MOVE SPRITE: "sprites that are placed completely outside the dimensions of the current screen mode will not be drawn"
                          I wonder if this is not taking account of the differences in H3's screen modes?

                              SanguineBrah I really have no idea what's going on. I tried loading the Shoot-em-up demo, to compare, but it's not loading with this build. If I use SCREEN 5, like in that program, the system crashes.
                              Maybe there's something wrong happening with sprites and screen resolutions?
                              I'll keep investigating, and if I find something conclusive I'll let you know, and see if a bug needs to be reported (maybe Ulrich already knows about this).
                              Cheers.

                                When you use LOAD to load a sprite pattern and say AS SPRITE ..., a location in off-screen memory is chosen automatically, the image is loaded there, and the location is assigned to the sprite as its pattern. When you use TO ..., ..., you override that location.

                                In your example, you have loaded the pattern to the center of the screen, and you also place the sprite itself there. [edit] That works (after bugfixes), but is probably not what you want.

                                Bottom line: Leave out the TO ...,... when loading the pattern.

                                There are two more things required for this to work as intended:

                                1. Set the sprite to the right size: SPRITE SIZE 14,12 ON.
                                2. Add a workaround for a bug that sets the colorspace to 0 after switching modes by adding PALETTE 2 after the SCREEN command. I'll have that fixed ASAP.

                                OK, then it works on SDL, but not on H3 (even if it should). I'll investigate...

                                The sprite/BG engine was not enabled when only sprites are used, and the ANSI terminal emulation caused the crash when switching screen modes. I have also fixed the incorrect default color space.

                                Note that I have been working on a somewhat disruptive change for a while now and I need to review that stuff before I push the next update, so this may take a day or two until it shows up in a git build.

                                Some more tips in the meantime:

                                1. It is not necessary to use STR$() here, PRINT/GPRINT accept both numbers and strings.
                                2. [edit] You can avoid the funny character at the end of the GPRINT output by appending ;
                                3. No need to tell VSYNC explicitly what frame to wait for here; just VSYNC will do.
                                4. SCREEN does CLS already, no need to do it manually.

                                BTW, with the bugs fixed your original program works almost perfectly, only the sprite size is wrong. šŸ˜„

                                [While we're here, I'd also like to point out how loading images with a mask is different if you load it in the off-screen pixel memory vs. the visible screen:

                                In the first case, all pixels are drawn, but the "keyed" pixels get an alpha value of 0. That allows you to BLIT or SPRITE the image without having to explicitly specify a key again, which is something that was not possible on the ESP8266.

                                In the second case, only the non-keyed pixels are drawn in the first place, because that's usually what you want, and the text screen does not have an alpha channel anyway. [At least not one that is actually used. [That might be a bit too much useless detail. [And too many brackets.]]]]

                                Thanks a lot Ulrich!
                                Everything that you wrote is interesting and very informative. In my case, I'm really not in a hurry. At the moment I'm trying to create a simple physics engine for side scrolling games. I was trying to make the character jump, and was puzzled when I got no visual results (but was able to see the values going as expected if I printed them out).
                                I can continue with other exercises and others parts of it, so no big deal.
                                Thanks a lot for your input on this. šŸ˜Š

                                Edit: I just realised that my use of STR$() is just a little paranoia coming from Javascript, being an untyped language, so I always fear of causing exceptions by using the wrong type of variable... šŸ˜†

                                Oh! @uli I forgot, I have a question:
                                Can a PNG with an alpha channel be loaded as a sprite?
                                Something like LOAD IMAGE "image_with_alpha.png" AS SPRITE 0
                                Or is PCX the only accepted format and you have to key it?
                                Frankly speaking, I had to download GIMP (a program I don't use and sincerely don't like) to convert PNGs to PCX to import as sprites. But I know other image formats are allowed now, though haven't tried loading PNGs with alpha as sprites yet.
                                If you tell me that a PNG with an alpha channel can be used, you'll make me a happy camper. šŸ˜
                                Edit: same for backgrounds, mind you.

                                • uli replied to this.

                                  Dmian Should work. Backgrounds now support transparency as well.

                                    Powered by: FreeFlarum.
                                    (remove this footer)