/vr/ - Retro Games

>>2508964
>expressive

I read that as expensive and gave myself a really good laugh.

>>2508964
>>2508990
Mah niggaz.

Both of those games ruled. It's a goddamn shame Capcom retired the Legends franchise, and Ganbare Goemon never gained much traction in America.

This is /vr/. Early 3D means wireframe and maybe flat shaded polygons. Hardware accelerated and texture mapped polygons are late 3D.

>>2508997
What the hell are you on about?

>>2508964

Mega Man Legends looks great to this day, especially when emulated at a higher resolution.

>>2509010
Megaman Legends is in now way "Early 3d".

>>2509015
First off learn to spell and convey meaning better. I had to read both of your posts several times before I understood what you were trying to say.

Second off, you knew what he meant, "Pre-2000s 3D". Stop nitpicking.

Silent Hill hid everything behind fog

does that count?

System Shock's cyberspace segments make great use of simple polygons and wire-frames.

>>2509019
I wish the SEGA AGES version had colors less dulled from the original, but any version of VR looks great.

https://www.youtube.com/watch?v=xQ7eUL7hTZA

Shitty filter aside, this is a 1993 game.

Legends looks 10 years ahead of its time. A lot of DS games have the exact same art style as it.

However, I disagree with the idea that "stylized graphics age better than realistic graphics" which is common here. The low-poly look is a stylization itself, and there's plenty of realistic-looking games that aged well on the PS1, like Driver 2, MGS and Silent Hill.

Contribution.

>>2509050
I wanted to do an indie game with graphics stylized like low-poly PSXera graphics. Something more like FFIV where everything looks kind of cute that way instead of like Silent Hill where everyone looks like their joints could use reassessment.

The Wipeout games certainly qualify. They took low-poly restrictions and ran with it as an entire design aesthetic The Crafts in Wipeout are sleek and triangular, and as such look appropriately futuristic. Add the right textures like Wipeout 3 did and you got yourself a game which remains beautiful to this day.

>>2509064
If you have some experience with C and 3D modeling software (most PS1 games used Lightwave) then you're pretty good to go.

>goes to play a game nearly 20 years old
>goes autistic about playing it in 1080p and 60fps+gay bilinear filters

I will never understand this faggotry. It's like having the chance to drive a rolls royce and demanding air bags, gps, abs...

>>2509064
all-things-andy-gavin.com/video-games/making-crash/

obligatory post whenever anyone mentions crash in a technology thread

>>2509156
I don't... What?
I haven't seen any of that in this thread.

>>2509168
>I haven't seen any of that in this thread.

see
>>2509014

>>2509015
are you really this pedantic

>>2509156
>calls other people autistic for wanting something to look nice

>>2509156
wat

>>2509170
I dunno anon, emulating something at a higher resolution is not the same thing as going "autistic about playing it in 1080p and 60fps+gay bilinear filters"

I don't generally emulate but I can understand upscaling it if you do, otherwise it will either look like shit or be confined to a tiny window.

This game looks so amazing holy shit, I was just playing it again recently, the optimization game 2stronk

>>2508964

The Legends/DASH games use an absurd amount of camera/perspective-aware textures for eyes and mouths. The game has no right looking as timeless as it does given the hardware it was designed for. Those people knew their shit something fierce.

>>2509014
>>2509209

Is it me or is there some of GTE Accuracy going on here? And it's better than I remember it being, too.

>>2509165
Well this is beautiful. guess I'm reading this for the next hour.

>>2509135
Oh yeah, man, I could totally do it, I've got some base Blender knowledge and can work with engines (A low poly PSX-like game on Unreal 4, how quaint and ironic.) It's just that I haven't yet.

Integer scaling on LCD looks fine.

>>2509027
That's actually kinda the opposite of what this thread is about. Low draw distance (imo) is a symptom of having an ambitious design but where the hardware isn't quite there, so you have to rely on the fog to get you the rest of the way.

>>2509069
it also had good graphic design. I can't think of many other games that were on the same level

>>2509019

For being one of the first 3D games and made up almost entirely of flat colours VR still looks fucking great, plus smooth as hell. 1992 SEGA were total wizards.

>>2509039

https://www.youtube.com/watch?v=-3zkcy1Sag4

Scud Race from 1996 has graphics easily on PS2 level and came out the same year as Super Mario 64.

>>2509315
So is hiding it as "fog" not clever on their part? It's not like Goldeneye where its not supposed to be there.

>>2509464
Yeah, and it was running on hardware 1000 times more expensive than a PS2 at launch.

>>2509478
Same era as these other games though, I guess it counts. It was able to look so nice because they had the money to make it that way, but that doesn't mean it wasn't impressive at the time.
Think about it though, just four years later capabilities like that were in a consumer-level product. Kinda cool.

This game looks beautiful, but the smarts were probably all put into the merging system; they're obviously palette swaps but they look definitely like something different that you made.

>>2509515
>palette
*texture

Whoops.

>>2509019
Virtua Racing looks kind of futuristic, really.

It's stylized as fuck. Hell, you could reasonably release a game that looked like it today if it had just a bit of additional gloss on it (like, reflective surfaces that still kept the bold, flat look).
It has a sense of style which some other early flat-shaded polygon games like Atari's Hard Drivin, Namco's Winning Run, etc. totally lack.

Even discounting Sega's use of color for that bright "Sega Blue Skies™" look, the geometry still looks fantastic.

>>2509464
I'm still bothered Scud Race didn't have a Dreamcast port.
actually, pretty much all the Model 3 games needed ports

>All this thread
>No Jet Set/Grind Radio
For shaaaaame.

>>2509562
I'm still amazed of what Sega did with that game. Shit looks FANTASTIC to this day.
Incredibly stylish.

non-/vr/, but JSRF looks even better and could easily be released almost as-is today in 2015 (maybe somewhat higher res textures and AA enabled), it's that pretty

>>2509464
>>2509519

It used the chipset that became the i740. I had a card that used one of those back in the day. neat.jpg

>>2509580
>>2509562
It probably was the first 3D game to pull of cel-shading well. And when cel-shading is done right, its look is timeless.

>>2509562
>>2509595
Jet Grind Radio is a very good game to me, and it's sequel, JSRF, is my favourite game of all time. You two must be wearing 9 pairs of special-order rose-tinted glasses think that Jet Grind Radio hasn't aged badly though. Pic related, just look at this shit.

>>2509616
>ITT: Early 3D games with clever aesthetic design choices given their hardware limitations
It looks good still, aged well is a different story but you could easily release a game that looks similar on steam and nobody would complain about the graphics.

>>2509616
>pic related
is for ants (less than half the DC's screen res) so I can't make out anything you're talking about

like, JSR has some low-res as fuck textures that are REALLY noticeable, and the geometry is maybe a bit too angular and low poly at times (a lot of that can be written off as style, even if not all)

but that picture looks fine
you could pass it off as a stylized drawing (particularly with how blurry it is)

>>2509616
I'd find that style comparable to Madworld on the Wii. The textures in JSR need a little freshening up but it looked fine when I played it in high resolution on my PC.

Agree, if MML 1/2 ever get a hi-res texture pack it wont need any extra detail to be an improvement. Also, has anyone tried a cartoon shader with these games on EPSXE? I'd try it myself but my shit station doesn't have GL2.

>>2509478

SEGA did practically nothing but burn money in money in this period, that doesn't surprise me. It always amazed me how ahead of the curve arcade games were compared to home consoles, but I guess it wasn't sustainable and it certainly isn't the case anymore.

ghoul panic was one of the best laser-gun arcade port for the playstation.

>>2508964
>clever aesthetic design choices given their hardware limitations
DASH was so good at it.

Come on now.... how could you forget.

Come on now.... how could you forget.

>>2510014

Point Blank for furries.

Pretty good game, but playing it side by side with Point Blank, it gets stale real fast due to the lack of variety- Those same ghosts and skeletons in every level. And the bosses are beyond tedious.

Would recommend if you are a furry or a fan of gratuitous polygonal upskirt.

>>2510318
thanks for the review no one asked

>>2510296
As good looking as the visuals are, the detailed background is a bit of a turn off for me.

>>2510294

Because that game is one of, if not the, ugliest games on the PS1, regardless of any aesthetics or hardware. It just looks like shit.

>>2510339
looks like someone's feelings are hurt that someone opened up the holes in his favorite light shooter

>>2510396
stop hurting me :'(

>>2510398
Vagrant Story had some pretty clever use of textures and the polygon counts is also pretty good for a PS1 game, some monsters still look gorgeus even today, the opening cutscene is also extremely well designed and has some really great cuts.

>>2510386
Um Jammer Lammy is better looking, plays better, is funnier, and sounds better than Parappa ever did. It had a better idea of what to do with the art style it garnered from then-modern pop.

>>2510386
I've seen ugly looking games on the PS1, but Parappa isn't one of them (at least imo). I think the game's style is rather colorful and charming; that said I can still understand why it could also be a turnoff for others.

>>2509562

JGR is not /vr/, nor is it early 3D

>>2511046
thanx internet police :^)

>>2511052

Any time. ^.^

>>2508964

>>2511119
fuck year they shaped every cylindrical object in the game as honeycombs

>>2511125
shaped every cylindrical object in the game as honeycombs
>in a game about bears
If that's not a clever aesthetic design choice given their hardware limitations, then idk what is.

Besides, the textures in BK still look good today. Kind of puts SM64 to shame by comparison.

>>2510709

Parappa was practically a launch title for the Playstation and was made by a small team, you've got to give 'em a pass for some of the more jagged stuff in the first game. What really made me appreciate its aesthetic was them bringing back Parappa for Sony Smash, two generations later and a team that didn't understand the artstyle and he looked putrid. Looked at this shit.

>>2511356
>Parappa was practically a launch title for the Playstation
Please don't just say things because you can. It came out two years into the PS life in Japan, and three years later in the US. I love the game but it's not anywhere near a launch title.

>>2509050
I think that deliberately cartoonish games age better than those who went for, at the time, realistic graphics. A non-/vr/ example would be Halo 2 and Super Mario Sunshine, think of how they looked back in 2004/2005, now think of how they look now.

>>2509515
I loved the idea of the merging system in that game when I was a kid but I only ever had the demo. I revisited the game many years later only to be dissapointed by how shallow it was.

>>2509318

Totally agree about the graphic design. Hiring Designers Republic was such a smart move. I'd never seen such sexy design in a game before. The iconography and team logos, the slick menus and that kind of Japanese-esque Blade Runner future felt so fresh and immersive. I fell in love immediately.

>>2511707
I thought the game was fun, but I was left wishing the mechanics were deeper. Story and fucking Ghibli kinda made up for it but not quite. I ended up just going back to Dragonseeds or Monster Rancher 2 at the end of the day.

One of the few PS1 games with really good full voice acting in it though.

>>2509165

Great read, thank you! Back in the day I dismissed Crash as a Mario 64 clone but even back then it was obvious it looked better. I just assumed it was because PS1 was better hardware. Really cool to read the whole story behind it.

>>2511356
This thread is all about games that don't need a pass and you're using it in your argument.
Jeeze man.
The fandom is completely reprehensible too.
Have some OC.

>>2508990
Is this game emulatable?

>>2509165
>reading these posts
>mfw this
Well this got rather meta.

>>2509019
I always hated racing games. Still hate them. But I played the fuck out of Virtua Racing on the 32X for some reason.

>>2508997
>Early 3D means wireframe and maybe flat shaded polygons.
That's my favorite style of 3D - everything from Elite to this kind of weird game (The Colony). There were many others though: Mercenary series, Hunter, Freescape engine stuff (Castle Master, Driller, etc.), The Sentinel (aka The Sentry), Stellar 7 / Nova 9, Starglider, Midwinter series, and tons more...

http://hol.abime.net/hol_search.php?N_ref_genre_dimension=2

Continuum (aka Alpha Waves) is particularly cool:
http://hol.abime.net/3085
It's a good game to "zone out" with. PC version is a little nicer because of in-game music.

>>2508990
1997 isn't quite "early 3D".

Does https://www.youtube.com/watch?v=kUe9ASlu9Us count?

>>2509191
Those are very different things. Upscaling is just doubling or tripling the pixels, so the game can display at a reasonable size on a high-resolution desktop (since video cards these days are no longer confined to 320x200 or other such low resolutions). That's not the same as increasing the in-game resolution (which allows for more detail), or applying weird filters and such.

>>2512479
>Upscaling is just doubling or tripling the pixels
Nitpicking, but upscaling may attempt to do additional detail not given by the original samples alone. Stuff like SaI or Super Eagle is also upscaling, and certainly not just doubling pixels. Good upscaling engines do a lot, including motion detection, to gain as much detail as possible.

>>2512461

Uh, ok, but why did you reply to me and not OP?
Mystical Ninja starring Goemon was released in august, 1997, and Mega Man Legends was released in december of the same year.

>>2512464
That's a Saturn game? It looks better than a lot of PS2 games!

>>2508990
I always thought Goemon looked like "baby's first attempt at programming a 3D game". Well I guess a lot of N64 games did, especially since the PS1 wasn't even true 3D.

>>2514503
>true 3D
shut up, really. So tired of this nonsense

>>2509156
I-I honestly prefer the way native res looks.
You're correct, though, I would never force my personal tastes upon someone else.

>>2514523
Well the PS1's GPU can't even accept three Cartesian coordinates as its parameters, only two. It is for all intents and purposes, a 2D chip.

>>2514552
It can calculate a program that demonstrates height, width and depth so therefore it's 3D. it's not a hard concept. 3D means three dimensions, those three dimensions being the aforementioned height, width and depth

Why people make out 3D to be more than it is is beyond me. Anything that can do math on this planet can do 3D, regardless of what it is.

>>2508964
>Early 3D
>came out in like 1999

I'm sorry, but to me early 3D is like PC games from 1991, or fucking Jaguar games with no textures at all.

>>2514552
so what? The output on screen is a 2D projection of a 3D environment. Are all the polygonal games from the 70s and 80s also "no true 3D"? What about any fully textured 6DOF game like Descent? It works without a 3D accelator. If that is not "true 3D", what is? Or how about games that don't even bother with polygons, like Comanche? How "true" is their 3D?
"true 3D" means absolutely nothing. It's a buzzword, and it limits 3D imagery to hardware accelerated polygonal textured rasterizing, which is but one variant of the vast world of 3D rendering.

>>2514665
>1991
You're off by only a decade.
Real time 3D has quite a history by now. Things just took a bit of a jump forward when the computations moved into dedicated hardware. However, even between 1980 and 1990 there's such a vast amount of development in terms of real time 3D graphics, that can't be brushed off.

>>2514660
>depth
The GPU doesn't accept depth as a coordinate. It performs affine transformations to give the illusion of depth (sometimes the illusion falls apart, because it is just an illusion).

This isn't a matter about opinions. It is a literal fact that the GPU does not take depth into account.

>>2514667
>The output on screen is a 2D projection of a 3D environment
That happens at the end, but the environment ISN'T fully 3D to begin with. The textures are merely 2D affine transformed texels.
>"true 3D" means absolutely nothing. It's a buzzword
Did you pass maths class? 3D requires width, height AND depth. Depth isn't some kind of imaginary concept.
>it limits 3D imagery to hardware accelerated polygonal textured rasterizing
Not necessarily. It's just that the perspective divide used to be too expensive for the CPU alone. Quake in software mode produces proper 3D environments and characters. That's why it required a Pentium.

>>2514691
>The GPU doesn't accept depth as a coordinate
Neither does a CGA, EGA or VGA GPU. Again, were these games 3D?

>the environment ISN'T fully 3D to begin with
If it wasn't 3D, you couldn't do a projection.

>The textures are merely 2D affine transformed texels
Affine transform is a suitable approximation of a perspective correct transform for a wide range of projection angles, and takes far less resources to compute.

>3D requires width, height AND depth
They're all found in the world models of these games.

>perspective divide
Please don't tell me you hinge your definition of "true 3D" on the perspective transform method used for textures.

>>2514706
>Neither does a CGA, EGA or VGA GPU. Again, were these games 3D?
You can't be this ignorant. Holy shit.

>If it wasn't 3D, you couldn't do a projection.
You don't need a Z coordinate to do affine projection. This is basic matrices, son.

>Affine transform is a suitable approximation of a perspective correct transform
Yeah...which falls apart when the transformed coordinates aren't perpendicular to the viewing frustum

>They're all found in the world models of these games.
No, they're not. The meshes for characters on consoles without a z-buffer (like the PS1) don't provide full depth information. The depth is derived from a polygon sorting algorithm.

>Please don't tell me you hinge your definition of "true 3D" on the perspective transform method used for textures.
If you take shortcuts on things like depth, it's not *true* 3D, but I won't go so far to say that it's *not* 3D either. Lack of 3D texture transform is the obvious shortcut, but some would argue that a system without a z-buffer isn't true 3D either, since there is no inherent depth being derived, only an algorithmic drawing order of polygons (or more commonly, groups of polygons).

>>2514691
Descent was released 2 years before Quake, used no affine transform for its textures and ran on a 486 just fine.

The Pentium had instructions that the 386/486 lacked though, and if a binary was targeting the Pentium processor, it would not work on a 486, even if the power was sufficient. In fact, the slowest first gen Pentiums were slower than the fastest late 486.


I think it's interesting that you're saying a game running entirely in CPU rendering, with no support from the GPU at all (Quake) is "true 3D", while a system with dedicated (albeit crude) support for 3D operations is not.

>>2514745
>You don't need a Z coordinate to do affine projection
I'm not talking about texture projection either. This is world transform and screenspace projection.

>Yeah...which falls apart when
Welcome to the world of real-time 3D

>The meshes for characters on consoles without a z-buffer (like the PS1) don't provide full depth information
The meshes are 3D. The z-buffer is a helper data structure during rendering. It's not necessary.

>The depth is derived from a polygon sorting algorithm.
wrong way round. Polygon sorting requires depth information to be present in the data structures.

>If you take shortcuts on things like depth
It's texture projection. That's long after world update and screen space transform. The memory model of these games is fully 3D.

>Lack of 3D texture transform is the obvious shortcut
You are saying that any texture-less polygonal shader is not true 3D. Might want to think about that some more.

>a system without a z-buffer isn't true 3D either
A z-buffer makes some rendering aspects easier, but it's not necessary to produce reasonable output.

>there is no inherent depth being derived
The Z-buffer is a support structure containing the depth of a pixel. It is computed FROM the original 3D data during screen space transform. It helps to determine occlusion on a pixel level, but it's not necessary for 3D rendering. A BSP, for example, works just fine without any Z-buffer at all. It has its own drawbacks (massive overdraw and static geometry), but that does not make it any less of a 3D mechanism.

>only an algorithmic drawing order of polygons
determined through 3D world space coordinates. No true 3D, my ass.

>>2514746
There's nothing stopping any CPU being capable of doing a perspective divide, except a lack of processing power. The reason Quake required a Pentium is because it is geometrically far more complex than Descent, and twin integer pipeline of the Pentium allows it to do perspective divides simultaneously with interpolation, so there is no penalty for attempting perspective correction.

On a 486, or older processor, there is a speed penalty. One divide per pixel.

>while a system with dedicated (albeit crude) support for 3D operations is not.
The PS1's GTE is fixed hardware, unlike a CPU it is not fully programmable. Rendering for pseudo 3D is fixed into its hardware. There is literally nothing a developer can do to overcome this, except to try and make it up with the R3000A, which is like a low-end 486SX.

>>2514764
>The reason Quake required a Pentium is (...) twin integer pipeline of the Pentium
So, instructions missing from the 386 instruction set.

>Rendering for pseudo 3D
I made my point. You can believe whatever you want, readers of the thread can form their own opinion.

>>2509014
>>2508964

So was Capcom trying to emulate nintendo or something? MMBN is Pokemon, Legends is Mario 64

>>2514759
>This is world transform and screenspace projection.
I don't exactly get your point. Things eventually get projected for a 2D framebuffer, so that means that depth is unimportant?

>wrong way round. Polygon sorting requires depth information to be present in the data structures.
I said that it did include a certain amount of depth information, but suitable for polygon sorting, not for z-buffer.

>You are saying that any texture-less polygonal shader is not true 3D
I'm not. If you go texture-less, then you are producing true 3D. Just, very primitive true 3D. But according to a stricter definition, it could also depend if you are using a z-buffer. Polygon sorting algorithms are usually fairly easy to break (drawing polygons in the wrong order kind of destroys the illusion of 3D), while sorting by pixel depth is reliable.

>A z-buffer makes some rendering aspects easier, but it's not necessary to produce reasonable output.
I agree. Sometimes a z-buffer is overkill. But it's useful if you absolutely must have perfect 3D depth.

>determined through 3D world space coordinates. No true 3D, my ass.
Well if you overdraw like crazy with painter's algorithm, you can get it right. But as you say, welcome to the world of real-time 3D, you want to eliminate as much overdraw as possible. So instead on PS1 you use cheaper and faster sorting algorithms that easily break. It's not hard to make Crash Bandicoot get drawn over a wall he's supposed to be standing behind. That doesn't sound like true 3D to me.

>early 3D
>good aesthetics

Pick 1

>>2514792
>this physics engine isn't quantum accurate
>therefore it's not a physics engine at all

>>2514804
More like
>this physics engine rounds off floating point numbers into integers so save processing power, so it occasionally results in inaccurate data, but it's good enough for this experiment right guys?

>>2514792
>I don't exactly get your point. Things eventually get projected for a 2D framebuffer, so that means that depth is unimportant?
You can not project correctly if your input data is not 3D to begin with. Depth is crucial there. Depth of the world and the models. The z-buffer is but a tool, and not a necessary one.

>not for z-buffer
The z-buffer is one of the outputs of the screen projections. It's fed with the 3D world data. The 3D positioning of the world data is all the data you get.

>But according to a stricter definition, it could also depend if you are using a z-buffer
That'd be entirely your definition. Go fire up Need For Speed: High Stakes. Be sure to use D3D hardware acceleration. Then go into the graphics options and enable/disable the Z-buffer. You will see no difference in rendering for the world and the cars. You will see differences for smoke and the headlights, that is all.

>perfect 3D depth
I have no idea why you're so obsessed with depth information of the pixels, which is merely derived from the world data. It's just intermediate helper data, to make some algorithms easier. None of this ever reaches the framebuffer.

>Well if you overdraw like crazy with painter's algorithm, you can get it right. But as you say, welcome to the world of real-time 3D, you want to eliminate as much overdraw as possible
Wait, so that's true 3D but isn't?

>while sorting by pixel depth is reliable
Z-fighting and resolution limits of the z-buffer say "no"

>That doesn't sound like true 3D to me.
It's just a glitch in the rendering process, nothing wrong with the involved approximations. You will find plenty of those even in the most modern engines. They just look a bit different (objects intersecting because of shoddy collision detection isn't actually matching reality well either)

>>2514809
>but it's good enough for this experiment right guys
Yes, it very much is. Next you're telling me deferred shading isn't "true 3D" either.
Real-time 3D is all about approximations. Even present day real-time 3D has heaps and heaps of those. Just because their glitches and failures are less visible, doesn't mean they aren't there.

>>2514796
That's not mutually exclusive at all.

>>2509478
We all know that anon, the point is to state how advanced arcades were back then compared to consoles.

>>2514814
>You can not project correctly if your input data is not 3D to begin with. Depth is crucial there. Depth of the world and the models. The z-buffer is but a tool, and not a necessary one.
GTE projects in 3D, but the necessary depth data that could allow GPU to project textures with perspective is discarded, because GPU is fixed into not accepting depth parameters. The texture unit in the GPU is not 3D, period.

>That'd be entirely your definition.
I don't feel strongly enough about the z-buffer to say whether it makes or breaks *true* 3D. But z-buffer was invented in order to take away the responsibility of polygon sorting away from potentially flawed algorithms.

>Wait, so that's true 3D but isn't?
I think the issue of whether texture mapping is 2D or 3D is fairly clear cut at the algorithmic stage, but it's not so with polygon sorting. That's why I am unwilling to get behind the z-buffer as a requirement for *true* 3D, so instead my benchmark is merely the output result.

It doesn't matter what polygon sorting algorithm you use, if the polygons don't get GROSSLY sorted in the wrong order (e.g. if it's just the occasional misplaced joint) it's true 3D. If it's blatant and flagrant (entire meshes drawn in the wrong order), then it's pseudo 3D.

>Z-fighting and resolution limits of the z-buffer say "no"
Z-fighting is basically polygon missorts but with the damage contained only to a few pixels instead of entire polygons (or more commonly entire GROUPS of polygons). See my above argument. Also, it's difficult to improve polygon sorting algorithms without just throwing huge swaths of system power at the problem. It's much more elegant to simply increase the resolution of the z-buffer to reduce errors.

>>2514831
>GTE projects in 3D
This is what people commonly refer to as (polygonal) 3D graphics

>the necessary depth data
It's a nice bonus, not more. Rasterizers work just fine with screen data.

>that could allow GPU to project textures with perspective
affine transform is a reasonable approximation

>The texture unit in the GPU is not 3D, period
affine transform is a reasonable approximation. The texture projection does not make or break a 3D projected game.

>z-buffer was invented in order to take away the responsibility of polygon sorting away from potentially flawed algorithms.
The algorithms are fine and work on a polygon level. z-buffering has been done to avoid doing any (or much) upfront sorting on that level. It's not a requirement, but simply a support structure to enable different rendering algorithms. Z-buffering is not the end-all of precision either, as already pointed out.

>I think the issue of whether texture mapping is 2D or 3D is fairly clear cut at the algorithmic stage
To you. Few people would brush off affine transform, and these are not even the only two options to draw textures. And you don't even need to use textured polygons (see pic).

>so instead my benchmark is merely the output result
apparently not, since you reject PS output based exclusively on the texturing stage, discarding the entire world transform and underlying memory model.

>If it's blatant and flagrant (entire meshes drawn in the wrong order), then it's pseudo 3D
You'll be happy to hear that OutRun 2006: Coast 2 Coast is "pseudo 3D", despite using D3D and accelerated hardware.

>Z-fighting is basically polygon missorts
Z-fighting is a z-buffer artifact. So I guess that "depth information" you require so much can fail, and fail hard.

>simply increase the resolution of the z-buffer
Yeah, no. The workarounds to deal with z-buffer limits are plenty. Increasing the values in the z-buffer only delays the problem.
In the meantime, have a "no true 3D" game for the thread.

>>2514853
Come on, post better pics.

>>2514859
The game was limited to 640x480 or 512x384 back then. The textures on the few polygonal models were not bilinear filtered and the voxel landscape was not approximated using a polygon mesh.

>>2514853
>affine transform is a reasonable approximation
>a reasonable approximation
>It's a nice bonus, not more
Pic related.

>The texture projection does not make or break a 3D projected game.
Sure it doesn't. But it certainly does mean a texture hasn't been projected with ANY depth at an algorithmic level (making it...not 3D).

>Few people would brush off affine transform
So why isn't it being used anymore? Surely by this logic our latest AAA blockbusters would run a lot faster if they simply ditched texture perspective?

>despite using D3D and accelerated hardware.
This doesn't guarantee a game will be using perspective correction, or even use a z-buffer.

>Z-fighting is a z-buffer artifact
No, z-fighting is a type of (pixel) sorting error, and it's a minor one compared to polygon sorting errors (projected polygons comprise of a large number of pixels).

Most of your arguments can really boil down to the following
>PS1 is the absolute apex of 3D graphics, damn those idiots for trying to fix what wasn't broken

>>2514874
>hasn't been projected with ANY depth at an algorithmic level
Because it's not necessary for a reasonable approximation

>(making it...not 3D)
So, you ARE hinging the whole thing exclusively on the texture mapping, disregarding the entire surrounding game.

>This doesn't guarantee a game will be using perspective correction, or even use a z-buffer.
And it's not "true 3D" according to your definition, although its entire memory model is, all meshes are, and hardware T&L is in full force.

>it's a minor one compared to polygon sorting errors
I'll take a stray polygon in a scene over flickering pixels any day, thanks

>PS1 is the absolute apex of 3D graphics, damn those idiots for trying to fix what wasn't broken
The fuck? Never seen someone strawmanning so hard. The PS is the bare minimum and its hardware could do less than what even software rendered DOS games did at the time. The sole issue is that you went around claiming "it's not true 3D", based on the texture transform stage only, which happens to use a very common mechanism for texture rasterizing at the time.
THAT is what I challenged you on. You take games like wipEout or Metal Gear Solid, and claim that for some twisted reasons these worlds presented in them are not 3D models, that the collision detection in there is not based on a memory 3D model of the world, and that it's all just a big illusion and a 2D game just looking the part, because you seem some textures wobble.
You're entirely on your own with that viewpoint.

>>2514874
It's funny that, according to you, this image flips between a "true 3D" game and "not a true 3D" game, despite the entire world and memory model being identical

>>2514895
better even, if you were to take the image with affine transforms, strip all its textures, it's suddently "true 3D" again.

>>2514893
>Because it's not necessary for a reasonable approximation
Only if reasonable approximation = affine projection. Which is a little laughable, I'm sorry my friend.

>So, you ARE hinging the whole thing exclusively on the texture mapping
Well the whole point was that the PS1 GPU wasn't 3D. The claim was never made about GTE. Also there is still the whole polygon sorting thing, but as explained above, I do accept that it is somewhat subjective.

>hardware T&L is in full force.
GTE is hardware accelerated T&L. What is known as "hardware accelerated" and "software accelerated" is really down to programmability. Fixed units being "hardware" and programmable units being "software". These days the lines are a little blurred with programmable shaders, but that's what it is.

PS1 has hardware accelerated 3D T&L and hardware accelerated 2D affine projection texturing. Ergo, the hardware acceleration itself does not comment on the capabilities (or utility) of the hardware. Matrox Mystique was a hardware accelerated 3D card in 1996, but was incapable of texturing filtering for example.

>I'll take a stray polygon in a scene over flickering pixels any day, thanks
If pixels can flicker, so can whole polygons.

>claiming "it's not true 3D", based on the texture transform stage only, which happens to use a very common mechanism for texture rasterizing at the time.
So? There wasn't a lot of true 3D around at that time. I really like the PS1 hardware, but let's call a spade a spade.

>claim that for some twisted reasons these worlds presented in them are not 3D models, that the collision detection in there is not based on a memory 3D model of the world, and that it's all just a big illusion and a 2D game just looking the part, because you seem some textures wobble.
The games ARE *mostly* 3D anon. But 3D is a sum of parts, and the PS1 presents a set that are mostly if not entirely 3D.

>>2514914
>Well the whole point was that the PS1 GPU wasn't 3D. The claim was never made about GTE
The claim was about the system as a whole
>>2514503
>the PS1 wasn't even true 3D.

>What is known as "hardware accelerated" and "software accelerated" is really down to programmability
No, it just means that certain computations are performed via logic gates in the hardware, or via a sequence of instructions in software.

>PS1 has hardware accelerated 3D T&L and hardware accelerated 2D affine projection texturing. Ergo, the hardware acceleration itself does not comment on the capabilities (or utility) of the hardware. Matrox Mystique was a hardware accelerated 3D card in 1996, but was incapable of texturing filtering for example.
It's almost as if your arbitrary distinction regarding texture projection means fuckall for a rendering pipeline relying on 3 dimensional world data.

>If pixels can flicker, so can whole polygons.
z-fighting happens due to rounding errors in the z-buffer, which can happen for the entire duration that a set of polygons is visible. Especially slow movement will make z-fighting go crazy, because the rounding errors differ every frame and every pixel. Mis-ordering happens usually during edge cases, which disappear a frame or two later, or stay consistently for several frames. So you either have a polygon blinking briefly, or staying missorted while visible.

>But 3D is a sum of parts
Oh, it's a pretty small sum. All you need is 3D game data and a projection. The exactness of either mechanism doesn't even enter the picture, except in your definition, where it matters entirely for texture transform, but is irrelevant for screen space projection, or non-polygonal objects.

>>2509580
Shit nobody? read through the thread but damn.

They did re-release JSR on steam with better textures and HD but not JSRF for some reason

>>2514928
>The claim was about the system as a whole
Yes, but only because one component in particular wasn't 3D. It's like saying "that person has a disability" because he's blind, but wait a second, how can he be disabled if he can still walk?

>It's almost as if your arbitrary distinction regarding texture projection means fuckall for a rendering pipeline relying on 3 dimensional world data.
Those polygons have to be filled with something. It's like you think the fill of those transformed polygons is unimportant for 3D. Everything else, it's important that it's 3D, but when it comes to filling those polygons, who gives a fuck right?

>Especially slow movement will make z-fighting go crazy, because the rounding errors differ every frame and every pixel. Mis-ordering happens usually during edge cases, which disappear a frame or two later, or stay consistently for several frames. So you either have a polygon blinking briefly, or staying missorted while visible.
Hey, guess what. The exact same thing happens with most polygon sorting algorithms. Z-buffer and polygon sorting algorithms tend to work in a similar way, except z-buffer is far higher resolution because it works with pixels.

>The exactness of either mechanism doesn't even enter the picture, except in your definition, where it matters entirely for texture transform
it seems that in your definition, texture mapping is exempt from the requirement of having depth information to be considered 3D, an exemption that by your admission wouldn't fly in any other part of the rendering pipeline.

>>2514945
>one component in particular wasn't 3D
That's exclusively you, really. You could buy 3D acclerators that did affine transform. It's not as huge as a deal as you make it out to be.

>when it comes to filling those polygons, who gives a fuck right?
Affine transform is a pretty good approximation, enough that players all around the world recognized the imagery produced by the playstation to be 3 dimensional. What's much more game breaking is when the world data is not 3D (doom is a famously quoted example), or the screen space projection has severe limits (see all raycasters). Note that both are still 3D games, just using different approximations.

>Z-buffer and polygon sorting algorithms tend to work in a similar way, except z-buffer is far higher resolution because it works with pixels.
Different number of data points is key here. Polygon sorting can fail at one point only, and once per frame. Z-fighting can go all over the place.

>texture mapping is exempt from the requirement of having depth information to be considered 3D
Indeed, it is. The pixel shading stage happens in 2D. Auxillary data is welcome but not necessary.

On old rasterizers (including perspective correct 3D accelerators) you lose all 3D information at the fill stage. Each vertex has associated UV coordinates. After screen projection the transformed vertexes produce a screenspace triangle, with each screenspace vertex mapped to a UV coordinate still. That screen output is, simplified, a distorted triangle. The goal of the rasterizer is to map that distorted triangle to the texture. It can do so in several ways. A very simple way is affine transform. It manages to reproduce the distortion exactly, but misses the shortening typical for perspective. You can, however, assume a perspective transform to produce that distortion and still don't need any 3D info at all for that. Pic related. It's a perspective correct distortion of a grid, without any 3D information.

>>2511162

Pretty much the Launch Title VS. a latter-gen title made by arguably the second-strongest wizards to program for the console. Yeah, it will make SM64 look worse. I still prefer SM64 though.

>>2514954
>You could buy 3D acclerators that did affine transform
Errr...which products marketed as 3D accelerators could only do affine transform? I can't think of any.

>Doom
>still 3D
That's it. I'm out. You are willing to accept any compromise as 3D. Go make love to a Galaxy Force II arcade machine.

> Polygon sorting can fail at one point only, and once per frame
Errr...it can fail in more than one place in the frame, but only once per sorted group, yes. But that's not really much of an argument, considering a failed polysort is almost always going to affect larger percentage of framebuffer pixels than a group of z-fighting pixels.

>On old rasterizers (including perspective correct 3D accelerators) you lose all 3D information at the fill stage
Not necessarily, the N64's RDP for instance retains depth information for the anti-aliasing blending algorithm which occurs towards the end of the fill stage.

>>2514965
>But that's not really much of an argument, considering a failed polysort is almost always going to affect larger percentage of framebuffer pixels than a group of z-fighting pixels.
That is precisely the argument. If a group as a whole fails, you may recognize the order is wrong, but that's it, the image looks stable. Z-fighting meanwhile will cause all the affected pixels to go nuts, very noticable and jarring. A big but steady error is less disruptive than small but twitchy errors.

>Not necessarily, the N64's RDP for instance retains depth information for the anti-aliasing blending algorithm which occurs towards the end of the fill stage.
Put those goalposts back, you might hurt someone. Unless of course you meant to say that the N64's texture rasterizer does perspective correct transform without using that depth information. Then thanks for making my point.

Otherfag here. I personally don't even care what's "real" 3D or not. And I don't even care about textures at all. Gonna go terminate some shit now...

>>2514990
Got to love it when they make the interface huge just to reduce the size of the 3D viewport to make the whole thing run reasonably well.

>>2514990
really nice use of dithering there

>>2514970
>A big but steady error is less disruptive than small but twitchy errors.
The size of the error for polysorts can also be much more serious. Z-fighting only occurs between two surfaces with indiscriminately similar depth values, while polysort errors can even occur between two surfaces that should be distant in the scene. That's a gross visual error. Furthermore, which do you think is going to be more harmful for gameplay? A few flickering pixels, or not knowing truly how close that enemy is?

>Put those goalposts back, you might hurt someone. Unless of course you meant to say that the N64's texture rasterizer does perspective correct transform without using that depth information. Then thanks for making my point.
What are you on about? My point was that the depth information IS retained at the fill stage. It's retained for perspective correction, and it can be retained for other things.

Also that grid you posted, I did a reverse image search and found the source code.

http://www.reedbeta.com/blog/2012/05/26/quadrilateral-interpolation-part-1/

It very much uses 3D information, thank you.

o_rgba = g_texColor.Sample(g_ss, uvq.xy / uvq.z);

>>2515003
>That's a gross visual error
But a consistent one, unlike z-fighting.

>It very much uses 3D information, thank you.
now read some more where q comes from and what it is.
Next up, try to replicate the concept with an arbitrarily shaped quad, on paper, using the diagonals to figure out the "center" and then recurse. You'll notice that none of this algorithm involves 3D data, since the only input data was the 2D warped quad.

>>2515015
You're confusing texture transform and vertex transform.

>>2515019
How so? Again, imagine vertex transform/screen transform already took place. What you have now is a distorted quad, like the one in the image. It has no depth information, just a shape on screen or framebuffer.

Put that quad on a piece of paper, no other data is given. Now try to cover it perspective-correct with a grid.
You first draw the diagonals in that quad, to determine the center point. You connect this center point with the edges, by lerping the position. The result is a group of 2x2 quads. Repeat the process as often as you feel necessary. The result is a grid-covered quad, perspective correct covered. If the vertices of that quad had UVs, you could use that as an input raster for a texture lookup, to produce a perspective correct textured quad. At no point in this process was depth information queried.
That was my point. Perspective correct transform does not require depth information.

>>2510424
I had never gotten past the Minotaur on vagrant story (I think I had a demo disc)

Definitely a top 10 game. Its a thinking mans game, although the combat system would make you assume its a pseudo-action RPG, its very much a tactical survival RPG.

It also looks fantastic, the artstyle is unique, and although I never really cared for Ashley's design, I feel it works really well.

>>2515027
That's by the way a similar mechanism to what Photoshop or Gimp use for perspective distortion. Programs that operate entirely on 2D data.

>>2515027
>>2515031
In that case it's just the old constant-z trick with its swath of practical limitations. Just face it, if there was a way around the depth issue you wouldn't have warping textures in every PS1 game.

>>2515057
>constant-z trick
The what now?

The textures warp in every game because the PS has hardware support for affine transform, which has that side effect, and perspectice correct transform on the CPU is too expensive.
That does not change the fact that perspective correct transform does not require depth data, and that the fill stage usually does not use depth data.

>>2515061
>That does not change the fact that perspective correct transform does not require depth data
Only true if depth is constant (e.g. Doom). If you disagree, I'd like to see the algorithm.

>>2515078
I gave you a verbal description of perspective correct mapping without depth data in >>2515027 and a relevant drawing of the process in >>2514954

Doom has no constant depth. Raycasting works by tracking the distance of polygon edges to the camera, and scaling the resulting wall down vertically accordingly. What Doom is lacking is elevation, or better, it's encoded in a way that makes the level data and world interaction largely two dimensional.

>>2515081
What you described was actually affine mapping. Furthermore, there is a contradiction in what you say. If depth is unnecessary for perspective correction, then why would the PS1 CPU have to do it instead of the GPU? After all, it sounds like the input parameters are no different than affine mapping...

Not to mention the most expensive operation for perspective correction is the divide by depth. But if you have no depth, that's not necessary. So why couldn't the CPU just do it?

>>2515096
>What you described was actually affine mapping
Affine mapping is a matrix transform. I wouldn't have to go through all this recursive junk to get there.

>then why would the PS1 CPU have to do it instead of the GPU?
GPUs are single purpose processors with a limited instruction set tailored to a specific task. In the case of the PS, that GPU can do affine transform, because it's useful for 3D (texture mapping) and 2D (sprite rotation, shearing). These functions are implemented in hardware, which makes them cheap and fast. The algorithm for perspective correct transform is not implemented in that hardware, and the instruction set of the GPU is insufficient to emulate it in software. Likely it was not implemented because it makes the die too big and too expensive.
In theory you could drop in a GPU with perspective correct transformations and get all the right results. However, since the affine transform stuff is generic (i.e. 2D and 3D games use it), the games simply lack instructions to make any calls distinguishing between "I need this affine transform" and "I need this perspective corrected", so such a replacement is not possible without adjusting the programs for it.

>>2515096
>the most expensive operation for perspective correction is the divide by depth. But if you have no depth, that's not necessary. So why couldn't the CPU just do it?
Divide is in general one of the most expensive CPU instructions, in terms of cycles, and die size, which is one of the motivations why the GBA lacks a hardware div instruction.
As you could see in the article you mentioned, A division (not by depth) is necessary for perspective correct mapping).
As you also pointed out, the PS CPU is rather weak. In particular it's too weak to perform the 3D operations. That's why it had additional hardware for that stuff to begin with, so it could focus on the general game loop. As such, offloading 3D work onto the CPU is not an option on the PS. It has been done many times in DOS games, where the CPU is doing all the work anyway (before 3D accelerators were a thing), and the difference between affine transform and perspective correct transform is not as stark.

>>2515108
>I wouldn't have to go through all this recursive junk to get there.
So what was the whole point?

>>2515115
To prove that perspective correct mapping requires no depth information.

>>2515118
But it's not a practical method. Or is this just one of those things to prove a point, like my recursive painter algorithm overdraw example much earlier?

>>2515123
The practical methods don't use depth either. It provides no useful data at that stage. Perspective correct transform is just a different way to distort the triangle of UV coordinates.

>>2515125
>The practical methods don't use depth either
Every method I know divides by z (depth). What are you on about?

>>2515129
The shader method you found in the article is based on the distance to the center point

>>2515131
Somehow I doubt the true accuracy of this method, considering it is per vertex, instead of per pixel as perspective correction normally is.

>>2515138
>true accuracy
If it looks right, it's good enough. That's the whole point of real-time 3D. Then again, it's not your approved and certified perspective correct transform, so it can't be true 3D. In fact, no 3D engine in this world, except a polygonal perspective correct textured rasterizer is probably "true 3D". You rule out impostors, voxels, non-polygonal primitives, raycasters, raytracers and a billion other implementations as not "true 3D". I'm glad devs are not this narrow-minded, and actually come up with these engines, and even modifications like normal mapping, parallax mapping and all the other "not true 3D" enhancements, that may not fit your definition, but they look pretty darn nice.

>considering it is per vertex, instead of per pixel as perspective correction normally is
What you describe as "normal" perspective correction maintains depth only per vertex and then linearly interpolates it in the pixel shader, just like the method from the article maintains q per vertex, then linearly interpolates it in the pixel shader.

>>2515151
>You rule out impostors, voxels, non-polygonal primitives, raycasters, raytracers and a billion other implementations as not "true 3D".
I work with CAD, so perhaps I have a stricter definition of what is true and accurate 3D. Most of the techniques you describe have severe limitations, and are not malleable flexible 3D

Ultimately 3D is about perspective. Things like normal mapping, etc don't mess with it. Affine mapping does.

>What you describe as "normal" perspective correction maintains depth only per vertex and then linearly interpolates it in the pixel shader,
That's not classic perspective correction.

This thread reminds me of the countless times I've argued that "not true 3D" crap, with people acting like they were fisting their eyes for how "bad" and "wrong" affine transformation looked. Except now my side was taken by a competent anon with shittons of patience trying to dissect everlasting arguments which were eventually, as expected, a mix of elusive double standards, goal post moving and no true scotsmans.

All of this because we wanted a thread about simplistic 3D graphics.

>>2515154
>so perhaps I have a stricter definition of what is true and accurate 3D
Indeed you do. That level of accuracy is entirely irrelevant in games.

>Most of the techniques you describe have severe limitations, and are not malleable flexible 3D
And yet, they're exact enough that people understood the virtual worlds presented in them, navigated them successfully using their mental (3D) map of these locations, made predictions on character placement. All things that wouldn't work if the representation was too far off.

>Ultimately 3D is about perspective. Things like normal mapping, etc don't mess with it. Affine mapping does.
Please tell me you're joking. You have a perfectly flat and even polygon. Then you apply normal mapping and it suggests a surface that is not there. That is the very definition of inaccurate perspective. It's desired in this case, because the polygonal model is insufficient to portray the desired model. The normal mapping "fixes" the mistakes introduced by a low resolution polygonal model. The very core concept behind normal mapping is MESSING WITH the actual correctly rendered object.

Affine mapping just lacks precision, which makes the rendered result deviate from the memory model. However the deviations are controlled and predictable as well.

>That's not classic perspective correction.
Might want to elaborate then. Polygons are generally assumed to be perfectly flat. As such, it's sufficient to figure the depth of the vertices, since a linear interpolation of these values will match the exact positions of the pixels in space.
Note that even in the most modern pixel shader pipelines you act on the screen space transformed vertices and lerped values between them. That's normal and fairly accurate behavior. This of course only applies to tris and similar realtime primitives. In CAD you often work with more complex primitives, where lerping does not hold and you probably have to mess with things per pixel.

>>2515161
For you. While not a "clever aesthetic design" and hence not entirely on topic, to me it's one of the most beautiful simple 3D games and still holds up exceptionally well.

>>2515161
>Except now my side was taken by a competent anon with shittons of patience trying to dissect everlasting arguments which were eventually, as expected, a mix of elusive double standards, goal post moving and no true scotsmans.

Yeah well, I'm on the other side and I still feel exactly the same way. Sure, there have been some interesting technicalities that have been brought up in this thread in alternative methods of deriving perspective correction, but nobody has been capable of defending actual affine mapping on visual grounds >>2514874

Except, of course, the nostalgia blinded.

>>2515167
during the onboard scenes you can see the other car models are a bit "jumpy" in their rotation. Anybody having an idea what's going on there? Seems a bit as if it clamps to specific angles, but I have no idea why or how.

>>2515167
Wait, what did I say? I think all 3D games look good and I only find faults with the art style and presentation.

>>2515168
There is only one valid defense for affine mapping and that is performance. Affine transform is always simpler and faster than anything more correct. It also introduces plenty of visual artifacts, which are negative. You would use affine transform if you're on restricted hardware and know that you won't hit problematic angles, and that's it. It's indefensible beyond that. However, it still is a reasonable approximation for how the texture transforms, and on that same hardware your alternative is no texture at all.

>>2515174
You said
>All of this because we wanted a thread about simplistic 3D graphics.
So, for you, I tried to bring it back a little on track. However, the "clever aesthetic" thing to me implies stuff like Grim Fandango or Psychonauts. Games that don't try to be realistic but instead try to be beautiful. Meanwhile Indy 500 is aiming hard for realism, just in a modest way. So, it's not really "clever aesthetic", just a damn pretty game.

>>2515180
Oh okay, sorry I misunderstood. I never had the chance to boot I500, but I played lots of Stunts and GP2 to make up for it.

>>2515168
I don't think visual grounds matter here though, only perception of 3D. And no, slightly distorted textures don't wake my suspension of disbelief, mainly because I put a lot of my own when I'm looking at a 3D world to overcome technical limits. I just can't stand people making a big fuss of all of this.

>>2515162
>That level of accuracy is entirely irrelevant in games.
The key words is *that level*. Accuracy is still important in games, however. We can see by the trends of the industry that image quality has won over speed. People are entitled to their opinions about aesthetics, but I still stand by affine mapping not being true 3D on technical grounds AND aesthetic grounds (pseudo 3D at best). In fact, you are the only somewhat technically knowledgeable person I have ever talked to that has argued otherwise.

>And yet, they're exact enough that people understood the virtual worlds presented in them, navigated them successfully using their mental (3D) map of these locations, made predictions on character placement. All things that wouldn't work if the representation was too far off.
Just because Elite made people feel engrossed in space doesn't mean that we couldn't progress to the graphics in Freespace.

> The very core concept behind normal mapping is MESSING WITH the actual correctly rendered object.
But they only mess with the perceived depth of the image, not distort the entire entity. If you take your argument about perception vs reality to the extreme, it essentially becomes epistemological, which is ridiculous in this context. Affine mapping is likely to cause Escheresque distortion. Normal mapping won't.

>Affine mapping just lacks precision, which makes the rendered result deviate from the memory model. However the deviations are controlled and predictable as well.
But it was impossible on PS1 hardware (remember, the actual subject of our discussion) to get these issues under control. With sufficient bruteforce you can fix everything, but that's not practical for PS1.

>Note that even in the most modern pixel shader pipelines you act on the screen space transformed vertices and lerped values between them
Classic perspective correction does not involve a pixel shader.

>>2515189
>Just because Elite made people feel engrossed in space doesn't mean that we couldn't progress to the graphics in Freespace.
Maybe there's a falso dichotomy at play here. I never suggested we should not improve beyond affine transform. I only insisted that 3D polygonal objects 2D projected and textured (optional) are 3D, in visuals and memory model, even if the rendering is inaccurate.
A game like Elite is not any less 3D than Freespace is. Doesn't mean Freespace is not more sophisticated.

>But it was impossible on PS1 hardware (remember, the actual subject of our discussion) to get these issues under control
You're the only one that argues they must be under control in order to be a 3D projection.

>Classic perspective correction does not involve a pixel shader.
A pixelshader is just a special purpose processor. Fixed shader pipelines (old accelerators) performed the same computations, and in software the same computations are performed sequentially.

>>2515198
>>2515198
>You're the only one that argues they must be under control in order to be a 3D projection.
For it to be a 3D *texture* projection.

>Fixed shader pipelines (old accelerators) performed the same computations, and in software the same computations are performed sequentially.
The newer GPUs are ridiculously more versatile than the old ones, and you can leverage this versatility with programmable fragment code.

>>2515230
>The newer GPUs are ridiculously more versatile than the old ones, and you can leverage this versatility with programmable fragment code.
No kidding. The subject was old perspective correct transform lerping the z values of the vertices, instead of computing them per pixel.
That you can do more than that in modern fragments is a no brainer. That you don't have to, as well.

>>2515235
Even if you lerp the values, you should still divide per pixel (or at the very least, by sets of pixels).

Namco does not get enough credit for early 3d games. Winning Run came out in 1988.
https://www.youtube.com/watch?v=VuwrbK35HQ8
https://www.youtube.com/watch?v=oepT_lR4-zY
https://www.youtube.com/watch?v=x6U3WhZrVHc

>>2515241
>Even if you lerp the values, you should still divide per pixel (or at the very least, by sets of pixels).
You lerp the per-vertex depth information. Then you divide by that lerped value

>>2515379
looks a bit sterile to me

>>2515414

>>2515418

BETTER RED THAN DEAD

>>2509295
>The Legends/DASH games use an absurd amount of camera/perspective-aware textures for eyes and mouths
>The game has no right looking as timeless as it does given the hardware it was designed for
>Those people knew their shit something fierce
So much this. Needs to be played in low resolution for the magic to work though.

>>2515420
Frank Burns eats worms

Hi, OP here,
First of all I'm sorry to those of you irked by the phrase "early 3D," I just didn't want to confine it to one generation necessarily and that's the term that came to mind. I guess I should have said "retro 3D". By all means if there are earlier examples utilizing wireframe or anything else, it's welcome (not that I have any authority in the matter). I was just impressed by a game I was playing...
>>2515180
>However, the "clever aesthetic" thing to me implies stuff like Grim Fandango or Psychonauts. Games that don't try to be realistic but instead try to be beautiful.

Just to clarify what I meant, if it matters: I suppose I was thinking of games with developers who, when presented with visual limitations, came up with viable ways to produce the illusion of the game looking "better". If a game used tricks to make its realism look "more convincing" I guess I meant that too. I don't know if that applies to Indy 500 or not.

>>2515951
All Indy has going for it, is that it produces a pretty recognizable version of the Speedway with a very low polygon count and dense starting grid, and that it plays like a sim from the mid 90s, despite being from the late 80s. It's one of my favorite retro racing games.

Magic Carpet absolutely belongs in this thread. Besides the game being miles ahead, visually, of everything else at its time, its texture work is just brilliant. The game maintains a very distinct drawn look. Take a look at the water in this screenshot. It has a subtle swirly pattern to it. It's details like that, that give it this fantastic timeless look.

Yes, that's real-time reflections, in 1995, a year before Quake. They move with the waves.

>>2515964
The game is from 1994, not 1995, just a year after Doom and the same year as Descent.