If we truly want to point out the ridiculousness of Italian tech regulations, the influencers' registry, the temporary ChatGPT ban from a few years back or even the new AI regulations cannot hold a candle to the 22-year-old war on... arcade games.
A poorly written regulation from 2003 basically lumped together all gaming machines in a public setting with gambling, resulting in extremely onerous source code and server auditing requirements for any arcade cabinet connected to the internet (the law even goes as far as to specify that the code shall be delivered on CD-ROMs and compile on specific outdated Windows versions) as well as other certification burdens for new offline games and conversions of existing machines. Every Italian arcade has remained more or less frozen in time ever since, with the occasional addition of games modded to state on the title screen that they are a completely different cabinet (such as the infamous "Dance Dance Revolution NAOMI Universal") in an attempt to get around the certification requirements.
I guess they were inspired by a very similar law in Greece from 2002[0] where in an attempt to outlaw illegal gambling done in arcades a poorly written law outlawed all games (the article mentions it was in was in public places but IIRC the law was for both public and private and the government pinky promised that they'll only act on public places). I remember reading that some internet cafes were raided by the police too :-P.
Not the OP, but I tried it when it came out. VR headset technology wasn't good enough for screens within screens and it was nauseating more than anything.
There's also impedance mismatch between using the headset controllers and the physical ones in the game. Ideally, I should be able to use my own fightstick in an augmented reality configuration.
The quest 3 is good enough and the Galaxy XR is incredibly high resolution. But it isn't a really ideal way to play arcade ROMs for long term but just to enjoy the nostalgia.
I got it for $75 a month for two years. Visual clarity is incredible and monitor replacement level but comfort is meh so I bought studioform creative head strap which helped a lot. You can use Virtual Desktop to connect to any computer easily.
I'm a sysadmin so I bought it to see if it would work when I want to ssh into systems I'm physically near in racks. It has worked really well for this.
Custom Flash players were actually relatively common in game development during the mid to late 2000s, as Flash provided a ready-to-go authoring solution for UI and 2D animation that artists were already familiar with. Autodesk's Scaleform was probably the most popular implementation but a number of AAA developers had their own in-house libraries similar to Doom 3's; some of them, such as Konami's "AFP" [1], are still in use to this day (the latest game to use it, Sound Voltex Nabla, was released last month).
It is actually much worse than that. Much like banking, the push for digital government services in many countries has ended up more or less requiring every citizen to own an up-to-date, non-jailbroken iOS or Android device. If you blocked your phone from accessing Apple or Google servers (or if it's 6 years old, a dumb phone or runs GrapheneOS), the support staff will just tell you to walk to your closest Best Buy equivalent and grab the cheapest Android device you can find; in the name of "security" there often is no fallback option, and when there is one it's SMS 2FA which is (understandably) rate limited to three uses per year.
If your phone gets stolen, meanwhile, you may find yourself unable to log into the police's portal for reporting it.
It has been enabled mainly by the the advent of streamlined tooling to assist with 1:1 byte-by-byte matching decompilations (https://decomp.me/ comes to mind), which allows new projects to get off the ground right away without having to reinvent basic infrastructure for disassembling, recompiling and matching code against the original binary first. The growth of decompilation communities and the introduction of "porting layers" that mimic console SDK APIs but emulate the underlying hardware have also played a role, though porting decompiled code to a modern platform remains very far from trivial.
That said, there is an argument to be made against matching decompilations: while their nature guarantees that they will replicate the exact behavior of the original code, getting them to match often involves fighting the entropy of a 20-to-30-year-old proprietary toolchain, hacks of the "add an empty asm() block exactly here" variety and in some cases fuzzing or even decompiling the compiler itself to better understand how e.g. the linking order is determined. This can be a huge amount of effort that in many cases would be better spent further cleaning up, optimizing and/or documenting the code, particularly if the end goal is to port the game to other platforms.
The PS1's GPU does not support perspective correction at all; it doesn't even receive homogeneous 3D vertex coordinates, instead operating entirely in 2D screen space and leaving both 3D transformations and Z-sorting to the CPU [1]. While it is possible to perform perspective correct rendering in software, doing so in practice is extremely slow and the few games that pull it off are only able to do so by optimizing for a special case (see for instance the PS1 version of Doom rendering perspective correct walls by abusing polygons as "textured lines" [2]).
A little more than just a multiplication instruction (the 68000, used in, say, the Sega Mega Drive, had one of those too). Have a look at https://www.copetti.org/writings/consoles/playstation/, and in particular, read about the GTE - it offered quite a bit of hardware support for 3D math.
Also, even though it didn't handle truly 3D transformations, the rasterizer was built for pumping out texture mapped, Gouraud shaded triangles at an impressive clip for the time. That's not nothing for 3D, compared to an unaccelerated frame buffer or the sprite/tile approach of consoles past.
It's not just a multiplication instruction. The CPU is equipped with a fixed-point coprocessor to accelerate the most common computations in 3D games, the geometry transformation engine [1], capable of carrying them out much faster than the CPU alone could. For instance, the GTE can apply a transformation matrix to three vertices and project them in 23 cycles, while the CPU's own multiplier takes up to 13 cycles for a single multiplication and 36 (!) for a division. Combined with a few other "tricks" such as a DMA unit capable of parsing linked lists (which lets the CPU bucket sort polygons on the fly rather than having to emit them back-to-front in the first place), it allowed games to push a decent number of polygons (typically around 1-3k per frame) despite the somewhat subpar performance of the cache-less MIPS R3000 derivative Sony chose.
If you have some basic familiarity with C, you can see both the GTE and the Z bucket sorting of GPU commands in action in the cube example I linked in the parent comment.
If anybody here wants to learn more about console graphics specifically, I think the original PlayStation is a good starting point since it's basically the earliest and simplest 3D-capable (though it would be more correct to say triangle capable, as it does not take Z coordinates at all!) GPU that still bears a vague resemblance to modern shader-based graphics pipelines. A few years ago I wrote a handful of bare metal C examples demonstrating its usage at the register level [1]; if it weren't for my lack of spare time over the last year I would have added more examples covering other parts of the console's hardware as well.
I'm late to the party but, as a prolific contributor to PSn00bSDK and the PS1 homebrew scene more in general, I feel obliged to shamelessly plug my own "PlayStation 1 demystified at the absolute lowest level" repo:
It's still very work in progress - I have only covered a tiny fraction of what the console's hardware can do - but I find it fascinating to explore how little code you actually need to get started on such a simple platform, even with no external SDKs or tools (aside from a completely standard MIPS GCC toolchain).
Flat triangles and trapezoids are sometimes used internally by these GPUs as a building block for other polygons, possibly since the logic to split up triangles and quads into flat trapezoids may have taken less die space than a rasterizer capable of handling three edge equations at a time rather than just two.
While exposing these lower level internal primitives typically did not make sense for general purpose graphics accelerators, some in-house embedded implementations did actually go further and only supported flat trapezoids, relying on the CPU to preprocess more complex shapes. For instance, the "SOLO" ASIC used in second-generation WebTV boxes took this approach [1] (among other interesting cost-cutting measures such as operating natively in YUV color space).
You can buy off-the-shelf modules that take a lithium ion cell and provide charging, overcurrent and overdischarge protection; just search your Chinese online retailer of choice for "TP4056 module" and you will find plenty of them. There is a Hackaday article [1] that goes in depth on how to use them properly.
If you'd rather not wire it up yourself there are also ESP32 dev boards with built-in battery management functionality, such as the LoLin32 Lite and Sparkfun ESP32 Thing. I haven't had much luck with the former (possibly due to its lack of RF shielding) but the latter seems to be pretty solid. I think Adafruit sells similar boards as well.
Not directly related to the course, but, should anybody want to see what programming on the PS1 would look like using only modern tools (latest GCC, CMake, no third party libraries), I've written a few bare metal C examples that explain in depth how the console's hardware works [1]. Currently only graphics and input are covered, but I'm planning to add examples showing how to handle interrupts, play audio and access the CD-ROM next.
There are homebrew tools that can be installed on a PS1 memory card [1] and allow for executables to be loaded from a host machine into RAM through the serial port on the back of the console, in a similar way to what Sony's official Net Yaroze loader did back in the day. These tools can also use undocumented CD-ROM drive commands to disable region checks without the need for a modchip, provide semihosting (host filesystem access) and so on.
On the PS2 it's slightly more complicated, as there is no way to launch the "native" PS1 backwards compatibility mode other than to use a modchip (or firmware mod on some models) and burn the executable onto a disc; the serial port is not exposed either, making debugging much harder. It can still be done, but it's much easier to just use an actual PS1.
A poorly written regulation from 2003 basically lumped together all gaming machines in a public setting with gambling, resulting in extremely onerous source code and server auditing requirements for any arcade cabinet connected to the internet (the law even goes as far as to specify that the code shall be delivered on CD-ROMs and compile on specific outdated Windows versions) as well as other certification burdens for new offline games and conversions of existing machines. Every Italian arcade has remained more or less frozen in time ever since, with the occasional addition of games modded to state on the title screen that they are a completely different cabinet (such as the infamous "Dance Dance Revolution NAOMI Universal") in an attempt to get around the certification requirements.
reply