OTD Export now available in Sketchup2IV
I’ve added basic OTD export to Sketchup2IV, it’s available in version 0.4.0. Head over to the Sketchup2IV project page to download the latest version.
OBD and ODD export support available in Sketchup2IV
I’ve added OBD and ODD export support in version 0.3.0 of Sketchup2IV. New version can be downloaded here.
To export OBD and ODD files select 2 or more components in your Sketchup scene, right click and select Export OBD/ODD.
Sketchup2IV 0.2.0 Released!
After more than 5 years I’ve released a new version of the Sketchup2IV plugin. The plugin now supports Sketchup 2017 and can be installed using the Sketchup extension manager.
More features will be added and feature requests are always welcome! Plans and development can be followed at GitHub.
The biggest challenge of Zelda64 VR is implementing the gameplay. We don’t want to reinvent the wheel and recode all the gameplay that can be found in Ocarina of Time. There are just to many big and small gameplay elements for that. Before I get into much technical detail I will explain how Ocarina of Time works.
Every object, every character and every item has its own piece of code. This piece of code is called the actor code. The actor code contains some basic information like the model that should be used to render this actor, the scale and much more. Besides this info there is also a piece of code that runs when the actor is active. For static object this can be as small as a few lines. But for animated objects that the player can interact with, the code can be thousands of lines.
So why haven’t you seen any gameplay videos yet? The code I told you about is compiled MIPS code. It’s not really easy to read and it takes a long time to build a program that runs the code properly. Besides that the code contains a lot of calls to functions that I don’t know the purpose of. There is a small list of documented functions but that’s by far not all of them.
The way I am currently implementing the gameplay is a big challenge but will give very accurate results and save me a lot of time in the end.
Work on Zelda VR has been continued
It’s been quiet a while since I last posted about Zelda VR. Summer is here and work kept me busy. After a long day of coding at the office I just didn’t feel like coding even more at home. So not much progress has been made until last week.
With the DK2 right around the corner I started getting hyped about VR again and decided it was time to get back to the project. First thing I had to do was update to the 0.3.x SDK (let’s hope the next version won’t mess up to much). Which surprisingly didn’t take that long due to the excellent examples and libraries floating around on GitHub. Once I got that out of the way I continues work on the main goal; Loading and emulating the Zelda ROM.
People might wonder why I am using the ROM as a base instead of ripping the assets from the original game and drop them in an engine like Unity or UDK like several other projects do. Let me explain why I take this approach:
Legal issues. One of the main main reason. Ripping models, sounds and other assets from a game and distributing them is not allowed. By loading all the assets from the ROM I try to bypass this and basically do the same as any other N64 emulator. With the only difference that my game will only work with one single game and contains a lot of custom code to fancy up the graphics and make everything VR compatible. For the user this means he needs to own a copy of the ROM and place that in the games folder.
Learning something new. It’s a challenge to get all this working. Especially because I’ve never tried to do something like this before, but have always been interested in Emulators and how they work.
Amount of work. The amount of work to get everything running is gigantic. I need to be able to emulate every part of the game. But doing it this way also has an upside, once you got one part working, for example loading one map, all maps will work. So instead of having to rip every single model, I’ll have to make sure I can load one map and all of them will automagically work. The same goes for the Actor scripts (all interactive elements in a map), audio and collisions.
That’s basically it. I hope you are as excited about this project as I am and maybe one day you’ll be able to play my favorite game in VR.