SoulofDeity

On third thought, 'do' is a bit more than boilerplate. Compare "for e in c something()" with "for e in c do something()". It adds to the readability of code, especially for one-liners. Still pondering iteration, I think I might change the format of ranges to "[from <start>] to <stop> [by <step>]", and the format of an iterated for-loop to "for i r"; where "i" is the iterator and "r" is the range. Then, your basic constructs are: for e in c do something() for i from 0 to 5 by 2 do something() for i from 0 to 5 do something() for i to 5 by 2 do something() for i to 5 do something() for i, j to 5, 5 by 2, 2 do something() ----- The C++ Equivalents ----- for (auto& e : c) something() for (int i = 0; i < 5; i += 2) something() for (int i = 0; i < 5; i++) something() for (int i = 0; i < 5; i += 2) something() for (int i = 0; i < 5; i++) something() for (int i = 0, j = 0; i < 5 && j < 5; i += 2, j += 2) something() It's a tad lengthier than before, but still much more compact than traditional for loops. Just some babbling about things on my mind, pay no attention... I finally decided on a good construct for function declaration. Basically, there are no functions. There are only events, which are handled via the 'on' keyword. eg. on print text do something() As with MS visual languages, events can also have senders. on Open path, text from File do something() This will only catch events that are signalled from File's. eg. `file.Open("file.txt", "rt")`. It's a unique approach to functions compared to most other languages. -------------------------- EDIT: A bit more theorizing... As I stated before, I'm a bit unhappy with the syntax of traditional if-statements. While pondering this, I thought of something kind of interesting. if (x == 5) then something() else something() is essentially switch (x == 5) case true something() case false something() You're just omitting and implicity casting to what it is that you're comparing against. Instead of having if-statements, it may be a better idea to improve the syntax of switch-statements.

For C, I thought "The C Programming Language" and "Linux System Programming" were pretty good books. For C++, there's http://www.cplusplus.com/doc/tutorial/. I'd recommend staying away from sites like Stack Overflow, because often times incorrect answers are upvoted, they're stupidly anal about what is a "good" question, and if you ask advanced questions that most people wouldn't understand, your questions will be downvoted and left unanswered.

This is actually a separate idea, but I'm too lazy to create a topic for it... Basically, I've been working on a new programming language. I want to make something that I can use on the go, so my primary goals are conservation of screen space & minimal vebosity, simplicity to type, and expressivity in spite of redundancy. My primary inspirations come from Basic, C++, Lisp, and Python. The first goal was to simplify variable declaration. The first thing that came to mind was to use automatic type deduction. However, typing "var" all over the place seems like an obvious anti-pattern. So I dropped the "var" and decided that the initialization of a variable should be declaration of that variable. eg. "x = 5" would be a declaration of x if it hasn't been declared, and it's type would be "int". Then I considered re-usage. For things like enumerating through collections of objects of different types, the variable may need to change types. Granted, register allocation optimization can do this automatically, but expressing it visually helps to make code more clear. For this reason, it's be best if all variables are dynamically typed at compile time. However, you could enforce a specific type like "x as int = 5". The difference is that the following code: x as string = "Text" x = 5 Is equivalent to typing: x = "Text" x = 5 as string In this case, all values assigned to "x" are implicitly casted to "string". The second thing I considered was declaring multiple variables at once. Consider something like, "x = 5, y = 5". There are two equals signs here. An "=" symbol is pretty annoying to type on a phone, so I decided to adopt the Python concept of tuple-assignment: "x, y = 5, 5". But then this causes a second issue, how do we assign static types now? Would it be "x as int, y as int = 5, 5"? With that, there are two "as" keywords, so instead, I decided to rearrange it: x, y as int, int = 5, 5 Oops! Looks like I inadvertantly added product-types to my language... Having to type "int" twice though seems like such a tedious thing to do. So why not add a rule where a single element product-type can be assigned to a tuple of any size. Then we can simplify the code to: x, y as int = 5, 5 At first glace, this may seem a bit verbose, but that's just a trick of the eyes. It's actually just as compact as C/C++ declarations, and far more compact if you use the preferred dynamically typed declarations. A side by side comparison: // dynamically typed declaration (only dynamic at compile-time) i, j, s = 5, 5, "Text" x, y, z = 1, 2, 3 // statically typed declaration i, j, s as int, int, string = 5, 5, "Text" x, y, z as int = 1, 2, 3 // C declaration int i = 5, j = 5; string s = "Text"; int x = 1, y = 2, z = 3; // C++14 dynamically-typed declaration auto i = 5, j = 5; auto s = "Text"; auto x = 1, y = 2, z = 3; Ultimately, the only case where the C/C++ code is shorter is when you try to declare static typed variables. Even then, the difference is only about a 2 character gain for each symbol. But that loss is completely meaningless in the face of how this type of variable declaration simplifies the code you write. old notes: One newer idea I had in mind was the concept of ranges, declarable as "[ <start> to ] <stop> [ by <step> ]". eg. "0 to 5 by 1", "0 to 5", "5 by 1", and "5" are all valid ranges. Collections are enumerated as "for e in c". How ranges are iterated is now up to debate since an assignment of a range to 'i' negates how type deduction works. I think we can all agree that those 2 little characters we sacrificed for static-typing are well-worth the ability to write for-loops that are about 1/2 to 1/3 the size of the ones in most other languages. Currently, I'm also considering generics. Something like "vector<int>" is ugly and tedious to type, so I though maybe "vector of int" would be nice. But then, you got to consider things like "vector<vector<int> >" being "vector of vector of int", and how you could apply such a style of generics to functions. Another idea I had for my language is how it will manage raw memory. In C, there are no arrays. "x[5]" is merely shorthand for "*(x+5)". In my language, there will be no pointers. They simply add too much complexity to the language. Instead, I've been considering alternatives such the Basic's peek/poke approach and pinning addresses to vectors. The advantage of the first approach is that I could support multiple addressing modes through tuples. eg. "poke (0x1000, 0x7c00), 0x01234567" would write "0x01234567" to the address 1000:7c00. Granted, it could also be written "0x0017c000", but that's aside the point. Consider newer pc's where there's 16GiB of RAM, with a 48-bit data bus. That won't fit into a 32-bit integer. There are also machines that have multiple addressing modes. But, this is just an idea. Anyhow, there's still much more work to be done as far as this language goes. I'm avoiding any specific paradigms and focusing specifically on what works in the simplest way possible; taking the least amount of time and effort.

I'd second this. C# is an excellent choice for a first language and an introduction to object-oriented programming (though in all honesty, I consider inheritance of behaviour, encapsulation of behaviour in state, and meta-programming to be the plagues of modern programming). C is also a really good choice for an introduction to low-level concepts such as memory management and calling conventions; with a syntax from which many other languages derive. Plus, if you're on a Unix system or Cygwin/MinGW and you install the documentation packages for gcc and your libraries, you have man pages on pretty much every C function. eg. `man strncpy` from the terminal would tell you everything about the function "strncpy". The primary advantages of C++ over C are references, namespaces, enum classes, generic-like templates, function/operator overloading, exception handling, association of behavior to types, and scope-tied resource management via constructor/destructor (RAII). C++14 also includes simplified enumeration of collections via for loops, 'auto'-matic type deduction (useful for things that would typically cause code ripples in the project, like changes in const-ness), and easier ways to manage reference counters to prevent memory leaks. C++ is also applicable if you want to have a career in programming. The pitfalls are the complexity of the grammar and anti-patterns that encourage bad programming habits. They're all excellent choices though. I would even recommend Python, though it's irrelevent to the project.

That isn't compiling, they're just wrapping it inside of a JavaScript interpretter. JavaScript cannot be compiled because it's a dynamic language. Also, that tool is Windows only.

I would suggest C++14. I'm currently learning it myself because it's an enormous improvement over C++98. I've never been a fan of C++, but for a project like this, it's best to have a lot of structure.

JavaScript is a JIT'd or interpretted language. It can't be compiled. There are things like Node.js, but that restricts our options even more than Unity does.

It's possible to incorporate those features in Unity via editor extensions, but creating a custom engine would be nice. Especially since many game engines are costly, lack decent shader or framebuffer support, only support skeletal animation and not morph-target animation (or vice-versa), have bad scripting languages, or aren't cross platform.

Console development requires a special license which can only obtained by permission from the creator of the console. Eg. You can't target PS Mobile devices without a PSM developer's license (which I have). Some of the targets I have in mind are embedded systems where you practically work bare metal. A few of the things I want to tackle before I continue this are version control, resource management, GUI development, and audio sequencing.

I actually find it easier to create low-poly models, especially when you have a goal. Regardless, these models are really good. I especially like the octorok.

Exactly. The closest thing I could find to a royalty free open interchange format was Collada, which is a nightmare (just try importing or exporting *.dae files in Blender...) So far, the structure I've came up with is: Vertices Morph Target Positions Normals Colors Weights Surfaces Polygon Mesh Edges Faces Textures Sampler Repeat Mode Mirror Mode Offset Tiling Source Image Region Unlike most 3D model formats, each texture map gets it's data from a particular region of a texture atlas referenced by Sampler.Source.Image. Using a texture atlas allows you to have texture reference animation by animating the origin and/or size of the texture map's source. The advantages of doing this over simply animating texture coordinates is that your texture atlases don't have to be powers of two in size and that it consumes far less memory. Materials are still in the planning process, but I'm thinking that each material should have a rasterizer and texturizer. The rasterizer would consist of what is mostly done by vertex shaders (transformation + lighting) with fallback modes for fixed pipelines. The texturizer would consist of what is mostly done by fragment shaders (multi-pass sampling + combining). There would be no shading language in the traditional sense, but the simplicity and separation of concern would allow you to easily convert to other shader languages (including ones with either fixed or only partially programmable pipelines like the N64).

Trying to find a good 3D file format has proven difficult, so I eventually just gave up and decided to work on my own. Syntax-wise, there are only 2 rules: Anything after an unquoted # symbol on a line is ignored Everything is an object, following the EBNF format: `object = type , [ name ] , ( objects | values | value ) ;`, where 'name' is the quoted name of the object, 'objects' is set of objects between curly braces, 'values' is a set of values between square brackets, and 'value' is a set of one or more numbers, booleans, quoted strings, or identifiers between between parenthesis. An example of what it looks like: # This is a comment that will be ignored. Object "My Object" { Vertices [ "Morph Target 1" { Float3 "Positions" [ (-0.30779600 +0.00433517 +0.00000000) (+0.29912600 +0.00433517 +0.00000000) (+0.29912600 +0.00433517 +0.48337000) (-0.30779600 +0.00433517 +0.48337000) (-0.30779600 +0.36415300 +0.48337000) (+0.29912600 +0.36415300 +0.48337000) (+0.29912600 +0.36415300 +0.00000000) (-0.30779600 +0.36415300 +0.00000000) ] } ] Surfaces [ "Polygon Mesh 1" { Faces [ (6 2 1) (2 6 5) (4 0 3) (0 4 7) (6 0 7) (0 6 1) (2 4 3) (4 2 5) (4 6 7) (6 4 5) (2 0 1) (0 2 3) ] } ] } This is just a ghist of it. What I'm aiming for is a text-based interchange format that supports skeletal, morph-target, texture coordinate, and texture reference animation. In the above example, you'll see that each set of vertices can have one or more morph targets and each surface can have one or more polygon meshes. The scene graph will be represented in a similar format, but a separate file. Any suggestions are welcome

Lol, picked up this piece of shit for $6 at goodwill Notice the name, "Super Joystick". Ironic because the joystick is fake (accessory sold separately). Also, the text, "76000 in 1" is Spanish for "13000 copies of 15" NES games

Was just talking about this with people on skype and wanted to state my reasons for dropping this project. The first reason was the limitations of Unity. It made things like framebuffer effects, gui design, and looping audio a pain in the ass. It also runs on .NET which isn't supported by the devices I was interested in. The second reason was that the resource directory was a mess. Someone added like, half the sounds from noproblo.dayjo to the project. Every time I would have to merge branches, the audio assets would have to be reimported which took FOREVER The third reason was that no one was pulling the latest version of the project before pushing their code. Every time a merge had to be made, I would have to read all the new and changed code to figure out what people were doing and rewrite it to be compatible with the latest version of the project (if you guys eventually did pull and noticed the exact code you wrote wasn't in the project, now you know that it's not because I'm some prick who thinks he can write better code than everyone else). Anyhow, this would often introduce bugs that would need to be fixed. Of course, people weren't pulling these fixes and changes, so as the project progressed I had spent more time doing bug fixes and rewriting other people's code than adding new content to the game myself. At one point, the bugs got so bad I had to entirely rewrite how the GUI system worked just to fix it. I got tired of it eventually and simply went off to work on collision, leading to a noticable regression. I can't saying I'm particularly interested in continuing or restarting this project in it's current state. I'd rather take some time to develop a new set of tools that can solve these problems and then come back to it.

Was on a phone before, so I couldn't do a full response well. It sounds like you're using a custom partition layout. Regardless though, Windows doesn't recognize EXT/XFS partitions and Unix systems can't be installed on FAT/NTFS, so it's almost certain that they're using an external media. Unless they have a single partition hard drive and no CD/DVD drive or have gone out of their way to remap the drive letters on their system (highly unlikely), their D is guaranteed to be a physical drive and not a substitution.

Nah, "queen" is the name of the user. Eg. On my Mint desktop, my username is "wajideu", so my home directory is /home/wajideu". Judging by the reference to ShUnqueen in the game, it's a possibility that Shun (the leader of the Grezzo team) uses the username queen. So an 8th thing the path tells us would be that that OoT was built on the project leader's PC while MM wasn't.

So I was reading the dumped information for TP, OoT3D, and MM3D in speculation of the kind of tools they use to make games. To begin with, the Nintendo64 sdk uses a build of GCC v2.7.2 targetting 'MIPSE'. This is a deprecated target, where the current version of GCC (v4.9.2) instead uses MIPSEL and MIPSEB, which stands for "MIPS Embedded Little/Big-endian". Despite the name, MIPSEL can still build big-endian binaries and vice-versa, so why they made a second target is a mystery. Anyhow, all of the libraries and demos in the N64 sdk were written in C, and there was no C++ compiler. All N64 games were written in C. The OoT MQ debug rom references a ton of *.c files, one of which to keep in mind for future reference is a file called 'z_player.c', which is listed 12 times at 0x00C240E0 in the rom. The N64 sdk also came with a suite of tools for converting and debugging audio and graphics. In particular, Nintendo used something called a "Nintendo Intermediate File Format', or 'NIFF' for short. It's basically an interchangeable container for multiple other file formats, much like the RIFF format used by Microsoft for AVI and WAV files. They would convert their 3D models to NIFF files, and then use a specific tool to convert the NIFF files into raw display lists for the RCP of the N64. When GC games came along, the game data took on the form of individual files. Zelda and Mario games in particular used BAS (audio source), BDL (display list), BMD (model), BCK (combined keys), BRK (rotation keys), BTK (translation keys), BMT (material), BTI (texture image), BTP (texture pointer), and BLO (layout) files. While vastly different, this separation of data gives us a bit of insight as to how resources are developed. For example, texture frame animation uses a separate file containing pointers. For the N64, they could toss out the pointers to reduce memory by simply dumping the textures used by the pointer list into the object file back-to-back and referencing them by index. Additionally, their GUI design is based on layouts. Finally, when we take a look at the information dumped from OoT3D and MM3D, we notice a lot of peculiar things. The things that tells us the most about how their development cycle works is a simple file path: 'd:\home\queen\dailyBuild\game_eu\sources\z_player.cpp'. What does this say exactly? Well, firstly, starting with Windows Vista, the 'd:/' drive has been reserved for the system recovery partition. This means that the developers are using either WindowsXP or earlier to perform their daily builds. The second thing is that they are using a Unix system for their main development (implied by the FHS-structured path). The third thing is that the developers are exchanging their daily builds via cd's. How can we tell this? Well, on Windows, drive letters A and B are reserved for floppies and C is reserved for the first hard drive. Everything after that is labelled D through Z. This means that D will be a second logical partition on the hard drive, a secondary hard drive, or a CD/DVD drive. Unix systems rely heavily on symlinks which are not supported by FAT32 or NTFS partitions. Since we know they are using Windows to perform daily builds and it can't detect EXT/XFS volumes, we can rule out that drive D is a secondary logical partition or hard drive. The fourth thing is that they contain all the resources for all their games in one directory. This is implied by the fact that the project is merely called 'game' and that each file has a 'z_' prefix that would otherwise serve no purpose. It also explains why OoT3D and MM3D would have leftover N64 graphics, and why some OoT3D models somehow made it into MM3D (sheik, ganondorf, impa, saria) despite there being no reason to copy the resources deliberately. The fifth thing is that they are now using C++, as shown by the filename 'z_player.cpp'. Nowadays, there are C++ compilers, but in the past it used to be translated to C and then compiled. So from this we can assume that the game was either entirely rewritten in C++ or that OoT and MM for the N64 were originally written in C++ and translated to C to compile for the N64. The sixth thing is that the developers were not using autotools or gettext despite using GCC. Otherwise, the 'sources' directory would likely be called 'src' or not exist at all and there would be no need for 2 letter language codes like 'eu' or 'jp' in file names. Another thing that can be inferred from filenames like 'z_en_choo.cpp' is that the game engine is based on the Entity-Component System. This name in particular says, 'Zelda - Entity - Choo'. I haven't tinkered much with the 3DS game files, but in the N64 ones, other prefixes like 'bg' and 'obj' for 'BackGround' and 'OBJect' are sometimes used instead of 'en'. The ones marked as 'en' typically were either characters, enemies, or unique objects. While it may not serve much purpose, I think it's kind of interesting to have a little insight like this as to how the Grezzo team works.

The problem is visibility. The way that the web works is that there are certain servers called domain name servers that keep track of all of the web pages on the internet. When you go to "google.com", your computer first checks a hosts file to see if it knows what the IP address for that site is. If not, it sends a request to a DNS that searches a database for that name and sends back the address. With onion sites, there is no DNS. Instead, each domain name is a hash of its own address. As you would imagine, remembering 03af4de5ac426b63a4dd6e25bc42cde64.onion would be a lot harder than remembering awesomeromsite.com While you could technically make your own DNS (in other words, creating your own web ), by making a database and unleashing a horde of spiders (also called webcrawlers) like google did, getting people to accept your DNS is not that easy. The point of tor is to remain anonymous, and you're asking them to go through a middle man

The chances of a blue dev disk popping up in 2015 are nilch. Didn't fall for that for a second. The only thing I'd be interested in is how the expansion would have worked had it have been made. If they're quoting something that Miyamoto had said, it sounds like they had intended for there to be a shovel as an obtainable item and that there would be a beach. For the most part, it seems like Ura Zelda was pretty much OoTMQ+MM. Same plot as OoT, but with redesigned and new dungeons New side quests (with a focus on mask quests) All of the same characters, with a few new ones Mention of using GB Camera to create masks, which is suspicious because you can obtain a camera in MM There is a beach in MM which willl leave footsteps behind when you walk (though these are only partially persistent)

No problem. In case you want to try it out, I'll give you a quick example of how to write a C hack: Create a new file for your C-code called 'stub.c'void mystub (void) { } Create a new linker script called 'stub.x'ENTRY(mystub) SECTIONS { . = 0x806000000; .text : { *(.text) } .rodata : { *(.rodata) } .data : { *(.data) } .bss : { *(COMMON) *(.bss) } } Compile your code like `gcc -o stub -EB -mabi=32 -march=vr4300 -mtune=vr4300 -Wl,-T,stub.x,--oformat,binary,--emit-relocs stub.c` This will create a binary file called 'stub' containing your stub (as opposed to an elf file) You can either turn it into a gameshark code, or you can inject it into the rom itself and manually DMA it into memory (which is what I prefer to do) You should still be able to use your hook without any issues. Forewarning, I wrote this tutorial off the top of my head without testing it, but I'm fairly sure it'll work. At least, with the exception of '--emit-relocs' as binary format doesn't play nicely I think.

I'm not mistaken I believe that the ZLE2 also had that dependency. It's a blind guess, but I think it's part of an old version of the .NET framework; perhaps v6. All I know is that *.ocx files are ActiveX controls which are used by IE and VB scripts.

This is why I suggested Renegade64 (it uses standard MIPS syntax with register mnemonics, as opposed to GCC's goofy and quirky syntax). Plus it generates GS code directly, including in the format Nemu64 uses. Although, if you use Galatea (or any ide supporting a mips configured GCC), you have the advantage of being able to use linker scripts to do most of your hacks in C.

I'm not sure about the placement of the stack in memory, but what I did to get input was decode the GS code for 'press L to levitate' and observe the changes in the states of the nearby bits when buttons were pressed by placing a watchpoint on the address that the GS code used. For one of the OoT roms (probably 1.0), I typically loaded my stuff starting around $80170000, so it should be safe to load at $801A0000 I think. Unless he has his hook at the wrong place, there's no need to preserve T* registers, they're temporary. The problem I see is that he's simply jumping to $801A0000, and the stub he has loaded there doesn't hang or jump/branch to anywhere else. He should be jumping to 'RA' at the end of his stub. I'd highly suggest using Renegade64 to compile your GS code. There's several versions of it, but the best one to use imo is the one that shows a splash screen of a shark when it starts up.

One of the best video game soundtracks ever

Love some of Metallica's songs Recently found an old artist that's a new favorite