Banner
Views: 784,942,435
Time:
11 users online: Fullcannon, kamekku14, Koulucky,  Linkdeadx2,  NeXuS15, PokerFace,  Sayuri, Sixcorby, Sokobansolver, SquidMan_Raps, Ultima - Guests: 44 - Bots: 124 Users: 41,044 (1,548 active)
Latest: CoffeeMugs
Tip: $5.27Not logged in.
NIE (NIT Interpretation Engine)
Forum Index - SMW Hacking - Resource & Tool Releases - NIE (NIT Interpretation Engine)
Pages: « 1 »
Hello,

NIT (Neutral Integration Technique) is a "high-level scripting" language made mainly for the purpose of hacking a binary file... The language cannot be compiled but can be interpreted by using its interpreter NIE (You already know the full form, don't you?...)

The language does what it sounds, it integrates itself with the file (
That's hacking, right there!
) by reading and interpreting what is written inside the source code.

The extension of the source code is planned to be *.nit.

Its main purpose is to reduce the use of assemblers and hex editors for hacking...

So I am happy to hear more suggestions about more functions and operators I should add...

For now, this is the list of them: (I know its dirty, forgive me)
Function list:

Code
Function name       : Use
RS x                : Shifts the pointer from its default location to times x in the right.
LS x                : Shifts the pointer from its default location to times x in the left.
REW                 : Rewinds the pointer back to start.
LRS x               : Shifts the pointer from its default location to the specified one.
VAA n (v)...        : Defines an array. (NOTE: This type is not a value, instead it stores values, default is zero elements)
VAM n x (y)         : Defines a byte member and assigns its location and optional initialization value or just use the value it had. (NOTE: This type is not a value)
VAX n v             : Creates a hexadecimal variable.
VAD n v             : Creates a decimal variable.
VAB n v             : Creates a binary variable.
VAS n s             : Creates a string variable.
VAC n c             : Creates a character variable.
VAO n v             : Creates a boolean variable.
VAI n i             : Creates a interface (Universal value) variable.
INC a (x)           : Adds x times to the a member. (If nothing is specified, it will be increased by 1)
SUM x y             : Adds x and y together and returns the value. For e.g, a < SUM x y.
DEC a (x)           : Decreases x times to a member. (If nothing is specified, it will be decreased by 1)
SUB x y             : Differentiates between two values x and y and returns it.
MUL a x             : Multiples a to x and returns the value. Similar to the "*=" operator in C.
PRO x y             : Returns the product of x and y.
LDI a x             : Distributes (Divides) a x times with itself.
DIV x y             : Divides x and y and returns the value.
LMO a x             : Divides a x times with its remainder.
MOD x y             : Find the remainder of x and y and returns it.
LSH a x             : Shifts a's value by x times in left direction. (Left Shift)
RSH a x             : Shifts a's value by y times in right direction. (Right Shift)
POS a x             : Changes the member's position to the specified position.
EQU a b             : Check equality between two values.
AND a b             : Return 1 if both bytes are 1. (AND)
OR a b              : Return 1 if any one byte is 1. (OR)
XOR a b             : Return 1 if none of the bytes are 1. (XOR)
LAN l o             : Return true if both statements are true. (Logical And)
LOR l o             : Return true if any one statement is true. (Logical Or)
NOT l               : Revert any value (logical statement or byte).
IF a [...]          : Run the next statement only if true. (Allows '[' and ']' block...)
INM a (t)           : Inserts the member inside the address t times (default is 1).
INS v (t) (p)       : Inserts v at the position specified at p t times (default is 1).
ERA x (s)           : Erase the value located at x till s (default is 1) in the file.
MRE m (s) (t) (p)   : Replaces the value stored in p (removed till s, default is 1) with a member byte t times (default is equal to s).
REP y (s) (t) (p)   : Replaces the value stored in p (removed till s, default is 1) with y t times (default is equal to s).
POW x y             : Returns the power of x to y.
HEX a               : Changes a value to hexadecimal value and returns it.
DCI x               : Changes a value to decimal value and returns it. (precision is removed and is rounded)
BIN i               : Changes a value to binary value and returns it. (precision is removed and is rounded)
REL k               : Release the member from memory. (It will become unusable)
FOR l [...]         : For loop until the logical statement becomes true.
END                 : Ends the program.
RND i               : Rounds the decimal number to the nearest value.
SHW v...            : Show the value on the console during compilation. (For debugging)
SHC v               : Show the value of a decimal (changed to decimal if it is not) on the console. (Rare necessity, but for debugging as well)
NME s               : Name the script (Returns nothing, nil)
SKP l (i)           : Skip the next lines (default is 1) lines if logical condition is false.
DFR o               : Defer the statement (run it at the end) does not return anything.
ABS n               : Shows absolute (positive) value.
NEG n               : Shows non-absolute (negative) value.
GTR x y             : Returns true or false if x is greater than y.
GTE x y             : Returns true or false if x is greater than or equal to y.
LSR x y             : Returns true or false if x is lesser than y.
LSE x y             : Returns true or false if x is lesser than or equal to y.
NIL                 : Returns nothing based on type. (Works for all values)
BRK                 : Breaks the loop.
FEN                 : Forcibly end the program, without waiting for any deferred statements.
BLK n               : Used for defining a block.
JMP n               : Jumps to the specified block.
MPO m               : Returns the current position inside the member. (In hexadecimal)
MVA m               : Returns the current value inside the member. (In hexadecimal)
RPV (p)             : Returns the value stored inside the particular address. (In hexadecimal)
GET r (p)           : Returns the value stored in the specified position inside the array.
SET r v (p)         : Sets the value stored in the specified position inside the array with the specified value.
SIZ r               : Returns the size of the array.
CLR r               : Clears the array.
DEL r (s) (p)       : Deletes the value stored in the specified position in the array till s. (Can lower the size of the array as well as affect its default positions)
INS r v (s) (t) (p) : Inserts the value in the specified position in the array with the specified value (removed till s) t times. (default is equal to s)
ASK a               : Asks the user based on their opinion, press Y or S with a message specified in a. (within inverted commas)
EBC                 : Enable Byte Change  (Enables changing to the size of the file)
DBC                 : Disable Byte Change (Disables changing to the size of the file)
CPO                 : Returns the current position the pointer is pointing to.
TRU                 : True boolean constant (1)
FAL                 : False boolean constant (0)
CST                 : Constant specifier
UNS v               : Returns the unsigned value to a decimal.
CAS v               : Casts the value to an interface
RST                 : Resets the value of all variables to zero (NIL).
CBN m n v           : Changes byte value of member of n'th byte with v.
RBN m n             : Removes byte value of member of n'th byte.
REV s               : Returns a reversed string
STD s               : Converts a string to decimal member.
DTS v               : Converts a decimal value to string.
CLS s               : Clears a string member.
NOF                 : Nil find value.
FIN a w (f)         : Finds a value and returns its position from f.
FIL a w (f)         : Finds the last value and returns its position from f.
FIF a w (f)         : Finds the first value and returns its position from f.
FNF a w (f)         : Finds the first non-value and returns its position from f.
FNL a w (f)         : Finds the last non-value and returns its position from f.
FRE a w t (f)       : Finds and replaces a value.                                (returns false if fail)
FRF a w t (f)       : Finds the first value and replaces it.                     (returns false if fail)
FRL a w t (f)       : Finds the last value and replaces it.                      (returns false if fail)
RNF a w t (f)       : Finds the first non-value and replaces it.                 (returns false if fail)
RNL a w t (f)       : Finds the last non-value and replaces it.                  (returns false if fail)
RAL a w t           : Replaces all occurences of value inside member with value. (returns false if fail)
TOS s               : Converts a character to a string.
GTC s k             : Returns the character stored in the specified position in string.
GTS s a b           : Returns the substring of string from a to b.
TKS m               : Asks user-specified input with a message and returns the input inside a string.
TKC m               : Asks user-specified input with a message and returns the input inside a char. (Press of a button)
SZF (f)             : Returns the size of a file specified. (If nothing is specified, the path of the NIT file will be taken)
NMF (f)             : Returns the name of a file specified. (If nothing is specified, the path of the NIT file will be taken)
ERS s a b           : Erases a substring of the string from a to b.
ISS s a v           : Inserts a substring in the specified position.
APP s v             : Appends a string to the end of another string
RES s a v (b)       : Erases the substring from a to b and replaces it with value v. (default value of b is equals a)
FDE o n             : Defines a new user-defined name for a function.
ELS                 : If the above 'IF' statement is false, then the body of else will begin.
EIF a [...]         : If the above 'IF' statement is false, then the body of else will begin when the given statement is true or else skips it as well.
STX n               : Representation of hexadecimal in string.
STO n               : Representation of octal in string.
STB n               : Representation of binary in string.
REF a               : Referencing a variable.
RUN s               : Runs a program. (to point to current directory, use ".\Some Folder\Some_File_Here.abc")
SYS s               : Run a system() command. (WARNING!! PLATFORM DEPENDENT!!!)
STA s               : Converts a string to a character array.
ATS a               : Converts a character array to a string.
GHA s               : Returns the decimal array of a string. (from Unicode)
DTN a               : Converts a decimal array to a base number value array after rounding off. (Hexadecimal or binary, since both have the same type)
BEG                 : Mark the beginning of code. (Can only be used once)
PIR r v             : Pushes a value into register.
RFR r               : Reads a value from a register.
CAR r               : Reads the value from register.
NOP                 : Skips the instruction and increases program counter.


Variable list:

C equivalent for the variables used...

Code
Var : C Equivalent ('Cause I like colorful headings.)
VAA : void** (A pointer which stores anything inside it)
VAM : struct Member { unsigned long long address, value; } (This is the type made specifically for hacking purposes...)
VAX : unsigned long long                                   (Hexadecimal numbers HAVE to be positive)
VAD : long double                                          (Decimal numbers have the highest precision, only double is used)
VAB : unsigned long long                                   (Binary numbers HAVE to be positive)
VAS : wstring
VAC : wchar_t
VAO : bool


Operator list:

Code
Operator      : Purpose
'|'           : Separate line within one.
';'           : Single-line comment.
';[' and ']'  : Multi-line comment.
'<'           : Assigns a value (always on right) to a variable (which is always on left) and assigns it with the value (always on right) after conversion if types mismatch. For example: (SOME_VAR < 20)
'$'           : A hexadecimal value.
'%'           : A binary value.
'0'           : An octal value.


Principle:

Here, I would say that all the errors and everything of the sort is working properly, that the only thing that remains is to implement all the functions...

You might also have encountered the word pointer while reading the huge list of functions there, and that is the default position where the interpreter points if you don't specify any position in the position parameter of the functions.

There is also great importance of parenthesis [')' and '('] inside a NIT source. For example:

Code
NME example_patch ; Naming our patch as 'example_patch'
SHW (DTS (ADD 5 3))
END


This code will show (print) the value of the sum of two numbers (Here, the constants 5 and 3)

NOTE: Never do anything such as:
Code
ADD(5 3)
because that is taken as an invalid term since it processes the parenthesized arguments and expects each one to begin with a function name (Which returns a value, of course!) I know you will be opposed to that since it is probably similar to lisp... a language that is not easy for many people...


Conclusion:

Small answer, it is incomplete...

Big answer:

So the next thing is to avoid whacking my brain by implementing hundreds of functions above since the interpreter is still incomplete (only 3-4 functions have been implemented)...

But, fortunately, except the functions, everything else (errors, warnings, messages, etc.) have been implemented...

Most of all, the code is also cross-platform... But I only have Windows (Virtual Machines lag a lot but have to do it anyway!)



Thank you for taking your time to read this #tb{:j},

Quad.

mod edit: fixed table stretch

Every hacker must hack through something before
attempting to hack it...
I've just read most of this (all except the function list, basically), but I still don't quite understand what exactly this is. What is this language's purpose, how is it related to SMW hacking and what are its benefits compared to other languages?

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
@RPG Hacker Here you go!

Originally posted by RPG Hacker
What exactly is this?

What? you say? It is a high-level "scripting" language of course... It is still not finished (if you read the principle section) and I'm still working on the functions, only 2-3 have been implemented...

Originally posted by RPG Hacker
What is this language's purpose?

EDIT: The purpose has been added to the post.

Originally posted by RPG Hacker
What are its benefits over other languages?

It is easier to use than other lower level programming languages and is made mainly for hacking...

Originally posted by RPG Hacker
How is it related to SMW hacking

It is a language for hacking binary files and I assume SNES ROMs can be taken as binary files as well.

Every hacker must hack through something before
attempting to hack it...
So if I understand correctly, it's basically a language for creating patches? A language that is interpreted and then modifies whatever file you specify?

What exactly makes this "easier to use"? Hex editors or Asar, for example, are already two very convenient and easy-to-use methods/tools for editing files/SNES ROMs. How would this language make things simpler?

I have a hard time imagening this, especially when editing actual code, which is a good transition to the final point mentioned: SNES ROMs may be "binary files", but they're not just data. A good part of them, and argueably the most important part, is code, and that's also what most useful patches edit. They edit either just code or code + data, but there are very few to no patches that edit just data. How would this WIP language be beneficial in those situations? Asar, for example, uses 65c816 assembly as one of its languages. This pretty much maps directly onto the machine code in an SNES ROM. How could this language/interpreter actually be easier to use than Asar in those situations? I currently have a difficult time understanding that.

Do you maybe have some kind of example patch or something like that demonstrating the benefits and core principles of this language? Maybe some sample patch that shows how this language easily accomplishes something that would be tricky to do with other tools. That would probably make it easier to comprehend what exactly this language is aiming to accomplish.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Reading the commands, i think that snes asm is friendlier, also commands like PRO (that should be MUL) and MUL (that should be POW) can be made with macros on asar. Also you should considere that already exists a C compiler for snes and nobody use it because returns very unoptimized code, the main reason that people use snes asm is because snes have a very old processor of 2.68~3.58 MHZ, then you need a very optimized code for snes, you need a very high quality parser to do NIE usable.

Also there are some commands that i dont know how you will apply them to snes, for example VAA, VAM ,etc...

Originally posted by anonimzwx
Reading the commands, i think that snes asm is friendlier, also commands like PRO (that should be MUL) and MUL (that should be POW) can be made with macros on asar. Also you should considere that already exists a C compiler for snes and nobody use it because returns very unoptimized code, the main reason that people use snes asm is because snes have a very old processor of 2.68~3.58 MHZ, then you need a very optimized code for snes, you need a very high quality parser to do NIE usable.

Also there are some commands that i dont know how you will apply them to snes, for example VAA, VAM ,etc...


This language might be faster than C when it comes to 65816 code. However, I find some of the notes confusing.

Originally posted by Quad

INC a (x) : Adds x times to the a member. (If nothing is specified, it will be increased by 1)
SUM x y : Adds x and y together and returns the value. For e.g, a < SUM x y.


Are these both adding instructions? Why is "x" in parentheses? Returns a value where? Is A, X, and Y supposed to correspond to the 65816 registers, or are they different?
Originally posted by Drex
Are these both adding instructions? Why is "x" in parentheses? Returns a value where? Is A, X, and Y supposed to correspond to the 65816 registers, or are they different?


No no, x here is not the register, but the parameter, see the end of the function list, maybe 3-4 functions, those are newly added to do just that... If you want me to recommend something else... I would be happy to hear it...

Originally posted by anonimzwx
Reading the commands, i think that snes asm is friendlier, also commands like PRO (that should be MUL) and MUL (that should be POW) can be made with macros on asar. Also you should considere that already exists a C compiler for snes and nobody use it because returns very unoptimized code, the main reason that people use snes asm is because snes have a very old processor of 2.68~3.58 MHZ, then you need a very optimized code for snes, you need a very high quality parser to do NIE usable.


Look closely, there is already a pow function, what MUL does is that it just multiples some number with the register (Eg: MUL var 2 would multiply the variable var with 2)... You are also right about applying the commands VAA, VAM... Hmm, I have to see about that... Looks like it would take me a while to develop this tool...

Originally posted by RPG Hacker
How would this WIP language be beneficial in those situations? Asar, for example, uses 65c816 assembly as one of its languages.


Well, this language is also going to use 65c816 assembly but internally not externally... As I said before, if you want me to add something more, I will be eager to hear it...

Every hacker must hack through something before
attempting to hack it...


Originally posted by Quad
Look closely, there is already a pow function, what MUL does is that it just multiples some number with the register (Eg: MUL var 2 would multiply the variable var with 2)...

Your description of MUL reads "Multiples a x times to itself", i.e. MUL 3 4 would do "3x3x3x3", not "3x4". And POW has a bit off an odd description itself; "Returns the power of x and y" should likely read as "x to the y", but then, what makes these two functions different?

And as previously mentioned, this language still has the issue of, "will it be worth the time investment to develop?". Keep in mind that people need a reason to actually learn this language, and because of the SNES limitations mentioned, unless you can provide a really good reason it's going to have limited use.

Unless you're planning to actually find a way to implement these functions in ASM (which will be extremely difficult for some of the concepts you have laid out, by the way), many of these are already implemented in existing assemblers. And SNES codes are rarely so complicated as to require many of these.


Please understand, we're not necessarily trying to discourage you from doing things like this, but consider whether or not what you're trying to do is worth the time and effort necessary to do it.

Professional frame-by-frame time wizard. YouTube - Twitter - SMW Glitch List - SMW Randomizer
Originally posted by Quad
Well, this language is also going to use 65c816 assembly but internally not externally... As I said before, if you want me to add something more, I will be eager to hear it...


Though what is the gain of using this language? Why would I not just use SNES ASM directly? It's already reasonably simple to use and, probably, results in better performance.

Usually, people use ASM if they want to achieve maximum performance and use some kind of higher-level language (like C or C++) if they want to sacrifice some of that performance for code that is easier to write and to maintain. This language currently feels like it doesn't fill either of those niches. It's unlikely to be as performant as native 65c816 code, yet it also doesn't feel like it's a lot simpler to write or a lot more flexible, and considering the SNES's processor isn't really that fast to begin with, there's probably never a real reason to not pick ASM/maximum performance over anything else.

As Thomas said, I'm not trying to discourage you or anything, I'm just raising a few actual concerns I'm having regarding the meaningfulness of such an undertaking.

--------------------
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!


Okay, I will try to be succint here.

The first thing I'll consider here is a lexical, syntactic and semantic analysis of your scripting language. My conclusion when looking at the syntax, the instructions' names and the language itself is... that it's confusing to the point that I can't describe how exactly some functions work, so I won't be able to write a program sufficiently clear in order to do what I want. The syntax don't help either, as I found some things I consider hard to comprehend and to even program, like (ADD 5 3) opposing to ADD(5 3); I think, and others may agree with me, that the second form would be easier to understand, because it's more related to we find, for example, in languages such as C and Java.

The second problem is the language structure itself: a bunch of commands I find redundant (like the store commands, such as HEX, DCI and BIN, since you differentiate the constants using unary operators), others too confusing to even understand, and, finally, some of the instructions being too complex to even think using this language to, say, use in something related to SMW (like the string ones).

The next issue I'll address: the names. It's clear that you're heavily inspired by the 65c816 assembly, I can tell. The problem is, while 65c816 has a set of a short-named instructions (like LDA, LDX, LDY... all of them with 3 letters and nothing more, sans modifiers, like .w, .b and .l), they're quite easy to understand based on usage context alone. Your language, however... is quite difficult to understand; I'm implying here that you can use longer names for your instructions, like x86_64 and even MIPS (yes, I'll cite here instructions like bgezal, bltzal, jalr, addi, etc.) do. Example: you declare the constant booleans as TRU (1) and FAL (0). I'll ask bluntly: Why don't you use "true" and "false", which are significantly easier to understand? The same of other commands: well, when I see something as PRO, I won't deduce in a acceptable time, in order for me to code something, that's a multiplication; I actually prefer that this particular command to be called "mult" or similar. Also, I'll cite your variable declaration names: please, one name for every type of variable to have? You can do something akin to JavaScript, but declaring the type afterwars: like, for example, "var int $7F" or "var bool false" and such, and you don't need to differentiate the integer base representations, such as binary, octal and hex by adding other types: you can do this inside the interpreter you code. Other instances of, as I see, bad language definition can be found, but I promised to be succint; if I were to address all the things I found problematic, confusing or just redundant, we'd have a complete essay here.

Now, let's go to the main issue here: the applicability. You weren't clear in what uses your script language has. And worse: this particular subforum deals with SMW Hacking resources. Pray tell, how this language helps in SMW Hacking? Let me give an example: is your interpreter ready to, say, convert a floating point variable to the fixed point that SMW uses? Other question: how would you deal with strings and the endianess of the SNES assembly? These questions may go on and on.

Now, let's go on about some quotes, shall we?

Originally posted by anonimzwx
Reading the commands, i think that snes asm is friendlier, also commands like PRO (that should be MUL) and MUL (that should be POW) can be made with macros on asar. Also you should considere that already exists a C compiler for snes and nobody use it because returns very unoptimized code, the main reason that people use snes asm is because snes have a very old processor of 2.68~3.58 MHZ, then you need a very optimized code for snes, you need a very high quality parser to do NIE usable.

Also there are some commands that i dont know how you will apply them to snes, for example VAA, VAM ,etc...


anonimzxw goes beyond my analysis saying that SNES assembly is friendlier (I saw that just using instruction names as a reference) and the existence of the C compiler for SNES. Seriously, SNES is a very old computer of sorts, its processor having a limited frequency (up to 3.58 MHz, while a crappy FPGA nowadays has at least 50 MHz) and mainly a very limited memory; as you probably know, high-level languages sacrifice time and SPACE (yes, space. Try to compile a simple C code to a x86 one, and try to do the same code directly with x86; the size difference can be HUGE, considering that C defines a lot of additional tables to the executable program after compiling; I'm not even mentioning the static linking process here) on behalf of ease to understand the code, a thing your language definitely doesn't have (sorry, but I have to be blunt here).

Originally posted by RPG Hacker
What exactly makes this "easier to use"? Hex editors or Asar, for example, are already two very convenient and easy-to-use methods/tools for editing files/SNES ROMs. How would this language make things simpler?


I'll answer this, RPG Hacker, considering all I and anonimzxw have said: this is definitely not easier to use than 65c816, asar or hex edits, mainly because it's confusing and, while trying to be a higher-level back-end for SNES, I'm afraid that it fails in this job.

Originally posted by Thomas
Your description of MUL reads "Multiples a x times to itself", i.e. MUL 3 4 would do "3x3x3x3", not "3x4". And POW has a bit off an odd description itself; "Returns the power of x and y" should likely read as "x to the y", but then, what makes these two functions different?

And as previously mentioned, this language still has the issue of, "will it be worth the time investment to develop?". Keep in mind that people need a reason to actually learn this language, and because of the SNES limitations mentioned, unless you can provide a really good reason it's going to have limited use.

Unless you're planning to actually find a way to implement these functions in ASM (which will be extremely difficult for some of the concepts you have laid out, by the way), many of these are already implemented in existing assemblers. And SNES codes are rarely so complicated as to require many of these.


Please understand, we're not necessarily trying to discourage you from doing things like this, but consider whether or not what you're trying to do is worth the time and effort necessary to do it.


I'll commend you for devoting your time to create something like this; I did something similar in a project ages ago, so I understand the difficulty (my project was to take a hypothetical language and convert it to an ELF object code, executable in Linux). The question is: have you thought in what reasons people would want to resort to your resources? In my case, for example, I can say, without a doubt, that my project was only to show that a limited set of instructions can be used to create a Turing machine. Thomas also cited some issues you have, again, with instructions, their behavior and names, things I already said in my initial comments. Last but not least, some of your instructions, if you're planning to convert them to 65c816... I wish you good luck and a LOT of patience. And I won't even start to say anything about the floating point shenanigans.

Originally posted by Quad
NIT (Neutral Integration Technique) is a "high-level scripting" language made mainly for the purpose of hacking a binary file... The language cannot be compiled but can be interpreted by using its interpreter NIE (You already know the full form, don't you?...)


Sorry, dude, but again I'll be blunt: this cannot, in any circumstance, be considered a "high-level" scripting; it looks like more an assembly than a language like, for example, C. And I'm comparing your language to a language that is the arguably one of the lowest level of the high-level languages that exist. Also, with all respect, there are some esoteric-language elements in your code; I'm not saying your NIT resembles something like, say, Brainf**k or Malbolge that much, but there's some level of clarity loss that puts your language in a level just above them. Another thing I'll say here: the fact this language is interpreted. Sorry, but if you want to make something SNES-related and it's not an emulator... interpreting ASM is a big no-no. It goes against the very idea of assembly, which you want to do when modifying your ROM to attend your needs. And, like RPG Hacker said, you didn't consider the peculiar format that SNES' memory has, like RAM Mirrors, SNES registers and such.

All in all, let's resume my thoughts, in order for me to not write a lengthy essay or similar: your efforts are admirable, I will give credit you for that, but... there's a big number of flaws and inconsistencies that make your language quite undesirable to use, even if it's not SMW-related usage. I found the syntax too confusing, you don't explain in detail how your instruction modes work, and you didn't give any concrete example of a solid code that uses the language and what it can do.

Last but not least, I'd like for you to see this project on GitHub; please take note that, while it's not a simple language to understand and it doesn't have practical uses, it gets the syntax thing clear, and you'll see that the instructions are not redundant to the point you'll crack your head trying to comprehend them. I'd like for you to think about that, and take in consideration things we all said here; I think just the improvement on your syntax would be good to your language and would even simplify your effort to code an interpreter or similar.

I hope that this review helps you, with all respect.

--------------------


Signed Major Flare, a.k.a Br OW Hacker.


Pages: « 1 »
Forum Index - SMW Hacking - Resource & Tool Releases - NIE (NIT Interpretation Engine)

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2019 - SMW Central
Legal Information - Privacy Policy - Link To Us


Total queries: 7

Menu

Follow Us On

  • YouTube
  • Twitch
  • Twitter

Affiliates

  • Talkhaus
  • SMBX Community
  • GTx0
  • Super Luigi Bros
  • ROMhacking.net
  • MFGG
  • Gaming Reinvented