Live data from Hacker News

MAR1D: First-Person Mario

mar1d.com

51–60 of 168 posts

Re: MAR1D: First-Person Mario

#53
post #51

TBH I was hoping for something a little more "realistic". I just see a line of squares moving around and seems unplayable.

Yeah I was hoping for something more like the Cruis’n USA racing games where the world is scrolling at you and your character stays stationary.

Re: MAR1D: First-Person Mario

#54
post #51

TBH I was hoping for something a little more "realistic". I just see a line of squares moving around and seems unplayable.

There are several VR 3D Super Mario Bros adaptations which are easily found on google. But of course they have to take liberties in the Z plane.

Re: MAR1D: First-Person Mario

#55
post #50
post #26

“this site proudly uses no javascript”, nerdy sites that don’t use modern css and or modern javascript most of the time have subpar user experience, I don’t read past the first sentence, it traps yourself into a niche of developers who don’t mind an ugly Design tradeoff

In what way could you make the experience of this site better with js?

i think they are just taking the piss out of people that say similar regarding sites that put up dark UI elements that prevent/slow down the reading of a site so that people bounce quickly. only, it just wasn't a good attempt at whatever was being attempted (humor/parody/sarcasm???). then again, maybe i'm just being way too nice to a non-coherent thought?

Re: MAR1D: First-Person Mario

#56

Something I've never understood about 2D/Flatland as a "visual" idea: In the case of this Mar1d, if I'm on the X-axis, and can only see the Y-axis, wouldn't any amount of detail in the Z-axis constitute a 3D image? The Y-axis stretched even a single "pixel" along Z would make it 3D, right? Similarly, for Flatlandia: If I'm a 2D square on the X-axis, and can see "around" me on the Z-axis, wouldn't my ability to see an…

A thing photographers / image-effects people think about a lot: pixels aren't little squares; they're sample points.

If you've ever played around with graphics-rendering — UV coordinate sampling, convolution, etc — then you know that you can think of a (2D) raster image as really being a grid of samples of what color you get when you look at the UV coordinate represented by the center of that grid-point on some underlying hypothetical continuous texture.

Which is to say: if you have a pixel-art image (i.e. one created at pixel scale, pixel by pixel, rather than created with continuous-art techniques and then scaled down), and you want to scale it up "conservatively", without making up any information that doesn't already exist in the image — then the right way to do that isn't to blow up the pixels themselves, nearest-neighbour style (as if the hypothetical underlying texture is a tessellation of infinitely-sharply-bounded little squares); but nor is it to stretch the image with bilinear/cubic/etc. resampling (as if the hypothetical underlying texture is a continuous blend from the color at the center of each sample into its neighbours.)

Really, the conservative approach to enlarging a pixel-art image, is to throw your hands up and give up — because you actually don't have the information for what occupies any UV coordinate of the underlying hypothetical continuous texture, other than the exact center-point of each grid square, where the pixel-art pixel sample is located. A pixel-art image, created from scratch as pixels, only really tells you what's at the exact center point of each grid-square. Every other possible sample-point in each grid-square is left undefined. If you picture an infinitely-small dot in the center of each grid-square, with the rest left "empty", that's the data you have about the "underlying image", from seeing a pixel-art image. Anything beyond that is "compressed sensing" — an inference, not a logical deduction.

But to directly address your point: you see pixels, because that's how the game has to be rendered — as a 2D extrusion — for it to show up on a screen for you to see. But in concept, the game is giving you a one-dimensional array of sample-points — a sampling of an underlying hypothetical one-dimensional continuous texture.

Re: MAR1D: First-Person Mario

#57

Well, we see the world as a 2d projection BUT we (usually) have 2 eyes so we have some amount of 3d-info. Maybe mario has 2 eyes too, which would give him some amount of 2d-info. (Just like an MRI can construct a 2d slice from 1d info). So the first person game should have maybe a depth info on those pixels. What I mean, mario does not see only a line. He sees a silhouette of what lies ahead of him.

I think it would require one eye above the other to have depth perception in his 2d world. Eyes can’t even be side-by-side as that axis doesn’t exist. Having said that, the human brain is capable of reconstructing a 3d perception with only one eye through learnt understand and interpreting the picture change over time as you move. I image it’s the same for Mario, but in 2d.

Yeah, as someone with a lazy eye 3d honestly isn't much different than 2d.

Re: MAR1D: First-Person Mario

#59

Well, we see the world as a 2d projection BUT we (usually) have 2 eyes so we have some amount of 3d-info. Maybe mario has 2 eyes too, which would give him some amount of 2d-info. (Just like an MRI can construct a 2d slice from 1d info). So the first person game should have maybe a depth info on those pixels. What I mean, mario does not see only a line. He sees a silhouette of what lies ahead of him.

2D Mario doesn’t have two eyes, he has one. If he is drawn with two eyes the second one would be inside his body and would not see anything as it’s view is blocked by pixels.
Post reply on HN