Would a game developed today with throwback visuals emulating the mid-90s 3D pre-rendered craze have something close to an actual audience?
Both this and "classic" straight pixel art-based graphics are borne of ingenuity and experimentation overcoming huge limitations. So what's the difference? Why does extremely minimal pixel art almost seem to validate a project creatively today by itself?
The stock responses are "pre-rendered looks like ass" / "pixel arts looks awesome". If you can spare the time, please do chime in with some actual argumentation on why do you think this is so
I would straight up say no but the idea of being able to accurately take the 3d render to a 2d form now would be easy to do now and honestly I would love to see a DKC where everything wasn't scaled down
What would be the point? Even the prettiest possible prerendered game will look like ass compared to a modern 3D game. The animation will be jerkier, the lighting will have discontinuities, the camera will be less dynamic and unless the sprites were designed with 4K in mind, it won't be as sharp.
Sounds interesting, but sincerely i dont think the average gamer would support the idea.
I'd rather have a dkc remake in a full 3D environment (with the same photorealistic style of the originals)
>dkc series were only good cause graphics meme
nah, the second game introduced several gameplay mechanics, added a lot of extra material and replay value, and managed to improve what was already impressive. even the gameplay was smoother and more consistent.
the third game was pretty much the same except for the shitier music and visuals (also the autistic baby 2bh)
It'd be simpler to program from the ground up than an actual 2.5 platformer, and exporting prerendered CG from Maya or Blender or whatever would be faster and more practical than handmade sprite art.
Mario & Luigi Dream Team did this with its character sprites. The game uses 2D sprites made from prerendered 3D models, it looks really nice and reminds me of what SMRPG could've looked like on better hardware. Definitely one of the better looking 3DS games aesthetically.
They're actually not prerendered from 3d models. The artists got rid of the outlines from past M+L games and upped the framerate, sure, but they're still hand-drawn sprites.
The style is meant to resemble "3d" though, so you aren't totally wrong but I still wanted to point this out
>If you can spare the time, please do chime in with some actual argumentation on why do you think this is so
Because pixel art fakes higher resolution by aligning features of the art to pixel boundaries. It's the graphical equivalent of font hinting. And the distortions needed to achieve this have a distinctive style of their own, so pixel art becomes a valid genre of art.
Pre-rendered 3D on the other hand is just a shit version of normal 3D. There's literally no reason to use it now that modern hardware exists.
Personally, I've never been a fan of pre-rendered graphics on older systems. They try to circumvent rather than work with the tile-based technology to give the illusion of quality. A lot of the opportunity for interesting art unique to the medium goes out the window when using this technique.
I think Yoshi's Island turned out to be such a graphical success partially because there was a protracted battle between the execs and artist over this issue. The execs wanted to replicate DKC's success with CGI while the artist argued for hand-drawn graphics. The influence of this tug-of-war can be seen in the wide variety of art direction of YI, and I think the artist made their point quite well that working intimately with your restrictions rather than circumventing them can lead to outstanding results.
That being said, hell yeah I asked my parents for Donkey Kong Country when I was a kid.
I was going to make side-by-side comparison pics with pre-rendered graphics and not, I know a lot series went pre-render back then, but I think I need more notable examples than just Lost Vikings 2 or HoMM.
Yeah, they're obviously a leftover from the grey background of the renders. If not erase them, at least change their color to be more consistent with the surrounding pixels. Donkey's alright in this respect.
I've always been of the opinion that 90% of pre-rendered 3D look like shit. I much prefer the look of games with competent art direction like Plok or Yoshi's Island as opposed to games that just use pre-rendered 3D as a cheap trick to look realistic.
That's not to say pre-rendered 3D can't have competent art direction, but it's usually used in place of it.
I think so. Remember that people didn't take pixel art seriously at first either.
I have a current obsession with pre-N64 early 3d, PSX and Saturn and 3DO and early DOS and so on. I think that is going to become a valid art style someday.
Only in the most roundabout sense. In that something like that was physically impossible to render in 3d in any sort of consumer hardware in 1994. DKC isn't a huge game, you don't really need that much storage space because the sprites and backgrounds aren't any larger than any other platformer.
Some PC games have really high res pre-render backgrounds, those probably took up way more space. The BG games max out at a 1 gig full install IIRC.
The original BG install was 5 CDs and most of those discs' content was huge area bitmaps, a full install was more than 2 GB then. They managed to compress them for later revisions, and the one I have is only 3 discs.
I find that prerendered backgrounds can be nice, but characters usually have that plastic appearance and they look like toys.
Of course he would deny it NOW, after DKC has become one of the most successful Nintendo franchises. Letting one of your most iconic designers shit on your games is bad PR. But back then it was likely for him to be pissed that Nintendo wanted him to use pre-rendered graphics for the next Mario game, which is why he gave it a super-cartoony style and justified it by using 3D background objects to give it an edge over DKC without using ugly CG art.
There would be no difference in terms of programming the engine, as it's sprite based regardless. The only thing would be, instead of providing a billion high resolution images on disc, that you'd have to stream and keep in memory, you just provide a model, and render it via parallel projection (no need for full world transform) into the "sprite". From there on the engine is just as 2D as it always was, but you get perfect resolution and smooth animation, even if the future will bring higher refresh rates or resolutions.
and it'll look like ass again on 16k HDRR displays. Never underestimate the development of technology.
Also, the only thing prerendered in RE are the backgrounds, which tend to not move as much. In fact, the RE characters are 3D models precisely for the reasons >>2944087 mentioned. More flexible and fluent animation, more faithful lightning and camera alignment
"pixel art" relies on the output being of very limited resolution. The endless "filter" fights we have nowadays are precisely because bitmaps do not define an interpolation method (nearest neighbor IS an interpolation method). Just like pre-rendered 3D is made obsolete by modern hardware, pixel art is made obsolete by it as well. In this case the high resolution takes away the need to tune the pixels, and the variety of resolutions requires to step away from bitmaps altogether and instead go for high quality vector art
they're talking about the grey pixels at the hat. They're a result of the render being anti aliased and in front of a grey background. You either got to render to transparent and support alpha, or render to a sharp outline.
It's not an issue of limitations but of wrong render settings or lazy cropping.
>nearest neighbor IS an interpolation method
It's not, because there is no standard number of subpixels per pixel. On CRTs it's not even consistent across the entire screen. Integer ratio nearest neighbor is literally the same thing as increasing the pixel size (with more subpixels per pixel).
correct, you need a shitton of memory to hold that sprite data, especially if you want to pretend these are not 2D sprites, but 3D models. People understand sprites to have a limited set of views. 3D models, not so much.
That's why on modern hardware it's much more efficient to just keep the 3D model around and render it just in time into the memory reserved for the sprite, or even straight into the scene, keeping a single pass render
>but characters usually have that plastic appearance and they look like toys
That's an artifact of the time. The plastic look is a result of using a phone shader for practically everything. It's possible, and has been done in the past, to render these objects with very realistic materials, that match the quality of the background
A pixel is not a little square. A pixel is a sample, within a logical grid. Its surroundings are undefined in terms of data. In order to map that logical grid onto a physical pixel grid, you need to computer intermediate samples. The most simple approach is to just take the value of the nearest sample, the nearest neighbor filter. Without doing that, you'd have a screen full of undefined pixels, as none of the screen pixels match the logical pixels.
>Random /vr/ user telling me to believe him over Miyamoto on Miyamoto's opinion.
>Calling Miyamoto a liar
This fucking meme about pre-rendered being crap and Miyamoto hating it and how superior you are by not liking DKC graphics has to be the most retarded faggotry ever.
also, you omitted the very important "especially if you want to pretend these are not 2D sprites, but 3D models". Because the implication here is that a 3D model can show any movement frame at any angle, and can have a lot of these frames. Bonus points if you can accessorize it (different player character outits, for example). With a 2D sprite you quickly hit a limit there, with tens of thousands of frames, which won't fit anywhere, SNES or otherwise. That's why 2D sprite animations, especially during the SNES times, have few frames that handle repetition well (loops), and avoid different angles (sidescrolling).
Compare against a game like Tony Hawk on the GBA. They decided to use a parallel mapped untextured 3D model for the player sprite, on classic bitmap backgrounds. The reason was what I mentioned above. The player needs to be able to perform any trick at any angle (movement direction and slope), with any of the skaters. That would have been way too much for even GBA carts. Keeping a handful of 3D animations on the cart though, and rendering them just in time, was possible, and ultimately done.
>none of the screen pixels match the logical pixels
Lets say you have a native 640x480 LCD and you want to display 320x240. Simply declare each pixel on the LCD as being made from 12 subpixels, and now it has a native resolution of 320x240. How you update those pixels is an irrelevant implementation detail, just like if the pixels are made of 3 subpixels. "Pixel" isn't something with an objective hardware definition, it depends on intention.
retro or not, pre-rendered looks like ass.
pre-rendered images looked bad in Mortal Kombat and pre-rendered 3D looked bad in Donkey Kong. You can only enjoy this games with some pink tinted nostalgia googles.
Donkey Kong Country ruined Rendering Ranger. It was supposed to be handdrawn and named Targa. I mean, in the end the game is one of the best looking prerendered games, but still, I want to see Targa.
logically a pixel is a sample within a grid, no exceptions. That applies to logical images, physical displays, anything. On the hardware level, a pixel is the smallest element of a raster display (subpixels are smaller, but incapable of reproducing the full color space). When outputting data on a raster display, a transformation from logical pixels to physical pixels must take place. That is, for each physical pixel the color must be determined based on the logical pixels. Whenever there's no exact match for a lookup, for example if the display has a different resolution, even if it's an exact integer multiple, an interpolation needs to be applied, to "guess" the missing sample.
In your example, declaring them as "12 subpixels" means that each of these "subpixels" has no equivalent on the logical image data, they map to parts of the logical image, that are not defined by a sample, so an interpolation needs to be applied, to fill in the blanks, and determine a color for the physical pixel. Nearest neighbor is one such interpolation. Bilinear is another common one. There are more complex interpolations with different qualities, some of them generic (bicubic, sinc), some of them domain specific (sal, super eagle)
>they map to parts of the logical image, that are not defined by a sample
They're exactly as defined as in the 3 subpixel case. Alternatively, you can say that the 12 subpixel case is really a 3 subpixel case, and the subpixels are overlapping and have weird non-contiguous shapes. If this is "interpolation" then native resolution is also interpolation. In no case do you ever have infinitely small pixels.
logical pixels are infinitely small, as they're point samples by definition. Physical pixels have a size, but for lookup reasons they're usually approximated as singularities. Usually, because when downsampling (several logical pixels result in one physical pixel) the sampling area can be defined by the shape of the physical pixel, though I'm not aware of any system actually doing that beyond approximating that region as a simple square. Also subpixels usually don't get their own lookup. The pixel is assumed to be one entity.
>If this is "interpolation" then native resolution is also interpolation
At native resolution each physical pixel's representation maps to a logical pixel in the image. It is not necessary to interpolate values. Physical interpolation happens by virtue of the physical pixel having a size and shape. That is, the physical output of the sample is not infinitely small, but has a size and shape. This might be a square of 3 colored lines (some LCDs), it might be a square of 4 colored squares (some OLEDs), it might be a blurry line (some CRTs), it may be a blurry circle (some other CRTs), it may be a cluster of light bulbs (stadium display), and so on. The common factor is that there's no control on the output below the size of a pixel, it's the smallest element of the raster display. So treating it logically as a singularity is a reasonable approximation. Otherwise the display driver would have to know the physical offsets of RGB components (the assumption of RGB components may not necessarily hold true) and perform a lookup for these offsets. I'm not aware of any software performing that kind of lookup.
>They're exactly as defined as in the 3 subpixel case
As described above, physical pixels are usually treated as monolithic entities. As such, there's a perfect match for each physical pixel, even if the subpixels are not physically in the exact same location. Per-subpixel lookup is highly uncommon, if it happens at all.
My suggestion would be, if you're going to make a pre-rendered game, just make it at a 1:1, high resolution -- that is, not the low resolution that suits pixel art. I think that would look fantastic because you can get all kinds of detail and the lighting/shadows and anti-aliasing will be as perfect as you render machine will allow. You get this nice WYSIWYG effect where everything is as the artist intended. Compared to real-time 3D, where on different machines, people might have to turn off AO, FXAA, turn down the resolution, turn off color correction, etc. And the animations might glitch or something. With pre-rendered that will never happen, everyone sees the final "beauty" render. Plus there's a huge performance boost because everthing is essentially baked to a quad, like how thousands of trees are billboarded for performance in a crysis game.
It's a great idea, but probably, if you're going to work in 3D, it's like you may as well just make it real-time, to get all the real-time benefits (dynamic rotation, perspective, lighting, animation blending, etc.)
on top of that, you are not stuck with prerendered or realtime 3D. A third option is rendering just in time. So what if it takes your GPU a full second to render that single static background? That's time you can use for a fancy transition effect, or start rendering it off-screen when you're about to leave the screen (player hovers over a "exit screen" marker), and then you can re-use that pic. You can render any camera angle and lighting conditions, but still get all the beautiful looks.
that's kind of what a lot of old 1st person dungeon crawlers do. The view of the dungeon, with the paths branching to the side, traps and whatever else matters at the moment is rendered just in time, from a small set of standard elements. It does not have to be realtime, since the rendered view is static, and players can handle transitions that take a couple frames.
Maybe if this is for a mobile game, that would make sense. Because you could reuse all the 3D assets but pre-render/bake at run-time to get the best possible render. For modern PCs, you have a case of diminishing return, ie. theres no point when you can brute force the same render on a medium/high end card and reasonably get the same result.
it's trivial to push a modern high end card into single digit fps and lower. Just add some radiosity and drop some imposters. The subject was rendering visuals that are too demanding for realtime. I just suggested that instead of pre-rendering everything, requiring large amounts of storage, rendering just in time, without a realtime requirement, can be a reasonable in-between option.
It's not a terrible idea or anything, but you still have a significant trade-off. Really, really nice static images, vs. average nice graphics that are fast and dynamic (as in, a fps where you can run around in it). In this case, I think you would have to describe the gameplay mechanics that justify the use of this just-in-time technique, I mean for people to be on board and truly understand what you're trying to do.
That was hideous. I recognised the main character from playstation magazines back in the day, I think. Game looked alright; reminded me more of Jazz Jackrabbit or Monster Bash than DKC, I absolutely hated the intro.
And holy shit that aliasing on the load screen.
FNaF is all pre-rendered, and pic related done by the same guy looks pretty good IMO
As somebody said, the music is much better than the graphics. And the game is satisfying and fun to play. Jumping on enemies feels fun, the levels are fairly well designed, you can play through quickly and it doesn't dick you, the barrel bits are hella fun. The list goes on - it's not perfect, but it's a good game.
have ye seen this, lads? the prerendered graphics were a big part of the look n feel of abe's oddysee & exoddus
I think modern gamers in general have an aversion to old 3D graphics. They appreciate 2D graphics because their limitations are seen as stylish, while the blockiness and low res textures of early 3D are just dated and "aged poorly"
Personally I like pre-rendered sprites, they sort of feel like a digital claymation sometimes.
Think Dungeon Master or Myst series. Games that have static locations, but a lot of them. The transition from one view to the next can take a brief moment (not a second, not half a second, less than that). Alternatively, think something like RE, but you can deliberately avoid bad camera angles, or show progression of the environment throughout the game.
Basically, any game that nowadays relies on static backgrounds, but you get to do more of them, and partially editable. In the Myst example, you can use that technique to render a full cube map, and then provide a standard cubemap viewer for a 360 degree experience, just like later Myst games had 360 degree views for their locations.
To clarify, the suggestion of just-in-time rendering is as a substitute for prerendering. In other words, the gameplay mechanics are identical to those of games with prerendered visuals. You only get to do more of it, because the storage constraint of prerendered imagery is not there. It's not for a new genre, or new kind of gameplay. Just a mechanism to tackle some of the shortcomings of prerendering, while still taking advantage of its strong points.
>pre-rendered looks like ass.
>please do chime in with some actual argumentation on why do you think this is so
I'm amongst the few people that always though DKC looked fucking hideous. I don't think is a issue with the idea of pre-rendered graphics but a issue on how was it done at the time.
>Bad models (lack of textures
>Bad lighting.(shiny look, shadows are too dark)
>Sprites aren't cleaned properly.
>Sprites perspective don't match with background perspective
>Sudden change from fluid animation to static animation.
I believe if its done correctly It can look great, sadly, can't think of any example of it right now.
>Why does extremely minimal pixel art almost seem to validate a project creatively today by itself?
Its the new fad. Is easier and faster to make, and they can hide the fact they barely put effor in their graphics with a 'is original, risky, new and looks retro' facade, while appealing at the same time at the nostalgia of people who probably never really played anything older than SNES games games.
I just mean that when prerendered sprites were popular, Phong shading was the standard and as a result : plastic, which I find ugly.
Now with all those fancy BSSRDF models, fur/hair rendering and let's not forget how 3D animation technique became better, of course you could make awesome sprites.
I agree with you, as I think prerendering wouldn't have any advantagesu upon models. I just wanted to acknowledge that, yes,you can make good looking prerendered sprites nowaday. But why would you? People won't notice the difference between a render and a nicely shaded model.
Plus you have more freedom with your camera, coherent lighting, smooth animations and outfit customization. Even sprite games have switched to 3D with Guilty Gear Xrd for example.