60fps in retro gaming

Called limited hardware.

6th gen and later it's just laziness. As packed up by at least one game that looks amazing while also running at a high frame rate.

>>3100823
>What kind of framerate did 3rd gen Euro home computer games (C64,CPC,800XL,Spectrum) have?
Spectrum had shit framerates. No graphics hardware so everything done in software with a slow CPU. 25fps is considered "smooth" by Spectrum standards, most games are far worse. And it's PAL, so it's capped at 50fps no matter what.

>Were 2D arcade games always 60fps
The Metal Slug games run at 30fps.

>Were 3D arcade games always 60fps
Outrun runs at 30fps (but the Saturn port has a 60fps mode).

Autism: the thread

The vast, vast majority of 2D games are 60fps. There's nothing really interesting about it.

>>3100852
>The Metal Slug games run at 30fps
sometimes lol

I know Galaxy force 2 on saturn runs at 30 while the arcade runs at 60
https://www.youtube.com/watch?v=JaUQfcRyjcY

Did the Vextrex do 60fps in its games?

Did the Virtualboy do 60fps in its games?

Did the Gameboy, Wonderswan, Neogeo Pocket, Atari Lynx, Watara Supervision, Microvision, etc do 60fps in their games?

>>3100958
>Did the Gameboy
yes. That platform's running on a fixed 60fps that can not be bypassed. The only thing you could do, if you're crazy, is spread out your computations over two frames, and not update on one frame; to get a framerate of 30fps. Beyond that though, hard 60fps, no choice.

>>3100958
>Did the Virtualboy do 60fps in its games?
No. Unusually for a portable system, it's forced 50Hz.

>Atari Lynx
Software configurable display refreshes at a maximum of 78.7Hz. In practice I don't think any games ran faster than 75Hz.

This is why the Dreamcast was such a big deal when it came out. So many of the games for it ran at 60FPS.

Dynamite Deka for Saturn runs at 60fps. Looks boss.

>>3100958
No, WonderSwan did 75fps

PC-9801 had 56 Hz and PC-9821 70 Hz
Mac used 75 Hz.

>>3101229
That's screen refresh rates. What's the frame rates of the games?

>>3100863
>The vast, vast majority of 2D games are 60fps

I remember lots of games on the Sega Genesis / Mega Drive being 30 fps. So much for blast processing.

>>3101249
>I remember lots of games on the Sega Genesis / Mega Drive being 30 fps. So much for blast processing.

Maybe lots on Genesis but MOST on SNES.

>>3100823
>Virtua Racing
>60 FPS

Back then this was emerging technology. It was expensive to produce, and at the consumer level fps was a concept beyond most peoples' grasps. It wasn't just consoles, even most home computers back then would get poor frame rates in 3d games. Arcade cabinets could achieve great performance because they were expensive. They were an investment meant to eventually turn a profit, and were outside of the average consumer's budget.

The fact that many home console games run as well as they do with such hardware limitations is a testament to the developers that managed to pull it off.

>>3101231
They'll normally aim for an integer fraction of that.

>>3100823
>What % of games in the 1st gen were 60fps?
All of them, if your TV was NTSC.

>>3100823
>Were 2D arcade games always 60fps
I know even old shit like Asteroids was 60fps.
>>3101029
Too bad they changed SA to 30fps before release.

>>3101387
Do vector displays work like that?

>>3101261
Target FPS is mostly 60fps on both, but SNES has more slowdown so it runs at 30fps more often.

>>3101281
People might not have understood FPS, but they'd notice shit motion quality in a side by side comparison, which is what you got in an arcade.

>>3100869
Only the first is 60.
Metal Slug 2 and later are capped at 30fps.

>>3100863
>you're autistic if you're interested in things that i'm not interested in.

>>3101249
I only know 3, ranger x, curse, syd of valis.

>>3101872
Metal Slug 1 is 30fps with a few 60fps palette cycling effects.

>>3101249
Oh yeah that's right general chaos and toejam and earl are 30fps too.

>>3101290
indeed, a fraction. At 75Hz (the best one in the set) you're down to 37fps if you can not maintain 75fps. That's quite a bit away from 60fps. It's quite typical for desktop computer games to not target the refresh rate. So, that post was needlessly boosting large numbers, painting a wrong picture

>>3101490
vector displays have no scanlines, but they still need to regularly refresh the image or it fades from the screen

>>3101371
>All of them, if your TV was NTSC.

Actually if your TV was NTSC then none of them ran at 60fps. They ran at 59.94.

>>3101934
But 56 isn't a large number.

>>3101261
I don't have time to fire up emulators and do some comparison, but I'm pretty sure most are on Genesis.

>>3101885
>>3101887
Almost every raster-based game was also 30 fps or even less. Out Run, After Burner 2, Super Hang On, the Road Rash series which is probably 20 fps.

>>3101950
close to 60. Yet likely real framerates of 28 or 18fps sound much less appealing

>>3101960
I should also point out that aside from SuperFX-based games, Lagoon, Outlander and Power Moves are the only SNES games I can remember being 30 fps (and the former two are multiplat titles that are 30 fps on the Genesis too).

>>3101960
Outrun is an odd one, because it runs at 60 and 30 fps. The system renders at 60fps, and the background is updated every frame. Sprites and road are only updated every other frame, resulting in 30fps

>>3101968
Given the nature of most PC98 games they shouldn't have trouble hitting 56.

File: arcade_feel.jpg (34KB, 368x460px) Image search: [Google]

34KB, 368x460px

>>3101867
>Target FPS is mostly 60fps on both, but SNES has more slowdown so it runs at 30fps more often.

In most games yeah, but "most" by a smaller margin than most people remember. Both 4th gen consoles had many, many games where the target was 30 fps. Not talking about slowdowns here but constant, stable 30 fps.

It's actually one of the things I loved about PCE / TG-16. All (or almost, but I can't remember a single game that didn't) of its library was 60 fps without even slowdowns. Back in the day I was too young and dumb to realize this, but I guess it's the main reason PCE games had that "arcade feel" that Genesis and SNES games didn't.

>>3101969
Prince of Persia is very low FPS on SNES (and probably all platforms).

>>3101946
Shut the fuck up.

>>3101993
Isn't that because of the rotoscoping?

>>3101946
No, Atari 2600 ran at 59.9227510135505fps

>>3101986
I can't think of many games running at 30fps, It's pretty easy to check, download a the rerecording gens (aka gens-rr) and turn on the frame counter, if it lags every other frame it's 30 fps.
I can only think of ranger x, general chaos, curse, toejam and earl, syd of valis running at that framerate.

>>3102341
Forgot to mention, that also works with snes9x-rr.

>>3101071
Seriously? That's interesting.
Virtual Boy was 50hz. Any 60fps N64 games?

>>3102341
Also Todd's adventure in slime world and Taz Mania outside boss stages.

>>3102353
Sin and Punishment, F-Zero X, Super Smash Bros are constant 60fps.

File: test.jpg (313KB, 1029x832px) Image search: [Google]

313KB, 1029x832px

>>3102380
I just checked it with glide64, it's aaaaalmost 60fps with four players, it just lags a bit.

File: 111.jpg (208KB, 1027x829px) Image search: [Google]

208KB, 1027x829px

>>3102484
Yeah I agree. I think it's an emulator bug, if you disable sync audio it's locked at 60fps. Here's Zelda for comparison.

Intellivision's games were all 20fps.
Its main competitor the Atari 2600 had worse graphics but smooth 50fps.

>>3102869
49.8607596716149fps in PAL regions

>>3102439
>>3102509
The bug is that SSB is running near 60fps on your poorly coded emulator when it was slow as molasses in nowhere near stable framerates on the real hardware

THANK YOU AUTISMO!!

>>3102869
Atari 2600 was 60fps.

Early PS2 games were often 60fps but as graphics were pushed more and more later games were 30 fps.

Shadow of Colossus was 20 fps during action scenes.

PC wasn't particularly well suited to moving tiles around at high frame-rates. 2D games were generally pretty choppy on the PC up until 1994-ish or so and, even after that point, a lot of them still suffered from issues that weren't present on consoles.

PCs didn't have hardware sprites.
Displaying a sprite on PC require copying some bytes from one place to another (blitting).

It should be noted that the approach to 2D on 3DO was similar to the PC which is why, despite its faster overall hardware, it struggled to handle 60 fps 2D platformers. Gex, for instance, ran at 30 fps with serious slowdown that dropped it well below in many cases. The games that could deliver smooth performance were rare. Shame everything was output in interlaced mode (despite being internally handled at 320x240).

Wait, do you actually believe that 60Hz refresh rate means that console outputs 60 individual frames per second? You can't be this thick /vr/.

Zelda Ocarina of Time was 20fps and 17fps for PAL consoles.

>>3105248
guess why every pro-speedrunner uses a 100hz CRT

>>3106869
>pro-speedrunner
what a joke

>>3101872
What about Metal Slug 2 T--T--TURBO?

>>3106869
>pro-speedrunner
>100hz
Spot the underage

>>3100823
Any emulated game can run at 60 dos if it is already running at 30fps. Just speed up the game by a factor of two and then decrease the object speed by 50%.

>>3105248
Don't you tell me how thick I can be, I'll have you know I'm stupid as fuck. I don't understand any of this but I do know that Ghosts N Goblins (NES) and The Immortal (NES & Genesis/MD) run at choppy-frames-per-second.

>>3101281

>>3100960

The Harry Potter RPGs did this.

>>3100841

It's not laziness. People think 30fps is more "filmic" and prefer the better graphics that extra 16ms can give you. Nor do they know about how frame rate is tied to input lag.

This is especially true for exclusives, who have become the trophy wives of video games. Ryse and The Order's job is to look pretty.

>>3107594
>It's not laziness. People think 30fps is more "filmic" and prefer the better graphics that extra 16ms can give you. Nor do they know about how frame rate is tied to input lag.
Pretty sure most devs know better.

Not going for 60fps is one thing. Not going for 480p. They were either dumb or lazy.

>>3100960
Not true. Yes, the display is approximately set at 60FPS - this is no different than any analog NTSC television operating at 60 fields per second. That doesn't mean you can only update in 30 or 60 FPS intervals - every frame doesn't have to be evenly spaced. That's why you see slowdown with a lot of sprites on screen and such and not in normal play.

>>3105203
>>PCs didn't have hardware sprites.
Depends on the kind of PC, Atari 400 or C64 for instance had them.

>>3100823
Wait wait wait, did you really just ask about frame rates for FIRST generation consoles? That is quite literally the most asinine thing I have read on /vr. Nobody CARED about frame rates up until the Xbox ps2 generations. Only people that care now are a bunch of under aged babies whining or trying to show epeen on how powerful their rig/console is. Please never, ever out again.

>>3100960
>he only thing you could do, if you're crazy, is spread out your computations over two frames, and not update on one frame;
That's not craziness, that's the standard way to handle a game frame that takes longer to calculate than a TV frame.

>>3107598
480p is brutally resource intensive on ram, only a few ps2 games supported progressive scan mode which is basically 480p. Most Ps2 games were 480i and most ps1 that tried doing higher res were weird non-square variations like 512x240.

>>3106880
Metal Slug X is still 30fps.

>>3107680
I thought 480p is the same load on the processor as 480i. You just discard alternating halves of the framebuffer for the latter every frame.

>>3107680
It was easier for shit devs to just pump out unoptimized trash at 480i.

2d games were almost always 60fps because the hardware could only be pushed so far and the visual quality wouldn't be enhanced - there would be just more on screen enemies etc, with 3d it is always a compromise between resolution, detail level and fps. That is still the case today. That pokemon arcade game for example for wii u is @60fps but sub 720p, so they went for high detail and high fps but low res. Others like ubisoft for example go for high detail mid res and 30fps.

On PC it's up to you and your settings and your hardware. Anything is possible.

>>3107687
Maybe the devs really were just untalented. I don't know.

>>3107692
Not to mention, some people report having motion sickness when watching fast scrolling backgrounds at 30fps. It can be physically sickening.

>>3107650
if you have a framebuffer (or two of them), you can assemble your frame off-screen/in memory, then flip the buffer. You don't get that luxury on tile hardware

>>3107687
You're suggesting that in a time when hardware was super limited and developer were fighting for every single cycle, they would drop 50% of the output, just because? No chance.

>This entre fucking thread.
>All this cancer

>>3108163
>You're suggesting that in a time when hardware was super limited
>2000s
>limited

Are you retarded? The 2000s is when gpus actual;ly became affordable. Could literally shit processing power.

>>3108189
that's why the game worlds used millions of polygons and multi-texturing everywhere, because their fillrate was practically unlimited, to the point that you could completely discard half of what you drew

>>3107680
The reason PS2 didn't often have the full 480p is nothing to do with hardware power but that the PS2's 4MB of VRAM was a really big space limitation. You actually have to store your frames somewhere, people.

Don't know why people can't understand this.

Almost all games were locked to 60hz/fps... The way these 2D games pushed the system was they caused games to drop to a crawl if they couldn't keep up (SNES) or sprites would be removed/flicker (NES) as they tried to display too much for the hardware to handle at once.

In old consoles, you hadn't to *draw* the scene. The console was outputting the image using the sprites data: both graphical data and position/rotation/scaling registers.

You could still only update the position registers at 30fps, and thus get a 30fps game.


But the fact is that having twice the time didn't allow you to draw more things on screen, in most case. The sprite budget is fixed. So there is very little advantage to NOT supporting 60fps. As long as you can update the positions in time, you're good.

The only slowdowns were because the processor couldn't update the positions of the sprites in time, but for most games, it's because you have too many items moving on screen (shmups, in particular, when there's too many bullets/items). That's not a drawing issue, that a computation issue.

>>3109462
>But the fact is that having twice the time didn't allow you to draw more things on screen, in most case. The sprite budget is fixed
While not /vr/ I'd like to add that the Nintendo DS of all things continued the "fixed budget" concept, but with polygons.

>>3108280
> Don't know why people can't understand this.
As for me, I don't know why you should store your frames.

>>3109521
on 2D systems a line would be rendered just in time, then sent to the display. That is very efficient on memory, and it works, because producing a 2D image is a completely linear thing, and you do not have much of a relationship between lines. Among other things, this means all your video RAM is usable for sprites, tiles and maps.

For 3D though, an image is created in 2D. When you got a polygon and transform it into screen coordinates, you got to render it at once into all its locations. That's necessary, because other polygons may draw over it, and you don't know until you're done. You could, of course, do all this for every single line, but the overhead is ridiculous. So instead you put aside a bit of memory that holds all the pixels of the output image, and then assemble your image there. When the time comes to send data to the screen, the controller just grabs whatever is in that buffer and calls it a day. That buffer needs to sit in video RAM, and needs to be uncompressed. That eats quite a bit of memory.

Even worse, you can double the memory requirement if you use two buffers. Why two? One is prepared for the graphics system to grab and throw at the screen, while the other is undisturbed and you can assemble your next frame in there. When the time comes, you just flip the two, which is instant. As said though, required double the memory. As another anon pointed out, these consoles did not have much memory. That's a bit of a problem.

>Actually, PAL is only the color encoding.

>NOT the frequency.


>PAL can be 30/60Hz at the "NTSC" resolution. PAL-M, for example, is interlaced, 480 lines at 60Hz.

>Granted, it's RARE, but it was actually used. In Brazil, for example.
Will TVs in Brazil accept input from NTSC U/C consoles?

>>3112375
Yes, usually it'll be black and white. The Brazillian (official) NES was a NTSC NES with a color system converter board.

>>3100958
>Did the Vextrex do 60fps in its games?
>>3101387
>I know even old shit like Asteroids was 60fps.
>>3101490
>Do vector displays work like that?

Vector displays do not work that way. They redraw only what lines are on the screen over and over again as fast as the beam can track. The rate at which they redraw the screen is variable, depending on how much geometry there is to cover. Most of the time they're doing this at much higher than 60 redraws per second.

Even the primitive "Quadrascan" vector monitor used in the original Asteroids cabinet can draw one line every 60 microseconds on average. Given a scene containing roughly 100 lines, it would be redrawing everything on the screen around 160 times per second.

>>3114180
That doesn't mean the game itself runs at high framerate. It wouldn't surprise me if the game ran at a fixed framerate and the display controller repeatedly drew its vector list asynchronously. This would be simpler to implement.

>>3114186

Asteroids controlled the display directly through a DAC with an opamp as a buffer.

>>3114196
It did not. The CPU controlled a dedicated hardware vector generator which drove the DAC. See http://www.jmargolin.com/vgens/aster.pdf

This could easily be used with a fixed framerate game engine.

On C64 you had stuff like Driller and Total Eclipse that were something like 1fps or even 0.2 fps (sometimes a frame took 5 seconds to draw, true story).
On Amiga you had games like Power Drift conversion that was probably 10fps and absolutely unplayable etc.

>>3114757
1fps can be plenty if you know what you're doing. first person dungeon crawlers rely on that

>>3101872
Really? Metal Slug on the PS1 runs at 30 and it's super noticeable due to the dropped frames of animation compared to arcade MSX.

>>3114770
Wait what does cut animation have to do with framerate. I'm pretty sure bladesoft plugin can count internal framerate in PS1 games, we should check.

>>3114779
if you disregard memory of the system and throughput of the drive, then reduced frame rate is the only reason to cut animation

>>3114782
On the PS1 it was definitely ram though.

>>3114792
RAM or drive, maybe both. hard to tell for me. Just saying, there's many reasons to cut stuff, and it's always a good idea to be aware of them

>>3114797
True that.

>>3109481
Yeah, it was weird having the only animal crossing game with an on-screen furniture limit.

>>3114761
1fps is too slow even for turn based games. You need at least 10fps for them to be tolerable.

>>3114770
Arcade original is 30fps too (with a few 60fps graphical effects). When I first played it I thought my emulator was broken but it really is that bad.

>>3114951
The whole screen is standing still, at that point you don't need to refresh at all.
Also, there are non-jokingly 3D games running in sub-10fps, and they're quite playable. You'd be surprised how low you can go

>>3114954
The screen standing still doesn't matter. It's not a question of motion quality in this case. 1fps means you have up to 1000ms input lag (in addition to all the other latency sources) for every command. This is far too aggravating for a game to be fun.

>>3114959
ok, I see where you're coming from. I mentioned the first person dungeon crawler for a reason, but was sloppy. Rendering their first person view can be slow and time consuming. Once it's done though, it's done, and you got a static backdrop, with speedy inputs. It's perfectly viable to have a dungeon crawler that takes over a second to render a "movement" step, though when navigating the menus it should be speedier, I agree.

>>3114964
If the rendering is asynchronous and it draws a wireframe or similar very quickly before adding the detail, then it's acceptable. So long as you can ignore the fancy slow graphics and navigate at 10 actions per second.

>>3114973
reminds me, years ago I wrote a dungeon crawler for my calculator. Drawing individual lines was dead slow already. I eliminated most of the lines, to bring it to bearable speed, but it wasn't enough. So I split the drawing routine in two. First the nearby walls, then another input check, then the distant walls. So you could still move fairly quickly (two steps a second or so), but also get the full picture if you stood still.

Notable Genesis games that were 30 fps or below.

Beyond Oasis (the Saturn sequel was 60 fps)
Chakan: The Forever Man (Same could be said for a number of Sega of America games)
Almost all of EA games(Road Rash, their sports titles, etc)
Practically all of their forward scrolling games (Space Harrier 2, Galaxy Force 2, etc. Actually I'd go as far to say they run at 15 fps or less)

Notable +/- 30 fps NES games

River City Ransom
Double Dragon (the sequels too IIRC)
Star Fox
Certain games tend to drop frame-rates for the mode 7 sections (Super Star Wars Trilogy)

Notable +/- 30 fps SNES games

Super Double Dragon

Neo Geo

Metal Slug (and not much else)

That's just off the top of my head. Undoubtedly there are quite a few more but it's minuscule compared to every subsequent generation.

File: beyond-8ec16446faf4.gif (165KB, 500x480px) Image search: [Google]

165KB, 500x480px

>>3117191
Most modern action games (fighters, racers, FPS etc) run at 60 fps. Rpgs and the like don't, but they don't need to. Unless something needs 60fps timing, I'm happy to have it run at a lower speed to look better.

Always have been. Pic related is one of my favorite games despite it's frame rate.

>>3117191
you mentioned Star Fox and mode 7 in the NES list

Also, your list is silently ignoring the frame rates common on 3D engines. It matters

F-Zero X on 64 was perfect 60fps

You could FEEL the fast
And thats with like 30 players

Most retro games were actually 60fps but would have some slowdown at parts if not managed right. It was mainly with the PS1/N64/Saturn era when frame rate started being less than 60 for most games.

Yeah, you had to make a serious compromise for 60 FPS then, whether it's limited visuals (likely with sprites taking the place of polygonal models), a limited play area (fighters), or very basic visuals (F-Zero X.)

>>3119886
>It was mainly with the PS1/N64/Saturn era when frame rate started being less than 60 for most games.
ever seen a PC?

>>3119897
30 double frames per second

File: 30fps.jpg (86KB, 649x285px) Image search: [Google]

86KB, 649x285px

>>3119901
Yep, can confirm, it's lagging every frame, therefore 30fps.

Framerate is overrated, I played Chakan for hundreds of hours and I never thought it was 30 fps.

>>3119918
Seconding this. Many games don't really need to be 60 fps.

>>3100823
Hello OP I too am writing an article about frame rates in video games and wish to harness these nerds into doing all my research for me

>>3119924
I can help with your article, no problem. I just find this stuff interesting.

Video cards back then didn't do much more than act as a frame buffer. You copy a piece of memory onto it and at the v-sync, that memory is converted to a video signal and displayed to the screen.

The amount of video memory only determined how big your frame buffer was and hence, your max resolution.

A 320x240 screen, at 8 bits per pixel, only needed 76,800KB.
640x480 = 307,200 KB

Having less video memory means smaller resolutions, which means less memory to blit to the video card, which means faster framerates, not slower. :)

>>3119918
Though I agree that framerate isn't everything, even as a kid I noticed there was something wrong with Chakan. Didn't stop it from being a cool ass game, but didn't stop me from wanting it to "feel" a bit better either.

>>3114986
Cool, I don't take it you still have the game, do you?

>>3117705
Yeah, at the time it was panned a bit for 'simple graphics'. Now it's praised for being playable. Pays to be forward-thinking.

>>3121945
Even as a kid I noticed the bosses and minecart stage in Taz Mania felt much smoother.

>>3122275
unfortunately I don't. wiped my calculator clean at some point. Lost some other handy utilities as well

Vectorman created such a fuss because no one believed such graphics can be achieved in the Genesis at that time. Some have even said it was Sega's answer to Nintendo's DKC.

I believe people were talking about 60fps character animations for Vectorman, which were done by arranging small sprites into a character and then just sliding them around the screen rather than traditional animation frames which would be a handful spread out over 60 frames.

>While modern 3D games have a fluctuating framerate depending on how much there is to draw on the screen; classic 2D games if not 60fps were locked at a simple fraction of 60 such 30, 20, or 15fps and stayed steady at that number.


Is this true?

>>3126556
A little bit too black and white, but in general, yes, why?

>>3126564
Was it easier to program that way?

>>3126624
that's part of it, and part of why some modern games even insist on running at a fixed framerate, instead of a variable one. It's a bit of a broad topic, but I'll try:

An old 2D system has no frame buffer. Instead each line of the image is rendered just in time, when it needs to be sent to the screen. The output on screen was determined by a couple variables, like window position, sprite locations, tiles used, etc. The developer would just set these values as desired, and then wait. The framerate of these systems was hard locked to 60Hz, no changing that. So, what about the fixed fractions? A common technique for complicated games was to keep the values for the renderer unchanged when the next frame was due, and instead prepare new values in RAM, to send them over to the VRAM system every other frame, or every third, or whatever the developer settled on. This effectively meant the developer had more time to do what was needed, but needed a bit of extra memory. The amount of extra time they needed was pretty easy to determine, as it was likely constant throughout the game, as the number of objects on screen was limited by the hardware, and that's one of the few things that introduce variance. The number of objects or effects on screen had no impact, it was all rendered at the exact same constant time.

>>3126624
>>3126679
Enter the frame buffer. The framebuffer is a piece of memory holding all the pixels of an output image, a frame. The framebuffer and 3D go hand in hand, and 3D itself is a main cause of variable framerate. In general, instead of setting some graphics "state" for the system to draw, the developer would produce all the pixels for the image in that framebuffer. The graphics system would just read that buffer line by line and spit it out on the screen. The framebuffer was important for 3D, because unlike 2D graphics, you can't just draw 3D graphics "line by line", or at least it's a bit unreasonable to do so. Instead a 3D image is assembled by drawing all the polygons one by one into the buffer, applying effects, etc. Without the frame buffer, 3D is not really feasible. Some nitpickers will now of course point out 3D games on the NES, Gameboy and other pure 2D platforms. However, these games do use framebuffers. They're just really well hidden. The developers just covered the screen with unique tiles, and then drew the lines into the tiles. The tiles became the buffer. An awkwardly split buffer, but it was better than nothing. Anyway, back to 3D. I already hinted a bit at the way 3D is drawn. You draw polygon after polygon on the screen, until you're done. This leads to a subtle change in rendering time. It's not constant any longer. If you stare at a wall in a game, there's very little to render, and you're done quickly. Stare at an explosion with lots of debris, and all that debris takes time to draw. The framerate is suddenly variable...

>>3126624
>>3126683
... Or at least it should be. Why should it be variable in this case? Because both examples are extremes. If you set the framerate based at staring at the wall, then the game will not be able to keep up during normal gameplay. Everything will be like a permanent slowdown on the NES. Likewise, if you target the framerate you had during that awesome explosion, which was likely very low, your entire game starts to stutter and go jerky, even though it's doing nothing most of the time, because it's quickly done with a normal frame. That's why 3D graphics normally use a variable framerate.

The developer needs to account for this variability in their game engine. When a different time passes between each image, physics have to be adjusted to the time passed, game ticks may happen several times during a slow drawing image, and so on. It's quite a nastly bit to juggle. Fixed framerate is much easier to code for.

The above is not 100% exact, I skipped over plenty of technical details, but maybe it helps getting an idea on variable vs. fixed framerate and 2D vs. 3D rendering

>>3126679
>>3126683
>>3126685
Good post.

>>3126679
>>3126683
>>3126685


What about 2D (not 2.5D) Playstation and Saturn games?

They have a framebuffer and fill it with textured flat polygons to make sprite equivalents.
Are their tiles and backgrounds also flat polygons?

Are they locked at 60fps with slowdown on intense sections or do they have a variable framerate?

Was the PS and SS only limitation for high quality purely 2D games memory or could they have used a stronger CPU/GPU?

What about the Jaguar and the 3DO?
Did the Jag use traditional or modern methods for displaying 2D games?
Why did the 3DO have poor framerate in 2D games?

>>3127139
>What about 2D (not 2.5D) Playstation and Saturn games?
>What about the Jaguar and the 3DO?
>Why did the 3DO have poor framerate in 2D games?
No idea, I have very little technical experience with these platforms. My posts were more about the general approach of state based 2D rendering and buffer based 3D rendering.

>Are their tiles and backgrounds also flat polygons?
On the PS I think so, really no clue on the Saturn

>Are they locked at 60fps with slowdown on intense sections or do they have a variable framerate?
To clarify a bit: the system itself is showing frames at a fixed refresh rate of the TV. The frame buffer does not change that. How often the content of the framebuffer is updated determines the framerate of the game. What really matters there is the way the graphics are produced. If the PS uses polygons to simulate sprites, and the sprite count varies, then it's subject to fill rate issues and can slow down on a busy screen. If the number of elements shown on the screen is virtually constant, the expected framerate will be virtually constant as well, and there's no reason to target variable framerate.

The whole variable vs. fixed framerate thing is largely a decision of the developer. You could do variable framerate on 2D hardware, but there's little reason to do so. And you could do fixed framerate on 3D visuals, but it comes with drawbacks. Ultimately the developer weighs the pros and cons, and goes with one or the other.

>>3100823
http://www.google.com

>>3103372
Smash 64 generally keeps 60 with 4 players on hardware, although it's not the most consistent thing (no game on the machine, bar F-Zero X which doesn't slow down ever, keeps a consistently high framerate in multi).

It's a damn sight further from slow as molasses, but if everyone is doing something at the same time, there will be drops, and that's not an uncommon situation.

>>3117705
man, that was one of the things that blew me away the first time I saw it
absolutely magnificent, especially after coming off of Mario Kart 64's framerate in 4 player (god, that was bad)

other than the fact that what little roadside scenery the game bothered with looked awful (why were those dopey looking things placed right next to the track even there), the game looked fine enough, especially with all the shit you could have on screen at once, kid me at least understood having 30 fucking machines on screen was impressive, most other games would choke even trying that
actually, the one thing that bugged me about F-Zero X was how textures looked, they were stretched all over the place diagonally and shit

>>3114959
>1fps means you have up to 1000ms input lag (in addition to all the other latency sources) for every command.

Only if you do more than 1 command per second.

>>3119886
>It was mainly with the PS1/N64/Saturn era when frame rate started being less than 60 for most games.

Nah, any game that was doing cutting-edge graphics was sub-60 fps, or at least dropped to sub-60 at some point, even at earlier consoles.

>>3117191
road rash is such a choppy piece of shit. i can't believe i found that game bearable as a kid.

>>3126556
It's only halfway true. Only the signal output to the TV has a fixed refresh rate. Games run at whatever speed you can get them to run. There are examples on sprite based games that drop the speed in a varied manner instead of just halving it.

Modern 3d games are the same, they also run at a fixed 60hz (or 50 or 75 or 144 or whatever screen refresh you have set up).

They operating keyword is: they just don't update the picture in every frame. This is kind of the same in 2d hardware is well (though technically they will instead just update with an unchanged picture instead of updating at a slower pace).

Old 2d hardware also had a fixed amount of sprites it could display, and if you went over, it just skipped displaying the extra sprites. So halving the framerate did not get you twice the graphic fidelity. It was only necessary to reduce the framerate if your game was heavily CPU bound and you could not keep up with 60fps, or if you were streaming in tiles (treating the 2d hardware as a framebuffer) by doing software 3d or FMVs.

And the real reason why people use fixed 30fps or 20fps or 15fps was to make the game more steady. It can be very jarring if a game is altering its framerate too often, so it was easier to just lock it to a lower maximum, and then you got the game running at a steady, even pace.
It also helped with coding a bit, it was easier to time things if you kept a steady fraction. Easier to compute exactly how much time you have, etc.

>>3126679
>>3126683
>>3126685
2d chips were drawing stuff into a line buffer. You could exceed their abilities just like on framebuffer based systems (for example, to draw more sprites on a screen than the hardware limit allows). But the problem is that then you also break the display to various degree. You had to "race the beam" to a degree.

For 3d this was just made easier since you could manually tell the system that "hey, I finished updating a frame". No racing necessary.

>>3127978
>2d chips were drawing stuff into a line buffer
unlike the frame buffer, you had no direct access to it, it's merely an implementation detail. Racing the beam is trying to manipulate the output by adjusting the graphics state while it rendered. As far as the developer is concerned, the line buffer might as well not exist and can be treated like direct output.

>>3127978
Next time, try to fucking read
>The above is not 100% exact, I skipped over plenty of technical details, but maybe it helps getting an idea

>>3127965
Road Rash is doing realtime scaling, so I can at least excuse it for that.
but at the framerate it runs at, it might as well not, it's as choppy as separately size-stepped images

>>3128004
>Road Rash is doing realtime scaling, so I can at least excuse it for that.
If it can't maintain a playable framerate that way, it probably shouldn't attempt to do it. Part of game dev is knowing what not to do

>>3103372
>Superior performance
>"poorly coded"
/:^)

>>3128007
listen mate, people bought road rash in droves so it was good enough

>>3128674
that's an odd conclusion. Not like it had much competition

>>3128674
>good enough
I don't give a shit about a game being good enough. I'm a gamer, not a company. If a company thinks they can half-ass it, I'll call them out as either incapable, or player hostile.

>>3128679
congrats you are in the minority

>>3128683
I can live with that. Certainly beats fellating developers at any opportunity

>>3128674
>Guys people bought The Order, it's good enough.

Get out, /v/.

>>3128687
nice strawman

by modern aaa standards it was a flop

xtra animations for the character gave the impression that it was much smoother. It's like X-Men: Children of the Atom and Street Fighter III. Both games run at 60 fps, but SFIII looked much 'smoother' because of the extra frames of animation given to each character.

I would just like to clear up a minor detail: slowdown is NOT the same as framerate drops. 2D games generally are locked at 60 no matter what and when there is too much stuff on screen

It's quite close, though.

Actually, on 3D games, when you have framedrops, you still get 60 images per second in the video cable. Even if the TV receives several time a copy of the same framebuffer, since it couldn't be updated in time. The framebuffer is still converted into a video signal 60 times per second.

On 2D games, if the game can't keep with 60Hz, the video registers (sprites positions, scale, sprite ROM pointers, etc.) are not updated in time. So the game actually send the same image. There's no framebuffer, so you can argue that it's still rendered at 60fps, and thus it's a slowdown, but for me, the equivalent of the framebuffer in old consoles is the video registers.

I'd say you can count this as a framedrop as much as a slowdown. I think that a failure to update the registers in time on olde consoles is similar to a failure to update the framebuffer in time on new ones. There's no actual rendering on old consoles...

Yes but the perceived visual phenomenon is completely different, is what I was getting at. Frames being skipped looks choppy while slowdown just looks like slow-motion, two completely different things for the end user.

>>3131509
>I would just like to clear up a minor detail
why didn't you?

>>3131509
>Frames being skipped looks choppy while slowdown just looks like slow-motion
Slowdown looks choppy *in addition* to the slow-motion.

Joy Mech Fight, a game released at the very end of the NES lifecycle (1993), pushed the system to its limits and thus had a low framerate.

>>3133747
>pushed the system to its limits and thus had a low framerate
One does not follow from the other. Low framerate is just an indicator of the system being unable to keep up. This can be due to bad code, this can be due to the developer misjudging the capabilities of the system.
A program that "pushes the system to its limits" will run fluently. It just uses the available cycles most efficiently

>>3131524
It doesn't look choppy since it's not avoiding drawing any frames.

Did you guys know slowdown have to be coded in? If you do things faster than the processor could handle it won't slow down on its own, it will simply crash and stop working.

>>3134217
>A program that "pushes the system to its limits" will run fluently

No, it is this that doesn't follow. What is objectively defined as 'fluently'? 30fps, 60fps, 120fps? A developer might be intentionally targeting a lower framerate like 20fps (see OoT) due to the ambition of the project.

N64 games like Perfect Dark and Conker don't keep a stable framerate, but their graphics look great. Can you honestly say they aren't pushing the system? There's no bad code there, those games just ask more of the system than it can provide.

Pushing the system is always equivalent to good code, not to arbitrary metrics of the output.

>>3134276
>What is defined as 'fluently'?
no slowdowns, no frame drops. Frame rate doesn't enter the picture

>Can you honestly say they aren't pushing the system?
If they frame rates dip badly, then yes, I dare say they don't push the system, they miss the mark.

>those games just ask more of the system than it can provide
Which is not pushing it, it's breaking it

>Pushing the system is always equivalent to good code
I can "push" a system, in your definition, by adding a bunch of sloppy wait loops in a simple move-the-cursor game. It's really trivial to bring any system to a grinding halt, that's neither good, nor desirable. What matters is that the program does the most with the available cycles. The key parts here being "most" and "available". Inefficient programs violate the former, programs with slowdowns and dips violate the latter.

There are still instances today in modern games where not all elements are rendered at the same framerate, though. Reflections, shadows, distant character animations, that sort of thing may be rendered at a lesser fps than the rest of the game is targeted at.

>>3136465
>still
it's a fairly modern thing to mix update rates like that. The few old cases I know are rooted in distributed computing

Yes. Nearly every game I own on my SNES hardware runs at 60 FPS, even the lower-tier movie tie-in games and the like. 60 FPS simply was the standard.

Though slow-downs were another story. No such thing as frameskip back then. If the game couldn't keep up the entire game crawled along, which does very much affect gameplay for better or for worse.

>>3139092
>No such thing as frameskip back then
that's completely up to the developer

>>3134217
>A program that "pushes the system to its limits" will run fluently.

This is simply not true as you are missing the context.

One can push a system to its limits by running games at 60fps with no slowdown (which is inherently more difficult to do the bigger - and more limit-pushing - a game gets). This usually involves designing a game to do exactly what the hardware can do.

Or, one can push a system to its limits to do the type of graphics which look significantly better than other games, or even look a generational leap ahead. These are less likely to run at 60fps since you are pushing the game way beyond the type of graphics that the hardware is designed to do.

Compare Streets of Rage 2 to the homebrew Wolfenstein 3d, both on the Megadrive. One pushes what the system is designed to do, up to and including the largest types of sprites the system can handle without multiplexing, as well as doing linescroll and row+column scroll powered rotation. It also pushes extreme amounts of characters with a very good AI. About the only thing it doesn't use is shadow/highlight. The game runs at 60fps, except for that short scene before you fight Jet.

The other game instead uses a ray casting engine, which the Megadrive VDP is completely unsuited for, but it is coded with such a high degree of efficiency, that it is still very playable (but not at 60 fps).

Both titles push the machine to its limits, irregardless of the frame rate.

>>3139192
As in real time change from 60 to 30fps? That didn't happen.

>>3139224
>60fps
Note how I never once required 60fps. I required no slowdowns and no frameskips

>>3139227
just because it didn't happen, doesn't mean it can't happen. It's up to the developer whether they perform the update of two ticks when they estimate they're about to miss a frame

>>3139235
Interesting, can you name any instances of it happening in a 4th or 5th gen game? I can only think of starfox skipping frames everywhere.

>>3139192
This.
As a developer you can either choose to skip frames, or slow the game down. Both of this gets you the same result from the viewpoint of the code: you have more processing time before drawing the next frame.

But from the users point of view, this can be the difference between the game totally changing timing at arbitrary points. Which one is more useful (slowdown vs frameskip) depends entirely on a case-by-case basis.

Take a look at X-Men COTA and Marvel Super Heroes on the Saturn for example. One of them skips frames, the other slows down. X-Men is way more playable...

>>3139238
>Which one is more useful (slowdown vs frameskip) depends entirely on a case-by-case basis.
This is a very important point. Slowdown is not bad per se. It can, when used wisely, contribute to the game..

>>3139236
It probably does not happen (often) on 4/5th gen because it is much more annoying on 2d games to change the framerate around like that (and possibly more difficult as well due to those systems using tilemap based hardware).

Starfox uses framebuffers so it has more in common with 6th gen titles.

>>3139236
Sonic Spinball

>>3139268
Cool, thanks.

>>3139236
Why not 3rd gen?
Battle Formula, Contra Force

>>3105203
>Shame everything was output in interlaced mode (despite being internally handled at 320x240).
Why? At 240p interlacing doesn't mean anything.

>>3140930
why not?

>>3141890
Because interlacing happen at 480 lines. Therefore 240 lines output 60 times per second.

I don't think the SNES with Super FX could run a non-textured cube at higher than 20 or 30 FPS.

>>3142145
>Because interlacing happen at 480 lines
You're begging the question. Why is the system interlacing on one resolution but not the other?

>>3142151
the SNES is a tile and sprite based system. It's not designed to output framebuffer based visuals.
A comparably powerful PC can't scroll two independent backdrops with alpha blending at 60Hz either

>>3142154
What's a comparably powerful PC? A Towns or x68k?

>>3142152
Because it's the standard and there are no TVs that can show 240i picture.

>>3142176
4.77MHz 8086. That's a faster CPU, and dedicated video hardware.
Look, you're already trying to argue technicalities, while missing the point. That's par for this board, unfortunately.
Graphics capabilities are determined by graphics hardware, especially at that time. The SNES has dedicated tile hardware, some old EGA card has a dedicated framebuffer. The SNES will ace giant sprites, something DOS couldn't handle up until Win9x was a thing. Meanwhile DOS could do untextured shaded polygons with ease, long before the SNES even dreamed about it with the help of an add-on.
You can pick fringe case "PCs" all you want, and it will not change that simple point. So go ahead, pick your fucking "I will win this argument" machine, win your fucking prize, and then fuck off.

>>3142195
can TVs show 240-anything pictures? How and why? It's not part of NTSC specs

>>3142201
They can't (if we are not talking about modern digital tvs), but 240p@60fps is converted to 480i without loss.

>>3142219
so it is interlaced. Glad we got that cleared up

>>3142198
DOS is an operating system, not a hardware. Towns had MS DOS.
Closest to your demand would be the original PC-9801 with a 5MHz 8086 since IBMs of the time only had a 8088 and only switched to 8086 and 80286 with higher clockspeeds.

>>3142228
so take that. What the fuck does it change about the original fucking subject? Fucking obsessed internet arguing shitheads. Why can't you just prove once and for all that you can kill yourself better than just about everyone on the fucking internet?

>>3142228
>demand
oh fuck off

>the original PC-9801 with a 5MHz 8086 since IBMs of the time only had a 8088 and only switched to 8086 (...)
So, with me mentioning 4.77MHz, a rather specific clock speed, you completely disregard that, and pick some shitbox from bumfark elsewhere? And again, how the fuck does that piece of hardware, or any fucking other PC on the planet change the point of tile hardware vs. frame buffer hardware? You're sitting here, arguing minute details of random bullshit platforms, ignoring the fucking main, wait, you will not see that ...

the fucking


MAIN

fucking

POINT!!

!

of desktops being outperformed in terms of 2D visuals at the time of the SNES release, despite them having considerably more computing power. Why is that? Because computing power means fuckall, when you don't have the graphics hardware for the task at hand. No, the SNES is not some miracle machine. It's a fucking abomination when you try to do anything requiring a framebuffer. No, desktops aren't miracle machines. They need excessive power to poorly emulate a simple 2D image processor. But you don't understand any of that. You're latching onto particular makes, models, CPUs and clock speeds, completely oblivious to the actual statement made. You, and fucking pieces of shit like you, are killing this goddamn board. It's impossible to have normal conversations about anything, because you shitheads will come in like a bunch of seagulls, shit over everything with worthless trivia, steer conversations off topic and leave everybody annoyed.

>>3142258
2D visuals is more than just sprites. SNES had poor resolution for instance.
It's only natural to compare it to machines in the place where it was first released instead of some foreign model.

You're the guy getting worked up over a simple question.

>>3142276
>SNES had poor resolution for instance
So what framebuffer hardware could best it in resolution AND rendering speed? Not one or the other? On desktops you had high resolution or sane refresh rate, not both. And even then, sane refresh rate was well below what the SNES did.

>It's only natural to compare it to machines in the place where it was first released
it's side-tracking, as it does not matter what machine you pick. And picking a machine that's unlikely to be in use by the audience of this board only makes you look like an elitist and argumentative asshole. THAT is why I'm losing my shit. You contributed absolutely zilch. Hell, you contributed less than that, by burying the actual statement in your dense bullshit.

>simple question
If only the question would have ANYTHING to do with the subject. What exactly does it change, about the actual made statement, when picking one computer over another? Don't bother answering. You know what? You're right, you won, have a cookie. That's what you're here for anyway, winning fucking internet arguments on fucking technicalities. Subjects? Actual statements? Fuck that noise, it's all about that sweet sweet victory. It's all yours buddy. Drink it all up, choke on it. You won yet another argument nobody but you was having.

>>3142292
>sane refresh rate was well below what the SNES did
I used to play Quake 3 at 160Hz.

>>3142292
>And picking a machine that's unlikely to be in use by the audience of this board
You don't seem to know this board very much.
Why not go after the price? SNES was obviously sold a lot cheaper than computers with comparably powerful sprite capabilities.

>>3142326
>Why not go after the price?
>>3142154
>the SNES is a tile and sprite based system. It's not designed to output framebuffer based visuals.

>>3142326
>Why not go after the price?

>>3142258
>No, the SNES is not some miracle machine. It's a fucking abomination when you try to do anything requiring a framebuffer.
>No, desktops aren't miracle machines. They need excessive power to poorly emulate a simple 2D image processor

>>3142339
The thing is that there were desktop computers with excellent 2D image processors, they just came with a pretty pricetag.

>>3142351
>>3142154
>comparably powerful

>>3142357
The question was what comparably powerful meant.
Comparable powerful in regards to sprite manipulation, comparably powerful to 3D images or something across the board?

>>3142360
>Comparable powerful in regards to sprite manipulation
>>3142334
>the SNES is a tile and sprite based system.
>A comparably powerful PC can't

Whatever, you win. Yes, obscure shitbox X1234 can do tiles better, faster, prettier and more colorful than the SNES for a fraction of the price. Never mind that the whole subject was single purpose video hardware vs. generic video hardware. You found that one machine that has that other kind of special general purpose hardware, that undermines the whole statement made. You won, and can now advance to the next level

>>3142371
Will you die when someone tells you the Neo Geo was better than the SNES?

>>3100960
A CRT television is set at a "fixed" 30FPS (effectively 60FPS in 240p games by overlapping the fields). Your LCD monitor is set at a "fixed" FPS based on its current video mode, probably 60 or so. None of that is relevant to how often the screen is actually being updated in VRAM.

>>3142393
does the neo geo use special purpose hardware or a generic framebuffer? You know the answer, you know you're shitposting

>>3142689
you're responding to a post about the gbc, which has nothing to do with crts or video modes.
there is no "screen" in vram either, as these old systems lack framebuffers

I would actually say it's the exact opposite. Old console games tended to stick pretty rigidly to the TV specs in terms of refresh timings and resolution, which is why there was slowdown, scanlines and sub-60 fps games like GnG locking their frame rates at factors of 60.

Nowadays console games have all sorts of weird, non-standard internal resolutions that have to be upscaled, and sometimes frames are sent to the screen without regard for refresh timing, leading to either tearing or stuttering.

If anything, framerate differences seemed *more* pronounced back then, but there were a ton of games that ran at 60fps along with those that didn't (compare Rad Racer NES to Out Run SMS or Ikari Warriors NES to Rambo SMS). The majority of 16-bit games were 60fps if memory serves right. There were edge cases like Blazeon or Lagoon (both SNES) that had crap framerates. Slowdown is a different story!

Some perspective on 3D framerates before 4th gen
>At the time, many people still had 4.77MHz 8088 PC's, the 80286 based AT machines were fairly new, and the smoking hot top-end machines were 25Mhz 386's - with EGA graphics! Remember that flight simulators were considered good at the time if they got frame rates above 8-10fps. I felt it was important to have the highest frame rate possible, and I was confident that we could get up to 15fps sustained!

ST owners going on about 7% faster CPU and higher frame rates in FA-18 Interceptor and Carrier Command, followed by rebuttals from Amiga owners shouting 'hardware scrolling!'

>>3101387
And then when they brought SA:DX to 60fps on PC and Gamecube they broke the game in half, hence the "SA is unplayable" meme

>>3144185
Old games locked the framerate at factors of 60 so the game could get a smooth framerate, and because the limiting factor was almost never the video hardware but the CPU power; putting 2x as many sprite on screen did not slow down the GPU (it either drew everything fine, or if it was over the pixel-per-scanline limit, it dropped the sprites).

With modern games, pushing more pixels than the GPU can handle will stall the GPU. There is no hard limit like there was previously. This also means that halving the framerate gives you twice as much graphics. People want better graphics, so the speed invariably gets tanked.

Also, in modern framebuffer architectures it is simpler to just make the game dynamically adjust itself, since the gpu can be easily set to do that anyway.

>>3142689
consider that you can have motion between fields of one frame, so you can kinda sorta have 60 fps in 480i as well (thish is where you will get combing artifacts)

>>3149235
>With modern games, pushing more pixels than the GPU can handle will stall the GPU
Unless you're an NDS. Not trying to nitpick your point, you're entirely correct in what you said. I just love how the NDS has this very "2D-ish" feature of a hard polygon limit, resulting in a virtually guaranteed framerate.

>People want better graphics
I really wished this meme would die, because it's so super harmful. Believing that assumption means the only people able to make games are the big companies. Yet so many indie games have simplistic graphics, sometimes insultingly simplistic, yet people play them, left and right, and pay good money for them. I'm not advocating for people to drop graphics, they're very important, and do consider some indie visuals an insult to my sight. But the point is, it's possible to have moderate and reasonable graphics and still produce excellent games, and games that sell. What matters far more than the latest shaders, is a solid set of game mechanics. The big shops only need the visuals because that's all their selling, stories and graphics. The gameplay is shallow and repetitive, because they're afraid of surprising the player in any way, accidental or otherwise.

>in modern framebuffer architectures it is simpler to just make the game dynamically adjust itself
Easy for the game, but really messy for the developer. The overhead of a physics engine with dynamic update intervals is far from trivial. And if you're not willing to do that overhead, you got to use a tick timer, which opens a whole different can of worms

Why are people so obsessed with 60FPS as of lately?
After a generation of sub 30fps games, it's something of a revelation (especially to anyone that entered console gaming during that time).
PS1->PS2 transition was similar (more so thanks to dominance of 60fps games on PS2 in its early years).
Shadow of Colossus, a game that pushed the PS2 to its limits, was 20 fps during action scenes.

>>3151772
We have real time rendering engines on par with cgi movies, there's nowhere else to evolve. The only thing people can bitch and troll about anymore are framerates.

>>3151772
>Why are people so obsessed with 60FPS as of lately?
It used to be the norm, and the current race to the bottom starts to stand out negatively

>a game that pushed the PS2 to its limits
it missed

>was 20 fps
see?

>>3151781
>We have real time rendering engines on par with cgi movies
please tell me you're kidding. We still can't handle any amounts of point clouds or non-trivial object densities, we still can't handle any amount of physics beyond simple ragdolls. The lighting model is still crude as fuck. We can't handle basic reflections, only support simple refractions. We need to badly emulate radiosity and caustics. Even ambient occlusion is either badly approximated, or precomputed. There are tons of artifacts from the various performance demands. We still have a very long way to go.

>>3151802
I have NO idea what you just said.

>>3151805
>We still can't handle any amounts of point clouds
particles, or arbitrarily shaped objects, are usually done using points, that are then rendered with some sprite-like overlays. Works fine for sparks and stuff. Modern engine can push a couple thousands of these. Try to model a flame, or a cloud, and you're fucked. They're still approximated using very few particles, or lots and lots of billboards (textures facing the camera)

>non-trivial object densities
like particles, but more complicated. Swarm of birds, dense fauna (not speed trees, individual leafs), Star Wars battle, and you're quickly in a world of hurt

>physics beyond simple rag dolls
water motions, wind and its effect on objects, complex cloth, shattering and crumpling of objects. Half of that stuff is currently impossible. The other half is done using pre-computation or very crude approximations. Like a cloth, is modeled as a grid of springs. Reasonably close, but leads to visual artifacts quickly.

>basic reflections
current reflection models are all based on a reflection map and some shader based lookups on it. That's only correct for an infinitely small object. Most shiny objects are not infinitely small. The approximation is so bad still, industries tend to take a fat computer and realtime raytracing instead of rasterizing, because the rasterizing result is misleading, if not outright wrong. It's good enough for games, but not more.

>simple refractions
Basic lenses can be modeled, but something with uneven densities is still very difficult. Glass of water with an ice cube in it, for example.

>>3151805
>radiosity
Take a colored object, hold it near a white wall, notice the wall takes on the color of the object. Reason is light diffusely bouncing off the object. It happens on EVERY surface, no matter how shiny or dull. There are a few attempts to get that working in realtime, but usually with very low resolution and only a few key objects.

>caustics
the cool wavy lines of light on the bottom of a pool. They're the result of refraction, so it's a variant of "simple refractions". They look pretty though.

>ambient occlusion
Take a piece of paper, it has an even color. Fold it to an L, and the edge looks faintly dimmer. The reason is, that less ambient light can reach into that fold, because it has to come precisely from the open wedge. Often modeled nowadays using Screen Space Ambient Occlusion (SSAO), which is a very crude approximation, effectively just shading sections that show up as "edges" during earlier computations.

>tons of artifacts from the various performance demands
moire patterns when the textures are too high a resolution. Blurring when textures are too low a resolution. Transparent objects in front of transparent objects are still a challenge, because the z-buffer is worthless in these situations, probably a ton more I am forgetting right now.

>>3151802
>>3151832
>>3151838
Would the avergae normie gamer (non-videophile) even notice a difference if lighting and physics were accurately modeled?

It is probably better for the extra power of 9th gen consoles to be used to increase the framerate.

Games would have a 60fps seal of quality on their picture in the online shop were they are bought. A button on the controller would be mapped to drop the fps down to 30 so skeptics can see for themselves.

>>3152763
that's some weird obsession you have with the number 60. It's not some magical threshold. It's an arbitrary leftover from analog tv. you're blowing the thing way out of proportion, to ridiculous levels. you're not gonna get any support from anybody with that stance.

>>3153389
It will remain the magical threshold until every display will have freesync or similar technology.

>>3152763
>Would the avergae normie gamer (non-videophile) even notice a difference if lighting and physics were accurately modeled?
your strawman wouldn't notice higher framerate either, or worse, find it weirdly amateurish

>>3155721
That guy is right, no one gives a shit about realistic lighting when fake lighting does the trick at a fraction of the performance cost.

>>3155734
>when fake lighting does the trick
until it doesn't

>>3155734
>when 30fps does the trick at a fraction of the performance cost