Some? There are tons of horrible old games, vastly outnumbering the good ones. It's just by now it's fairly established what the good games are and the bad ones are mostly forgotten my most.
We simply don't have the same luxury with new games, they can be hit and miss, and reviews are untrustworthy.
I feel as though this reply doesn't really address what is being said in the prior post at all. Yes, bad old games exist. But there were literally dozens of genre-defining games that would go on to shape how games continued to be made in the decades since. Somebody posted a list of indie titles they consider good and probably half of them are outright homages to these older games. Games that are so good they define or reshape genres are few and far between nowadays. They do exist (Vampire Survivors was mentioned, and it is one), but not anywhere near the rate they used to.
You have to consider that it’s easier to create a genre when there are fewer games in existence. On Atari you’d make a game called “basketball” and bam, new genre!
That is why I specifically included "or reshape". Atari was first for many genres, but it didn't meaningfully define them, or to the extent it did they were significantly reshaped by future games. Super Mario Bros. was far from the first platformer but it, and future developments in the franchise, were so much better than everything that came before them that they became the face of the genre. We see Metroidvanias copying the Super Metroid / Castlevania formula for three decades and counting. None of those copies, not even the wildly successful ones like Hollow Knight, reshaped the genre such that future games were made in their image. And so it goes for most genres. It is certainly possible to reshape a genre in the modern era; Stardew Valley did it, for example. But it is rare for new games to pull off a concept so well that everyone after them copies their homework. Everyone is still copying the homework of the games from 20, 30 years ago.
Yeah I was responding to the opinion that old games are good because of nostalgia, which I don't agree with at all. Some are good because of nostalgia, some are good because they're just that good (there's a thriving community around NES Tetris for instance), some are good because they pushed the medium forward (Metal Gear Solid, Warcraft, The Sims, ...).
>Yes, bad old games exist. But there were literally dozens of genre-defining games that would go on to shape how games continued to be made in the decades since
The N64 had one of the smallest videogame libraries ever. It had less than 400 titles. How many of those were "Super great" vs how many were utter garbage?
The SNES had 1749!
The vast vast majority were slop.
A lot of the "great" ones are only really great in context, ie no preceding works to draw from and with the technological limits of the time.
Is Pilotwings good? As someone who grew up with similar age flight simulators but not pilot wings, it is extremely mediocre. Same for StarFox and StuntRaceFX even though both were dramatic at the time, but they do not hold up in the slightest. 12fps is not that fun.
>Games that are so good they define or reshape genres are few and far between nowadays.
Yes, this is called a new domain maturing. This is the expected outcome in all new domains. You pick all the low hanging fruit and explore most of the solution space.
Scroll through this list and tell me things were better back then
Do I get this right that this effectively dlopens glibc (indirectly) into an executable that is statically linked to musl? How can the two runtimes coexist? What about malloc/free? AFAIK both libc's allocators take ownership of brk, that can't be good. What about malloc/free across the dynamic library interface? There are certainly libraries that hand out allocated objects and expect the user to free them, but that's probably uncommon in graphics.
You have to tell musl to use mmap instead of brk. You're right that it doesn't work in all cases but as long as you switch TLS on calls (and callbacks), at least with a project the size of Godot, you can approach a workable solution.
> In an ideal world, there would be a header-only C library provided by the Linux kernel; we would include that file and be done with it. As it turns out, there is no such file, and interfacing with syscalls is complicated.
Nolibc, which is incorporated in the Linux kernel sources (under "tools"), contains generic wrappers for the Linux syscalls and a set of simplified implementations for the most frequently needed libc functions.
It is useful for very small executables or for some embedded applications.
It is not useful for someone who would want to use the Linux syscalls directly from another programming language than C, bypassing glibc or other libc implementations, except by providing models of generic wrappers for the Linux syscalls.
It also does not satisfy the requirement of the parent article, because it does not contain a table of syscalls that could be used for separate compilations.
Nolibc implements its functions like this:
long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
{
return my_syscall3(__NR_ioctl, fd, cmd, arg);
}
where the syscall numbers like "__NR_ioctl" are collected from the Linux kernel headers, because nolibc is compiled in the kernel source tree.
As explained in the parent article, there is no unique "__NR_ioctl" in the kernel sources. The C headers that are active during each compilation are selected or generated automatically based on the target architecture and on a few other configuration options, so searching for the applicable "__NR_ioctl" can be tedious, hence the value of the parent article and of a couple of other places mentioned by other posters, where syscall tables can be found.
Funny how you chose `ioctl` specifically to illustrate your point, when that's quite uniquely just a syscall inside a syscall… Ideally, high level library devs should abstract ioctl while treating libc as the stable userland kernel ABI, as has always been the case for the BSD's.
I think the real problem is GNU libc devs' unwillingness to stabilize it (not sure why, perhaps the menace of HURD still haunting them?)
I chose "ioctl" precisely because it has maximum simplicity, in order to show that in "nolibc" it needs externally provided syscall numbers.
Some other syscall wrappers from "nolibc" may be somewhat more complex, by doing some processing on the arguments, before invoking a generic syscall wrapper like "my_syscall3", "my_syscall5" etc. (where the number from the name of the generic syscall wrapper refers to the number of syscall arguments).
Ioctls are the single most complex example for API design, cause like, that's another opaque interface inside one opaque interface. Ioctls will be routed to the desired kernel module (driver) depending on the FD, after all.
Basically all I'm saying is that a syscall "ABI" is but a red herring for everyone but the [mainline] Linux devs themselves.
Java solved it by having exceptions be able to attach secondary exceptions, in particular those occurring during stack unwinding (via try-with-resources).
The result is an exception tree that reflects the failures that occurred in the call tree following the first exception.
We simply don't have the same luxury with new games, they can be hit and miss, and reviews are untrustworthy.
reply