Some features of the Amiga that are peculiar even today:
1. The mouse is a hardware sprite and its movement stays responsive and smooth even under heavy load and even when the OS freezes
2. A screen can be divided into multiple resolutions, e.g. you can have a half a screen in high res and half in low res and with double the amount of simultaneous colors (or even HAM mode)
3. It can genlock natively, i.e. match its screen refresh rate with an inbound video signal, making it popular with broadcasting studios up to the late Nineties
I'm sure they are 3d models and are rendered using the CPU. You can check by entering the secret Options Mode and selecting the Polygon Test, which will allow you to freely rotate your ship and the enemies, including the end of level bosses (except the final one). Screenshot: https://www.vizzed.com/vizzedboard/retro/user_screenshots/sa...
Fabien seems to be unaware of this, by the way.
This is also why the game play is so bland. The number of 3d objects and their complexity was severely constrained and did not allow for varied or more sophisticated game elements.
I think there is realtime 3D used for the player and enemy "sprites" (really 3D objects), including the end of stage bosses. They are small and extremely simple, as this was the maximum the Genesis/Megadrive's 68k CPU could handle. The final boss fight is the exception.
Silpheed was amazing back in the day. It was one of the first titles that really showcased what CD drives could add to games in terms of cinematic experience. The live orchestral music gave it an epic feel and the mecha-design of the SA-77 is beautiful and modern even by today's standards.
> think I could come up with a python example that maps 1:1
My take on it:
class Stuff:
def __init__(self):
self._list = [1, 2, 3, 4]
@property
def each(self):
for el in self._list:
yield el
for item in Stuff().each:
print(item)
It's even less verbose than the Ruby equivalent in the original article, thanks to the indentation-defined blocks.
I agree with your preference. I too lean towards a pragmatic approach to REST, which I've seen referred to as "RESTful", as in the popular book "RESTful Web APIs" by Richardson.
> Easily discoverable data, e.g. user ID 3 would be at /users/3. All of the CRUD (Create Read Update Delete) operations below can be applied to this path
Strictly speaking, that's not what REST considers "easily discoverable data". That endpoint would need to have been discovered by navigating the resource tree, starting from the root resource.
Roy Fielding (author of the original REST dissertation): "A REST API must not define fixed resource names or hierarchies (an obvious coupling of client and server). (...) Instead, allow servers to instruct clients on how to construct appropriate URIs, such as is done in HTML forms and URI templates, by defining those instructions within media types and link relations. [Failure here implies that clients are assuming a resource structure due to out-of band information, such as a domain-specific standard, which is the data-oriented equivalent to RPC’s functional coupling].
A REST API should be entered with no prior knowledge beyond the initial URI (bookmark) and set of standardized media types that are appropriate for the intended audience (i.e., expected to be understood by any client that might use the API). "[1]
Do you have an impacted wisdom tooth? Consider getting it extracted, even if it doesn't appear to be causing any problems. It can be the root cause of chronic migraines.
Write your app in pure Python. Deploy on desktops and mobile devices.
The main disadvantage is that it does not use the native widget toolkit, although there are projects like KivyMD that attempt to replicate the native look and feel by theming the UI.
I made a email dispatcher for web forms hosted on shared hosting providers, like Namecheap. I originally did it for a site my wife did, and then decided to open source it. It's here: https://github.com/zedr/simple-mailer
