Project Mode7
 

'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.
Attachment 54621

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!

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.

http://i.imgur.com/6XUR3.png

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.

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.

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

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.

Good riddance.

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

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.

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

http://i.imgur.com/ZNCnu.png

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.

Amazing :O

Very interesting, good job!

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.

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:

http://i.imgur.com/XvXLM.png

Instead of:

http://i.imgur.com/R8lHY.png

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.

http://i.imgur.com/D6W2f.png

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 :)