The Amiga had a hardware blitter that was very good at drawing lines and doing area fills, so it made perfect sense to encode video to polygons on that particular hardware.

Yep! That's what I meant in an obtuse way about the hammers and nails :D

Well, I would argue that a 'conventional' video codec would not work nearly as well on a stock Amiga 500 as this polygon approach does. The closest thing to full-motion video on the platform was probably what they used on the CDTV (same hardware as an Amiga 500, but with CD-ROM). It used the CDXL format: https://en.wikipedia.org/wiki/CDXL.

In short, you got 160x100 video at 12 fps. It was uncompressed data, because the system was too slow to decompress in realtime. So the Amiga really wasn't powerful enough for 'conventional' codecs to begin with. Especially 9 Fingers gets pretty detailed video at the full resolution and certainly more than 12 fps. And the whole thing fits on just two floppies, so the storage is quite efficient as well. Imagine what you could do with a CD-ROM.

The successor to the CDTV, the CD32, got a hardware MPEG decoder, despite having a much faster CPU and chipset than the original Amiga the CDTV was based on.

I had a CDTV and a CD32, but I never knew the details about CDXL format, thank you! I just checked and it looks like ffmpeg supports it, bless. It looks like the simplest possible video encoding format you could imagine.

Yes, the reason I was doing it like that on the PC was for the same reason you mention -- using polygons probably is faster because you cut out a lot of math and branches (as long as the polys are large enough) and just drop down to blitting huge swathes of solid color into the frame buffer.

On a PC it is different, because you need to render the polygons in software. On an Amiga you basically draw lines into each bitplane, and then do a single area fill at the end, all with the blitter. The area fill won't have to be stored, as this is done for each frame. Which means you only need to store the lines, and those can be stored directly as preprocessed register values for the blitter. So you can basically just stream the data directly from floppy and fire it off into the blitter.

But as I say, on early PCs you couldn't draw ANYTHING quickly into video memory. Which is also why for the 8088 MPH demo I developed a polygon renderer that calculated the differences with the previous frame, and then only drew that. This allowed a much higher framerate than clearing the stream and redrawing all polys. Similar to how the XDC encoder here encodes the differences.

On the Amiga the CPU isn't fast enough to draw entire screens either, but it has the chipset with the blitter, DMA transfers and whatnot to help it.

That is an interesting difference with the 8088+CGA platform by the way. The Amiga has no problem displaying entire screens of uncompressed data. CGA however is so bandwidth-limited that you simply can't update an entire screen at acceptable framerates, so the lossy compression that is used with XDC is a requirement to improve the framerate to FMV-like levels, it is not primarily required for data reduction on disk.

It was actually patented by Access Software, under the name of RealSound. https://en.wikipedia.org/wiki/RealSound

What a dumb patent. We were already doing this before their patent. We just ignored it and they didn't try to challenge. I remember talking to my EE father at the time and he said the idea of doing PWM for audio was obvious and ludicrous to patent.

Yes, thanks! Fixed the original text.

Yes, combined with streaming the data from disk in realtime, and playing the audio over the PC speaker in this case, bit-banged. Given the limited performance of both the HDD system and the CGA adapter, the most important thing the compiler has to do is to stay within the budget of HDD and CGA resources.

The video clock (I assume you mean pixel clock) isn't relevant. The synchronization of video and audio happens on a per-frame basis. And since the frames are clocked out on the audio-clock, there cannot be any drift.

Having said that, the CGA card does not actually have its own clock. It takes the NTSC base frequency of 14.31818 MHz from the OSC-pin of the ISA bus. On early PCs, such as the IBM 5150/5160, the CPU frequency is also derived from this same base clock (which is why you get the oddly specific speed of 4.77 MHz).

Yes, I posted a followup which investigates the issue somewhat further. It appears to be some bug with the message queue handling, specifically when the UI is in Aero mode. In classic mode, the problem is not there. In Windows XP, the problem is also not there. https://scalibq.wordpress.com/2012/03/28/the-story-of-micros...

Exactly. As I tried to explain, you NEED a context switch (which doesn't make it a spin-wait) in order to avoid the deadlock between your main loop and the processing of the Windows message queue (and as you see, I do check the quantum, via QueryPerformanceCounter()). The goal was to find a way that didn't deadlock the system, while also not wasting so much time that it impacts your framerate to the point where you can't even drive a high-refresh display at say 144 Hz.

Ofcourse I'm open to even better solutions, but so far this is the best solution I know of.

I doubt that events/semaphores would work better, as they'd be implemented as spinlocks for short periods of time, in which case they wouldn't actually trigger a context switch. Once you use a long enough time to get to a context switch, it's probably going to be worse than doing the context switch explicitly, the way I do here.

All in all, it's a bug in Windows Aero, as the followup blog expained (not sure if it was ever fixed in later versions of Windows, I haven't been working with multiple display adapters/screens in situations like these in recent years): https://scalibq.wordpress.com/2012/03/28/the-story-of-micros...

"Justify why people died" Lol, you sound as unhinged and radicalized as Jim. The point I was making was that all these people had a criminal record that showed they had a violent nature, and were likely there to cause trouble. But to understand that, you need to be not radicalized, and be able to think calmly, logically, and humanly.

Also, a conversation is more than just deflecting and ignoring things, it means engaging with a topic and exchanging arguments. Clearly Jim was not open to that. The way he was misrepresenting what I said at some point is nothing short of sick. Much like what you were doing just now.

Which is funny... from 56+ pages of conversation, you STILL have to twist and frame my words in an attempt to make me look bad. Lol.

>But to understand that, you need to be not radicalized, and be able to think calmly, logically, and humanly.

I guess I'll just have to defer to you about what I am.

Why don't you come hang out with me in Montana, we'll find unhinged people just by trying to have a discussion in public, and they won't be antifa.

The ATi Small Wonder is not entirely cycle-accurate. When I studied the CGADEMO by Codeblasters, I found that the scroller didn't look entirely correct, because the Small Wonder was slightly slower: https://scalibq.wordpress.com/2014/11/22/cgademo-by-codeblas... It appears to insert a few extra waitstates compared to an IBM card. This may trip up some effects in Area 5150.