PTDS (formerly PED81C) - pseudo-native, no C2P chunky screens for AGA

PTDS (Pixel Tetrads Dots / Speed) is a video system for AGA Amigas that provides pseudo-native chunky screens, i.e. screens where each byte in CHIP RAM corresponds to a dot on the display - in other words, it offers chunky screens without chunky-to-planar conversion.

Download: https://www.retream.com/PTDS

Some examples:
* https://www.youtube.com/watch?v=0xunQ6ldVKU
* https://www.youtube.com/watch?v=4eikEo45v1I
* https://www.youtube.com/watch?v=eVzTIyg_MeE
* https://www.youtube.com/watch?v=ebxwKm9K4Os
* https://www.youtube.com/watch?v=tLtLhJXInOY
(Due to technical limitations, the video quality is lower than the actual one.)

For the details, please refer to the documentation included in the archive.

Clever... is it sort of like subpixel font rendering to achieve the effect?

@NinjaCyborg

I don't know how that works, so I can't answer. The best, most complete and shortest explanation I can give is the one in the CORE IDEA section of the documentation.

@NinjaCyborg

Quote:No. Visual results might be similar, but it's something completely different.
For subpixel font rendering you basically just quadruple or sixteenfold the resolution a B/W font is rendered to, then you scale the result down to the original resolution again but using grey scale colours (or matching alpha masks) instead of just B/W for the 2x2 or 4x4 pixels groups which have 1/4, 1/2, 3/4, or in case of sixteenfold rendering additionally 1/16, 2/16 ... 14/16, 15/16, black pixels.

@joerg no that's not sub pixel rendering that's what apple uses for retina display and such. sub pixel rendering anti aliases by splitting each full pixel into separate r g and b pixels and then setting boundary pixels to swatches that will blur the line between the white and the black.

@saimo

this is screaming for a kick arse horizontal shooter !

@328gts

I guess you've been influenced by the video examples, but "native" chunky would be better used for other things (although, I did try to imagine if an interesting horizontal shooter could be done). To be honest, I feared I'd get a flock of Doom-like game requests/proposals :D


@all

Improved/corrected documentation.

Uploaded an archive with updated documentation.
While at it, given that I was asked for a source code example, I whipped up an AMOS Professional program that shows how to set up a PTDS screen and to perform some basic operations on it - hopefully, this will be easy to understand and also open the door to AMOS programmers. The program source is included in the archive.

Really impressive.
Should be a definitive + to Amos Professional as an extension

@AmiDARK
Quote:
Thanks!

Quote:
I wrote the example in AMOS to make it easier to understand by more people, but the system isn't intended for any specific language.
I decided to let programmers implement PTDS in the way that fits best their projects and in their language of choice, given that setting up PTDS screens is easy and given that general-purpose routines would perform worse than tailor-made ones.

@Saime :
I did never said that it should be "Amos Only" system ;)
But simply that it may be interesting to add support for it using extension format. The support should handle screen setup. User will create his/her own custom methods for required effects.

I must admit that I read doc and didn't understand how it works but I'll do another check and if I find time, I will maybe look to see if I can do something interesting with it using extension format.

EDIT :
From doc I read this :
RGBW
does this mean it is a 32 bit value ? Because after you talk about $ww using $wwwwww ..
I don't understand.
Ew... I think I understand you talk about RGB value for the ColorXX register used for the 4th pixel ? Same for others pixels. Right ?

@AmiDARK
Quote:
Key concepts:
* each dot is 8 bit;
* each dot is made of 4 SHRES pixels;
* each SHRES pixel is 2 bit (i.e. it can be assigned 4 different RGB values);
* the RGB values assigned to the SHRES pixels are 24 bit and can be chosen freely.

$wwwwww is a placeholder for any 24 bit value assigned to the W(hite) SHRES pixels in the RGBW mode (e.g. $333333 or $eeeeee).

I hope this helps.

I have just released a little update, accompanied by the PTDS Voxel Engine (PVE), i.e. a new demo. If you can't be bothered trying it yourself, you can see it in this video - but beware: YouTube's video compression degraded the visual quality (especially the colors saturation and brightness).



About the update, I fixed some palette values in a table in the documentation, added the formulas for calculating DIWSTRT, DIWSTOP, DIWHIGH, DDFSTRT and DDFSTOP to the documentation and implemented them in the AMOS Professional source code example. This is the snippet relative to the register settings:

Just released a new version of PVE. Full changelog below. In short: it's faster and it's got a few little additions.

https://retream.itch.io/ptds

v1.1 (22.12.2023)
* Reworked screen buffering, so that the raster data is more efficiently written to CHIP RAM when bitplanes DMA is inactive.
* Improved 68030 caches handling.
* Added 68040 and 68060 caches handling.
* Added MMU handling to avoid that the MMU affects the speed negatively.
* Optimized rendering core by making it write the dots sequentially.
* Made a little 68060-specific code optimization.
* Ensured 68060 susperscalar dispatch is enabled.
* Added live-toggable staggered lines video filter, which helps see better colors on devices that do not support SHRES and reduces the jailbars effect on devices that support SHRES (to enable/disable: [F1]).
* Made fps indicator live-togglable (to enable/disable: [F2]).
* Made quitting from the voxel screen return to the splash screen.
* Replaced mouse controls with keyboard controls.
* Added benchmark function.
* Added command line switches to control the CPU caches.
* Fixed bug that caused a longword to be written to a random location when the fps indicator was on.
* Fixed an innocuous initialization bug.
* Made cleanup code more robust.
* Updated, extended and fixed documentation.

It was ages that I intended to dig up some 20+ years old code and use it to play with PTDS a little more. Finally I got around to do it and came up with a new test program called Zoomaniac.
Details in the video and in the manual excerpt below. Download available at https://retream.itch.io/ptds.



CHANGELOG

March 27, 2024
* Added the Zoomaniac demo.
* [PTDS Voxel Engine] Made a couple of minor changes.
* [PTDS Voxel Engine] Updated documentation.

January 1, 2024
* Rebuilt demos against latest custom framework.
* [PTDS Voxel Engine] Optimized slightly background rendering.
* [PTDS Voxel Engine] Corrected benchmark fps calculation (312 rasterlines were considered instead of 313).
* [PTDS Voxel Engine] Built against latest custom framework.
* [PTDS Voxel Engine] Updated, extended and fixed documentation.

In response to the feedback received, I have uploaded a new version of Zoomaniac that allows to enable/disable the fps limit by means of [F3].



Also, this new version runs 1-2 fps faster on 68030 thanks to the data cache burst:



CHANGELOG

v1.1 (28.3.2024)
* Turned the 68030 data cache burst on for slightly faster performance.
* Made a couple of minor optimizations.
* Added frames rendering limit toggle ([F3]).
* Worked on fps indicator: added hundreds digit; made digits smaller; made digits auto-clearing, so that they read correctly also when they are not cleared before drawing.
* Made staggered lines toggle as soon as [F1] is pressed (instead of when it is released).
* Updated splash screen.
* Redesigned the 'M' in the logo.
* Updated and extended manual.

To have a complete set of scaling routines (which hopefully I'll use for something someday), I added support for color-keying, zero-keying (color-keying with color 0), and horizontal and vertical flipping.
Morever, given that initially the focus was on the stock A1200, the performance on expanded machines was not optimal (as the rendering was done directly in CHIP RAM), so I added also an alternative buffering method that, when 2 rasters can be allocated in FAST RAM, allows rendering in FAST RAM and then copies the rendered raster to the raster in CHIP RAM as quickly as possible, starting when the beam reaches the bottom of the screen. This, relatively to the first effect in the test program (which is the only one whose performance was measured until now), produced a gain of 8-9 fps on my 68030-equipped Amiga 1200.

The updated test program (available at https://retream.itch.io/ptds), to demostrate the new features, streches and shrinks a color/zero-keyed texture covering almost the entire screen over a full-screen zooming background, with all the possible flipping combinations. That is of course a bit taxing for a stock A1200, whose performance drops between 12 and 16 fps in the busiest cases.



(Side note: the video was recorded before finalizing the test program, so it shows an outdated splash screen and zooming jumps relatively to the background when passing from/to the color/zero-keying effects.)

By chance I discovered that Zoomaniac might crash on my real A1200. After some investigation it turned out that it was due to a stack issue that happened when the execution dropped below 50 fps on 68020, 68030 and 68040 (an instruction was executed before instead of after a branch). That's fixed now.
While searching for the problem, I realized a way to make the solid scaling routine a bit faster - so the bug, although finding it required some effort, was actually a good thing!

The new download is available on the PTDS page: https://www.retream.com/PTDS

Wow, this is pretty cool, I hadn't seen this before. Very neat.

@cloverskull

Thanks!


@all

More experimenting with PTDS. This is a proof of concept. It is just the core of a graphics engine for various vague game ideas (that are not going to materialize). It was useful to evaluate the visual quality and the speed (around 20 fps on a stock Amiga 1200, constantly much above 50 fps on an Amiga 1200 with Blizzard 1230 IV, 68030 @ 50 MHz and 60 ns RAM).



https://www.retream.com/PTDS

Notes:
* the video quality is affected by the fact that: the scandoubler did not support SHRES (so a real-time software trick was used to somehow produce the colors, although it is only a visual illusion and causes a sort of rasterline effect); the monitor did not support progressive PAL; the video was shot with an ancient phone at just 24.917 Hz; YouTube's compression degraded the video quality further;
* graphics are just placeholders;
* the city skyline has been derived from the picture at https://www.pinterest.com/pin/some-oth ... line--327988785356024774/