@26 mins, the presenter yawning during the compile, fitting. As for topics. A suggestion would be a exposition of the Ports, and messaging. I don't recall from that time programs that worked together sharing the same data and going to sleep and being awakened by a change in a shared resource (memory). Wait() MsgPort(...1
I want to put together a game and video set using the ROM routines, including lots of little exec tasks. That's what the routines were for in the first place.
Love your excitement, but as a game developer who has had to deal with multithreading, UX, and audio priority a little, I'm not sure you're well in tune with the actual needs. Those priorities are more likely to get in the way than help. They're probably good enough for arbitrating between applications, but within a game you're most likely going to want something tailored to the purpose. Ideally, you reserve a specific number of channels and then deal with priority yourself. I also would definitely not use OS threads for most scheduling -- it can make sense to have a separate sound thread if that means you don't need to implement an ISR or callback, but beyond that I'm very skeptical. Multithreading is hard to design around, hard to debug, causes unpredictable latency problems, and generally is a tax on performance if you don't have multiple cores to parallelize over.
I have done this for the Amiga in the past, using the OS routines, and intend to do so again, in a video series. But I appreciate the condescending pat on the head. p.s. if you're going to try and push against what I've done, provide code. otherwise sod off.
There's a distinction to be made between the situation on Windows(which most gamedevs today are familiar with) and the Amiga, and why you'd land on one or the other set of best practices. On Windows, you are in an adversarial environment and have to do things through a hardware abstraction layer that talks to vendor device drivers. There's no method to access audio hardware registers because that's not something you abstract. The abstraction may change internally. And the abstraction falls over when the layers you don't control break. Therefore a Windows dev doing something complex and timing-dependent is inclined to be paranoid about what the operating system provides and attempt to grab whatever the lowest level of control is, then hold it statically until the program exits, because you don't know what sort of mystery meat is in between you and the hardware, so the next best thing you can do is to hoard all the system resources. The Amiga is a more holistic design - one vendor doing hardware and software together - and it's designed from a position of trusting the user software, which keeps it uncomplicated. There's no motive to be paranoid, and therefore it's reasonable to view Kickstart as a framework that you can use directly for the deep internals of your programs.
@@JH-pe3ro These libraries were originally designed to be used when the Amiga was to be a game console, and were designed by an interesting confluence of people: * Bob Pariseau came from Tandem, big iron. * Carl Sassenrath came from the big iron HP world, who wrote Exec. * As did Dale Luck, who wrote graphics.library. * RJ Mical and Sam Dicker came from Williams Electronics, and were part of Eugene Jarvis' Vid-Kidz team. They were all in VERY close quarters, right next to each other, for the better part of 18 months, assembling all this library code onto a SAGE IV with a set of terminals hanging off of it. (Exec actually had its first bring-up on an HP 64000 development system) As such, progress literally happened via (as the great Ron Milner once put it) "spatial devance" as print-outs would cross from one side of the room to the other. The result literally was a well thought out homogenous set of routines intended to be used together to make games, which, because there was just enough wiggle room in the design, was able to make the leap to being a computer when RJ Mical wrote Intuition, which leveraged the graphics, layer, and input libraries. It's a very rare thing when you have a set of people who are so comfortable, yet driven, and have such a will to work together, that you're able to produce something so well designed.
