As far as I heard, the memory architecture of the TI-99/4A is really inefficient (something about all memory access being indirect, like how you would access VRAM on MSX), so the CPU is not able to reach its potential and it comparatively slower than a Z80 on MSX.
Plus there is another factor. AFAIK Z80 is more register-oriented than TI/99 Cpu which was more memory oriented.
temporary operations could benefit of storing data in registers
I think they both have advantages that can be fairly balanced against each other.
And another demo example on TI-99/4A with TMS9918 VDP you can find here
The Demo you suggested gave me a lot of ideas. I think I know how to do most of these effects but if never understood how demo's do this zoom and rotate so quickly like in this video at 1:38 - 2:01. C64 demo's use this a lot too. It's a bit blocky but still impressive.
Anybody know how to do the calculations AND the output to VDP so fast?
rotozoom effects are actually much simpler than they seem. Specially if you do not need to check if you reached the border of a triangle/polygon when drawing!
The idea is very simple:
- you store your pixel data in a matrix in memory (let's call this the "reference texture")
- you precalculate the "offset" that you need to move in the reference texture in X and Y, when you move one pixel "to the right" in video memory. Notice that this will be a constant amount, as it's just a vector for a fixed angle and zoom factor.
- To draw you keep a pointer P to the reference texture (initialize it to the top-left)
(a) - access the color in P and draw it to video memory
(b) - add the offset in X and Y to P, and move one pixel to the right in video memory
- repeat (a) and (b) until you have drawn a whole row of pixels.
- you have a similar outer loop for Y
So, it's just basically "adding an offset, reading color, and sending to VDP". The one complication in MSX is that each byte in the video memory is not just one single pixel. So, you need to accumulate a a few pixels before you send to the VDP, but that's basically it.
If you are rendering a texture to a triangle or polygon that is not a square, then it's a bit trickier, but rendering to a rectangle is just the above!
@santiontanon Of course! Pretty simple! I was just thinking way too complicated. Thanx for your detailed explanation!
But I wonder how much FPS do you need before it gets jerky?
I think I know how to do most of these effects but if never understood how demo's do this zoom and rotate so quickly like in this video at 1:38 - 2:01. C64 demo's use this a lot too. It's a bit blocky but still impressive.
Anybody know how to do the calculations AND the output to VDP so fast?
https://www.msxcomputermagazine.nl/mccw/93/rotator/en.html
It builds up the possible ways of going about it, up to the fastest way to implement this (like demonstrated here in screen 3 )
There is even a basic implementation on that page (ROT3.ASC) that gives you a good idea how it is done
So is anyone currently working on an MSX demo or part of a group who is?
They've gone out of fashion, a bit. In the early 90's everyone did 'm. Then music disks were hot. Then everyone started making disk magazines. Then people started making games. Then the silent years happened. Then internet became a thing, and whatever occasional demos from this scene would often be part of an MRC-challenge. Then game-development took over again, I think we're still in that particular phase.
Many of the old scene were from the scroll & logo era, and due to influences from other systems (e.g. C64), it seems those demos appear to be a bit dated now. Yet, not everyone is able to go beyond that, artistically. Hence, the demos have grinded to a halt, I think.
Well on Pouët.net I see about 3-4 demo's for MSX a year and most are of low quality.
If I look for C64 I see about 10-14 a month... and a lot are of high quality
So why the difference?
The VDP. In bitmap-mode It doesn't lend itself to non-block based screen actions very much (too slow). Tile mode is fast, but not always easy on graphics/detail. For demos, you typically want to be able to update the whole screen each time unit (e.g. every two interrupts, for 25 fps).
Most MSX-coders have dealt with demo effects based on hardware scrolling and palette changes, combined with screen splits 'n such. Compared to demos on other systems, that's fairly easy. Also: milking the effects to death. Like, at some point there were these effects with large color gradients moving vertically. Behind a logo, in a logo, in a scroll, behind a scroll etc. Each time packed as a new demo but basically the same effect. Then there was vertically stretching... a logo, a scrolltext, later on these things were stretched onto tubes, or multiple tubes were stacked on top of each other. In the end it's the same effect, packed as a new demo every time. But if this is what you know, this is what you do. If you are living in a tribal culture, living in a place surrounded by bamboo, it's likely that your only musical instruments are bamboo flutes and percussion. I can envision an MSX-coder in the 90's eyeballing demos on other systems like "whoa, what's this?" in the same way that tribal clan would react when they see and hear a grand piano for the first time in their lives.
And secondly, as I pointed out earlier, I think our scene has different interests. Some would rather make games instead, the rest takes a bit of a backseat position.