Originally released for the Sony PlayStation in 1998, Resident Evil 2 came on two CDs and used 1.2 GB in total. Of this, full-motion video (FMV) cutscenes took up most of the space, as was rather common for PlayStation games. This posed a bit of a challenge when ported to the Nintendo 64 with its paltry 64 MB of cartridge-based storage. Somehow the developers managed to do the impossible and retain the FMVs, as detailed in a recent video by [LorD of Nerds]. Toggle the English subtitles if German isn’t among your installed natural language parsers.
Instead of dropping the FMVs and replacing them with static screens, a technological improvement was picked. Because of the N64’s rather beefy hardware, it was possible to apply video compression that massively reduced the storage requirements, but this required repurposing the hardware for tasks it was never designed for.
The people behind this feat were developers at Angel Studios, who had 12 months to make it work. Ultimately they achieved a compression ratio of 165:1, with software decoding handling the decompressing and the Reality Signal Processor (RSP) that’s normally part of the graphics pipeline used for both audio tasks and things like upscaling.
Texture resolution had to be reduced for the N64 port.
In the video you can see the side by side comparisons of the PS and N64 RE2 cutscenes, with differences clearly visible, but not necessarily for the worse. Uncompressed, the about fifteen minutes of FMVs in the game with a resolution of 320×160 pixels at 24 bits take up 4 GB. For the PS this was solved with some video compression and a dedicated video decoder, since its relatively weak hardware needed all the help it could get.
On the N64 port, however, only 24 MB was left on a 64 MB cartridge after the game’s code and in-game assets had been allocated. The first solution was chroma subsampling, counting on the human eye’s sensitivity to brightness rather than color. One complication was that the N64 didn’t implement color clamping, requiring brightness to be multiplied rather than simply added up before the result was passed on to the video hardware in RGB format.
Very helpful here was that the N64 relied heavily on DMA transfers, allowing the framebuffer to be filled without a lot of marshaling which would have tanked performance. In addition to this the RSP was used with custom microcode to enable upscaling as well as interpolation between frames and audio, with about half the frames of the original dropped and instead interpolated. All of this helped to reduce the FMVs to fit in 24 MB rather than many hundreds of MBs.
For the audio side of things the Angel Studios developers got a break, as the Factor 5 developers – famous for Star Wars titles on the N64 – had already done the heavy lifting here with their MusyX audio tools. This enables sample-based playback, saving a lot of memory for music, while for speech very strong compression was used.
Video
Don't take this the wrong way, but understanding the reason for that decision is pretty important if you're planning to run your own email server. A misconfigured email server (which is very easy to do) becomes a problem for everyone else when it inevitably gets used to spam. There's also a lot of ancillary things to configure correctly as well (DKIM, SPF, DMARC policies, spam filtering, etc) lest everything seems to work but no one is able to receive mail from you or it always ends up in their spam folder.
While I disagree with port 25 being permanently blocked on residential (and often even business-class) connections, I understand why in the grand scheme of things.
I don't read Finnish, but here are the general reasons why:
Port 25 is for SMTP transport and typically only used for server-to-server (MTA) email traffic. This is unauthenticated between servers. Clients (MUAs) connect through a "submission" port which is pretty much expected to be authenticated/access-controlled. That's why you can send emails to an email provider but you can't be an email provider yourself. By blocking port 25, malicious people or people that have been compromised with malware cannot just blindly blast out spam email. This reduces spam considerably, though with a compromise of slightly restricting what a residential connection can be used for.
Most big email providers universally block emails that originate from an IP address that's assigned to a residential IP/provider. Same reason as above. This means even if your ISP were to unblock port 25 for you, you likely wouldn't be able to send email to any major email provider (Gmail, Outlook, Yahoo, AOL, etc) as they would just sinkhole any messages you send to users there.
That's pretty much it in a nutshell.
Can you bypass that and host at home?
Yes, if you're willing to work for it. You can setup a VPS (cloud server) and port-forward across a VPN connection to your home server. Your DNS records for your email server would point to the VPS's IP, and the email server would need to be configured to use the VPS as its default route so all traffic goes in/out over the VPN connection. This is how my email server is configured.
Sounds easy enough, right? Well, good luck getting a VPS with a "clean" IP. Most VPSs you can get in public clouds are already on one or more public spam blocklists as well as many private/internal blocklists. You can clean up an IPs reputation and make it work with minimal to no delivery problems, but it's a LOT of work and often requires finding hidden forms to submit the request (Microsoft/Outlook was a brute, and I only found the link to the form in a forum post). I've cleaned up two IPs like that, and it took 2-3 weeks of work before I was able to get reliable delivery.