2:48 That cube deforming could be coded in various ways specific to amiga CPU accelerators, and an example is the 68040 without a patched maths libary (so that it cannot do transcendental operatoins without penalty). So an operation defined as a polynomial is something such a FPU (unpatched maths library 68040) could still do well. For 68040 CPU upgrades which do not have the maths library patched for the FPU, they can still do polynomial functions very well, even though transcendental functions (basically Pi stuff that cannot be defined as a polynomial). So here is an example of 3D model mathematics which use polynomial splines so as to be more computationally efficient. For example, the deforming of a crashed car in a small GTA style game could use it (or even fluid motions in materials).It makes the 040 an interesting upgrade (or even just a4000) for homebrew and demoscene. Pre-Calc can be used before handing over to the akiko or the copper can be done to have a 3D object deformed (where f(x) is the spline) such as a balloon with a colliding paricle warping its shape or similar changing its light (as if a colour changes on it, such as with colour cycling). Done right, coding need not leave homebrew games copper choked or blitter choked, or even akiko choked. The akiko is always worth having. On a PC but could be done (cut down) on a motorola: th-cam.com/video/7o3g-rG1qYg/w-d-xo.html See? Cool, huh?
I'm just seeing this for the first time. Really excellent work. The bit that blows me away is the nine bobs whizzing around at 6:10. Incredibly fast and smooth! However, I don't quite understand your explanation of the technique used to achieve this. Is the blitter drawing some of the bobs and the CPU drawing the rest of them? Are hardware sprites involved? Am I right in saying there are 5 bitplanes on that screen?
Nice demo for sure! Just thought about something I don't think I have seen on the Amiga really... maybe I have though but not realized it. My first Amiga was a Amiga 500+ with the ECS chipset. So it had a 12 Bit color palette and it was back then really nice. But around the same time on the C64 "FLI" could technically display lots of colors for the C64 (well at least double or triple what the C64 could normally display using it's fixed 15 color palette. I know HAM mode for the OCS/ECS was pretty good ofc and maybe that is why it never was pursued to do a "FLI" technique for static images on the OCS/ECS? or has it been done? On AGA it would just be a waste of time ofc, but on OCS/ECS it would have been cool to see 320*256 with at least 255 colors :-) on static images as I think it would not be impossible at all.
The tricks on the c64 were needed due to its low palette count which is why the vic hacks were so impressive. FLI - more color to the screen by Pasi 'Albert' Ojala (po87553@cs.tut.fi or albert@cc.tut.fi) (All timings are in PAL, altho the principles will apply to NTSC too) All of us have heard complaints about the color constraints on C64. One 8x8 pixel character position may only carry four different colors. FLI picture can have all of the 16 colors in one char position. What then is this FLI and how it is done ? In the normal multicolor mode can one character position (4x8 pixels) have only four different colors and one of them is the common background color. Color codes are stored in half bytes (nybbles) to the video matrix memory (anywhere video matrix pointer points at, normally $0400) and to the color memory ($D800-$DBFF). In multicolor mode the color of each pixel is determined by two bits in the graphics memory. Bit pair 11 will refer to color memory, background color is the color for bit pair 00, and video matrix will define the colors for bit pairs 01 and 10. The Amiga on the other hand had the feature of ECS with 32/64 colours and HAM mode too, even HAM video was possible if you had the disk space. Of course hacks were used on the Amiga too especially in demos and games but that would be a long story... :)
@@mjnurney I think they where a lot of different "FLI" techniques with the C64 (some of them in hires interlaced also). I had to google it a bit after I made the comment to see if I can find anything more about it. Using only copper you could have 32 (or 64/EHB) different colors per scanline and if I think about it that was ofc done as well in Workbench with the screen dragging feature (which I miss even today). But you still had a limited 12 bit palette on OCS/ECS (but again with EHB it would be sort of 14-15 bit palette I guess). Then there is ofc the normal screens with copper effects and if you freeze frame it and count the colors it could be more then 255 colors on screen. But I just thought about static images... and both bigger palette and more colors on screen for a OCS/ECS Amiga. I did not look at JPEG's much on my Amiga 500 but I guess if I had written a display program for it I would rendered it in HAM mode. And on AGA it was ofc always in HAM8 mode. Maybe the Amiga (even OCS/ECS) was just to good for it to make an effort :-) and as you say C64 was just begging for more colors so someone just had to try to make it happen :-)
![TEK - Transhuman/Pachinkoland [Amiga 500]](http://i.ytimg.com/vi/lJyir-XEDwg/mqdefault.jpg)
![TEK - Transhuman/Pachinkoland [Amiga 500]](/img/tr.png)
2:48 That cube deforming could be coded in various ways specific to amiga CPU accelerators, and an example is the 68040 without a patched maths libary (so that it cannot do transcendental operatoins without penalty). So an operation defined as a polynomial is something such a FPU (unpatched maths library 68040) could still do well.
For 68040 CPU upgrades which do not have the maths library patched for the FPU, they can still do polynomial functions very well, even though transcendental functions (basically Pi stuff that cannot be defined as a polynomial). So here is an example of 3D model mathematics which use polynomial splines so as to be more computationally efficient. For example, the deforming of a crashed car in a small GTA style game could use it (or even fluid motions in materials).It makes the 040 an interesting upgrade (or even just a4000) for homebrew and demoscene. Pre-Calc can be used before handing over to the akiko or the copper can be done to have a 3D object deformed (where f(x) is the spline) such as a balloon with a colliding paricle warping its shape or similar changing its light (as if a colour changes on it, such as with colour cycling). Done right, coding need not leave homebrew games copper choked or blitter choked, or even akiko choked. The akiko is always worth having.
On a PC but could be done (cut down) on a motorola:
th-cam.com/video/7o3g-rG1qYg/w-d-xo.html
See? Cool, huh?
This is insane!
Amiga demos are getting so much better!
Are there any homebrew games that push the system to its limits? What about one that looks better than the official games?
Great optimization and captivating sound!
Awesome video
Tanta roba, BELLO!!!! 😎👍🏻
Excellent!!!
Amazing aren’t they ! 2019 is a good Amiga demo year
I'm just seeing this for the first time. Really excellent work. The bit that blows me away is the nine bobs whizzing around at 6:10. Incredibly fast and smooth! However, I don't quite understand your explanation of the technique used to achieve this. Is the blitter drawing some of the bobs and the CPU drawing the rest of them? Are hardware sprites involved? Am I right in saying there are 5 bitplanes on that screen?
Cracking art. Nice.
My dad made this lmao
Nice demo for sure!
Just thought about something I don't think I have seen on the Amiga really... maybe I have though but not realized it.
My first Amiga was a Amiga 500+ with the ECS chipset. So it had a 12 Bit color palette and it was back then really nice. But around the same time on the C64 "FLI" could technically display lots of colors for the C64 (well at least double or triple what the C64 could normally display using it's fixed 15 color palette.
I know HAM mode for the OCS/ECS was pretty good ofc and maybe that is why it never was pursued to do a "FLI" technique for static images on the OCS/ECS? or has it been done?
On AGA it would just be a waste of time ofc, but on OCS/ECS it would have been cool to see 320*256 with at least 255 colors :-) on static images as I think it would not be impossible at all.
The tricks on the c64 were needed due to its low palette count which is why the vic hacks were so impressive. FLI - more color to the screen by Pasi 'Albert' Ojala (po87553@cs.tut.fi or albert@cc.tut.fi)
(All timings are in PAL, altho the principles will apply to NTSC too)
All of us have heard complaints about the color constraints on C64. One 8x8
pixel character position may only carry four different colors. FLI picture
can have all of the 16 colors in one char position. What then is this FLI
and how it is done ?
In the normal multicolor mode can one character position (4x8 pixels) have
only four different colors and one of them is the common background color.
Color codes are stored in half bytes (nybbles) to the video matrix memory
(anywhere video matrix pointer points at, normally $0400) and to the color
memory ($D800-$DBFF). In multicolor mode the color of each pixel is
determined by two bits in the graphics memory. Bit pair 11 will refer to
color memory, background color is the color for bit pair 00, and video
matrix will define the colors for bit pairs 01 and 10. The Amiga on the other hand had the feature of ECS with 32/64 colours and HAM mode too, even HAM video was possible if you had the disk space. Of course hacks were used on the Amiga too especially in demos and games but that would be a long story... :)
@@mjnurney I think they where a lot of different "FLI" techniques with the C64 (some of them in hires interlaced also). I had to google it a bit after I made the comment to see if I can find anything more about it. Using only copper you could have 32 (or 64/EHB) different colors per scanline and if I think about it that was ofc done as well in Workbench with the screen dragging feature (which I miss even today). But you still had a limited 12 bit palette on OCS/ECS (but again with EHB it would be sort of 14-15 bit palette I guess).
Then there is ofc the normal screens with copper effects and if you freeze frame it and count the colors it could be more then 255 colors on screen. But I just thought about static images... and both bigger palette and more colors on screen for a OCS/ECS Amiga.
I did not look at JPEG's much on my Amiga 500 but I guess if I had written a display program for it I would rendered it in HAM mode. And on AGA it was ofc always in HAM8 mode.
Maybe the Amiga (even OCS/ECS) was just to good for it to make an effort :-) and as you say C64 was just begging for more colors so someone just had to try to make it happen :-)
Nice! What does the QR code at approx. 6.36 do? My QR code reader can’t read it.
I’m not sure it’s too faint to scan , I’ll have another go tomorrow
Mikes Retro Tech Let me know please, I’m very curious.
Wholegrain!
3:20 ITS HIM.
THIS IS ORIGIN OF SCP 087-1
Should have won imo.
good music
1:45 nice graphics but a bit jerky, like compiled C.
Not bad for an atari.
nice demo