Aug 5

v0.7 05/08/19


Edited: Aug 8

A new version is out! It has the wrong date; it says 05/05/19 - Now fixed with 07/07/19 version.


I've copied the A1200 manifest into it and compiled a program. It's giving a syntax error on an input line:

locate 19,22:input pw$


It looks like co-ords are working better, as pixel co-ords now match the bob/sprite co-ords. Bobs are now showing much smaller. Possibly too small, but I'll do some testing on that. - Now fixed. The scaling was wrong.


main.amos:181:18: error: syntax error

main.amos:182:18: error: syntax error

main.amos:184:14: error: syntax error

main.amos:185:47: error: syntax error

for check=1 to bobson a#=abs(x#-(bpos#(check,1)))^2 b#=abs(y#-(bpos#(check,2)))^2 dist#=sqr(a#+b#) area#=63*bz#(check) if (dist#<area# and dist#<>0) and (abs(z#-bz#(check))<0.05) then hit=1 next check


Not sure if PAL screen should work yet, but I'm still having to use the tiny NTSC 200 pixel high one. I noticed PAL mentioned in the manifest, and I tried changing the screen to 256 high in there. - PAL screen seems to work now

Aug 6Edited: Aug 6

This is giving a type mismatch:

if (k$="." or (mouse zone=5 and mouse key<>0)) and gridzoom<=10


I also have a bizarre problem where a gosub isn't being done. I've removed a lot of the code and it then works, but I'm trying to work out what is causing it to fail. [update] Found it. It's the Else If problem again. It's the bug that just keeps giving! It used to just fail. Now it causes a gosub near the top of the code to be ignored. Not an easy bug to fix. Who'd have thought that Else If would be so annoying?

This just locks up (though I did get a screen of "u" once, before adding the top two lines):


cls print "key...":wait key txt$="u" if txt$="l" print "l" else if txt$="r" print "r" else if txt$="u" print "u" else if txt$="d" print "d" else print "other" end if



main.amos:61:17: warning: variable used without been declared for this line:

if gamepad axe(controller,1)=-1

Aug 6Edited: Aug 6

This gives a type mismatch:

if a=1 and (b$="U" or c=3)

Anything using different types in brackets seems to give the error.

New Posts
  • With my AMOS Code, when I want to compile it with AMOS2 Compiler, I have errors on the "Shared" statement. V1=23:X=0:Y=0:LIFE=5 Dim MAP(121) Shared V1,MAP(),X,Y,LIFE >> Syntax error here But on Amiga and AMOS Pro, that's works very well. Will "Shared"statement be available? Thanks.
  • Hi there, I downloaded the most recent build (2019-07-13), and followed the Quick Start instructions, but I needed to manually install the pngjs library. If you hit F5 in the Code workspace without doing this, you get: Error: Cannot find module 'pngjs' Require stack: - c:\Development\amos-2\compiler\utilities.js - c:\Development\amos-2\compiler\messages.js - c:\Development\amos-2\compiler\amosc.js at Function.Module._resolveFilename (internal/modules/cjs/loader.js:625:15) at Function.Module._load (internal/modules/cjs/loader.js:527:27) at Module.require (internal/modules/cjs/loader.js:683:19) at require (internal/modules/cjs/helpers.js:16:16) at Object.<anonymous> (c:\Development\amos-2\compiler\utilities.js:21:7) at Module._compile (internal/modules/cjs/loader.js:776:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:787:10) at Module.load (internal/modules/cjs/loader.js:643:32) at Function.Module._load (internal/modules/cjs/loader.js:556:12) at Module.require (internal/modules/cjs/loader.js:683:19) I fixed this by entering the amos-2 folder and running: npm install pngjs I'm running NodeJS v12.6.0.
  • I run a 100Hz monitor, and after recent work in other bugs, I was a little perplexed as to why in amosball, every other animation frame was ~16ms, then ~4ms. In a very predicatable pattern, it was always 2 frames totalling ~20ms. This makes sense for an average of 10ms per frame, or 100Hz, but the every other frame being non-existent was puzzling me further. Digging into this a bit more, I found that this is due to the wait vbl command, which is causing this to skip a frame, but then this raises an issue. On 50Hz displays, your effective FPS would be 25fps (Half PAL) On 60Hz displays, your effective FPS would be 30fps (Half NTSC) On 100Hz displays, your effective FPS would be 50fps (Full PAL) etc... This comes down to a more fundamental question... if we are looking to be backwards compatible with old AMOS programs, which FPS should we target in a wait vbl call? Should this be tunable by the compiler in the manifest? Using the previous times, we should be able to work out if we need to double a frame every now and then (i.e. if we're targetting 50fps, and we're on a 60Hz screen, then we would need to add 10 skipped frames, every 6ms or so). We could use the previous n frames to gauge the current average frame length, and compute whether we need to skip or not. I'll look to add a patch in the next week to see how this looks, and fire it over to you Francois!