SoulofDeity

Well, regardless, UEFI is a merely a way of standardizing hardware interfaces, is flashable, and most (if not all) pc's still support BIOS for legacy mode. So Linux won't be locked out.

Sound nice! Are you using a solid-state drive or a traditional magnetic disk drive for your HD? I'm also doing something similar. I bought a Raspberry Pi2 B+ myself that I plan on turning into a homebrew Nintendo64. Mainly because I want to make my own N64 games and shitting out $250 for an Everdrive64 is ridiculous.

This article has no idea what it's talking about. UEFI is not a security toolkit. it's a Unified Extensible Firmware Interface (in other words, it's does the job of the traditional BIOS, and it can be flashed) The security check they're talking about won't prevent you from installing Linux or w/e third party OS you want, it just won't let you install a pirated version of Windows.

Thanks man It's not just 2 people though. Currently, there's 5. CloudMax, Jack Walker, and I are doing the programming; MelonSpeedruns is ripping the music and making it loopable, and Zeth is currently learning how to use Blender so he can help rip models and animations from the game. Anyone is free to help out as much as they want. A link to the project source is in the first post on this topic (it's a tad outdated atm though), and if you send your skype info to me in a pm; I'll add you to the group chat.

So I've been doing a bit of thinking, and it might be best if we tried not to mangle OoT/MM's content too much into the engine itself. Perhaps, using the _All_ game directory for only the core components of the engine. This way, if by some odd chance we get lashed out at by Nintendo, we can just swap out the assets and keep engine itself. I'm going to try to improve the camera and player control scripts a bit today; making it so that the camera doesn't clip through walls and hopefully getting Link's animations looking more natural.

That dungeon looks awesome! The room in the first pic looks like it could use a little more contrast though. Perhaps a different texture for the ceiling and steps? Also, when you say there will be 2 new characters to play as, I'm assuming this is going to be a MM mod?

On top of this, I don't think the animation is playing at the correct speed, nor do I think I'm using the correct animation. I had to sift through about 475 animations one-by-one just to find anything that resembled a walking or idling pose; and there's like another 300 more to go. I just used the first ones I found.

Added smoother player control and raycasting collision for falling instead of a rigidbody. Now Link has no problem climbing stairs. Shortly after I uploaded this, I also fixed the z-targeting so Link doesn't flip sideways. Currently, the pause menu and hud are disabled because they are dependent on the old player script.

Not really. I actually wrote the script like, sometime last year, shortly before I left the community for a few months. The sounds were most likely from noproblo.dayjo.

Yeah. Though it wouldn't do much good aside from improving the lighting I think. Sub-surf modifying can cause some pretty fugly looking defects. Just look at Link's sword hilt and the messed up hair in this pic.

I wouldn't say that it's impossible. Glide64 and Rice's plugins use Direct3D iirc. D3D uses a scene system; so it's probably possible to write a small program that hooks the D3D dll to intercept drawing like 3D Ripper DX does and swap out the models.

Finally got everything ported to the new engine Currently in the process of committing the changes to the repository. * Repository is now up to date

Been expanding on the new GameEngine api. Currently, there are 13 functions: GetScenePath(name) - Gets the path to the directory for a scene by it's name GetScene(name) - Gets the id of a scene by it's name GetActorPath(name) - Gets the path to the directory for an actor by it's name GetActor(name) - Gets the prefab GameObject for an actor by it's name GetMusic(name) - Gets music by it's name GetSound(name) - Gets a sound by it's name GetAnimation(root, name) - Gets a localized animation in root by it's name GetAnimation(root, name, localized) - Gets an animation in root by it's name GetMaterial(root, name) - Gets a localized material in root by it's name GetMaterial(root, name, localized) - Gets a material in root by it's name GetTexture(root, name) - Gets a localized texture in root by it's name GetTexture(root, name, localized) - Gets a texture in root by it's name GetString(root, name) - Gets a localized string in root by it's name GetString(root, name, localized) - Gets a string in root by it's name LoadScene(name) - Load a scene by it's name LoadScene(id) - Load a scene by it's id SpawnActor(name) - Spawn an actor by it's name SetBGM(name) - Set the background music by it's name SetBGM(clip) - Set the background music to a clip The name format is "Game:Name". For example, in order to load the scene for Hyrule Field, you'd just type: GameEngine.LoadScene("OoT:HyruleField"); You may optionally omit the "Game:" part of the name, in which case it defaults to "_All_:". Localization is extremely simple. Say for example, that the actor "CH_Darunia" has a string called "LostWoodsDance". You'd load it like: string text = GameEngine.GetString(GameEngine.GetActorPath("OoT:CH_Darunia"), "LostWoodsDance"); If the player's localization settings were set to German, it'd first check if a file called "LostWoodsDance-DE" exists. If so, it would return the text in that file, otherwise, it would default to the originally specified file name. This makes the job of translators super-easy.

As I've mentioned before, I've recently been doing a major overhaul on the directory structure of the project; and since I haven't done so before, I'm going to take a little time to explain it. The Basic Directory Structure Below is a simple diagram representing the basic directory structure and files: /Assets +- /Resources | '- /Game | +- /Actors | | +- /Characters | | +- /Common | | +- /Creatures | | +- /Enemies | | +- /Interface | | +- /Scenery | | '- /Uncommon | +- /Audio | | +- /BGM | | '- /SFX | +- /Data | | '- /Static | '- /Scenes '- GameEngine.cs The Assets directory is the root directory for Unity Files. All of the data is placed in the Resources directory so that files can easily be loaded on the fly like: AudioClip clip = Resources.Load<AudioClip>("OoT/Audio/SFX/Explosion"); Notice that when loading files like this, the "Assets/Resources/" part of the path is omitted. In order to make assets more manageable, they're organized into Game directories. For example, all of the Ocarina of Time assets will be placed under "/Assets/Resources/OoT" and all of the Majora's Mask assets will be placed under "/Assets/Resources/MM". Assets that are not derived from any game at all and are shared among all games are placed into the "/Assets/Resources/_All_" directory. The underscores in the file name are placed there to make it easy to find and kept at the very top of the game list. The Actors Directory The first sub-directory inside of each game directory is Actors. As the name suggests, it contains all of the actors in the game. These actors are organized into 7 groups: Prefix | Actor Group | Description --------+---------------+----------------------------------------------------------------- CH | Characters | Character actors (Link, gorons, zoras, etc.) CO | Common | Common actors (doors, chests, switches, etc.) CR | Creatures | Creature actors (butterflies, fireflies, fairies, etc.) EN | Enemies | Enemy actors UI | Interface | Actors for the user-interface (hud, file menu, etc.) SC | Scenery | Scenery actors (skybox, trees, grass, fire, etc.) UN | Uncommon | Actors that are generally only used by other actors. Inside of each of these group directories is an Actor directory, which as the format: /{actorName} +- /Animations +- /Materials +- /Shaders +- /Strings +- /Textures +- <models> +- {groupPrefix}_{actorName}.cs '- {groupPrefix}_{actorName}.prefab For example: /Skybox +- /Materials | +- Skybox.mat | '- ClearDawn.mat +- /Shaders | '- Skybox.shader +- /Textures | +- ClearDawnF.tga | '- ... +- SC_Skybox.fbx +- SC_Skybox.cs '- SC_Skybox.prefab This structure not only makes it easy to navigate, but also simplifies the creation of game objects. Back in the first diagram, you probably noticed there is a file outside of the Resources directory called "GameEngine.cs". It's a static Monobehaviour class that simplifies managing the gameplay and assets. One example of it's use would be spawning an actor: GameObject actor = GameEngine.SpawnActor("OoT:SC_Skybox"); This is where the Actor group suffixes come into play. The GameEngine class expands the above file name to the resource path: "OoT/Actors/Scenery/Skybox/SC_Skybox". While the class is currently unfinished, it will eventually have functions for things like scene/room transitioning and displaying raw gui objects; it will also contain variables that will control things like whether or not actors are allowed to move or if enemies are allowed to be aggressive. Think of it as the equivalent of the code.zasm file in roms. The Audio Directory The Audio directory is fairly simple. It contains 2 sub-directories: BGM - Background Music SFX - Sound Effects All of the background music files are 2D sounds while all of the sound effect files are 3D. You can set the background music with the function: GameEngine.SetBGM("OoT:HyruleField"); Which will cause the currently playing music to fade out and the specified music to begin playing. The reason why the sound effects are placed into a different directory than the actors that might play them is that they can often serve several purposes. For example, a laughing poe sounds like Ganondorf's evil laugh if you lower the pitch. The Data Directory The Data directory is what is used hold miscellaneous assets. By default, it usually contains at least one directory called Static; which contains all the static assets for the game. Kind of like gameplay keep. The Scenes Directory The Scenes directory, as the name suggests, contains all the scenes for the game. Each scene has it's own directory with the structure: /{sceneName} +- /Maps | +- /Rooms | | +- /Materials | | +- /Textures | | +- Map##_Room##.fbx <-- Model for Room # of Map # | '- Map##.prefab <-- Prefab for Map # +- /Stages | +- /Collision | | '- Stage##.fbx <-- Collision model for Stage # | '- Stage##.prefab <-- Prefab for Stage # +- {sceneName}.prefab <-- Prefab for Scene '- {sceneName}.unity <-- Unity scene file For example: /TestScene +- /Maps | +- /Rooms | | +- /Materials | | | '- Checkerboard.mat | | +- /Textures | | | '- Checkerboard.png | | '- Map00_Room00.fbx | '- Map00.prefab +- /Stages | +- /Collision | | '- Stage00.fbx | '- Stage00.prefab +- TestScene.prefab '- TestScene.unityThis new directory structure will be available in the next commit made to the master branch of the repository.

Sadly, that list doesn't work with my importer. To be honest, the animation part of the script was done by a guy called RodLima before I could do it myself.

The shaders that I wrote probably won't look right on OoT3D models, but testing it yourself isn't hard at all. You just drag and drop the model into the assets to import it, then drag and drop it from the assets into the scene hierarchy. Right now, I'm sifting through Link's animation files files trying to find the idling, walking, and running animations. Already went through 150 without any luck. Once I find them though, I'm gonna update the player control script; finish up the new HUD script, and commit the changes.

Did a short video just so you could see it in action:

I was importing the animations for Link and figured I'd go ahead and rip Link's model from MM as well. Busted out laughing when this happened: Fixed the problem by creating an asset post-processing script for the editor. Below, you can see adult link from OoT and child link from MM using the same drinking animation. A Link dance party! The most difficult one to import was deku link, because his body texture clamps in the y direction and repeats in the x; but unity only allows you to clamp or mirror textures in both directions at once. To get around it, I write a custom shader that takes 2 textures (which are the same image); one with the wrapmode set to clamp and the other set to repeat. When the coordinates of the Y axis are greater than 1 or less than 0, it uses the clamped texture; otherwise it reduces reduces the othermode coordinates by .0275 and uses the repeating texture. I'll end up applying this shader to hyrule field's walls later as well.

I finished creating the animated skybox and am currently working on cleaning up what we have so far and improving a bunch of stuff. Also, I created a skype group so we don't spam the GCN's irc as much. To join it, just pm me your skype info and I'll add you.

Of course. Unity is free to use; unless you want to get a pro license, which is pretty much pointless. You can download the latest commit from the link in the first post on this topic. Obviously

I was planning on adding all the game content from both games. Then anyone who wanted to make their own Zelda game could just remove what that didn't need and add their own stuff.

Maybe they just have shitty monitors then -.-; Seeing the text on my screen is as clear as night and day. This seems less about visibility and more about aesthetics, which is what irked me. If the problem is that they simply just don't like the colors, they can pick a different theme.

It's the last breadcrumb in a trail; doesn't link to anything, is redundant, and not even that difficult to see. Navigate to anywhere else on the forum, and the last breadcrumb is white as well. None of these are dark backgrounds, and the text is very clearly visible. It's not hard on the eyes at all. Maybe you just need glasses.

I don't see why people keep saying this. No where, anywhere, do I see black text on a dark background. Even in the areas with the least amount of contrast, it's still easy to read. I'm sorry if I'm coming off as an ass, but people were causing a riot about this like, last year, blowing it ridiculously out of proportion. Complaining about a few pixels on a checkboard not lining up perfectly with your preferred screen resolution as being "unfinished" or "half-assed" is just beyond absurd to me. EDIT: Just pondering this a bit, taking into consideration that the side of the borders and scrollbars on browsers is different. I'm using a 1366x768 screen resolution with Maxthon browser (sidebar disabled) which has no horizontal borders. Trying resolutions of 1360x768 and 1024x768, I've concluded that for the checkerboard to line up 100% perfect for me, I would need either 2px more or 4px less of space. Then, consider that typically, in Win7, the borders on windows are 8px wide. If he was using a 1360x728 screen resolution on Win7 with a browser like Firefox or Chrome, disregarding the width of the vertical scrollbar, the checkboard would have been lined up perfectly for him.

It actually looks a little bit like really heavily stylized Katagana. ｴﾄﾜﾖﾛﾓï¾ï½¾ï¾‘ï¾ï¾‡ï¾‰ï¾•ï¾Ž Flip some characters, straighten curves, remove a few serifs, and you can see the resemblance. On a side note, the voice recognition unit of the N64 also uses a table of japanese characters for the dictionary instead of english.