>he doesn't even have a floating point unit

I'm making a floating point unit in Turing Complete and it's a massive pain. I have a lot of respect for the people who actually designed them in the real world.

>>105897770 (OP)
they had coprocessors back then for people that needed it.

>>105897770 (OP)
Just use two integers. You don't need floats.

>>105897770 (OP)
Neither 386dx or sx did have an fpu
That nomenclature refers to its address bus

>>105897770 (OP)
> he is a floating point unit

>>105899500
> don't need floats
how dare you.

integers are perfect, smooth numbers
floats are ugly
simple as

>>105897770 (OP)
Don't need em
Just make the multiply instructions behave like MIPS and use fixed point

>>105898718
>Turing Complete
what a fucking synchronicity i just got back into it after like a month or 2 of being a faggot and stalling i currently got conditions registers and little box up next im going registers first tommorow when i wake up

>>105899745
yea about that

>>105900328
I forget, this was caused by the PS GPU not being able to calculate any sub pixel values so it just snapped (quantized, I guess?) geometry to the nearest pixel value, right?

>>105897770 (OP)
Use case for floating point units?

>>105900806
yea, the psx gpu is entirely integer, no float support, which leads to a lot of rounding. vertices are snapped to the nearest screen pixel.
i'm specifically talking about the "jittery" effect it has, the psx also lack perspective texture mapping and a z-buffer, which results in different visual artifacts, but that's not because it doesn't do floats

>>105900328
>>105900861
more soul than anything released recently

Floating point drive me crazy, when I place a 3D object in Y=0.3, it actually set to 0.29999999999

>>105899745
>floats are ugly
L take.
Floats are genius. Period.
You get more accuracy where it matters (small numbers) and less accuracy where it doesn't matter (large numbers).
Integers and even fixed point are way less accurate near 0.

>>105900913
that's because there simply is no "0.3" to begin with. it's like asking an integer system to store 2.9, it turns into 3 because there simply is no value for "2.9" as an integer
for most things "0.300000011920928955078125" is close enough, floats are great at "close enough"

>>105901031
it is a very clever solution and widely applicable. infinite precision doesn't make sense most of the time and can be very wasteful, and using large integers (fixed point) is also often wasteful

>>105900328
That's not really issue with integers but that they use 8bit indices or something like that.
With int32 there would be no issues.

>>105897770 (OP)
tfw one of the things I do at work is write code for a FPU-less processor

>>105901284
>600mhz risc
interesting chip. how much external ram can it support?

>>105900861
Ahhh, the lack of a z buffer in hw so one had to be done in software
They don't make em like that any more..

>>105901951
oh no, anon, you didn't do a software framebuffer either. i mean you probably could maybe, but no commercial game i know of did, that'd surely be too expensive.
no, you just had to be smart about how you sort and draw polys on the playstation, and eat the artifacts when it's not perfect.
it's just another reason why psx rendering looks so unique, it's so janky but you know it's trying

>>105902098
software z-buffer*

>>105899620
I'm old, so I remember when we all thought the 486 had a 16 bit data bus or something.
Now here we are, 35 years later, and all the zoomers think a 386SX doesn't have a math copro.

>>105902108 (Me)
486SX, rather.

>>105901951
>>105902098
instead to mitigate artifacts from the lack of z-buffer or perspective mapping, the fancier game engines went for triangle subdivision. the psx's triangles weren't high quality, but it could throw around a lot of them. things like floors are often a finer grid of triangles than it looks like just because large textured triangles look /really bad/ with affine mapping and smaller tris means smaller errors if they're rendered in an unfortunate order or overlap each other. the n64 could get away with larger triangles because it had both perspective textures and a z-buffer

>>105902098
I see. Thanks, Anon. I wish I understood all this shit better :(
>expensive
You mean as in it would cost too many CPU cycles, right?

>>105899455
>coprocessors
Cuck processors

>>105902537
>You mean as in it would cost too many CPU cycles, right?
i mean in any capacity (except monetary cost), which includes cpu cycles, memory usage/bandwidth, whatever. i know enough to know it'd be expensive, but the details would require someone with experience programming the playstation
suffice to say it was still the early days of real time 3D graphics, and the playstation went for the super shotgun approach. they surely knew about things like z-buffers, but this was 1994 (well, before then since it came out in 1994), and whoever was an sony designing the playstation knew what was and wasn't critical for games, because all the nice-to-haves didn't exist, yet it still had all the must-haves. it's a beautifully designed system that was exactly what it needed to be and nothing more.

>the GPU handles sorted polygons by providing an ordering table: a dedicated structure in which each entry is indexed by a depth value (also called ‘Z-value’) and contains the address where the corresponding GPU command resides [14].

>The CPU must manually sort the polygons first, and then place references in the appropriate entries of the table. Finally, the CPU orders the DMA to send the table to the GPU. This process enables the GPU to render the geometry in the correct order.

>>105900861
The z-buffer is an anti-feature. Its introduction was the point at which 3d really started to go wrong.
Also, technically you don't need float to avoid texture wobble, fixed point would have worked as well.

>>105902747
>The z-buffer is an anti-feature. Its introduction was the point at which 3d really started to go wrong.
i'm not sure i'd go that far, but the playstation does demonstrate that it's possible to do 3D without one
>Also, technically you don't need float to avoid texture wobble, fixed point would have worked as well.
"texture wobble" is a bit ambiguous here, are you referring to vertex 'wobble' or the funky effects of affine mapping? because sure, if you used high enough resolution integers you could do vertex math that doesn't look that bad, but floats are still the solution to that problem
i couldn't say what cost difference there would have been between the integer-only GTE we got and a hypothetical floating point capable GTE (GTE or "graphics transformation engine" being the "gpu" of the playstation)
https://youtu.be/UcL1sMI8snQ

>>105902878
vertex wobble is what I intended to say.

Anyway, in regards to why I think the z-buffer is an anti-feature, is because its incredibly limited in usefulness, specifically it becomes worthless as soon as anything is transparent. I prefer being able to mix transparent and solid geometry freely without restriction. The z-buffer is so useless for transparency that a lot of modern games have straight up given up with alpha and are now using meshes like the Saturn.