Emulating 5th and 6th generations appearances

[Anonymous No.3279570]

This might not be the correct board for this, and if it isn't I can delete the thread. I'm looking to emulate the appearance of n64- ps2 era graphics. I appreciate how you can tell the difference between ps1 and n64 games, and ps2 games and gamecube games for example. Each console had it's own visual charm. I want to understand the process that went into designing for each of these consoles so I can try and emulate some of the "looks" each console was known for. If anyone can point me in the right direction I would be grateful for that.

[Anonymous No.3279585]

[Anonymous No.3279590]

>>3279570
Uhm what

[Anonymous No.3279598]

>>3279590
I had trouble formulating my thoughts, I want to emulate the look of some of the older consoles in terms of making 3d graphics. know each consoles look was dependent on a lot of factors, and I was hoping some people could help explain some of it. (types of hardware, certain tricks or techniques used, etx.)

[Anonymous No.3279608]

>>3279598
I'd say go over to >>>/3/ but they're a bunch of unhelpful meme master faggots. Polycount is a useful site off the top of my head.

Point is, try posting on some 3d forums about this graphics look.

[Anonymous No.3279618]

>>3279608
The reason I came here is that I know a lot of what you see stylistically in older games, was a compromise between what was available on each machine. I figured this board would have that best insight on what i was looking for because they would understand these consoles much better than a 3d graphics forum would. I'll still give that a shot though.

[Anonymous No.3279628]

>>3279618
Oh well you can replicate the look of 5th and 6th gen game easily I'd think seeing as their not too old. What programs and methodology to do so I have no clue, but I'm sure someone does.

[Anonymous No.3279634]

>>3279570
From my non-technical point of view, Playstation 1 and 2 graphics were more jagged and pixelated, N64 and Gamecube graphics were smoother (moreso with the Cube) and blurrier (moreso with the N64). If you want to make an "early 3D" looking game, I would definitely try to recreate the 5th gen graphics, as 6th gen graphics don't really look that bad compared to today's stuff, just much lower resolution.

[Anonymous No.3279645]

>>3279570
>6th

Stop trying to sneak your not retro crap into my board you piece of inhuman dog shit.

[Anonymous No.3279668]

>>3279608
Building on this:

Polycount. Texture resolution. That'll get you about quite a bit of the way to replicating that look, but the time periods you listed have significant differences in both.

Are you looking for N64-tier graphics, or PS2-tier graphics? Pic related is some of the worst looking N64 graphics to some of the best looking PS2 graphics. There's a lot of room in between them.

[Anonymous No.3279674]

>>3279618
I feel like it shouldn't be too hard once you know what youre doing, but searching online has only given me results of emulating games, and shitty videogame journalism articles from kotaku. Nothing pertaining to any of the techniques or tricks that contributed to the iconic looks of popular games or console libraries.

>>3279634
My understanding is a lot of the differences between the ps1 and 64 came from the differences in the data medium they used. One think I know is while the 64 looked smoother, the carts had no room for textures which is why they all look stretched out in comparison to the ps1. I really want to understand all of this stuff so I have some insight when making my own stuff in past consoles images.

>>3279645
Im sorry I got you mad.

[jj No.3279678]

>>3279570
try using darkbasic

[Anonymous No.3279689]

>>3279570
This is a really technically complicated question that won't be appropriately answered on this board, or likely any board. You can't just lower polycounts or texture quality or whatever. You have to go for the full package which means using older techniques as well. If you don't, you'll end up with a game that has "basic" visuals yet still looks new like pic related. The reason for this is that when you use new techniques, such as newer or more technically demanding lighting, it completely warps the finished product to the point where it's unrecognizable as your original intention. You're gonna need to go balls deep here. Consult a tech forum for game devs and you might get better leads. It would be ideal if you used the same tools they used back in the day too because it makes it easier to put together and not mess up. Maybe even find old game devs online and just ask them outright. They love this stuff even if they're pretty well known.

[Anonymous No.3279695]

>>3279668
Thats probably something for me to consider. Each era has it's own looks I'm fond of. For the moment I think I will concentrate on n64 era graphics because low polygon modeling for a beginner will be easier for me to grasp.( I have some experience, I just am trying to tackle this from a practical standpoint.)

[Anonymous No.3279702]

>>3279689
I had the feeling this was more or less what would have to happen.. Thats why I've been trying to figure out the differences in game development between different past consoles. It's all fascinating to me, but I just can't find much information. Some of what youre saying to me is reminding me a bit of minecraft or something. That mix of old and new is interesting but it definitely isnt what im going for, so i appreciate that input.

[Anonymous No.3279732]

OP here, would it be worth my time learning how to rip 3d models from old games, and viewing those and studying them up close? Im thinking examining the textures up close and seeing how they used each polygon might give me an idea of where to go next.

[Anonymous No.3280237]

>>3279570
>you can tell the difference between ps1 and n64 games


what did you mean by that?

1- between (ps1 / n64) and (cube/ps2) ?

2- or between n64 and ps1?

if 2, i dint think you can, you might be thinking of rare and nintendo franchises and their more cartoonish looks, so its wasnt something that was technologically different from ps1, but perhaps the predominant style on the most popular games fits your definition of "the 3d look of n64".

[Anonymous No.3280245]

>>3280237
There's a pretty clear distinction between Playstation 1 graphics and N64 graphics. N64 has Z-buffering resulting in more stable 3D and built in anti-aliasing, but also suffers from lower texture resolution in many games due to cart size limitations. PS1 on the other hand tend to have a sharper, more pixelated appearance with higher res textures and visual artifacts like 'wobbling' and texture holes from the lack of true Z-buffering.

[Anonymous No.3280283]

Mise-en-scene

[Anonymous No.3280339]

>>3280245
This anon has the right idea.

Ps1 textures look like crap at certain angles due to no perspective correction. Look up affine texture mapping.

I might be wrong on this but the n64 had very blurry or even non existent looking textures (basically just colors) because of some oversight in the systems design where some sort of buffer related to the graphics was only 4096 bytes making it near impossible to have decent resolution textures while having a playable frame rate. Someone please fill in the details.

And yeah ps1 had no z buffer, again I'm shaky on the details but ps1 isn't true 3d rendering, is just a bunch of 2d triangles pasted on a flat canvas, that's why shit disappears and reappears when you're near walls and such.

[Anonymous No.3280434]

>>3279570
Make a low-poly model that represents the basic "concept" of what you want in as little polygons as possible, then add in details with textures. Make use of solid color polygons if you can.
When making characters or objects add shading manually to the textures to give them a bit more depth.

For a very good example take a look at Megaman Legends.

[Anonymous No.3280438]

>>3280245
The z-buffer is only part of the equation. The lack of it doesn't cause wobbling. Basically the PS1 lacks three things that the N64 has which is responsible for its janky looking graphics.

Z-buffer: Prevents polygons from being drawn in the wrong order along the z-axis (e.g. a character that is supposed to be behind a wall is drawn in front of it)

Sub-pixel correction: Prevents polygon animation from jittering

Perspective correct texture mapping: Prevents textures from distorting when viewed from non-parallel angles

>>3280339
> but the n64 had very blurry or even non existent looking textures (basically just colors)

I think the "non-existent" textures thing or colors (the technical term is 'gouraud shading' as you say, is really just a stereotypical view of early N64 games like Mario 64 that isn't actually true. Mario 64 isn't actually very heavy on gouraud shading. Most of the surfaces in the game are basically monochrome textures blended with vertex colors. That may look quite simple, but it's more than just gouraud shading.

I would say that Playstation games go much harder on gouraud shading than N64 games. But you are also right when you say that Playstation games tend to have higher resolution textures. So how does one explain this discrepancy?

It's due to the texturing architecture of both systems. The Playstation can pull larger textures "in one hit" straight from its VRAM but fewer of them due to a larger overhead of texturing from VRAM. The N64 can only texture from its texture cache, which is 4 KB in size, which means that is the maximum size per individual texture - but the texture cache is a fast access piece of memory, you can pull lots of separate textures from it. The Playstation has a texture cache too but it's smaller.

So on average you get N64 games that have medium-sized textures covering everything, while PS1 games usually show a few high resolution textures but gouraud shading makes up the rest.

[Anonymous No.3280709]

>>3280438
>Prevents polygons from being drawn in the wrong order along the z-axis
Or you could just sort your polygons and go painter algorithm on the whole thing, like all the software 3D engines in that decade before the PS was a thing. Meanwhile Z-buffers and laziness lead to "beautiful" Z-fighting.

[Anonymous No.3280752]

>>3280709
>Meanwhile Z-buffers and laziness lead to "beautiful" Z-fighting.

You can argue against z-buffer on performance grounds, but attempting to hold instances of z-fighting against it is very deeply misguided, given that z-buffer is more accurate than the alternatives (that's the whole point of it).

Painter's algorithm is deeply inefficient, which led to processing shortcuts being taken in retro hardware, and so, a high instance of errors. Errors in PA manifest as **all** pixels from facing triangles or groups of facing triangles mis-drawn, while z-fighting only results in individual pixels mis-drawn. Although a 16-bit z-buffer isn't perfect, I would argue that I see far more instances of mis-sorted polygons on PS1 than z-fighting on N64.

[Anonymous No.3280771]

>>3280752
>You can argue against z-buffer on performance grounds
how? z-buffers are purely performance boost. It's a text book example of trading memory consumption for processor usage

>z-buffer is more accurate than the alternatives
z-fighting is an artifact exclusive to z-buffers. What you call "more accurate" is misleading. The only "accuracy" you gain is for odd overlap situations, where BSP would split the polygons to begin with.

>Painter's algorithm is deeply inefficient
duh. But it works if you have fillrate

>which led to processing shortcuts being taken in retro hardware
like, culling? Because that's about what it boils down to. The "high instance of errors" you claim (which is practically non-existent on early 90s untextured vector engines) is a result of sloppy sorting because that shit's expensive.

>Errors in PA
PA is dead simple. you can at most screw up the sorting

>**all** pixels from facing triangles or groups of facing triangles mis-drawn
You sound like someone I had the displeasure of talking with before. The number of wrongly colored pixels is not a useful quality indicator. z-fighting stands out like a sore thumb because of its brutally flickering nature. Badly sorted polygons you got to be aware of, unless the errors were really sloppy.

>I would argue that I see far more instances of mis-sorted polygons on PS1 than z-fighting on N64.
That's because you're talking about consoles. An underpowered little toaster taking insane shortcuts to skip the expensive sorting, vs. an underpowered little toaster being so stingy with its polygon budget, devs need to avoid z-fighting out of habit, because it's too wasteful to have multiple polygons close together, you're better off making them a single surface. I'm, unlike you, not arguing for or against the z-buffer. It is not a black and white issue. All I said, and stand by, is that there are effective ways to deal with a lack of z-buffer. And they're proven effective, on hardware that's not the PS.

[Anonymous No.3280805]

>>3280771
>It's a text book example of trading memory consumption for processor usage

Memory consumption and bandwidth.

Of course, z-buffer is a performance boost if you are chasing accuracy end of things since trying to do splitting in every possible situation over thousands or millions of polygons would be insane.

>z-fighting is an artifact exclusive to z-buffers

Z-fighting is just the name given to a depth mis-sort on the pixel level as opposed to depth mis-sorts on the polygonal (or groups of) level.

>The only "accuracy" you gain is for odd overlap situations

Not so odd. Try a segment of animated tessellated waves, you'll get piercing and overlap like no tomorrow.

>which is practically non-existent on early 90s untextured vector engines

Most of these engines weren't throwing around a lot of polygons. Those that were (e.g. Sega Model 1) had the DSPs to handle it.

> a result of sloppy sorting because that shit's expensive

Exactly.

>PA is dead simple. you can at most screw up the sorting

Z-buffer even simpler, the only way you can screw up is not going more precise (or having co-planar polygons).

>z-fighting stands out like a sore thumb because of its brutally flickering nature

Only because the unit that is being sorted is smaller. Of course, a PA algorithm that attempts to sort between minute differences in depth between a back polygon that is penetrating a front polygon would also experience flickering. Just across the whole polygon, instead of individual pixels. I would bet that your PA vs z-buffer experiences are not comparing apples to apples in what is trying to be rendered.

>Badly sorted polygons you got to be aware of, unless the errors were really sloppy.

A polygon mis-sort is almost always a devastating error since it can fiddle hard with the user's depth perception (e.g. how far is that polygon). While z-buffer it is rare for more than 50% of pixels of a polygon to be z-fighting so the depth perception is not entirely destroyed.

[Anonymous No.3280807]

(cont)

>>3280771
>unlike you, not arguing for or against the z-buffer. It is not a black and white issue

I'm not arguing anything, my original post was just clarifying the purpose of z-buffer in N64 vs what the PS1 did.

It was your post injecting a completely separate argument / discussion into the thread based on your viewpoint.

[Anonymous No.3280819]

>>3280805
>is a performance boost if you are chasing accuracy
no if

>trying to do splitting in every possible situation over thousands or millions of polygons
situations that require splitting are VERY rare

>Z-fighting is just the name given to a depth mis-sort on the pixel level
odd phrasing for it, as there's no sorting involved.

>you'll get piercing and overlap like no tomorrow
sort them better

>Most of these engines weren't throwing around a lot of polygons
so you'd think the odd unsorted polygon would stand out like a sore thumb, and yet ...

>Z-buffer even simpler
not the fucking point, god-fucking-dammit. You are really pissing me off, shithead. It is not a fucking vs. debate.

>Only because the unit that is being sorted is smaller
and because it's changing every single frame

>a PA algorithm that attempts to sort between minute differences in depth between a back polygon that is penetrating a front polygon
If it's penetrating, your engine fucked up. You do not use penetrating polygons with PA

>I would bet that your PA vs z-buffer experiences are not comparing apples to apples in what is trying to be rendered.
I would bet it wouldn't fucking matter because I'm not arguing against the fucking buffer. Why can't you little shithead comprehend something so stupidly simple? It is not a debate. It is NOT a debate! Z-buffer is the only thing used for a reason. Nobody's denying that it's useful. Yet here you're fucking desperately arguing that a z-buffer is better than the technology it replaced. Well who the fuck would think otherwise? It is NOT a fucking, get it? NOT a fucking DEBATE.

[Anonymous No.3280824]

>>3280805
>>3280807
>A polygon mis-sort is almost always a devastating error since it can fiddle hard with the user's depth perception
You have no idea what you're talking about. I've seen so many sorting errors, or downright lack of sorting, because it's not worth it. The disruption is very difficult to notice, because in well designed engines it happens on a small scale and briefly. Otherwise it would be avoided to begin with.

>While z-buffer it is rare for more than 50% of pixels of a polygon to be z-fighting so the depth perception is not entirely destroyed.
Who the fuck gives a shit about depth perception? The fucking polygon is flickering like a bad pokemon episode. Depth perception is utterly secondary.

>It was your post injecting a completely separate argument
You tried to paint z-buffering as some panacea. It's a tool, just like you. And quite capable engines existed long before it. That's what's pissing me of. You're the same kind of shitster that would dismiss raycasting as a "2.5D" thing, or line scrollers as not being 3D, just because an engine doesn't tick off that one magical checkmark of a modern engine. You're showing something as being required that simply isn't required, and then throw around some bullshit technical "details" that are just deflections. It's par for the course with you assholes though. You never ever can see a statement made. No, you have to argue the corner cases just to win a fucking argument only you are having. Fucking tired of the likes of you.

[Anonymous No.3280838]

>>3280819
>no if

Low accuracy sort-by-mesh style PA stuff will be faster than z-buffer without a doubt.

>situations that require splitting are VERY rare

That's only because you'd be crazy to use PA in situations that involve splitting.

>odd phrasing for it, as there's no sorting involved.

Just for the point of clarity. It's sorting without storing.

>sort them better

With these kinds of performance demands, may as well invest in a higher depth z-buffer.

>You are really pissing me off, shithead. It is not a fucking vs. debate.

But you started one? You wrote above >Meanwhile Z-buffers and laziness lead to "beautiful" Z-fighting.

>so you'd think the odd unsorted polygon would stand out like a sore thumb

It would have also stood out like a sore thumb to the programmers, hence the work that would have gone into ensuring it didn't. By the time of PS1 I guess they were more willing to let it slide.

>and because it's changing every single frame

That would hardly unique to z-buffer in the example I provided. Does that even need to be said?

>Yet here you're fucking desperately arguing that a z-buffer is better than the technology it replaced. Well who the fuck would think otherwise? It is NOT a fucking, get it? NOT a fucking DEBATE.

You're going irrational here.

[Anonymous No.3280851]

>>3280838
>without a doubt
I doubt it

>It's sorting
nothing's being sorted

>may as well invest
not the point, retard

>But you started one?
no. Just pointed out that there was a life before your z-buffer, and that unlike your implied claim, it does not solve all problems the old implementations had. And yes, unlike you, I have good eyes, and consider z-fighting a jarring mess

>By the time of PS1 I guess they were more willing to let it slide.
not enough power on the PS to be exact. Got to work with what you're given

>That would hardly unique to z-buffer in the example I provided
it just so happens to be a z-buffer specific issue

[Anonymous No.3280863]

>>3280824
>The disruption is very difficult to notice, because in well designed engines it happens on a small scale and briefly

I don't think that's the experience most people get when playing PS1. It even pops its nasty head up in Crash Bandicoot 1 which I presume is a well designed engine (not so much the sequels).

>Who the fuck gives a shit about depth perception?

Well it's kind of important in video games since it relates to gameplay. I guess it doesn't matter as much if you're just rendering a cutscene.

>The fucking polygon is flickering like a bad pokemon episode

I guess the elephant in the room is that improving a PA algorithm in a game (to prevent polygon mis-sorts) without also dramatically increasing processing requirements is quite difficult. While reducing z-fighting is usually just a matter of making two polygons less co-planar which is easy.

>You tried to paint z-buffering as some panacea. It's a tool

Not really. It's just a more modern replacement for PA. As I've tried to explain in my posts, at the end of the day (performance aside) they really only differ in the units being 'sorted'. PA is fine in certain situations. Actually using some PA with z-buffer can be useful.

>You're the same kind of shitster that would dismiss raycasting as a "2.5D" thing, or line scrollers as not being 3D

You're fighting shadows.

>No, you have to argue the corner cases just to win a fucking argument only you are having. Fucking tired of the likes of you.

No need to get emotional.

[Anonymous No.3280881]

>>3280851
>I doubt it

Memory bandwidth tends to be the bottleneck in consumer computer systems.

>nothing's being sorted

In a z-buffer values are being compared bigger or smaller. That's sorting. The only difference is that losing value doesn't get stored. Effectively the goal is to have the front polygons get their colors sorted to the front and therefore included in the framebuffer. You can try to use more exact terminology instead of a more layman example, but leave it for arguments with your comp sci professor instead of an imageboard.

>it just so happens to be a z-buffer specific issue

PA has to be run through for every frame. Z-buffer has to be run through for every frame. Obviously the former will sometimes put polygons that were in the back on the previous frame into the front on the current frame. While the latter will sometimes do the same for pixels.

So it's hardly unique. Z-buffer is just working with a smaller unit. There's no other difference in that example.

[Anonymous No.3281460]

>>3280824
>The fucking polygon is flickering like a bad pokemon episode.

[Anonymous No.3281792]

OP here, just wanted to let you guys know Im still reading this and your input isn't wasted. A lot of the "techniques" you guys are listing are above my head, but i appreciate that because its giving me new material to read and look up, so thank you.

While searching around last night I found this link which lists polygon counts of certain assets of some n64 games.
http://www.oocities.org/zeldaadungeon2000/polygonchart.html

This was a valuable find for me because it gave me some ballpark levels of complexity to work with and reference points for making models. Im not sure how accurate these polygon counts really are but they seem to be reasonable estimates.

[OP No.3281814]

>>3280434
I'm new to all of this and am unsure if I have the terminology right, but is what your referring to called "light baking"? I've always appreciated the painted on static highlights and shadows in older games on textures, it reminds me of wargamming miniatures somewhat. Wargamming miniatures are so small they paint on highlights and shadows to exaggerate details and give them more depth to trick the eye.