nesdev.com

Update 25/06/2016

3DNes is released at : https://geod.itch.io/3dnes
---------------------------
Update 08/03/2016

Finally the beta is ready:
http://tructv.bitbucket.org/3dnes/
It only runs on Firefox for now.
Have fun!

-------------------------------------------
Update 19/02/2016

The beta release candidature trailler is here
https://youtu.be/Ti2fwroyP2A
with many new features : better shape segmentation, transparency, z layers etc ...

------------------------------------------------------
Update 12/31/2015
Hello Everyone!
Longtime no see .
Lately i'm working to improve the vision and sound.
Lighting and shadows are added.
And now it's time for showcases.
Next step, i will work on z layers problem.

https://youtu.be/wzBjHEdh14k
https://youtu.be/_Sl_Ou3Wrbc
https://youtu.be/576mERxRnj4
https://youtu.be/oPsWI5htHNw
https://youtu.be/bKHYgiLuiNUw
https://youtu.be/oPsWI5htHNw

----------------------------------------------
I'm currently working on a 3D Nes Emulator. My work has achieved an initial result. Below are several clips to showcase my program.

https://www.youtube.com/watch?v=cUXYgxEfQrA&list=PLhplDJFRf1RINuz-T3s16_7OssOeiAx8y

I would like to receive any remarks or suggestion.
Please share your thought. Thank you.

_________________
3DNes Emu
https://geod.itch.io/3dnes

I am impressed.

At first I thought everything is beveled into a block with repeated texture wrapped around, until I realised that different tiles/sprites can have different breadths, and that pipes are properly cylindrical.

I think every single game has to be setup independently to achieve this result, right?

I never realized that piranha plants always rendered, even in the pipes.

No, every game is automatically rendered with the same engine, the same code.

_________________
3DNes Emu
https://geod.itch.io/3dnes

I know that it's the same engine(same emulator), but different games has to use different data files, right?

I meant data files that define how to coop with different tiles/sprites, like how 'thick' a wall tile and a ground tile are (from the video it's obvious that a wall tile is not as thick as a ground tile, and the text fonts are even thinner, intentionally) and in case of pipes, etc., what models to use.

Of course when no such data file is provided an emulator may still consider each tile/sprite as a block of the same thickness, just won't look as good.

This is similar to the HD emulators, in which you need to provide new graphics for each game.

No, the 3d scene rendering is based on automatic "on the fly" analysis of 2d scene. I don't follow the approach of HD Nes. This approach requires huge amount of graphic work done to let just a game played. You can see that when an object is rendered for the first time, the game become a little lag due to the analysis computation.

_________________
3DNes Emu
https://geod.itch.io/3dnes

How do you decide whether a given tile/sprite thing is rotationally symmetric or something else?

General speaking , the emulator have a fixed set of predefined geometric pattern like cylinder, cube ... vertical or horizontal, when the game played, the 2d scene will be analysed to detect 2d geometry objects on it. Then a set of heuristics rules will be used to assign each object a pattern which will be used later to convert this objects into 3d. That's the mechanism behind it.

_________________
3DNes Emu
https://geod.itch.io/3dnes

Very impressive for a heuristic method. Super Mario Bros. works OK, except the treetops in 1-3 look like a green log on top of the tree trunk. But it seems to treat the outdoor background in The Legend of Zelda as thick fog.

I wonder what it does with Dr. Mario or any of Shiru's games or any of my games.

Now that's really really impressive!

So you're saying, for example, it can see that the pipe looks like a cylinder in that it's bright in the center and darker along the edges (and the pattern repeats vertically)? What I really want to know is how well this would work on an NES game with non perfectly front facing floors, (if that makes sense) like Battletoads. In order for this thing to work flawlessly (or even close to it) without hacks, it would practically have to be a human looking at the game. And just thinking, in the case of Battletoads, I guess it would also have to infer what is supposed to be up, and what is supposed to be further in the background for the characters.

It's pretty cool, definitely more interesting to look at than the trivial solutions.

That "first person Mario" video reminded me of many PSX/N64 games with short draw distances, some fog might be funny in that video in attempt to cover it up somewhat. (I'm sure this would lead to somebody making a comment in YouTube about NES's draw distance...)

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

In fact, that's one of the reasons games went 3D in the first place: in order to be able to draw things both close and far away. It's helpful in many outdoor scenarios and flat-out necessary in a racing game, with few exceptions.

Really impressive, especially given your explanation on how it works.

Well we can say that the emulator is still in a very alpha stage. What the emu has succeeded to establish is the infrastructure, the framework. In the future, more semantic info will be collected from 2D scene,more predefined patterns will be added, more rules will be created to make the emu more robust. You say it right there will never be a perfect solution for this kind of problem but better solution is always possible. For the camera mode/direction detection: top down, left right or front back, perspective or orthographic or 2d projection, currently the emu has not detected it yet so the render will not be good for 3d camera or complex background game.

And when the emu becomes mature enough, the optimization for a specific game is as simple as values assigning for a set of coefficient. That's how i see things.

_________________
3DNes Emu
https://geod.itch.io/3dnes