/vr/ - Retro Games

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

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

>>2710739
G-Zero looks awesome! I'd like to know what did author use to make this Mode 7-esque view.
Though it looks less smooth than its SNES original, I believe it is because the game is in development.

>>2710734
Sonic CD special stage
Jazz jackrabbit Special Stage
Wacky Wheels.

Is there anything aside from Genesis?


>>2710819
>Sonic CD special stage

AFAIK, sprite stretching and zooming was a Sega CD hardware feature, wasn't it?

>>2710739
That Wacky Races game never got released did it? I bet some scummy publisher pulled out at the last minute as usual.

>>2710871
All mode 7 is is the ability to rotate, stretch, and scale a background layer while having only a single sprite layer. Many other games do this, it was a common feature of the day. Nintendo just named it. It frankly isn't even that impressive considering you could only have one sprite layer and no other effects while doing it. Anyways the most impressive games are probably Road Rash and Super Hang-On
https://www.youtube.com/watch?v=DAprFOGApsQ
https://www.youtube.com/watch?v=cXJRpZyYgjQ
Power drift also looks pretty neat.
https://www.youtube.com/watch?v=eisCeK0HX8A

>>2710881
In that case there's Panorama Cotton. It's pedoshit though.
https://www.youtube.com/watch?v=ufVi3aL6ol0

I remember Alien Soldier, Contra Hardcorps, Ranger X doing mode-7 esque effects, but mostly just rotating backgrounds, no aerial view or flat texture bending.

>>2710886
That's all mode 7 is. It's just a rotating background.

>>2710893
I know, I mean, the perspective shifting thing.

>>2710734
Sega CD and Saturn had hardware inside to do that mode 7 background.

https://youtu.be/onFnV_swG2I?t=3881

>>2710897
So did PSX, I think? I remember there were no proper 3D consoles till the N64.

>>2710967
The psx only did 3d. It was not capable of rendering pallatized sprites. Simply sprite looking textures on a triangle

>>2710967
That has nothing to do with 3D. All you need for "Mode 7" is the ability to rotate a background. Sega CD has a rotation and scaling DSP, the Saturn has a very specialized background generator, and the PS1 would just rotate and scale sprites and backgrounds with the same chip that transforms polygons. N64 would do it exactly the same way.

The only advantage Saturn and N64 have is they can apply perspective correction (Saturn can only do it to backgrounds, N64 can do it to anything), but that's only situationally useful for 2D style games.

>>2710734
GBA had 2 or 3 F Zero games made in the SNES style, and a Mario Kart similar to the SNES one.

>>2710970
Wasn't the "3D" just sprites to begin with?

>>2710983
>2 or 3 F Zero games made in the SNES style
2, plus a JP exclusive (the best from the bunch).

GBA also almost got itself a Wipeout.

https://www.youtube.com/watch?v=1Bixb6ZVaxU

This whole thread is why layman shouldn't be taught about technical concepts.

>>2710734
Mode 7 is a hardware function, not a programming technique. All it is is 2D matrix multiplication and addition mapping a rectangular texture to screen.

Polygons in modern real time graphics hardware are a much more sophisticated way of doing in essence the same thing, except with polygons you can draw millions of em (as opposed to Mode 7's one).

>>2710747
Basic math.

>>2710993
>http://danielprimed.com/2009/09/visual-connection-%E2%80%93-raylight-studios-blue-roses-gba-tech/

Sonic 3 & Knuckles has bonus stages that could be considered Mode-7esque

>>2710970
>It was not capable of rendering pallatized sprites

Source: your ass

GP0 opcodes 64h through 67h are responsible for, guess what, drawing textured, palettized 2D rectangles of variable size, which you may as well call sprites.

There also functions for calling 8x8 and 16x16 tiles from the VRAM.

>>2711008
That was actually a brilliant use of palette cycling.

>>2710881
Space Megaforce would be a good example, then?

It's important to understand that many video chips let you tweak the display on a line-by-line basis, this is generally what people mistake not-mode7 effects for (vertical stretch/squish, bumpy roads that slide side-to-side, palette cycling for pseudo texture movement).

If you can set up a scene that is only enhanced by, but does not require, rotation or zooming of the tile map, then its probably usable on other systems. Notice a lot of 'fake mode7' effects use mostly blank or simple checkerboard textures for this sort of reason.

>>2710884
>pedoshit
How?

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

>>2711007
>Street Racing Syndicate
Used to have that. Amazing graphics but absolutely shit-tier framerate and even worse controls.

>>2711007
>draw distance

It reminded me Sega 32X demo tape somehow.

>>2710734
Sega CD had a bunch of games that did scaling actually better than the SNES, it could even create "bumps" in the road for racing games:

https://youtu.be/TcKrOKjhVPY?t=1255

More racing games are shown 28 minutes into that video.

>>2710991
WRONG, PSX cant do sprites, it was all flat polygons, the CPU could only do 3D, no 2D dedicated hardware was included on the PSX

>>2711508
Not him, but I thought the GPU only dealt in 2D, 3D vertices were provided by the CPU's GTE chip.

>>2711223
It's anime.

>>2711508
>>2710970
All polygons ever created by framebuffer based "brute force" rasterizers are flat polygons. A sprite is also a flat polygon, by definition. Saturn was also doing flat polygons.

PSX is also capable of using palettes and drawing quads, by hardware. (the quads are internally broken down to two polygons, but that is irrelevant since you tell the gpu to draw a square shape)

>>2711517
3d vertices were calculated in software (by the game engine), the GTE transformed those to 2d coordinates for drawing with the gpu. The GTE could also calculate per-polygon Z values based on the vertices, which you could use to sort your draw list with.

I think it could also do some matrix calculations for lightning, but I'm not sure.

>>2711664
you're a fuckin anime

>>2711049
Why, I know. I've even seen this at www.extentofthejam .com /pseudo/

The question is I am interested if there were more games that simulate background stretching, zooming and rotating. I believe Amiga games used it somehow.

>>2711701
It's just 1 huge texture that gets rotated. Any polygonal system can do that (obviously you are limited by the texture size and fill rate, but that's it).

>>2711664
>everything anime is pedophilic
Well ok, I'm not gonna waste time trying to change your mind.

>>2710734
>Mode 7
kek, try a real 3D game.
https://www.youtube.com/watch?v=q7Ow3w2DIRc

>>2711839
But that uses an external chip.

>>2712825
A lot of polygonal games on the Genesis don't though.

>>2712870
Because Megadrive was superior?

>mode 7
>external chips

get on my level plebs

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

>>2712897
We had Elite

Wacky Wheels.

Pretty much a Mario Kart clone for DOS.

>>2711006
>Mode 7 is a hardware function, not a programming technique
When people talk about mode 7 they often mean the angled plane thing, which is a programming technique, as the scale factor and layer offset is changed on every scanline.

>All it is is 2D matrix multiplication
unlikely. Usually a lookup table is involved. Faster, and simpler.

>much more sophisticated way of doing in essence the same thing
Doing an entirely unrelated thing, you mean.

>as opposed to Mode 7's one
Mode 7 has no "one" (polygon, or whatever). Any aspect of the translation and rotation of the background plane could be altered at any scanline. That includes wavey screen effects for transitions, and the "bent" underworld in Terranigma. You can't replicate this effect using a single polygon (or any number of polygons, for that matter)

>>2713410
>Usually a lookup table is involved.
Is lookup table stored on the cartridge?

>>2710881
This

>>2713410
>You can't replicate this effect using a single polygon (or any number of polygons, for that matter)

You can break down your texture into several small strips of polygons (say, 1 pixel tall), and then do the wavy thing on those, or stretch them out to different values per scanline. PSX games used to do effects that way (line scroll was used in many 2d games). So with a lot of polygons, you can indeed replicate the effect, accurate to the pixel, but it uses up more power.

Also, consider that many effects they used mode 7 for, are cheaper to do with polygons natively. In some cases it might even be faster to procedurally generate the effect (on a given texture) on the cpu.

And that's only considering late 90s hardware. If you consider "modern" hardware, then you can use shaders to do similar stuff.

>>2710881
Road Rash and Super Hang-on don't do screen rotation, they just change the background x/y scroll values per scanline to simulate depth. Road Rash also does software scaling.

Power Drift uses a vastly more powerful arcade board and builds the entire landscape out of a jillion scaled/rotated sprites.

>>2714127
look at the bottom end of the underword distortion in the screenshot, and you'll see that's kind of difficult to pull off with polygons, because it's non-perspective distortion. Shaders are not polygonal but pixel effects.

>>2713410
That game gave me nausea

>>2710747
contrary to what nintendo wants you to believe, mode 7 scaling was very doable by the genesis. Pier Solar makes use of it if I remember correctly.

>>2710871
Sega CD adds no real extra hardware except the ability to stream a buttload of data from CD.

>>2714127
>If you consider "modern" hardware, then you can use shaders to do similar stuff.
N64 had a color combiner unit built into the GPU so in theory you could do some rudimentary pixel shading

>all this hardware that was never used properly

god dang it man

>>2714432
Because an extra CPU doesn't count as "real hardware". Smells like summer in here.

>>2714430
Isn't Megadrive's Mode 7 held by software?

Can a Mode 7 floor (eg Sonic CD Special Stage) be simulated in Flash 8? I'm genuinely curious about this.

>>2711664
could've had an interesting post there, but nope, ruined it with /v/ shit from the get go

>>2714528
Sure it can, but this ain't the right place to ask.

Overall, how does Mode 7 work?

>>2715381
It's just a big sprite on which you can apply a 3s Matrix operation. It's a like a 3D card that can draw only one polygon, but with a texture on it. It was revolutionary.

>>2714874
Where is a good place? My Google Fu is weak.

>>2710734
I remember playing around with a similar effect in QuickBasic by using some basic trigonometry.

>>2715381
The SNES does tile based 2D graphics. A background, for example, is a grid of many regular tiles. A standard operation for this grid, that even the NES did, is simple movement/scrolling. It's used to make the background move, for example in platformers.
Mode 7 is a special display mode that limits the complexity of the background (for example just one layer), but offers two new and very important features: scaling and rotation. Instead of having one pixel on the tile map being one pixel on the screen, it allows to zoom out or zoom in. When zooming in, nearest neighbor filtering is used. Rotation is just flat 2D rotation. It does not yet allow to put the background plane at an angle.
So far it's just cool 2D graphics, so why is Mode 7 always about this whole angled plane? There's a trick to it. The programmer changes the zoom factor with every single scanline. When the SNES starts drawing the plane from top to bottom, the zoom factor is very small. The plane is seen from far away, but top down. On the next scan line, the zoom factor is a bit larger, so it seems the plane is closer, but top down. Then larger, larger and so on, until at the bottom of the screen the plane seems very close, still top down. All these individually zoomed pixel lines end up looking like an angled plane, if the zoom factors follow a certain progression. You see them as one angled plane, instead of many slices of a top-down plane at different distances.
If you want to be fancy, you mess with the zoom factors. Instead of the math used for a flat plane, you change the factors a bit around, and end up with distortions like on Terranigma's underworld.

>>2715420
is wrong, there's not a single polygon involved, there's no perspective camera involved. It's simple 2D scaling and rotation, which is modified per scanline. The only thing related to 3D is the progression of zoom factors, and as said already, it can be altered, to produce unreal effects.

>>2716130
There is one seemingly simple thing that Mode 7 can not do: You can not "roll" the view, like a banked horizon, or a wall (pic related). The reason for this is obvious, once you understand the scanline based zoom.
If you zoom per scanline, then each horizontal line on the screen needs to have a constant distance from the viewer, across its whole length. For a wall though, that's just not the case. The pic makes this easy to see. The wall is closests on the left, the most distant on the right. It would have to change zoom factor per "pixel column", but there's nothing to hook into to do that. A banked view is technically between a wall and a floor.
For a polygon it makes no difference if it's a floor or a wall, it's all the same matrix math. For Mode 7 though, one is trivial, the other impossible. That should show a bit better how Mode 7 not at all polygonal in nature.

>>2715430
>using some basic trigonometry
You just described ALL 3D computer graphics, no exceptions. Voxels, polygons, point clouds, it doesn't matter, the very foundation of 3D graphics is a projection onto a virtual screen, which is basic trigonometry. The rest is just data structures, optimizations (ways to save computations) and approximations (adding simplified assumptions and restrictions in order to save math. Raycasters and Mode 7 are examples of this)

>>2716130
>is wrong, there's not a single polygon involved, there's no perspective camera involved. It's simple 2D scaling and rotation, which is modified per scanline. The only thing related to 3D is the progression of zoom factors, and as said already, it can be altered, to produce unreal effects.
It's exactly all the transformation that are involved when rendering 3D. It's 3D but you suck to see it.
Having a big rectangle with a sprite you can render in any direction with position in 3D is exactly what is mode 7.

>>2716363
>Having a big rectangle with a sprite you can render in any direction with position in 3D is exactly what is mode 7.

see >>2716308 and >>2713410 You can't do the latter with a "big rectangle"

>It's exactly all the transformation that are involved when rendering 3D
The math to determine the zoom factor is the same as for 3D transformations, otherwise you won't get the flat plane. You can compute these factors once though, and put them in a lookup table, to be used during hblank.

>>2716130
>>2716308
>>2716372

You're awesome!

>scanline tricks

I suppose, this is the reason why there is no Mode 7 on PCs

>>2716485
The primary reason you don't find Mode 7 like engines as much on DOS is simply the lack of hardware scaling and rotation. The effect needs to be done on the CPU anyway, so there's no real "benefit" to doing a Mode 7 like effect compared to something else.
That said, at least two fairly famous games, Wacky Wheels ( >>2712935 ) and Skunny Kart used engines based on the concepts of Mode 7.

>>2713410
>When people talk about mode 7 they often mean the angled plane thing, which is a programming technique, as the scale factor and layer offset is changed on every scanline.

On the SNES messing with video registers per scan line is called Horizontal Direct Memory Access (HDMA) and is an entirely distinct concept from Mode 7.

Mode 7 is 1 out of 8 possible display modes the SNES can be in as controlled by video register BGMODE. Mode 7 allows the display of a single background that is transformed by an affine (matrix + translation) operation.

As you pointed out HDMA and Mode 7 can be used in conjunction for false perspective, warping effects, etc., but fundamentally they are independent concepts and can be used to great effect by themselves

>unlikely. Usually a lookup table is involved. Faster, and simpler.
Dunno about the implementation, but whatever it is, it's accurate up to at least 24 bits.

>Doing an entirely unrelated thing, you mean.
No.

Modern real time computer graphics pipelines are highly customizable now, however a simple graphics pipeline fundamentally takes geometry and textures as input, applies a matrix transform to the geometry, and then maps a texture onto the resulting transformed geometry.

The SNES allows you to specify an affine transform (2x2 matrix + 2x1 vector = 6 variables) which it uses to map a texture to the screen.

One could argue Mode 7 just lets you set texture coordinates using an affine transformation of a fixed geometry that spans the screen. You could write a specialized shader to emulate limited bit precision and special options.

>You can't replicate this effect
Terranigma's underworld could easily be reproduced in modern hardware and APIs. In OpenGL you could use a scissor test to limit the output of a drawn polygon to only one scanline. Iterate over all scanlines, change the matrix stack as you go, and draw the map.

In fact, scissors tests are effectively HDMA and Mode 7 is a 3D affine transform limited to 2D.

>>2716961
>As you pointed out HDMA and Mode 7 can be used in conjunction for false perspective, warping effects, etc
Any examples of this?

>>2716961
>but fundamentally they are independent concepts and can be used to great effect by themselves
No question there. It sounds a bit like you're nitpicking by saying "actually, that's not Mode 7, that's Mode 7 combined with HDMA usage." How that makes a point, I don't know

>it's accurate up to at least 24 bits.
Accuracy is not exactly relevant here.

>The SNES allows you to specify an affine transform (2x2 matrix + 2x1 vector = 6 variables) which it uses to map a texture to the screen.
That's planar scaling and rotation. There's no world transform, perspective transform, projection or anything of that sort in there. In fact, any perspective achieved is not because of the matrix, but because of the HDMA usage. That's why I said they're entirely unrelated.

>You could write a specialized shader
Pixel shaders are just that, they operate on pixels. You're back to the old school of software rendering engines. Only that in this case you have a couple hundred parallel processors to speed things up. However, to do THAT effect in a shader, you do not need any angled polygon. A fullscreen billboard is plenty. The geometry plays no role in the process, which was the whole point,

>limit the output of a drawn polygon to only one scanline
And you're back to per pixel/per scanline effects, making the actual backing polygons irrelevant.

>is a 3D affine transform limited to 2D
It's an affine transform. Affine transform is not limited in any number of dimensions. You could have 4D, 5D nD affine transforms. Their output is not very useful for graphics though.

And yes, among other things, scaling and rotation is done through affine transform. Trigonometry is everywhere. Trigonometry is not instantly 3D graphics though, and neither is a 2D matrix multiplication

>>2716974
What's usually called "mode 7" is a combination of mode 7 and HDMA, that anon was just nitpicking. Mode 7 by itself is not perspective, it's just planar rotation and zoom support. The perspective comes from changing the zoom of the mode 7 background per scanline. That mechanism uses HDMA.

>>2714209
>look at the bottom end of the underword distortion in the screenshot, and you'll see that's kind of difficult to pull off with polygons, because it's non-perspective distortion.

Break down the background graphics to a series of polygons, one per each line of the texture, and you can do the exact same effects as any other hardware that uses horizontal interrupts to modify the scroll coordinate of the background.

>>2717006
And by that point you're not using polygonal graphics anymore. You're crudely emulating scanlines, with polygons co-planar to the screen. You're not resolution independent anymore, you will have to adjust the size of the polygons with the distance, to keep their height exactly one screen pixel. You're in a world of hurt and achieved nothing.

>>2714432
>Sega CD adds no real extra hardware except the ability to stream a buttload of data from CD.

It adds a dedicated scaler, a pcm sound chip, an extra cpu, and quite a bunch of memory (which you need to cut down on load times anyway).

>>2714523
>Isn't Megadrive's Mode 7 held by software?

Megadrive had line scroll (change vertical position of a background every scanline), column scroll (change horizontal position of a background every 16 pixels in a line), and also it had horizontal and vertical interrupts (signal the cpu whenever a line or a frame is finished drawing.

Actually, I'm not sure if it had hardware line scroll, but with h-interrupts you change the background coordinate on the fly anyway.

You can combine the two to due rotation and even scaling, or generally insane special effects, but you had to compute the necessary scroll values for your effect in software. For rotation/scaling it could end up looking a bit crude since you can only update the column scroll at 16 pixel intervals.

Many games used those, from the top of my head: Castlevania (the tilting tower), Streets of Rage 2 (pirate ship), Kawasaki Superbike (rotates the background), Vectorman (boss on first stage, background on second stage), Panorama Cotton and Gunstar Heroes and Dynamite Headdy (everywhere in the game), Adventures of Batman & Robin, Virtua Fighter 2 (the ground), some levels in Contra, the Mickey Mouse game with that moose, the sega logo and title screen in Comix Zone, and the title screen in Puyo Puyo. Probably all racing games that used the perspective-warping ground too.

Also you had a bug in the columns scroll where the leftmost column did not update properly. You can see it in SOR2, Kawasaki Superbike, and on the first stage of Gynoug. Emulators have it fixed, but on real hardware you get glitches there. Castlevania got around it by only doing the effect on the middle of the screen!

>>2717018
>And by that point you're not using polygonal graphics anymore.

Technically you are still using polygons. Yes, you use them to emulate scanlines, but still. And it was done in commercial games too.

>You're not resolution independent anymore, you will have to adjust the size of the polygons with the distance, to keep their height exactly one screen pixel. You're in a world of hurt and achieved nothing.

You'd need the exact same math to do this as you would on a console that manipulates the background with horizontal interrupts, you only need to adapt your h-interrupt counter to count the polygonized lines instead.

The only downside is that it would eat more processing power and gpu fillrate, but you could even do an optimization pass and only send the lines for drawing that won't get obscured (not hard if you are only doing line scroll based perspective with no rotation involved for example).

>>2717083
>it was done in commercial games
Names and screenshots

>You'd need the exact same math to do this as you would on a console that manipulates the background with horizontal interrupts, you only need to adapt your h-interrupt counter to count the polygonized lines instead.
One major advantage of polygons is resolution independence. You sacrifice this advantage, must sacrifice it, to crudely emulate scanlines, because polygons are not able to replicate this effect, since it's not clean perspective projection.

>Technically
>you'll see that's kind of difficult to pull off with polygons, because it's non-perspective distortion.
You argued for the sake of argueing, so I guess there is that. Have a cookie, and claim yourself proud victor.

>>2716980
I'm not nitpicking at all. "Mode 7" as you claim people understand it is fundamentally HDMA + Mode 7. The OP's original question is if "Mode 7" could be emulated on other hardware of the day? In other words, could other consoles of the day provide HDMA (read per scanline effects) and Mode 7? The short is answer is no. While per scanline facilities where common, Mode 7 was only available to the SNES.

Of course with software any effect can be generated (obeying hardware restrictions), however it could be time prohibitive. For instance, a Gameboy could do "Mode 7", but the game would run at 0.01FPS.

However modern hardware is much more powerful than old stuff, and can fully emulate Mode 7 in hardware. My point is that a properly configured graphics pipeline could do Mode 7 on a GPU.

> Accuracy is not exactly relevant here.
Lookup tables operate on the principle of trading time for space, ie computation time for memory footprint of the table. Since the multiply registers tied to Mode 7 have at least 24-bit accuracy, I'm wondering if such a lookup circuit would be prohibitively large. I only know how to make basic multiply circuits, so I can't comment on this.

>That's planar scaling and rotation. There's no world transform, perspective transform, projection or anything of that sort in there.
Or in other words those matrices are set to identity, so if they were considered, they wouldn't affect the final transformation. Of course the SNES hardware doesn't keep track of this stuff, but my argument is that you can map SNES hardware onto modern hardware.

> Pixel shaders are just that, they operate on pixels.
> And you're back to per pixel/per scanline effects, making the actual backing polygons irrelevant.
"Mode 7" as you claim most people understand it as is fundamentally a per scanline technique, as you yourself have acknowledged. Do you not see the similarities?

> affine transform[s] ... [are] not very useful for graphics.
Are you retarded?

>>2717130
>For instance, a Gameboy could do "Mode 7"
Without pixel-precision access rotation is gonna be a world of hurt, and an exercise in futility.

>I'm wondering if such a lookup circuit would be prohibitively large
I'm not talking about a circuit. I'm talking about a table of precomputed values in ROM/RAM, that's just read and used during hblank. Since the individual zoom factors are constant if you maintain the same elevation and viewing angle, it makes perfect sense to skip computation of these factors, and just dump them as a table of 200 or so factors on the rom, when producing the game.

>my argument is that you can map SNES hardware onto modern hardware.
I don't get the point behind this, or what statement it is supposed to relate to.

>is fundamentally a per scanline technique
Which makes it rather dysfunctional in a polygonal context. You even suggested that the polygon would not actually be needed, as you'd implement the whole thing on the pixel shader. That was my point. Polygons do not help when emulating the effect.

>>2716974
The false perspective stuff is the poster child of HDMA + Mode 7. Just look most RPG world maps, F-Zero, or PilotWings.

The warping effects can be seen in games like Terranigma's underworld or Castlevania 4's cylindrical rooms.

Castlevania 4: (around 4:00)
https://www.youtube.com/watch?v=JICVErYZ4KQ

Sorry if you thought I meant something different.

Honestly I'm stil trying to figure out what's up with Chrono Trigger's time gauge background. I don't have a save atm to verify, but I suspect it's Mode 7 too with a wacky HDMA pattern. It may be a different BG mode though using an offset feature though, but I seriously doubt it...

>>2717156
>Chrono Trigger's time gauge background
Got a video of it?

>>2717152
>Without pixel-precision access rotation is gonna be a world of hurt, and an exercise in futility.

You just define a tile map that has a one-to-one correspondence to the character map and you can then emulate a bitmap by drawing to character memory. A gameboy is a turing complete machine, and Mode 7 is a computable function. It would be slow, yes, but doable. The only hardware limitation I can think of concern palettes, which unlike a true bitmap, an emulated one could have only 2^n number of colors, n depending on hardware and settings.

>I'm not talking about a circuit. I'm talking about a table of precomputed values in ROM/RAM, that's just read and used during hblank. Since the individual zoom factors are constant if you maintain the same elevation and viewing angle, it makes perfect sense to skip computation of these factors, and just dump them as a table of 200 or so factors on the rom, when producing the game.

Computing the values of the matrix on a perscan line basis isn't the computationally expensive part, which at worst running a handful of equations or a best table lookup. The hard part is applying matrix multiplication followed by vector addition on 256x240 individual pixels at 60Hz, which is why the hardware was revolutionary at the time.

>I don't get the point behind this, or what statement it is supposed to relate to.
The OPs original question:
"Are there any games that simulated Mode 7 on the other hardware than SNES?".
The answer is; old hardware no; new hardware it's possible.
Seems you forgot why you're in this thread.

>Which makes it rather dysfunctional in a polygonal context.
Dysfunctional or not, modern hardware can emulate Mode 7, and moreover do it millions of times a second. Just because the hardware is more capable doesn't change the fact that it can produce pixel perfect reproductions while still leveraging the mechanisms built into hardware (ie matrix multiplication).

>>2717195
>Mode 7 is a computable function
>Dysfunctional or not, modern hardware can emulate Mode 7
>which is why the hardware was revolutionary at the time.
So what? That wasn't even the subject

>The answer is; old hardware no; new hardware it's possible.
Yeah, how dare I say that polygons don't help for a mode 7 effect, obviously in the context of contemporary systems with polygonal capabilities (including the super fx chip, if you want). So naturally you whip out the latest pixel shaders to show me that no, polygons do work, and the Playstation could do this effect all along. It was just a massive troll by the devs to never use it.

Listen, nothing of what you said is wrong. And nothing of what you said is in any form relevant to what I said.
I was making a few posts on how the effect works conceptually and you suddently jump in with modern hardware and technically correct "solutions" that are thick layers of workarounds and inconvenience. If you think that contributes in any useful way, you're in a minority.

>>2717195
It looks like your posts were just convoluted ways to say

Few other system at the time of the SNES did Mode 7 like effects, because none of them had hardware support for scaling and rotation of tile maps, which are necessary for the effect.
There are some later software implementations in DOS and probably other systems, but they don't perform or look as good as the SNES, due to lack of hardware support.

That would have been a relevant, useful and on-topic post. It also would have been unrelated to what I said, and not a reply to my posts. So maybe that's where the confusion came from. My posts were part of a sub-thread, about Mode 7 being just a single polygon being 3D transformed, and, well, that's just not the case, as you know.

>>2710886
This.
Alien Soldier and Ranger X especially
and the mission briefing parts in Ranger X
are doing a pseudo mode 7 and 3D some of
>Pic related
>>2710734
To the Op look up Panorama Cotton on Genesis/Megadrive.

Did the Jaguar do Mode 7 in hardware?
https://www.youtube.com/watch?v=uSreTHiwi_E

>>2718387
according to wikipedia
>all graphics effects are software based

The speed seems sufficient to do something like that in software as well.

>>2718396
Have a Mode 7 style engine that was rather "late" to the party. DOS. Very smooth and playable though.

Here's a Mode 7 style engine that, I think, originated on DOS, and was ported to 3DO and Sega 32x/CD. It's interesting because of its obstacle density, and a night mode. Also interesting in terms of gameplay, due to the side car.

>>2718407
night race

>>2718407
I just decided to (re)play BC Racers and holy shit, that game is taking the concept of Mode 7 to its limits. There's dense jungle, lava pits, bridges, even a cave. The SNES can't do half of that due to sprite size and background count limits, but for DOS it's all software anyway. Grab the game, give it a run.

>>2718396
Jaguar was a beast.

Am I only one who thinks that Mode 7 or Mode 7-esque games still look fine?

>>2721017
yes

>>2721017
nah

>>2721025
this guy is a faggot

>>2717161
I suppose it is: http://www.youtube.com/watch?v=toIQ4rljIIY

>>2723918
10m mark is the time gauge background. I can't tell if the effect is generated by HDMA + BG Offset, or HDMA + Mode 7. If there is any "squishing" in the horizontal direction it has to be Mode 7, but it's hard to tell from the video if that's the case or not.

>>2724125
>it's hard to tell

Another video is needed?

In SNES9X at least you can turn off HDMA emulation so it helps you identify the effects.
I know some builds let you turn on mode7 smoothing too, so maybe that helps?

>>2710881
Tell that to Dracula x

>>2710734
Bloodshot on Genesis is a fps that emulates the "mode 7" feeling very well.

>>2728473
That is a raycaster engine.
It also has no texture on ceiling or floor.

>>2717093
>Names and screenshots

Not sure if they used 1 pixel tall stripes, but some games that used linescroll on PSX are Street Fighter, Mortal Kombat, Darius Gaiden.

>You sacrifice this advantage, must sacrifice it, to crudely emulate scanlines, because polygons are not able to replicate this effect, since it's not clean perspective projection.

Yes, you do. And? You can still replicate mode 7 style background effects pixel perfectly with polygon hardware. It's not like you need resolution independence anyway, since most games on, say, PSX or PS2 or Dreamcast run at a fixed resolution.

>>2728514
>And?
It's much more expensive to develop, much harder to control, much more resource eating, far less flexible and more error prone

>You can still replicate mode 7 style background effects pixel perfectly with polygon hardware
prove it. All games you mentioned have a plane at an angle, something that can be done much more effectively with a polygon mesh. Mode 7 is not restricted to planes.

Moving a pixel-tall strip back and forth does not work, because its height changes, and the PS is notorious for its "jumpy" polygons, so you can't even make them stick to one pixel line in that case.
Moving a pixel-tall strip does not work because each polygon needs a texture, mapped to it via uv coordinates. A mode 7 tile map is considerably bigger. That's likely also a reason why the games you mentioned have a shallow side scrolling plane, to keep texture size under control.
Moving a pixel-tall strip does not work, because if you were to rotate the plane, like in almost all famous mode 7 games, it means re-computing the uv coordinates every frame, which is ridiculously expensive.

>>2725984
>In SNES9X at least you can turn off HDMA emulation so it helps you identify the effects.

Could you point where is it exactly?

>>2728643
keys 9-0

>>2728649
All right.
It affects on the time pointer - it disappears.

>>2728535
>It's much more expensive to develop, much harder to control, much more resource eating, far less flexible and more error prone

Yes, there's an amount of trade off. But you are over estimating how difficult it would be to make or manage the effect (no harder than on the SNES).

>the PS is notorious for its "jumpy" polygons, so you can't even make them stick to one pixel line in that case.

The jumpy polygons are caused by rounding errors in the low accuracy math that the GTE uses to translate coordinates from the 3d space onto the 2d framebuffer. If you are already working strictly in 2d space, then you will bypass that completely. Or is there some bug where if you tell the GPU to draw a triangle with both vertex and texture coordinates v0(0,0), v1(319,0), v2(319,0), then it won't end up exactly as a 320 pixel wide, 1 pixel tall strip?

And even if triangles don't work:
1. PSX can draw rectangles (GP0 60h to 7Fh), and no, it does not split them up to triangles internally.
2. Do a VRAM to VRAM copy from texture to framebuffer, line by line. That might be even faster; you won't have to set up draw lists.

>Moving a pixel-tall strip does not work because each polygon needs a texture, mapped to it via uv coordinates
>if you were to rotate the plane, like in almost all famous mode 7 games, it means re-computing the uv coordinates every frame, which is ridiculously expensive.

Good thing then that the PSX has a co-processor for matrix multiplications! Really, you'd be doing the same as if you were rotating your plane, except you'd rotate the texture coordinates instead of the vertex ones.

And even if you are not using pixel stripes, you can probably do mode 7 effects in other ways I haven't thought of. The SNES -> Playstation RPG ports all managed to do it (Chrono Trigger, FF 4-5-6). I heard that those just emulate the SNES, but if you have enough power to emulate an entire system doing this effect, then surely, doing it natively can only be faster.

Closest thing to Mode 7 on the Genesis right now:
https://www.youtube.com/watch?v=fWNGNh8JDcQ

Wacky race floor is polygonal iirc

>>2728535
I described a way to do pixel perfect Mode 7 in this post >>2716961.

You consider the screen as a fixed polygon geometry (say two triangles), and you compute the 2D texture coordinates at the vertices of the triangles using a 2D affine transformation. This lets you do Mode 7 using modern GPU hardware.

If you want to reproduce per-scan line effects, just set up a scissor test, or do something with the stencil buffer, or hell, use the depth buffer and draw geometry at different depths. There are lots of ways to do it. This let's you do HDMA using modern GPU hardware.

These techniques are easily implementable in any graphics library using core ideas. To say this is not a way to implement "Mode 7" is to hide your head in the sand.


>>2728746
I heard that PSX polygons look jumpy because the PSX interpolates textures in screen coordinates rather than in scene coordinates. In other words, it incorrectly implements texture mapping. The trade off was slight distortion vs. more polygons/second and simpler and cheaper hardware design and development.

In contrast the N64 _did_ implement correct texture mapping, and as such does not suffer from jumpy polygons. From what I understand, this was impressive for (any?) hardware at the time.

>>2728801
>I heard that PSX polygons look jumpy because the PSX interpolates textures in screen coordinates rather than in scene coordinates.

That would make sense. But it would not be a problem with what I proposed since the "scene" and the screen would have the same sizes.

>>2728801
>I heard that PSX polygons look jumpy because the PSX interpolates textures in screen coordinates rather than in scene coordinates. In other words, it incorrectly implements texture mapping
The PS uses affine transform for texture mapping, which is not perspective correct. That's not the cause of jumpy vertices though, just the "wobbly" textures (which also get in your way when moving around uv coordinates)

>>2728808
>what I proposed
That right there is the strongest indicator that it just doesn't work, or is not efficient, or useful. Otherwise it would have been done.

All you're argueing is convoluted techniques to somehow maintain the claim that you can do a crappy 2D effect on a system that doesn't need it anymore.

>>2729301
>on a system
Should probably clarify, I don't know, or care, if the PS can do native HDMA, that wasn't even the subject. The subject was merely whether you can do the effect using polygons. You can't, not without resorting to crudely modelling scanlines, which means pissing away all the reasons you started with polygons to begin with, and introducing tons of overhead and issues. The key difference is and remains that the Mode 7 + HDMA effect is not 3D in its nature, there are no 3D primitives involved, and it's not subject to any parallel or perspective or otherwise projection. As such, anything using polygons and a projection will hit issues, and has to work around it, or better, don't try to emulate something using the wrong tools.

>You can still replicate mode 7 style background effects pixel perfectly with polygon hardware
>prove it.

That's what I did. You seem to acknowledge that it's possible to map the technique to modern hardware, but that my solution is invalid for some bizarre reason because you feel it's inefficient or something. So what? You contested that it can't be done when it can.

> That's not the cause of jumpy vertices though
Not the cause of jumpy verticies, but I'd argue that when most people talk about "jumpy polygons" in relation to the PSX they are referring to the distortion brought on by the perspective incorrect texture mapping, just as you've argued most people refer to "Mode 7" as what is properly Mode 7 + HDMA.

This effect is most obvious when a line in a texture multiple polygons forming a flat surface. As the image plane becomes less parallel to the polygons and oblique incidences, the line will appear to zigzag. It seems weird that some flat surfaces are broken up into many more polygons than needed on the PSX until you consider it's to mitigate the distortion introduced by the approximate texture mapping done by the PSX.

>>2728746
This guy knows what's up. My question is were jumpy verticies really an issue with the PSX? I can't remember seeing any artifacts because of low precision vertex transformation math that I didn't put down to jerky animation.

>>2729319
> La! La! La! La! I can't hear you!!!
This faggot. He knows he's wrong.

>>2729350
>I'd argue that when most people talk about "jumpy polygons" in relation to the PSX they are referring to the distortion brought on by the perspective incorrect texture mapping
You'd be wrong

>my solution is invalid for some bizarre reason because you feel it's inefficient or something. So what?
You're missing the point of the question, and working so damn hard on pissing away all features of polygons, treating them like scan lines, which fucks with so many aspects of a rasterizer and ultimately rendering it useless. What you're missing in all this, you're not using polygons at this point anymore. You're using scanlines, done on a different logical level. You argue for the sake of proving someone wrong while missing the actual subject, that mode 7 simply does not render a plane, so there is nothing planar for polygons to mimic.

>>2729301
>That right there is the strongest indicator that it just doesn't work, or is not efficient, or useful.

And the fact that you keep repeating IT CAN'T BE DONE is the strongest indicator that it can be done. Clarke's laws, bitch.

And it worked fine on, for example, Darius Gaiden:
https://www.youtube.com/watch?v=5HhNHytuMCk

Check all of Zone H, especially the boss with the plasma effect. It looks absolutely psychedelic.

There was also another PSX game that did 2d rippling for stuff inside water, but unfortunately I don't remember its title. It may have been a polygonal sidescroller.

>All you're argueing is convoluted techniques to somehow maintain the claim that you can do a crappy 2D effect on a system that doesn't need it anymore.

So now that you are proven wrong, you are trying to dismiss the effect as pointless. Classic argument right there.

>>2729357
Try to do a wavy linescroll effect (like, say, the screen transition in the Dice Palace in Gunstar Heroes), and tell me how you'd do it with polygons alone. On a Playstation 1.

>>2729441
linked to the wrong post? Because that's my point?

>>2729429
>IT CAN'T BE DONE
You're not working with polygons per se at this point anymore, why is this so difficult for you to grasp?

>Darius Gaiden
most of the later stages look like regular parallax scrolling. I can't get it to run right now, so I can't look at that first stage on a different resolution. Kind of suspect parallax scrolling or a polygon strip. Wouldn't be a problem, since its visual is a flat plane.

>PSX game
It's not about the PS, it's about polygons.

>dismiss the effect as pointless
I kind of suspected you're argueing from a "the PS is oh so superior" angle. Thing is, it's not about the PS, or the SNES. It's about the effect used, and polygons. Nobody is trying to knock on the PS or SNES, or calling either system incapable in some sense. That particular effect simply relies on HDMA effects and a 2D transformation. If the PS can do that, cool, no problem, that was never even up to debate. If the PS would be using polygons for that, it'd be in a world of hurt, since it's ridiculously complicated to do it with polygons, when there are many more better options available.

>>2728514
>Street Fighter, Mortal Kombat, Darius Gaiden
All three games feature a ground plane that scrolls parallel to the camera. The plane is not being rotated around the up axis (map rotate), the camera does not move towards the plane, or away from it (scale/zoom).
That means, this particular effect would not even need Mode 7 on the SNES. It's parallax scrolling. In fact, on the SNES you would instead use one of the modes that has more background tile maps, without the scaling and rotating, to increase the number of parallax planes. The PSX probably has a field day with that effect, as it's just polygon layer on polygon layer, all parallel projected and moved at different speeds. It can outperform the fixed layer model of the SNES there easily.

>>2729487
>You're not working with polygons per se at this point anymore, why is this so difficult for you to grasp?

If I'm sending the GPU a draw command to render a polygon that is 1 pixel tall, then I'm still working with polygons. Yes, I use them to emulate scanlines, but that does not matter, since it's just my draw command of choice to rasterize a line. (and I'm using polygons as an example because then you can do other types of shading on top, entirely in hardware).

You could even do it by drawing rectangles, or directly copy the data in VRAM to framebuffer, or even handle the effect entirely in CPU and just upload the precomputed texture to the gpu. Whichever is possible and is the fastest on the target system.


>I kind of suspected you're argueing from a "the PS is oh so superior" angle.

I'm not having an angle here. I'm just using the PSX as an example, since it cannot do perspective correction, so you'd need to go to additional lengths to simulate such effects with its hardware with per-pixel accuracy.

>>2730305
and you could even get rid of textures or tile maps all together, by using square flat shaded polygons, each of them 1x1 pixels in size. Of course you'd argue that's using polygons to produce graphics, and I'd hope anybody with even casual interest in graphics would point and laugh.

>>2729487
>If the PS would be using polygons for that, it'd be in a world of hurt, since it's ridiculously complicated to do it with polygons, when there are many more better options available.

It's not "ridiculously complicated".

for (i = 0; i > framebuffer.height; i++) {
x = Math.cos(i/framebuffer.height * Math.PI) * 30;
vertexCoords((x,i),(x+framebuffer.width,i),(x.framebuffer.width,i));
textureCoords((0,i),(texture.width,i),(texture.width,i));
drawTriangle(vertexCoords,textureCoords);
}

This draws a background that ripples horizontally according to a sine wave to a maximum of 30 pixels in either direction. Yes, you could do it in other ways too, but then you wouldn't be pixel accurate to how scanline tile mappers do it.

You can modify the cos() function there to manipulate the offsets, or change it to add vertical rippling, skew or pinch the graphic, etc. You could also manipulate the texture coordinates instead of the vertex ones, apply a matrix transform to them to rotate the graphics, etc.

One thing this pseudo-code does not take into account is repetition, so you are only transforming a single background once. That could be fixed by drawing multiple stripes per line depending on the amount of deformation you apply. Of course if you are doing an infinite plane like in the OP pic, then you'd end up with excessive amount of stripes, and that would definitely require a different solution.

Yes, you can do similar effects with large triangles, but they would suffer from affine distortion and they wouldn't be pixel-perfect. Which some games would need, if you wanted to make them look accurate. Picture related.

>>2730310
Okay, now you are the one arguing for the sake of arguing. And it looks like you completely skipped my point that:

>I'm using polygons as an example because then you can do other types of shading on top, entirely in hardware).

>>2730351
>This draws a background that ripples horizontally according to a sine wave to a maximum of 30 pixels in either direction
No Mode 7 needed for that one. Mode 7 introduces affine 2D transform to background planes. vertical or horizontal offset change per scanline is a HDMA effect and can be done on other modes as well.

>You could also manipulate the texture coordinates instead of the vertex ones, apply a matrix transform to them to rotate the graphics, etc.
So, naturally, you know of games that did this, because it's so easy and useful and leverages the abilities of the platform.
What you provided is a "technically correct" solution, that fails to understand the problem posed.

>Yes, you can do similar effects with large triangles
Again, I refer to Terranigma specifically because it does not show a flat plane, it does not even show a curved plane. It shows arbitrary, non-projected distortion. So anything using a projection is not gonna help.

>it looks like you completely skipped my point
Back to you. You went to great lengths to show how polygons can pretend to be scanlines, and think for some reason that shows how polygons can perform Mode 7-like effects, instead of it showing how scanlines can be used for scanline effects. What you're missing, or dismissing, is that you're applying a workaround that gives you scanlines, instead of polygons. All I did is take your workaround one step further. I don't even need textures anymore. Flat shaded polygons are fine. That's missing and dismissing the whole concept of a polygon though, a vector-defined shape, resolution independent, usually not tied to logical pixels at all.

>>2730368
>No Mode 7 needed for that one. Mode 7 introduces affine 2D transform to background planes. vertical or horizontal offset change per scanline is a HDMA effect and can be done on other modes as well.

But it cannot be done directly on polygon based graphics hardware, only by simulating it with "tricks", of which the ones I posted are just a few methods.

>So, naturally, you know of games that did this, because it's so easy and useful and leverages the abilities of the platform.

I'm not familiar enough with PSX games to give you a dozen titles right now from the top of my head, if that's what you want. But I'm sure that if you look through ports of 2d games, you are bound to find some. I already pointed out Darius Gaiden (the boss fight in the hyperspace section has a plasma ripple), and Cotton Original definitely uses stripes for the rippling text in the credit roll (and for the parallax in the options menu and title screen, even if those are taller than single pixel blocks).
Or, you know, the ports of the SNES Final Fantasy and Chrono Trigger games, which had no problems bringing the mode 7 effects over.

>Again, I refer to Terranigma specifically because it does not show a flat plane, it does not even show a curved plane. It shows arbitrary, non-projected distortion.

And it can be replicated pixel accurately on a polygon based hardware with the pseudocode I posted above, you just have to punch in the same code that generates the arbitrary distortion.

>What you're missing, or dismissing, is that you're applying a workaround that gives you scanlines, instead of polygons.

I'm not missing nor dismissing it, in fact I started the argument with the fact that this is a workaround to simulate scanlines and scanline based special effects on a framebuffer based system. And I already told you that it is a trade off that has its own drawbacks, primarily by the amount of draw commands you bomb the GPU with.

>>2730368
>That's missing and dismissing the whole concept of a polygon though, a vector-defined shape, resolution independent, usually not tied to logical pixels at all.

It's neither missing nor dismissing that fact, it just does not use it to its advantage. Just because it is what it is, does not mean that you must use it for that function.

I already told you that you could be using the draw rectangle command. Or manually move data in the VRAM. Or do it in software. But then you would be missing out some other advantages of using the draw triangle command, like the fact that you can do scaling or shading (on the PSX, anyway).

And yes, you could draw every pixel one by one too. You could be drawing it in the CPU completely. Whichever solution gives you the best results and the best speed. There is no limit.

>>2730396
>it cannot be done directly on polygon based graphics hardware
Unless you render into a render target, then use HDMA when projecting. As we established, you can do everything with enough workarounds. I see you do understand the concept at least when you want to.

>a dozen titles
I'm not picky, one is plenty. Should have actual Mode 7 related effects though, like rotation, and scaling.

>Cotton Original definitely uses stripes for the rippling text in the credit roll (and for the parallax in the options menu and title screen, even if those are taller than single pixel blocks).
Parallax mapping is fun. Though it sounds awkward if the PS needs to abuse stripe polygons to achieve the effect.

>polygon based hardware
Yeah, at this point I suspect you are intentionally missing the point. I'm done trying to get my point across to you. Others reading the thread can form their own opinion.

>>2730408
look, some asshat earlier in the thread already threw junk along the line of turing completeness at me. I don't care that you can technically compute anything on a general purpose computer. That's not what my casual remark was ever about. Just in case you missed it, since it's been days ago
>You can't replicate this effect using a single polygon (or any number of polygons, for that matter)

From this on you probably took a statement, that means the map shown on Terranigma is not a 3D object, does not obey geometrically consistent projection and hence has no polygonal equivalent, as a challenge, and devised computationally feasible, but not really useful workarounds, that openly reject 3D construction of the mesh (because it's not possible, as I said) and for some reason think you're making a point.

So just for you: You're technically correct, you win, have a cookie. That what you want to hear? Have at it. I don't give a damn. I'm not here to win. I tried to make a few high level posts on the concept of mode 7, for people with curiousity and casual interest, not more, not less. All you did was derail the thread into a deeply technical and ultimately useless exchange about crude workarounds, not seeing the forest for the trees. Well done, I suppose. A well deserved victory cookie.

>>2730409
>Unless you render into a render target, then use HDMA when projecting.

Framebuffer based gpus don't have horizontal interrupt based direct memory access. So you have to do this in software, and since you want to change some parameters per horizontal interrupt (ie. per scanline), the logical solution is to draw the graphics per 1 pixel strips, simulating scanlines.

I was using polygons because it has other advantages, but in the end it's just a select tool for rasterizing, you could use many other tools as well.

>Should have actual Mode 7 related effects though, like rotation, and scaling.

Final Fantasy Anthology, Chrono Trigger.

>Yeah, at this point I suspect you are intentionally missing the point.

Right now I don't even know what the hell is the point you want to make? I posted examples of games that replicate per-scanline effects, I posted pseudocode that replicates per scanline effects, I described potential drawbacks, and all you come back with is BUT THAT'S NOT HOW YOU USE POLYGONS, even though I already mentioned three or four other ways you can do the same without polygons.

I feel this is just a circular argument now.

>>2730450
>the logical solution is to draw the graphics per 1 pixel strips, simulating scanlines
and the logical solution is to do that on the pixel level of the frame buffer, not the polygon level.

>Right now I don't even know what the hell is the point you want to make?
No kidding. That much was obvious a handful posts ago.

>even though I already mentioned three or four other ways you can do the same without polygons.
Fun stuff, because the polygons were the original subject, not the feasibility of the effect on the PS or any other platform.

>I feel this is just a circular argument now.
Probably because you keep argueing useless shit, because you failed to see the original subject and just needed to tell someone they're wrong on the internet.

>>2730449
>computationally feasible, but not really useful workarounds

I've yet to see you post a more useful way of replicating that effect on systems that use fast framebuffers instead of scanline based background processing.

>>2730465
>and the logical solution is to do that on the pixel level of the frame buffer, not the polygon level.

The pseudocode I posted does NOT work on polygon level. It works on a per-pixel level for every line in your framebuffer.

It only uses the polygon draw command because I used the Playstation as a context and maybe you want to apply additional shading or vertical scaling of the graphic or whatever, which the Playstation can do with that specific draw command.

You could do the same using draw rectangle commands. Or entirely in main memory if you wanted (however that may be slower since GPUs usually have much faster memory bandwidth since they are designed to handle such tasks). Or use OpenGL compute shaders or whatever else gives you a boner. This is maybe the fifth time I'm saying this, and it is the point you are purposefully skipping so you can say that I'm arguing useless shit.

>>2730483
>I've yet to see you post a more useful way of replicating that effect on systems that use fast framebuffers instead of scanline based background processing.
Largely because that's not my battle, just yours.

>The pseudocode I posted does NOT work on polygon level. It works on a per-pixel level for every line in your framebuffer.
So it's entirely irrelevant to my original point.

>use OpenGL compute shaders or whatever
Which is also irrelevant to my original point.

Here, I'll help your reading comprehension once more
>You can't replicate this effect using a single polygon (or any number of polygons, for that matter)
and because that was too complicated for you
>does not obey geometrically consistent projection and hence has no polygonal equivalent

You're argueing loudly and furiously that the PS, OpenGL and all kinds of buffer manipulations can do Mode 7 effects. I don't give a shit. That's never been contested, or the subject, or in any form relevant.

The only thing that was remotely relevant was the polygon stripes approach, which was missing the whole point, regarding mode 7 and the purpose of polygons, and was just an attempt at being technically correct.

>>2730465
>>2730492
>>2730450
>Right now I don't even know what the hell is the point you want to make?

The real question is what point are you trying to make?

Everyone in this thread is proving you wrong about your pet idea that Mode 7 can't be mapped to modern hardware. In fact there seem to be several ways to do it, all leveraging hardware by specifically using polygons and texture mapping to achieve pixel-perfect reproduction of the effect. You have been deflecting repeatedly saying either the solutions are invalid or miss the point of discussion.

At this point it seems like you're butt-hurt about being wrong, because you seem to dumb to be a troll. Your understanding about mode 7 and computer graphics in general sucks, and all you're doing is flaunting your ignorance.

> technically correct.
The only kind of correct that matters.

>does not obey geometrically consistent projection and hence has no polygonal equivalent
Techno-babble. You are trying to use big words and concepts and failing miserably.

>>2710739
>G-Zero
Why not make this a Sega CD game so that people with Sega CD consoles can burn it and play it on real hardware?

>>2730606
it's just a proof of concept, not a game.
real hardware is overrated anyway

>>2730591
>The real question is what point are you trying to make?
Once more, heh?
>You can't replicate this effect using a single polygon (or any number of polygons, for that matter)
>does not obey geometrically consistent projection and hence has no polygonal equivalent

>Mode 7 can't be mapped to modern hardware
Wasn't my claim

>using polygons
Not modelling the object seen, just using it to emulate scanlines

>the solutions are invalid
When the polygons are emulating scanlines, instead of modelling the structure

>Your understanding about mode 7 (...) sucks
What things I said about the mode were wrong?

>Techno-babble
The original post, several days ago, was in reaction to someone saying mode 7 is essentially a single polygon, turned and angled arbitrarily. I used Terranigma's usage of the mode and hdma to show that a single polygon is insufficient to model this structure. On top of that, the way it's drawn in Terranigma does not resemble any 3D structure. Especially the bottom couple lines show heavy distortion. That caused me to state that this curved surface can not even be modelled in polygons. Even if you got an arbitrary number, to model the curvature, the distortion is not possible with a polygonal structure. You need additional processing or 2D post processing effects to achieve that.
Some folks just took my statement as a challenge and devised schemes how to work around the stated issue (inplicitely acknowledging it that way) or bypass it entirely (again, proving my original statement valid)

>>2730614
>>You can't replicate this effect using a single polygon (or any number of polygons, for that matter)

But it was just pointed out how it can be done, using polygons.

>Not modelling the object seen, just using it to emulate scanlines
>When the polygons are emulating scanlines, instead of modelling the structure

It's the end result that matters, and the end result is that we can replicate that effect in Terranigma, on hardware that plots polygons on a framebuffer, that is also without any form of per-scanline drawing or HDMA.

Yes, it's a trick, a workaround, name it however you want - but tricks like these are what give you the most unique effects on literally every console. You can use tricks to draw circles on hardware that can only draw squares, or to display 200+ colours on the 64-colour Megadrive, or to create motion blur on the Playstation, or to do bump mapping on a Saturn, or to do cel shading on the Dreamcast.

Whether we use textured polygons per line or 1x1 flat shaded polygons per pixel is irrelevant. Both of them would work, and so would entirely software processing, and so would emulating an entire goddamn SNES to do the Terranigma effect for us. The only relevant questions, should we ever implement any of the proposed techniques, is:
- does it end up looking the way I want it to look?
- is it fast enough for my purposes?

If the answer is YES to both, then the method you use is the correct one.

>>2730657
>It's the end result that matters
You're still missing the point.

>tricks (...) give you the most unique effects on literally every console
Ok, that's it, shut your fucking trapping you retarded asshole excuse of a technical troll. The whole HDMA messing with the settings of Mode 7 is a damn programming trick. People are well aware of tricks. It's your fucking imbecile braincell that fails to grasp a simple statement and now you're coming off like a high and mighty wannabe expert like a bad Sheldon imitation.

>Whether we use textured polygons per line or 1x1 flat shaded polygons per pixel is irrelevant
Look, shithead. It is not, never was, and never will be about the ability to replicate the visuals. It's about the displayed object not being a 3D object, and hence the impossibility of modelling it as one.
Everything else is your, and entirely your, goddamn narrowminded obsession with exclusively your viewpoint.

>then the method you use is the correct one.
Once more with feeling, because apparently you can't read for shit: It was never once about how to make another system have a similar looking effect. All this is a strawman in your deranged fucking head. Get it between your goddamn ears you piece of shit. Give me the fucking mesh of the effect used in Terranigma, including uv coordinates, and I'll shut up. Can't do that? Too fucking bad. That's because you can't model this thing as a mesh, and all you can do is squirm and shit bullshit about trickery and turing.

>>2730657
>But it was just pointed out how it can be done, using polygons.
deliberately ignoring my second statement I consider you nothing but a troll at this point, because that takes malicious intentions by now. You may have knowledge, a lot of it, but you have absolutely no idea how to read, or understand the problem. It's not a programming problem. The strawman in your head is, that's all.

I'm just going to leave this here...

>>2730691
>deliberately ignoring my second statement I consider you nothing but a troll at this point, because that takes malicious intentions by now. You may have knowledge, a lot of it, but you have absolutely no idea how to read, or understand the problem. It's not a programming problem. The strawman in your head is, that's all.

It's a problem of you repeatedly trying to move a square peg through a round hole, even after you are pointed out the square hole.

>>2730821
wouldn't you still have perspective errors on that if the hardware (for ex. PSX) does not support perspective correct texturing?

Also, I think you would have issues if your texture coordinates are larger than the vertex coordinates - and infinite playfields would not work either.

Nice visual guide though. Saved.

>>2710881
>Power drift
lol that was a fucking super scaler game with 3 68k cpus

>>2730857
>wouldn't you still have perspective errors on that if the hardware (for ex. PSX) does not support perspective correct texturing?
Naw dawg. Notice how all of the polygons I drew are parallel to the plane of the screen? This is the one special time when texture interpolation in screen coordinates equals interpolation in scene coordinates.

Also I would use an orthographic projection matrix (think how a blueprint is drawn) to essentially bypass the perspective divide. Thus even if I wanted to use 3D to implement HDMA effects using z and the depth or stencil buffer somehow, perspective effects wouldn't be present.

Good question.

>>2730857
>Also, I think you would have issues if your texture coordinates are larger than the vertex coordinates

Actually this method is advocated precisely because it allows you to set the texture coordinates larger than 1, which is important if you wanted to, say, repeat the texture twice on screen.

Infinite playfields are no trouble if you set the texture coordinates correctly. Really this technique boils down to setting texture coordinates in a way that the results mimic mode 7.

Also I would like to point out that the HDMA + Mode 7 method on the right let's you use the solution on top at the cost of overdraw, while the solution on the left has no overdraw at the cost of more complexity in figuring out what the right texture coordinates are.

Sorry to double post, but overlooked this.

>>2731145
Wait, if you specify texture coordinates which overflow (ie. are larger than the texture), you end up repeating that texture? I did not know that was possible. I thought it would just load the "next" texture, the one that is subsequent to the data you specified.

As for perspective correction I think you'd get errors if you, for example, tried pinching the texture coordinates so your playfield is trapezoid. ie. the top is thinner than the bottom. Or, to not mix in the overflow issue I mentioned above, make it so the top is normal but the bottom is "wider" (which means that the texture coordinates for the bottom two vertexes are "thinner", since you are modifying texture coordinates while keeping the vertex static - if you can follow my half-assed explanation).

>>2731270
>Wait, if you specify texture coordinates which overflow (ie. are larger than the texture), you end up repeating that texture? I did not know that was possible. I thought it would just load the "next" texture, the one that is subsequent to the data you specified.
On modern APIs you can specify the overflow behavior to either "clamp" (prevent the overflow and just stick to the highest or lowest actual coordinate available) or "wrap" (start over on the other side)

>>2730828
It's not a programmng problem. The strawman in your head is.

>>2714127
>Road Rash also does software scaling.
I thought there was just a bunch of different sprites for different distance.

>>2731949
don't know about Road Rage specifically, but sometimes it's a blend of both, with sprites drawn for certain distances, and sprite scaling done for in-between distances.

>>2731950
funny enough, while the SNES had that Mode 7 and actively used it for a kind of 3D view, it had no abilities to zoom sprites, which is kind of the "necessary" second half to make that look work.
F-Zero SNES vs. GBA is an example where they added sprite scaling to the latter, to smooth out the movements a bit, among other things.

>>2731487
Doing a 3d mesh that looks like that effect is not possible, coming up with an alternate method to achieve the same effect is not a strawman argument.

But go ahead, keep throwing that word around, if it makes you feel better.

>>2731482
Ah, I see. That's on modern APIs though, where you can also get perspective correct rendering.

I was thinking of specifically the Playstation, which can't do perspective correct texturing, and as far as I know can't do wrap around textures either (if you draw rectangles, they can wrap around, but only a maximum of 4 times).

>>2732040
>coming up with an alternate method to achieve the same effect
It was never about achieving the effect on other hardware. My statement was exclusively that you can not construct a polygon mesh for the object. It was a throwaway statement to illustrate that the "plane" in Mode 7 does not resemble any 3D object and some people just took half the statement, read what the want into it, and ran with it.

>>2732051
Often texture sizes are a power of 2. A reason for that is that you can trivially wrap texture coordinates by applying the modulo function. A limit in this is the size of numbers the hardware can deal with.

>>2732040
>A straw man is a common form of argument and is an informal fallacy based on giving the impression of refuting an opponent's argument, while actually refuting an argument which was not advanced by that opponent.
People refuted a claim I did not make. I did not claim that the effect can not be reproduced visually on hardware other than the SNES. The claim was merely that the shown object can not be made from a mesh. We're even in agreement on that statement.
>Doing a 3d mesh that looks like that effect is not possible
I do admit that my wording was not as clear as it should have been, but I stand by what I said. People tell me how to model scanlines using polygons or other mechanisms are not refuting what I said. It's a straw man.

>>2732061
So basically you are angry that people got the square peg in the square hole, instead of forcing it into the round one, which, as everyone can see, is not possible. Good job.

>>2732065
Playstation can also apply texture windows where the texture then repeats itself, so I guess there's that.

>>2732081
>got the square peg in the square hole
It's not a programmng problem. The strawman in your head is.

>as everyone can see
You think it's immediately obvious that the rendering of the Underworld in Terranigma has no clean equivalent in form of a polygon mesh? It's quite obvious you got a programmer's mind. Try to get outside of your bubble occasionally.

>>2732061
I showed how you can construct a polygon mesh in post >>2730821. You're wrong. Face it.

>>2732341
yeah, and that mesh is totally resembling the object, and not used for scanline approximations.
This is not a programming course

>>2730821
Are there seven rectangles?

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

Smurfs on the Mega CD
https://youtu.be/qXkGQk0r7O0?t=47m8s

>>2733781
most of the game is parallax scrolling. The downhill snow section contains HDMA effects but does not rotate or zoom the layer.

>>2710734
It's fun how SNES wasn't very powerful but on the other hand, it had so impressive graphically games.

>>2736119
>wasn't very powerful
CPU clock speed means very little when you have hardware instructions and hardware support for extremely versatile rendering. DOS could only dream of tile layers, hardware support for alpha blending or scaling.

>>2736129
Was it able to produce something like picrelated alone?

>>2737246
way to miss the point.
No, the SNES graphics hardware has no per pixel access, among other things. It's almost as if it's specialized hardware, made to excel at tile map scrolling and sprites.
Meanwhile, Commander Keen 1 was a huge deal on PC because of fluent full screen EGA scrolling, while for the NES it's not even something special.

>>2737252
bringing up the NES because it has even less computing power than the SNES. Commander Keen 1 was released in 1990, 2 years before Wolfenstein 3D, a year before the SNES was released, and 7 years after the NES made full screen scrolling effortlessly. It took the almighty DOS 7 fucking years to do smooth full screen scrolling, something the NES did in practically every game at launch.

NES and SNES share some similarities in their tile hardware, and the general concept applies: dedicated hardware can outperform generic computation, making clock cycles a rather meaningless measure.

>>2737246
Was DOS able to produce something like pic related at the same time? Were you understanding what was being said, at all?

>>2737280
>Was DOS able to produce something like pic related at the same time?
I think yes, but it is the question of the swifter CPU. SNES hardware remains the same.

>>2737254
>NES and SNES share some similarities in their tile hardware, and the general concept applies: dedicated hardware can outperform generic computation, making clock cycles a rather meaningless measure.
Uhh... Maybe it is.
Though it is impressive that stock Genesis could produce polygons. Starfox demo is looking nice.

>>2738368
forgot a link
http://www.youtube.com/watch?v=YUZpF2JLF4s

>>2737254
>It took the almighty DOS 7 fucking years to do smooth full screen scrolling, something the NES did in practically every game at launch.

The IBM PC was designed to be a multipurpose office tool. Being able to play games was completely coincidental.

I mean I could argue that it has been 24 years since it launched and the SNES still can't do my accounting.

>>2731949
Road Rash uses real scaling. Here's it emulated with an overclocked 68k (kind of looks like a Super-Scaler board game now, really cool stuff).
https://www.youtube.com/watch?v=eP0aWO-ny6Q

(don't actually play Road Rash like since the handling seems to be CPU speed dependent)

>>2738393
read the exchange before responding

>>2738371
But that's not even that impressive http://youtu.be/pfe2Ze_yDk4

>>2738368
>Though it is impressive that stock Genesis could produce polygons
You don't need much computing power to produce polygons, pic related. You need the graphics hardware for it though. To draw polygons, you need to be able to access invididual pixels. The SNES had no such mechanism, everything was done through tiles and sprites. Before the nitpickers come: yes, you can cover the screen in unique tiles (if your tile palette is big enough) and work on their tile data. The performance is abysmal though, as you're essentially working against the hardware. See Elite NES as example.
Starfox worked DESPITE the SNES. It basically did ALL graphics on the cart, and streamed the result back into the SNES. The SNES itself had no clue about the Starfox graphics, it just passed to the screen what ever the cart spit out.

>>2712897

>You will never impress Shigeru Miyamoto with your coding skills so thoroughly that he lets you marry his only daughter

>>2738845
Yep, but I don't remember Hard Drivin' on the SNES.

I heard Kawasaki Superbike on the SNES wasn't full polygonal

>>2740696
It's not (the road is done Outrun-style, the 3D transformation isn't freely rotatable and follows the road path, someone told me that the other bikes on screen are using flat vector graphics instead of the engine's sprite scaling -- dunno if that's true or not). It cheats a fuckton for its performance (as it should, it's not a general purpose 3D engine, it's a 3D engine made for racing games on the Genesis).

But most of the the scenery is just straight 3D geometry being rendered. There's a couple of scaled sprite billboards and arches, too. Pretty nifty stuff.

>>2738634
>(don't actually play Road Rash like since the handling seems to be CPU speed dependent)

It's not, the dude who made that video is just using a secret bike you get from a password, which has insane stats far beyond the rest of the bikes in the game, which makes it extremely easy to crash.

>>2741362
Then why when you ride a usual bike, sprites scale less smooth?

What more games exist that are SHMUPs and go into perspective?

>>2741778
few, because perspective fucks with aim

>>2741778
https://www.youtube.com/watch?v=XVbZAPBPwZY

Cosmic Epsilon is a great one. its actually for the NES(famicom if you're a faggot who likes to correct anyone.)

Earliest mode7-style graphics I've seen on any console.

Tetrastar is by the same devs but its a an earlier version of the same concept... but a shitter. still fun though. (seizure warning)

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

>>2712897
This is really impressive. I've never actually seen X in action on a Gameboy or otherwise.

I do want to point out that once you have a highly optimized line drawing routine (something like all integer and only using either 4 multiplies/1 divide and a bunch of adds per line), many of the effects in X really aren't that hard to do. People don't realize how powerful even the most feeble of hardware can be when you carefully utilize systems resources, nor how small and simple a 3D computer graphics library can be.

Just look at the demo scene:

SNES:
https://www.youtube.com/watch?v=wi-NxM1EaXM

C64:
https://www.youtube.com/watch?v=9SRRTgo-LWA

2600: (pretty sure this would have melted peoples minds back then)
https://www.youtube.com/watch?v=04Wk9Oi_Fsk

>>2710884

>>2710734
Not sure, but can the tower effect of Castelian considered "Mode 7"?
https://www.youtube.com/watch?v=ZXVy6XumttI

>>2743159
Mode 7 is just (hardware support for) rotating and scaling the background tile map, not more, not less.
The usual angled ground planes associated with Mode 7 are a result of tweaking the scaling factors per scanline, using a feature of the SNES called HDMA.
Line scrollers, parallax scrolling, or that effect in castelian have nothing to do with it.

>>2742048
>Cosmic Epsilon
Oh fuck that looks cool. Why haven't I heard of this before?

The way it draws the ground reminds me a bit of SkyRoads for DOS, it even has the same sort of weird perspective angles.

>>2742048
To be honest I can't even see a pattern of the floor.

>>2741790
At least any of these few?

up