Project Mode7

[DustyPorViva]

'ello! I thought I'd try my hand(again) at attempting Mode7 in Graal. For those unaware, mode7 was graphical mode embedded in the hardware of the SNES that emulated 3D projection. Obvious examples would be Super Mario Kart on the SNES.

People have attempted to do this many times before in Graal, but it tends to be a taxing endeavor. There is always a lot of looping involved and on top of that having to entirely rerender the player's view.

So I've been going over in my head various methods to try to emulate Mode7 in Graal in the least intensive way possible. I thought I'd post a thread on the subject to share my progress, and possibly exchange ideas and maybe even get some others on board.

See, I'm not good at math. Any math I accomplish I pretty much wing my way through it, tweaking and messing around until I get a desirable result. So I'm probably not the most qualified person to do this, but I'm trying!

My first attempt is already underway. This attempt is being done in a sort of progressive, tweaking matter. What I did was start by rendering tiles in a standard grid view with polygons. The polygons are important because in the end I want to tweak each point of the polygon as if I were manipulating the vertices of a 3D plane. The downside is that polygons seem to be VERY expensive to Graal. Rendering even half a level's worth of polygon tiles drops my FPS down to 12. Rendering the full level(without further 3D math and other intensive calculations) drops it to a staggering 3 frames per second. Anyways, then I took this plane of tiles and I added rotation math to it. This is the first step to emulating mode7 for me.


However, I don't think this will be a viable method. Rendering polygons are just too taxing. So I'm also contemplating other methods. My most promising idea is to use a drawingpanel to emulate a screen buffer. This would allow me to create mode7 using methods similar to how actual programming languages would do it. See, what I would do is use the canvas like a buffer, rendering each pixel individually. I haven't done any experimentation yet though, so I don't know how taxing this method will be. However the upside is that because I'm emulating a screen, I can lower the resolution, thus lowering the calculations needed to be done. I could actually allow users to specify their own resolutions that fit their computer.

In the end my desire is to make a flexible and more importantly, user-friendly mode7 emulation. Something that others can be able to drop directly into a level and easily manipulate the camera to do their own thing with. Everything from rendering a map to porting old game types like Mario Kart of F-Zero. The more cooperation and help, I think the better off I'll be!

[DustyPorViva]

Update. Thought I'd check out the drawingpanel render times. Just to render a screen on each tick. It's abysmally slow. Even rendering a very small resolution like the SNES results in a framerate of 2.

[Tricxta]

Looks pretty interesting so far. Have you talked to beholder?, he had alot of great ideas to get the most out of his mode7 emulation.

[Hezzy002]

There really isn't a practical way to do it in Graal. All of the native transforms that Graal uses are done in screenspace with no 3D projection whatsoever, even writing your own projection for verts results in broken interpolation of the texture you assigned to the polygon. When I did this, the only way I could get it at a reasonable speed was with showimgparts with larger parts near the bottom, and increasing the texel density as it reached further off the screen.

Unfortunately, even with precomputing all of the math that's possible to precompute into lookup tables, rendering was still the bottleneck. I don't think there is a reasonable way to accomplish this in Graal unless you do something with an external server/process in some manner. Keep in mind you can embed Flash, so I guess that's the cheap way.

[cbk1994]

Originally Posted by Hezzy002

Keep in mind you can embed Flash, so I guess that's the cheap way.

Flash isn't supported on v6 or on non-Windows platforms.

[Hezzy002]

I just remembered Graal can display some 3D models, might only be in OpenGL mode or something, but it's worth looking into to get those transforms.

Originally Posted by cbk1994

Flash isn't supported on v6 or on non-Windows platforms.

Good riddance.

[xXziroXx]

Originally Posted by Hezzy002

I just remembered Graal can display some 3D models, might only be in OpenGL mode or something, but it's worth looking into to get those transforms.

It was OpenGL only with v5 at least, might've changed with v6.

[DustyPorViva]

Originally Posted by Hezzy002

There really isn't a practical way to do it in Graal. All of the native transforms that Graal uses are done in screenspace with no 3D projection whatsoever, even writing your own projection for verts results in broken interpolation of the texture you assigned to the polygon. When I did this, the only way I could get it at a reasonable speed was with showimgparts with larger parts near the bottom, and increasing the texel density as it reached further off the screen.

Unfortunately, even with precomputing all of the math that's possible to precompute into lookup tables, rendering was still the bottleneck. I don't think there is a reasonable way to accomplish this in Graal unless you do something with an external server/process in some manner. Keep in mind you can embed Flash, so I guess that's the cheap way.

I had intended to do my own projection, yes. Each tile is a polygon, so I'm hoping by scaling each tile to its own polygon I can alleviate some of that horrible normal issues with the textures that Graal seems to have.

[DustyPorViva]

Some progress, but it's just trial and error. Me tweaking numbers over and over. Fun stuff though.



I'm hoping IF I get anywhere, I can optimize it to only need to render tiles in view of the camera, and that the necessary tiles to render a proper view is low.

[Emera]

Amazing :O

[BlueMelon]

Very interesting, good job!

[Hezzy002]

That's about the furthest everyone gets. Beyond that, you require more texel samples if you want to extend the view range toward the horizon, especially with rotated views, which is what really kills performance.

[Crono]

what if you chop the tileset up so its only loading bits of the tileset you know will be used. for example is it loading all the snow/lava aswell? dont need dat!

[DustyPorViva]

Originally Posted by Crono

what if you chop the tileset up so its only loading bits of the tileset you know will be used. for example is it loading all the snow/lava aswell? dont need dat!

Most likely no because pics1 is already in memory. Rendering the entirety of pics1.png onto the polygon as opposed to an individual tile yields no difference in framerate. The only thing that can help here is to 1) cut back on rendered tiles. This is to reduce the looping and calculations that take up a lot of processing power 2) clip unviewed polygons. I already added this, though it doesn't make a very noticeable difference when you're rendering an entire level. But this may help as I tweak the camera in final levels(the more I can keep out of view, the better).

Can anyone math savvy help me out with a little issue with my perspective rendering? When I apply my math I get this sort of perspective going on:



Instead of:

[DustyPorViva]

Huge breakthrough : D

I had a great idea, and I was able to pull it off. Before, I was rendering each tile to a polygon. Before that, people were mimicking pixel buffers with showimg's, rendering a showimg for each tile(or multiple per tile). Either way was very slow... however I had an idea!

I first process the level(or gmap, eventually) and render it to a drawingpanel. Then I take the image and save it. Now I have an image of the level(thus in the future I can easily use this script in any desired level) that I can use to render. Instead of rendering a polygon for each tile I now can specify subsections. The higher, the better the rendering. Then I chop the prerendered image up into sections dependent on the subsection count. This allows me to keep the horrible artifacts of Graal's poor texturing to a minimum while being able to easily render the entire level without framerate loss.



As you can see, still 20fps. Chances are even the slowest computers will be able to render it this way. Now I just need to figure out the math involved and I'm almost done

[Gunderak]

Wow. Just wow.

[Rave_J]

y not just tell stefan to release the Graal 3d platform he made a while ago ?
oh wait this will be in 2020

[DustyPorViva]

I'm very close to getting something "playable" but I've run into a problem that I just can't seem to fix.

Here's what my rendered looked like:


Okay, but see that perspective is VERY wrong. It's especially obvious when turning as everything gets a very funnel/spiral distortion. So I want to correct this. What I need to do is make the render shrink as it nears the horizon. Sounded easily enough but I just can't seem to get it to work. I ended up with ONE result that works perfectly, visually, but with the sideeffect of... flipping the view vertically.


I desperately need to figure this out. That view is perfect, especially when you're moving. Everything is normalized great, but I just can't get the view oriented right.

Here is the portion of the script that deals with the positioning of the vertices:

PHP Code:

for (temp.p= 0;p<4;p++) {
  // Rotate vertices
  vert_px[p] = (vert_x[p] * cos(this.cam.angle)) - (vert_y[p] * sin(-this.cam.angle));
  vert_py[p] = (vert_x[p] * sin(-this.cam.angle)) + (vert_y[p] * cos(this.cam.angle));

  // Stretch horizontal view as it nears the camera
  vert_px[p] *= ((vert_py[p]+(screenheight/1.5))/256);

  // Problem line. This is what's currently rendering the distance, but also flipping the render
  vert_py[p] *= abs(vert_py[p])/-screenheight;

  // Orient new render to center of viewing
  vert_px[p] += screenwidth/2;
  vert_py[p] += screenheight;
} 


Any help from you math guys would be awesome.

[Fulg0reSama]

Originally Posted by DustyPorViva

Any help from you math guys would be awesome.

I'll see if I can get a friend to help ya on that math.

[Emera]

This is mind blowing! Amazing work dusty.

[Hezzy002]

Why don't you just flip the verts along the center of the screen and then translate them down? Also, I'm not sure how you're able to increase performance with the technique you discussed, unless it enables you to render in horizontal strips? But then how would you handle rotation?

It also looks like you have the same problem that everyone else has; if you were to change the viewing angle/view distance to properly look like a SNES racer's horizon, you'll find either horrific artifacts or if you increase the resolution to remedy that, really poor performance.

[DustyPorViva]

Originally Posted by Hezzy002

Why don't you just flip the verts along the center of the screen and then translate them down? Also, I'm not sure how you're able to increase performance with the technique you discussed, unless it enables you to render in horizontal strips? But then how would you handle rotation?

It also looks like you have the same problem that everyone else has; if you were to change the viewing angle/view distance to properly look like a SNES racer's horizon, you'll find either horrific artifacts or if you increase the resolution to remedy that, really poor performance.

I sorted out the distance issue, and here it is running at 20fps(a few frames lost while recording):

But I have yet to try it in a real "racing" level and I need to add gmap support before I can start tweaking FOV and how far to render out. A single level actually is pretty damn small for mode7.

As for how I'm accomplishing it, imagine I'm taking the level, rendering a flat image of it and slapping it on a single polygon. Now imagine I'm slicing that polygon up into multiple segments. Not visually, but mechanically. It's the same technique I was using from the start except now instead of grabbing level data in realtime I'm working off of a prerendered image of the level generated from the start. Then instead of one polygon per tile, I can render as many polygons as I desire, and just cropping the image into parts. I can lower or raise the quality of the plane with a single variable, so I suppose for those with more powerful machines they could crank even better quality. In the video I rendered I was processing 20x20 segments in the plane. Lowering it more and more 'causes all those seam issues with texture normals that Graal is so well known for. The segments help alleviate that issue.

Originally Posted by Fulg0reSama

I'll see if I can get a friend to help ya on that math.

That'd be cool. I got it figured out, but as you can see in the video I'm still having the same issue with the sort of barrel effect. I don't like it and would love to have the plane render straighter.

[Crono]

hah that's awesome dusty, graal kart inc.

[Tolnaftate2004]

x' = x*h/z; h generally of your choosing.

hth

e:
x = orthogonal horizontal coordinate
x' = projected horizontal coordinate
h = "camera height"
z = distance along the axis that comes through your screen

[James]

nice work as always dusty

[DustyPorViva]

Well I feel I'm crippling the potential of this by doing it on my own. I'm not that great at math and I have absolutely no experience with 3D projection. This is my first attempt and I don't feel like I'll be able to accomplish my end goals.

So if anyone familiar with 3D projection wants to hop aboard and collaborate, I would absolutely love it. My goals are to:

1) have a fully customizable camera with roll, pitch, height so users can easily adjust the view.
2) Make the 2D to 3D transition smooth and hassle-free. Ideally I'd love to see a command that takes any position in the 2D world(in this case a level or gmap) and return the values needed to render it to the screen in a 3D space.

The two above combinations would make it insanely easy to share this functionality with others, and I'd love to have this sort of thing easily available to other developers to play with.

If someone with the math skills can help me out here and pull this together into a proper mode7 effect(instead of a hacked together version) then I'd be truly grateful. The functionality and backbone is already there, I just need the 2D -> 3D projection and camera smoothed out. I know there are at least a few scripters floating around with the experience to do this.

[DustyPorViva]

Also, future mockup!


This sort of effect would be insanely easy to pull off. Basically I'd take water(in this case from pics1) and give it a semi-transparent fill(like 80% opaque or so). Then I'd take the sky/npcs/players and duplicate them under the horizon, vertically flipped and render them under mode7. Very, very easy to do and I can't wait to get to it. I want to do an entire water course with this. This effect, with some nice parallax sky scrolling... suhweet.

Also, sky was just ripped from New Super Mario Bros for mockup purposes and the noob in a kart was pulled from someone elses attempt at mode7 in Graal(I think obviously edited from Super Mario Kart).

[BlueMelon]

Now that would be pretty great to see. Mario kart style.

[Unkownsoldier]

That would be great, and you would do other things other than just Graal Kart right? It could have some great possibilities if you get it working properly.

[Fulg0reSama]

Originally Posted by Unkownsoldier

That would be great, and you would do other things other than just Graal Kart right? It could have some great possibilities if you get it working properly.

Yeah, you could also venture into a whole different perspective based experience for Graal in general lol.

Graal Nukem Online, anyone?

[DustyPorViva]

Originally Posted by Unkownsoldier

That would be great, and you would do other things other than just Graal Kart right? It could have some great possibilities if you get it working properly.

Me? Probably not. I intend to do a little kart-game with it but that's it. But I will release the script(hence the need for it to be user-friendly) and what others do with it is up to them. You could use it for old RPG-style overworlds. Use it to create LttP-style map interfaces. But mimicking Duke Nukem? That's an entirely different type of 3d casting, as that would be raycasting instead of floorcasting.

[Fulg0reSama]

Originally Posted by DustyPorViva

Me? Probably not. I intend to do a little kart-game with it but that's it. But I will release the script(hence the need for it to be user-friendly) and what others do with it is up to them. You could use it for old RPG-style overworlds. Use it to create LttP-style map interfaces. But mimicking Duke Nukem? That's an entirely different type of 3d casting, as that would be raycasting instead of floorcasting.

Yeah, I was off with the duke nukem bit, but you could very easily make an interesting kind of survivor shooter regardless with enough planning.

Also could make one of those dodger games (like skiing and avoiding the trees)

[Hiro]

Almost like Graal3D, right? Right?


Right... ;_;

[DustyPorViva]

PFA(Tolnaftate2004 up there) is taking a stab at the maths now. I trust his skills so I can't wait! In the mean time I will be having at the graphical side, doing some graphics, working no the parallax scrolling and such.

[Devil_Lord2]

I don't know who would know, but have you asked Thor or Fowl?
I feel like you are trying to seek for help through this thread,
not sure if you've advertised elsewhere, and everyone is
commenting with spam / not providing useful information
like myself.

I'd like to use this, only walking, in one quest. Mini quest...

I'm not sure who is good at math though, I've gotten only to trig and that was it.. I just tweak with things until they work also. :/

Even when I do find out equations that work, 1-2 weeks later I've forgotten what I've done and the whole thing confuses me, like my pet system. >.>;

I've love to help though. D:


I know ZeroG made a 3D Cube on Graal... doubt that helps though..

[Hezzy002]

Duke Nukem doesn't use ray casting, it's just polygons being traced out through a BSP tree and rasterized with a software rasterizer. You can't pull something of that calibur out of Graal, but you can do something like Wolf3D with floor casting if you use ray casting and this floor casting method in tandem.

[Crono]

Originally Posted by Devil_Lord2

or Fowl?

Let it forever be known that mentally challenged Crono's math is better than FP4's.

[ffcmike]

Originally Posted by Devil_Lord2

I don't know who would know, but have you asked Thor or Fowl?

Originally Posted by Crono

Let it forever be known that mentally challenged Crono's math is better than FP4's.

No good asking me either it's WhiteDragon's job to do the mathematical thinking.

[linkrulz4]

This mode.
It has a flavor.

[DustyPorViva]

PFA went ahead and completely rescripted it into a PROPER 3D projection mode... and it is awesome

I'm still tweaking what he has, but so far it looks great! Ignore the temporary Mario graphics(sky)