Jul 14

pngjs installation


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.

@Francois... one for an

npm install pngjs --save

it looks like

Jul 24

Hey Robert. Sorry for the late response, catching up after leaving my job at Q-Loc, I finally have time. Yes, in previous versions on Bitbucket, I have not included the node_modules directory. I do not know where you downloaded AMOS-2 from... Bitbucket or the download link. If Bitbucket, you are a developer and I see you have found your way. If download link, the you should not run the compiler by F5, as it will not run, but by running the packaged version executable from the command line, OR the "amos_test" task that you will find in the .vscode/tasks.json file, already defined for this purpose. And if you assign the F2 key to it, then you will have a TEST key, as in the original AMOS... Much quicker, I use it all the time.

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.
  • 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
  • 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!