Roy___ 2019-05-03 19:05
Playing with sprite Y coordinates each raster line. You can also do similar things with X coordinates.
Also a simple animated parallax starfield.
Timo 2019-05-03 19:13
Super cool :)
dredds 2019-05-03 20:23
That is amazing
was8bit 2019-05-04 05:32
Roy___ 2019-05-04 07:42
Just poking random things to see what happens!
was8bit 2019-05-04 08:43
Dats so clever ;)
I like PEEK and POKE, lots of fun :)
Roy___ 2019-05-04 20:38
I was hoping poking values for stuff would be quicker than using basic statements (sprite positions for example) - but it actually seems slower? Trying to fit things in per Raster line is hard!
was8bit 2019-05-05 04:33
I reserve using PEEK and POKE where there are no easy basic approach... I’m unsure about the time factor, im guessing on average to about the same as basic commands time wise...
TIMO has been adding lots of cool basic stuff ... I really look forward to more :)
was8bit 2019-05-05 04:40
There are some cool PEEK ones that let you read the values of the note and volume of each of the four voices, which is great for visibly synching special effects with music or sounds :)
Blockhead 2019-05-05 08:35
Timo 2019-05-05 11:53
Roy, POKE has the same CPU cost as any other command, too. The details are explained in the chapter "CPU Cycles" of the manual. You probably expected that POKE behaves more like an assembly command, but it's actually just BASIC. Anyway, the costs of the BASIC commands are calculated as if they were machine language, not like an interpreter.
I stole the cycle limits from a Game Boy. The raster interrupt time is really short, but you could prepare data in the main program (e.g. write the values for all scan lines into arrays) and use the raster interrupt just to set them.
I read that Game Boy games quite often prepared all sprite registers in working RAM (using the same format) and then they just copied them to the real registers when needed. This may not be necessary in LowRes NX, but it's an interesting idea.
was8bit 2019-05-05 13:14
Cool tech info, thanks :D
dredds 2019-05-05 15:04 (Edited)
Re preparing sprite state in RAM & then copying to device registers — that’s what I’ve started doing in my new programs (Bouncer, and a sequel to Interceptor 2000). I’m hoping I can use this to have more than 64 sprites, with a max of 64 per scanline. It also means I can sort them to create the right display order before each frame so I don’t have to keep track of which sprites need to be given high or low numbers when creating new sprites.
was8bit 2019-05-05 15:05
I'm thinking sprites are not part of the scan line....
Timo 2019-05-05 15:24
yes they are, this is how this demo here works.
Roy___ 2019-05-05 16:59
Hi Timo, thanks for the info! Yes, that is what I was thinking. Precalculating data will help as you say, so will look at giving that a go!
was8bit 2019-05-06 05:34
Ahhh... will have to look deeper :)
was8bit 2019-05-06 07:24
Can I post a remix of this? I’ll be sure to post it with credit to you as the original author...
Roy___ 2019-05-06 07:43
Yeah, of course!
was8bit 2019-05-06 08:11
Yea! Thanks :)
Toddl 2019-05-06 19:33