_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Super Mario 64 for the PS1
musha68k wrote 12 hours 44 min ago:
Amazing feat. I was a very happy owner of both consoles back in the
day, and this port clearly shows how much the N64 brought that "SGI at
home" feel in midâ1996; at least until Voodoo 1 / QuakeGL, maybe even
up to Unreal (Glide) or Sonic Adventure on DC?
I still remember gasping when I first saw the basically unattainable
(for me) Japaneseâimport N64 running Mario 64.
Such an interesting and varied gaming landscape back then; for example,
the Wipeout experience on PSX was beyond the N64 port in that
particular niche, for its own set of reasons.
wodenokoto wrote 19 hours 16 min ago:
Lots of people complaining that this has warped textures and whatnot -
but come on! This is amazing!
schlauerfox wrote 22 hours 6 min ago:
There is an explosion of decompilation projects spawning new ports, but
was there something that enabled better decompilations? I see it across
many retro games.
userbinator wrote 16 hours 40 min ago:
More people have discovered Ghidra.
spicyjpeg wrote 20 hours 55 min ago:
It has been enabled mainly by the the advent of streamlined tooling
to assist with 1:1 byte-by-byte matching decompilations ( [1] 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.
(HTM) [1]: https://decomp.me/
barbs wrote 21 hours 47 min ago:
Perhaps AI has made it easier?
coro_1 wrote 21 hours 49 min ago:
AI
DrewADesign wrote 21 hours 10 min ago:
Aye, AI.
arcanemachiner wrote 21 hours 46 min ago:
AI what?
SpaceManNabs wrote 1 day ago:
this is the devil's work. nicely done. what stood out to me is that one
of the known issues is the pause menu not working. wonder why that is.
edit: whoever did the gameplay video is really good at mario n64. They
were playing to and reacting to stuff that had rendered very late, if
at all.
aussieguy1234 wrote 1 day ago:
And they said it could never be done
itomato wrote 1 day ago:
âFinally, Super Mario 32â
mywittyname wrote 1 day ago:
Obligatory mention of Kaze, who has spent the past several years
optimizing Mario64 using a variety of interesting methods. Worth a
watch if your interests are at the intersection of vintage gaming and
programming.
(HTM) [1]: https://www.youtube.com/@KazeN64
extraduder_ire wrote 10 hours 53 min ago:
I was just about to post his video from August explaining how much
excess ram mario 64 uses and where, which was the first serious
mention I saw of a ps1 port being possible. He uses the ps1's smaller
ram size as a kind of benchmark.
I did not expect it to happen so soon. [1] - Mario 64 wastes SO MUCH
MEMORY
(HTM) [1]: https://www.youtube.com/watch?v=oZcbgNdWL7w
malucart wrote 10 hours 32 min ago:
I've been working on it since mid 2024, so that video was a funny
coincidence :)
eru wrote 15 hours 53 min ago:
He's great. (And ripped!)
I wonder what someone who has PS1 knowledge equivalent to Kaze's N64
knowledge could do on that console---perhaps using Mario 32 as the
benchmark.
(Mario 32 = Mario 64 on PS1.)
amlib wrote 1 day ago:
> Tessellation (up to 2x) to reduce issues with large polygons
From the videos I've watched there is still insane amounts of affine
transformation texture warping, is that because it's not enable or
because 2x is not enough?
I guess they will need to also redo all level geometry to be more
amenable to tesselation... I guess that's why many ps1 games had blocky
looking levels.
malucart wrote 1 day ago:
right now there is basically no preprocessing of level polygons and
they are copied as is, but when it is implemented, the largest
polygons will be split to solve this
this is also necessary to fix the occasional stretched textures, as
texture coordinates are also limited to a smaller range per polygon
on PS1
mewse-hn wrote 1 day ago:
I see a lot of texture warp like you mentioned but I'm not seeing the
geometry popping (wobble?) that was a hallmark of ps1 games, I'm
guessing they're using soft floating point for the geometry and doing
perspective-correct texture mapping would just be too expensive for
decent frame rate
malucart wrote 1 day ago:
it's not possible to have either subpixel vertex precision or
perspective correct mapping with the PS1 GPU, as it only takes 2D
whole-pixel coordinates for triangle vertices. (contrary to popular
belief, N64 also uses exclusively fixed point for graphics btw, it
just has subpixel units.) better tessellation can mitigate the
perspective issues by a lot, but the vertex snapping is unsolvable,
and it is indeed present here. look closer and you might see it.
eru wrote 15 hours 56 min ago:
Interesting!
I guess you could pretend to have sub-pixel precision on the PS1,
if you did it manually? Eg change the colours around 'between
pixels' or something like that?
But that would probably get very expensive very soon.
spicyjpeg wrote 1 day ago:
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]).
[1] - bit of a shameless plug, but notice how the Z coordinates are
never sent to the GPU in this example.
[2]
(HTM) [1]: https://github.com/spicyjpeg/ps1-bare-metal/blob/main/src/...
(HTM) [2]: https://fabiensanglard.net/doom_psx/index.html
eru wrote 16 hours 8 min ago:
It's funny that the PS1 got so famous for 3d games, when its
'GPU' was entirely 2d.
I guess the main thing the console brought to the table that made
3d (more) feasible was that the CPU had a multiplication
instruction?
spicyjpeg wrote 13 hours 55 min ago:
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.
[1]
(HTM) [1]: https://psx-spx.consoledev.net/geometrytransformatione...
wk_end wrote 14 hours 15 min ago:
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 [1] , 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.
(HTM) [1]: https://www.copetti.org/writings/consoles/playstation/
LarsDu88 wrote 1 day ago:
Darn I posted the same thing in another thread
wk_end wrote 1 day ago:
The README mentions that it uses both (new) fixed point as well as
soft floating point.
Unless I'm mistaken, the PS1 just plain doesn't support perspective
correction. All texture mapping is done in hardware using a very
not-programmable GPU; there'd be no way to do perspective
correction, decent frame rate or not, outside of software rendering
the whole thing (which would be beyond intractable).
The common workaround for this was, as suggested, tessellation -
smaller polygons are going to suffer less from affine textures. Of
course that does up your poly count.
wk_end wrote 1 day ago:
It notes in the Known Issues section that "Tessellation is not good
enough to fix all large polygons".
Maybe it just needs more tessellation or something else is going on,
because you're right - even as someone who grew up on the PS1 and is
accustomed to early 3D jank, it looks painfully janky.
zamadatix wrote 1 day ago:
If you like this port, you may also enjoy this ground-up effort to
clone SM64 on the GBA
(HTM) [1]: https://youtu.be/nS5rj80L-pk
ddtaylor wrote 1 day ago:
Does anyone know where the source to this is? It seems to have been
nuked.
zesterer wrote 18 hours 17 min ago:
I'm slowly preparing it to be released, I just have a lot of IRL
stuff going on!
no_wizard wrote 1 day ago:
While this is cool, it is really hard to look at for me.
Still bravo! I know getting it working and complete is the real goal
and it is commendable.
throwaway314155 wrote 1 day ago:
> it is really hard to look at for me.
What were you expecting?
no_wizard wrote 21 hours 45 min ago:
Nothing. I have zero expectations. Giving an honest take on what
I saw is all.
whizzter wrote 1 day ago:
Affine texture mapping is kinda jarring to look at, especially in
this GBA port since there is no fixup with huge ground polygons
drifting around.
One of the listed features in the PS1 port in the OP article is
tesselation to reduce the issues of the PS1 HW affine texture
mapper, on the GBA you have some base cost of doing manual
software texture mapping but also oppurtunities to do some minor
perspective correction to lessen the worst effects (such as doing
perspective correction during the clipping process).
zamadatix wrote 22 hours 3 min ago:
The GBA version does actually leverage dynamic polygon
splitting in direct reference to how PS1 games used this
approach [1] I think the resolution makes it particularly rough
though.
(HTM) [1]: https://www.youtube.com/watch?v=1Oo2CZWbHXw&t=271s
whizzter wrote 4 hours 38 min ago:
Almost felt like the second video (despite being older)
looked better in terms of texture jumping, looking closer now
the wandering textures actually seems more to be more of an
clipping issue than directly perspective correction related.
le-mark wrote 23 hours 57 min ago:
I am probably misremembering but wasnât super Mario 64
âflat shadedâ ie no textures just colors?
mikepurvis wrote 22 hours 42 min ago:
Like a lot of N64 titles, there were many solid colour
objects to save on RAM, but lots of things in the environment
especially were textured too.
wk_end wrote 23 hours 53 min ago:
Youâre misremembering. SM64 was fully textured, outside of
specific models.
Also flat shading (vs. say gouraud shading) is isomorphic to
the question of texture mapping, and concerns how lighting is
calculated across the surface of the polygon. A polygon can
be flat shaded and textured, flat shaded and untextured,
smoothly shaded and textured, or smoothly shaded and
untextured.
wk_end wrote 20 hours 53 min ago:
(Too late to edit but did not mean âisomorphicâ, meant
âorthogonalâ. Wrong smart person word trying to look
smart, how embarrassing, sigh.)
kibwen wrote 1 day ago:
Given that this is HN, I'm contractually obligated to mention that
the GBA port is written in Rust:
(HTM) [1]: https://www.digitec.ch/en/page/the-impossible-port-super-mar...
pmarin wrote 11 hours 54 min ago:
That sound more like a demake than a port. Very cool anyway.
deaddodo wrote 8 hours 0 min ago:
A demake would be a reimagining of a modern game into the style
and aesthetics of the time. E.g. taking God of War and turning it
into a 2D Shinobi-style platformer for Sega Genesis. Or turning
Gran Turismo into a Mode7-style racer on SNES.
In this case, the creator wrote a custom 3D renderer and
recreated the models/meshes to get as close of an approximation
of the N64 experience onto the GBA.
I wouldn't call it a port necessarily ("recreation" seems more
apt), but it's closer to that than a demake.
giancarlostoro wrote 1 day ago:
Interesting, I'm wondering if the GBA could handle a light version of
a Minecraft style game, but the N64 looks like it could be great at
it too. I need to get me a SummerCart64 one of these days and
experiment with my old N64.
takantri wrote 20 hours 57 min ago:
ClassiCube ( [1] ) exists, which is an open-source Minecraft
Classic reimplementation with an N64 port among dozens of others.
HN discussed it two years ago ( [2] ).
ClassiCube has a WIP GBA port, but according to commits it only
hits 2 FPS as of now and is not listed in its README.
On a related tangent, there's also Fromage, a separate Minecraft
Classic clone written for the PS1 ( [3] ).
(HTM) [1]: https://github.com/ClassiCube/ClassiCube
(HTM) [2]: https://news.ycombinator.com/item?id=37518874
(HTM) [3]: https://chenthread.asie.pl/fromage/
alexisread wrote 10 hours 47 min ago:
Related to this is the Atari Falcon port of Minecraft using a
sparse voxel octree, might work for the GBA seeing as the Quake
ports are similar performance-wise:
(HTM) [1]: https://www.youtube.com/watch?v=nHsgdZFk22M
wk_end wrote 4 hours 34 min ago:
Man, that DSP made the Falcon an insane piece of hardware for
its time. Shame that it never found any real success.
lbrito wrote 23 hours 43 min ago:
this guy builds a very similar engine
(HTM) [1]: https://www.youtube.com/@3DSage/videos
maximilianburke wrote 1 day ago:
Probably. There's Tomb Raider for the GBA via OpenLara:
(HTM) [1]: https://www.youtube.com/watch?v=_GVSLcqGP7g
ranger_danger wrote 1 day ago:
There was also just recently a Dreamcast port made, as well as Star Fox
64 for Dreamcast and also Mario Kart 64 for multiple platforms.
(HTM) [1]: https://github.com/CharlotteCross1998/awesome-game-decompilati...
bena wrote 1 day ago:
They just finished a Star Fox 64 port as well
Larrikin wrote 1 day ago:
Are there any pictures or video of it running? I understand why they
are not on the GitHub page
platevoltage wrote 1 day ago:
here's another video that showed good gameplay shots that I happened
to see last night.
(HTM) [1]: https://www.youtube.com/watch?v=kscCFfXecTI
eru wrote 16 hours 24 min ago:
Thanks for the link!
The first comment is pretty funny:
> Finally, Super Mario 32.
zoeysmithe wrote 1 day ago:
Its incredible to how compltely unwatchable modern youtube norms
are, to me at least. I feel like youtubers now aim almost
exclusively for the 12-18 demographic. I mean, this person is doing
some kind of character or affectation instead of using a normal
voice. Everything is some kind of grift or character or PR or
persona now it seems. I understand they do this to get viewers, but
its just depressing how much more content I'd enjoy if the PR
gimmicks and lowest-common-denominator tricks were stopped.
I just saw techtips Linus interview Linus Torvalds and the constant
manboying and bad jokes was just embarrassing and badly hurt the
interview. I really wish people like this would turn it way, way
down. I think we all love some levity and whimsy, but now those
gimmicks are bigger and louder than the actual content.
viraptor wrote 23 hours 0 min ago:
Torvalds didn't hold back either though, so not sure what the
complaint is... If you watch some WAN you'll see you're not
getting some weird persona in that video, just the same guy with
a bit of extra energy - which is just what you want to do for
presentations / shows / whatever. It was a genuine experience.
brailsafe wrote 1 day ago:
> I just saw techtips Linus interview Linus Torvalds and the
constant manboying and bad jokes was just embarrassing and badly
hurt the interview.
If you've been watching LTT for any amount of time, it wouldn't
be surprising that that's just LTT Linus' nervous awkward style,
he's just a person. The jokes can be cringe as hell, but I
thought the video was great, I don't think most nerds would be
any different in front of a camera.
kanzure wrote 1 day ago:
To me this sounds like a computer-generated voice for obvious
pro-privacy reasons for this kind of project. If it bothers you,
then maybe work on better voice synthesis tech! I assume it
sounds not-leading-generation because it was locally rendered but
I could be wrong.
ginko wrote 1 day ago:
The distorted textures and weird triangle clipping issues are
exactly what you'd expect from an unoptimized port to a platform
that doesn't support perspective correct texturing or depth
testing.
LarsDu88 wrote 1 day ago:
John carmack complained about this same issue for the Playstation
DOOM port: page 337 [1] Playstation rendered with affine
texturing which made it impossible to get perspective correct
rendering without hacks. The porting team ultimately did a very
interesting hack where they would use polygons to render 1 pixel
wide strips effectively simulating how non-hardware (that is
CPU-based/integer) acclerated rendering was done on the PC.
(HTM) [1]: https://fabiensanglard.net/b/gebbdoom.pdf
jml7c5 wrote 18 hours 36 min ago:
That link gives a 403 for me, presumably because
fabiensanglard.net disabled hotlinking.
For others who run into the same problem, the file can be
accessed via [1] . (I've highlighted the link to click.)
(HTM) [1]: https://fabiensanglard.net/gebbdoom/index.html#:~:text...
bluedino wrote 1 day ago:
It looks pretty decent but seeing the texture warping and
glitching reminds me of why I was team N64
mghackerlady wrote 8 hours 58 min ago:
Personally I'd take it over the N64s muddy textures, the
playstations wobbly but I can at least make out what
something's supposed to be
segmondy wrote 19 hours 59 min ago:
psx is r3000, n64 is r4300 a much faster and capable cpu.
krispyfi wrote 21 hours 22 min ago:
I had the opposite reaction. As someone who was on team PSX,
the wobbly jank is pleasingly nostalgic. Didn't someone say
that the limitations and artifacts of the obsolete media of the
past become the sought-after aesthetics of the future?
ginko wrote 13 hours 58 min ago:
As someone who was team N64 I do agree PSX has more of a
"trademark look" compared to the N64 which is pretty much
just a very limited version of a modern graphics rasterizer.
nmz wrote 16 hours 44 min ago:
This is all subjective so I suppose I should add an IMO, Even
back then many games were preferable on the N64 like megaman
legends, what the PS1 offered that was superior was storage,
which allowed for more music and FMVs, and also allowed for
voice acting and probably why MGS is still talked about to
this day, my guess is the lack of detail helps immersion the
same way you would read a novel, and I imagine the PS1 with
its storage would've been the perfect vehicle for Visual
Novels, but that still is not popular anywhere but Japan.
Even with realism, ports to dreamcast were better overall and
considering the latest port of Final Fantasy Tactics does not
emulate any of its PS1 limitations, I don't think a lot of
people strive/like the aesthetic.
ginko wrote 14 hours 7 min ago:
>Even back then many games were preferable on the N64 like
megaman legends
Huh, I generally see megaman legends cited as an example
where the PSX version looks better due to the crisper
textures.
(HTM) [1]: https://www.youtube.com/watch?v=J6lravGmPPQ
nmz wrote 2 hours 1 min ago:
I stand corrected.
eru wrote 16 hours 23 min ago:
> [...] and I imagine the PS1 with its storage would've
been the perfect vehicle for Visual Novels, but that still
is not popular anywhere but Japan.
I guess you can pretend that the JRPG or Resident Evil are
Visual Novels with some action game play (or turn based
combat) thrown in?
nmz wrote 1 hour 55 min ago:
That's what I do with sons of liberty
mpyne wrote 20 hours 54 min ago:
They are certainly sometimes a key part of the retro look
that makes things nostalgic.
But even during the PSX era I found it distracting and
annoying to look at so I can't say I have any nostalgia for
it even now in the way I do for N64-style low-poly 3-D games
or good pixel art.
01HNNWZ0MV43FF wrote 1 day ago:
The N64 definitely has the nicer GPU of the two. An N64 with a
CD-ROM drive would have been amazing.
president_zippy wrote 4 hours 56 min ago:
That "expansion pak" RDRAM upgrade was designed to give the
N64DD enough buffer space so devs could continue using about
4MB of RAM for everything else, so I can't imagine how
expensive the N64 would have been if they had to ship it with
8MB of RDRAM to maintain the same standard of visual quality
and a 2X CD-ROM drive.
Then again, the good games would have been $50 instead of
$70, and there would have been a lot more developers willing
to pay $0.20 per unit to ship games than $20 per unit for the
common 12MB and 16MB ROM chips.
However, I don't know if Ocarina of Time or Majora's Mask
would have worked as well without that ability to load entire
scenes in < 500ms. Diddy Kong Racing and Indiana Jones & The
Infernal Machine relied on the ability to stream data from
the cartridge in real time to smoothly transition between
scenes/areas. DKR only used it in the overworld AFAIK, but it
was still impressive.
Not saying you're wrong, just that I'm glad things turned out
the way they did because Ocarina and Majora's Mask likely
could not have been done on a Saturn or PS1 beefed up with
the N64's GPU.
I could be wrong, and some experienced romhackers could
conjure up enough clever optimizations to make a faithful PS1
port of Ocarina of Time that doesn't have noticeable load
times, but it would have been the result of years of research
with no deadline pressure. I admit I'm just speculating, but
not in a presumptuous and baseless way.
greeniskool wrote 10 hours 1 min ago:
There was actually an unauthorized third-party CD-ROM drive
for it, the Bung Doctor V64[1]. It didn't actually expand the
available ROM space beyond what was possible with cartidges,
but its still interesting in that it was allegedly used by
licensed Nintendo devs as a lower-cost alternative to the
devkits officially provided to them.
(HTM) [1]: https://en.wikipedia.org/wiki/Doctor_V64
mghackerlady wrote 8 hours 56 min ago:
not allegedly, iirc the turok devs used one
klipklop wrote 22 hours 7 min ago:
And a bit more texture memory!
redox99 wrote 19 hours 5 min ago:
The RAMBUS speed is the main issue. The RDP can literally
be stalled over 70% of the time waiting for memory. It's
extremely flawed.
They could have used SDRAM and it would perform so much
better, and I believe the cost is around the same.
If you wanted to cut something, cut the antialiasing. While
very cool, it is a bit wasted on CRTs. Worst of all, for
some reason they have this blur filter which smears the
picture horizontally. Luckily it can be deblured by
appliying the inverse operation.
eru wrote 16 hours 20 min ago:
Would SDRAM have been faster and cheaper? Why did they
pick RAMBUS?
redox99 wrote 16 hours 7 min ago:
I think the main reason is that when they architected
it, RDRAM seemed like the better choice based on price
and bandwidth at that time, and they underestimated the
performance issues it would cause (RDRAM has amazing
bandwidth but atrocious latency).
By the time the N64 launched, SDRAM was better and
cheaper, and they considered it was too late to make
the switch. Allegedly SGI wanted to make changes but
Nintendo refused.
Basically they made the wrong bet and didn't want to
change it closer to release.
eru wrote 15 hours 51 min ago:
Thanks!
OK, I also just read that basically Nintendo bet on
ram bandwidth, but ignored latency.
A more general lesson: Nintendo bet on cutting edge,
speculative technology with RDRAM, instead of
concentrating on 'Lateral Thinking with Withered
Technology'.
president_zippy wrote 20 hours 20 min ago:
The whole thing about the texture cache being the worst
design decision in the N64 just gets parroted so much, but
nobody can cogently explain which corner should have been
cut instead to fit the budget.
eru wrote 16 hours 18 min ago:
You could have saved a lot of money by using CDs instead
of cartridges.
If you sell games for roughly the same amount as before
(or even a bit cheaper), you have extra surplus you can
use to subsidise the cost of the console a bit.
Effectively, you'd be cutting a corner on worse load
times, I guess?
Keep in mind that the above ignores questions of piracy.
I don't know what the actual impact of a CD based
solution would have been, but I can tell for sure that
the officials at Nintendo thought it would have made a
difference when they made their decision.
dole wrote 15 hours 46 min ago:
imho, Nintendo had a hard enough time with preventing
piracy and unlicensed games with the NES and SNES and
saw the PS1 got modded within a year, even with the
special black coated discs to hide the tracks. There
wasnât a lot of optical/compact disc copy protection
magic at the time and, cd-rs and writers started
getting popular quickly as well. ps1 in 1994, n64 in
1996, backwards Dreamcast GD-ROMs and beginnings of
larger discs and DVDS in 98.
eru wrote 14 hours 22 min ago:
The discs being black was a marketing gimmick, the
actual magic was in the 'wobble'.
> Nintendo had a hard enough time with preventing
piracy and unlicensed games with the NES and SNES
[...]
Yes, so I'm not sure that the cartridge drawbacks
bought them that much in terms of piracy protection?
I agree that the PS1 had more piracy, but I'm not
sure that actually diminished its success?
pezezin wrote 9 hours 19 min ago:
> I agree that the PS1 had more piracy, but I'm not
sure that actually diminished its success?
At least in my corner of the world (Spain), piracy
improved its success. Everybody wanted the PSX due
to how cheap it was, I think it outsold the N64
10:1.
indigo945 wrote 16 hours 21 min ago:
The N64's CPU, with pretty much every single game
released on the platform, is just sitting there idling
along at maybe 30% load tops, and usually less than that.
It's a 64 bit CPU, but Nintendo's official SDK doesn't
even support doubles or uint64!
Of course, Nintendo clearly cared about the CPU a lot for
marketing purposes (it's in the console's name), but from
a purely technological perspective, it is wasteful. Most
of the actual compute is done on the RSP anyway. So,
getting a much smaller CPU would have been a big corner
to cut, that could have saved enough resources to
increase the texture cache to a useful resolution like
128x128 or so.
It should be noted, though, that the N64 was designed
with multitexturing capabilities, which would have helped
with the mushy colors had games actually taken advantage
of it (but they didn't, which here again, the Nintendo
SDK is to blame for).
pezezin wrote 9 hours 25 min ago:
> So, getting a much smaller CPU would have been a big
corner to cut, that could have saved enough resources
to increase the texture cache to a useful resolution
like 128x128 or so.
How? The texture RAM (TMEM) is in the RSP, not in the
CPU.
indigo945 wrote 6 hours 5 min ago:
How is that relevant? "Resources" really just means
money, which can be allocated between different items
on the BoM at-will. The N64's chips are all (more or
less) bespoke, so the functionality of each
individual part is completely under Nintendo's
control. Spend less on the CPU, and you suddenly have
money left to spend on the RSP. (And on the RDP,
which contains the TMEM -- it lives on the same chip
as the RSP, but is a distinct thing. I assume you
know this, but just to add to the discussion for
readers - the RSP is the N64's SIMD coprocessing
unit, which most games use to perform vertex shading,
whereas the RDP is the actual rasterization and
texturing hardware.)
mrguyorama wrote 1 hour 20 min ago:
Realistically it wasn't even "We only have X
dollars to spend". They needed the console to have
a final budget and they really could have "just"
added more transistors dedicated to that texture
unit without significantly altering prices or
profit.
But hardware was actively transitioning and what we
"knew" one year was gone the next and Nintendo was
lucky to have made enough right choices to support
enough good games to survive the transition. They
just got some bets wrong and calculated some
tradeoffs poorly.
For example, almost everything Kaze is showing off,
all the optimizations were technically doable on
original hardware, but devs were crunching to meet
deadlines and nobody even thought to wonder whether
"lets put a texture on this cube" needed another
ten hours of engineering time to optimize.
Cartridges needed to be constructed by Christmas. A
lot of games made optimization tradeoffs that were
just wrong, and didn't test them to find out. Like
the HellDivers 2 game size issue.
Sega meanwhile flubbed the transition like four
different ways and died. Now they have the blue
hedgehog hooked up to a milking machine. Their
various transition consoles are hilariously bad.
"Our cpu and rasterizer can't actually do real
polygon rendering and can't fake it fast enough to
do 3D graphics anyway. Oh, well what about two of
them?"
eru wrote 16 hours 14 min ago:
> It's a 64 bit CPU, [...]
Only really in the marketing material. It's a bit like
calling a 386 with an arithmetic co-processor an 80 bit
machine, when it was still clearly a 32 bit machine by
all metrics that matter.
However, I agree in general that the N64 CPU sits idle
a lot of the time. It's overspecced compared to the
rest of the system.
malucart wrote 10 hours 37 min ago:
no, it really is a true 64 bit CPU. it's just that
that fact is useless and it usually runs in 32 bit
mode because games don't need that.
indigo945 wrote 6 hours 0 min ago:
Yes. Although people like to point out that on the
N64's CPU the external data bus is restricted to 32
bits, that's irrelevant in practice. The real
limitation is the RDRAM's data bus, which is only 9
bits wide (of which the CPU uses 8 bits). The
problem is that the rest of the system simply
cannot match the overspecced CPU.
redox99 wrote 19 hours 5 min ago:
See
(HTM) [1]: https://news.ycombinator.com/item?id=46227453
anthk wrote 1 day ago:
That was an issue in tons of PSX games.
vereis wrote 1 day ago:
yeah this is the distinctive ps1 look I think all games look
like this, at least polygonal games
eru wrote 16 hours 14 min ago:
You can use lots of tricks to make your PS1 game not look
like this. Or at least much less like this.
ranger_danger wrote 1 day ago:
(HTM) [1]: https://www.youtube.com/watch?v=6f92hKbz5Eo
zamadatix wrote 1 day ago:
For those that prefer pure gameplay to skip through
(HTM) [1]: https://youtu.be/kkJWZlAjZp0
threethirtytwo wrote 1 day ago:
This is emulated as I'm sure the other videos are, but the PS1
back in the day had no way of running anything this crisp, so the
emulator is `enhancing` it here. It's not an actual
representation of what the game would have looked like.
anthk wrote 1 day ago:
CRT's smoothed out the image a little bit. Also, the screens
were much smaller back in the day.
eru wrote 16 hours 12 min ago:
> Also, the screens were much smaller back in the day.
Not if you watch the video on your phone or iPad or laptop!
Actually, even most desktop pc monitors aren't bigger than
people's TVs back then.
(Of course, TVs now are bigger than TVs back then. And
desktop pc monitors are bigger than desktop pc monitors back
then.)
anthk wrote 15 hours 19 min ago:
The 14" Nokia TV from my old bedroom disagreed a little :)
In the end if you reescaled the emulator window down to
320x240 or 640x480 with a 25% scanline filter on LCD's or a
50% in CRT, the result would be pretty close to what
teenagers saw in late 90's.
eru wrote 14 hours 24 min ago:
For a video, yes.
Though I suspect for interactive use, CRTs might have had
better latency?
zamadatix wrote 1 day ago:
It doesn't really work right on "normal" PS1s yet, at least
when it was making the rounds a few weeks ago, so you need
either an emulator or modded/dev PS1 with more RAM to prevent
crashes and most people won't have the latter [1] . Probably
shared a few months to early.
But yeah, on a "real" PS1 it would be blockier due to lower
res. The main rendering problems should be the same though.
(HTM) [1]: https://www.reddit.com/r/psx/comments/1p45hrm/comment/...
malucart wrote 1 day ago:
nah, it's not even configured to use the extra RAM, though
there is a compile option for that. seems like the freeze was
some sort of bug in the tessellation code, but I'm rewriting
that part, so the bug is gone now. it should be working fine
on hardware after I publish the changes.
zamadatix wrote 19 hours 7 min ago:
Cool work man - can't wait to try it out when the fixes
land!
BugsJustFindMe wrote 1 day ago:
No screenshots :(
(DIR) <- back to front page