@pik33 said:
A video driver I use in my stuff (Basic iterpreter, player) works like this:
in line #x:
- preload line #x+2 from the PSRAM to the hub ram cache. The cache keeps 4 lines.
- draw sprites on line #x+1
- stream the current line #x to the video output
I don't do the pixel doubling in the current version of the driver but having the line in the hub should make it easy - I have older versions of my drivers that have no sprites, but can multiply pixels vertically and horizontally (x1,2,4,8)
The main issue I have with extending the scan line buffering to three scan lines from two is that I still want to be able to swap regions at any time in the frame. This requires keeping more state in the "pipeline" for the different stages. If it was just a single region for the entire frame, doing this is a lot easier. That being said if I can free a bit more COG space sometime I may be able to look into supporting pixel doubling of extended memory sourced regions. I think it should be more straightforward by just halving the streamer rate for any pixel doubled regions sent via the analog outputs, the main issue is for the DVI/HDMI output which needs the three scan line buffer approach and more complex region handling when deciding what to do. Given enough COG RAM it is doable.
@pik33 said:
A video driver I use in my stuff (Basic iterpreter, player) works like this:
in line #x:
- preload line #x+2 from the PSRAM to the hub ram cache. The cache keeps 4 lines.
- draw sprites on line #x+1
- stream the current line #x to the video output
I don't do the pixel doubling in the current version of the driver but having the line in the hub should make it easy - I have older versions of my drivers that have no sprites, but can multiply pixels vertically and horizontally (x1,2,4,8)
The main issue I have with extending the scan line buffering to three scan lines from two is that I still want to be able to swap regions at any time in the frame. This requires keeping more state in the "pipeline" for the different stages. If it was just a single region for the entire frame, doing this is a lot easier. That being said if I can free a bit more COG space sometime I may be able to look into supporting pixel doubling of extended memory sourced regions. I think it should be more straightforward by just halving the streamer rate for any pixel doubled regions sent via the analog outputs, the main issue is for the DVI/HDMI output which needs the three scan line buffer approach and more complex region handling when deciding what to do. Given enough COG RAM it is doable.
I use your PSRAM driver to access the PSRAM: it has the PSRAM access list. While I don't use the list now (and because of it, the feature is not debugged) my driver has an option "display a line from the PSRAM access list". I have also a display list that can select the line display address for every line (or select the PSRAM list mode instead). This makes vertical pixel doubling (and muliitplying by anything) easy, just prepare a proper display list. The scroll text at the bottom of my player scren is done that way. A region, 16 lines high and wide enough to fit 2 copies of the scroller (several thousands of pixels) is prepared in the PSRAM, then the text is rendered on it, then, at every vblank, only display list entries are modified to point the driver to the next pixel in the scroll area.
Yeah I do quite like the idea of determining the scan line contents from a PSRAM request list sequence, as it allows for some interesting indirection and dynamic effects. I remember you did that a while back and it could be useful for some sort of GUI window rendering. If I get to modify the pipeline I'll probably try to look into adding some similar or equivalent feature to my video driver.
THAT is STUNNING! is that on your P2-Retromachine? how can I do that? I wanna draw multicolor text at any position and lines, fast like that. This is a long thread, and I've lost track of what made that video.
THAT is STUNNING! is that on your P2-Retromachine? how can I do that? I wanna draw multicolor text at any position and lines, fast like that. This is a long thread, and I've lost track of what made that video.
This is an output from P2-EC32 using my video driver. Yes, these drivers are in the repositories I am linking at the bottom of my posts. I have to clean the chaos in these repositories...
There are 2 versions of the driver, one can do pixel multiplying so you can use low resolution and character based graphic modes, still signalling 1024x576 (or 600) on HDMI. The second one (the newer) has 16 sprites, but cannot cannot multiply pixels, I ran out of the cog ram
The most debugged versions are these used in the media player and Basic interpreter. They contains graphic primitive drawing functions (lines, circles, rectangles, characters) so you can copy them from there. There are 2 versions of character output: slow, calling putpixel, and fast, optimized in asm, but restricted (the character x position has to be divisible by 4).
Comments
The main issue I have with extending the scan line buffering to three scan lines from two is that I still want to be able to swap regions at any time in the frame. This requires keeping more state in the "pipeline" for the different stages. If it was just a single region for the entire frame, doing this is a lot easier. That being said if I can free a bit more COG space sometime I may be able to look into supporting pixel doubling of extended memory sourced regions. I think it should be more straightforward by just halving the streamer rate for any pixel doubled regions sent via the analog outputs, the main issue is for the DVI/HDMI output which needs the three scan line buffer approach and more complex region handling when deciding what to do. Given enough COG RAM it is doable.
I use your PSRAM driver to access the PSRAM: it has the PSRAM access list. While I don't use the list now (and because of it, the feature is not debugged) my driver has an option "display a line from the PSRAM access list". I have also a display list that can select the line display address for every line (or select the PSRAM list mode instead). This makes vertical pixel doubling (and muliitplying by anything) easy, just prepare a proper display list. The scroll text at the bottom of my player scren is done that way. A region, 16 lines high and wide enough to fit 2 copies of the scroller (several thousands of pixels) is prepared in the PSRAM, then the text is rendered on it, then, at every vblank, only display list entries are modified to point the driver to the next pixel in the scroll area.
PS: This experiment:
That's PSRAM list in action.
Yeah I do quite like the idea of determining the scan line contents from a PSRAM request list sequence, as it allows for some interesting indirection and dynamic effects. I remember you did that a while back and it could be useful for some sort of GUI window rendering. If I get to modify the pipeline I'll probably try to look into adding some similar or equivalent feature to my video driver.
THAT is STUNNING! is that on your P2-Retromachine? how can I do that? I wanna draw multicolor text at any position and lines, fast like that. This is a long thread, and I've lost track of what made that video.
This is an output from P2-EC32 using my video driver. Yes, these drivers are in the repositories I am linking at the bottom of my posts. I have to clean the chaos in these repositories...
There are 2 versions of the driver, one can do pixel multiplying so you can use low resolution and character based graphic modes, still signalling 1024x576 (or 600) on HDMI. The second one (the newer) has 16 sprites, but cannot cannot multiply pixels, I ran out of the cog ram
The most debugged versions are these used in the media player and Basic interpreter. They contains graphic primitive drawing functions (lines, circles, rectangles, characters) so you can copy them from there. There are 2 versions of character output: slow, calling putpixel, and fast, optimized in asm, but restricted (the character x position has to be divisible by 4).
https://gitlab.com/pik33/P2-retromachine/-/tree/main/Propeller/Videodriver_develop