Page 2 of 2

Re: Parallax Distorter 2

Posted: Thu Sep 20, 2018 8:48 am
by lotek_style
Simply because we have no extra platform for STE... we have to tag it that way on Demozoo.

Re: Parallax Distorter 2

Posted: Thu Sep 20, 2018 10:00 am
by troed
(yeah if that had been plain ST I would've given up demo coding ;))

Re: Parallax Distorter 2

Posted: Tue Aug 20, 2019 10:23 am
by slingshot
Exuse me, but may I ask on what hw/emulator this screenshot made?

https://media.demozoo.org/screens/o/80/ ... 169612.png

It has black lines on the right side in every 16(?)pixels.

Re: Parallax Distorter 2

Posted: Tue Aug 20, 2019 12:05 pm
by sigge
slingshot wrote:Exuse me, but may I ask on what hw/emulator this screenshot made?

https://media.demozoo.org/screens/o/80/ ... 169612.png

It has black lines on the right side in every 16(?)pixels.


Not sure about which emulator, but I think this is from an older version of the code. I had a couple of issues that I discussed earlier in the thread. If I remember correctly, one was with regards to "resetting the buffer" (screen address) at a bad place, and another where the screen start address was set incorrectly at the top of the screen. The reset of the buffer address only touched the middle byte of the screen address, so the offset in the low byte was preserved. The black lines are caused by displaying the end of the buffer, which was never filled with any font data (or even background playfield data).

I think the version on github has these issues fixed.

Re: Parallax Distorter 2

Posted: Tue Aug 20, 2019 2:39 pm
by slingshot
sigge wrote:
Not sure about which emulator, but I think this is from an older version of the code. I had a couple of issues that I discussed earlier in the thread. If I remember correctly, one was with regards to "resetting the buffer" (screen address) at a bad place, and another where the screen start address was set incorrectly at the top of the screen. The reset of the buffer address only touched the middle byte of the screen address, so the offset in the low byte was preserved. The black lines are caused by displaying the end of the buffer, which was never filled with any font data (or even background playfield data).

I think the version on github has these issues fixed.


Secretly hoped that happens on the real HW, since the STe shifter code I wrote also displays similar black lines, however if it's due to bad video address, then it's not the shifter, but the GLUE/MMU.
But if it's a bad video address at the end of the line, how it's possible that it has the correct pixel data before the black spike? Or just look like it's correct, but not.

Upd.: seems the demozoo version is an older one, which works in Hatari, but not on real HW. I've downloaded from your github repo, it's perfect!