I have a very simple monocolor icon for AR that needs to emit light. How can I edit the MTL file to make it do so?
This is what I made so far but is not glowing.
newmtl #63c7b2
Kd 0.3058824 0.8470588 0.5921569
Ka 0.3882 0.780 0.6980
Ke 17 12 4
illum 2
Even though this post is over 2 years old, it's sad it only received one wrong answer, adding this question to the billions of unanswered (or incorrectly answered) questions littering the internet. So, here's the answer to it finally to get one more unanswered question off the internet.
Emission is handled by rendering of whatever software you use to render the OBJ, just like how the software is responsible for applying the normal map.
To respond to that bluntly wrong answer above that said "MTL files offer no form of emission support and Ke is not a valid keyword", I will paraphrase Luke Skywalker: "Everything part of what you just said is wrong."
-There is an "map_Ke" keyword, although un-official like most of MTL's keywords, and MTL's do offer emission support, the software that processes the MTL file (and OBJ) just has to support it also.
example:
map_Ke texture.png
or even
map_Ke -s 1 1 1 -o 0 0 0 -mm 0 1 texture.png
So basically, you can have emissions in OBJ's but the 3D software you use that loads the OBJ and MTL has to know how to apply emissions. Most 3D software can apply emissions but not many expect emission data from an OBJ file so they don't look for or process it. So solution to this question is "use 3D software that can fully process an OBJ file with emissions". Admittedly that will be hard to find.
There's probably a few out there, the old "Honorsoft OBJ Importer" does, but it's been made private.
-Maybe try Blender? Here's proof (from other people) of what I said already though:
-To any still saying that emissions in OBJ aren't officially supported, that's not true. Emissions are supported and have been given a specific Ke. What people have to understand is it's not the format that is not supporting emissions, it's the 3D software you're using to process the OBJ that doesn't support emissions, or at least doesn't bother to process them from OBJ's. I have used and made OBJ software that supports emissions and can even process rig data, just like in DAE.
-Like I said, most statements in OBJ are unofficial, but that's just because the developers of Wavefront don't care much about it anymore and don't bother to update the "official" docs.
...and software that doesn't support a simple emission line is like making a video-player that doesn't support audio.
MTL files offer no official form of emission support and thus Ke is not a valid keyword, although some applications will unofficially understand it, and proposals for its extension have been made.
If you have the freedom to do so, switching to a software that understands it, or, preferably, another format that supports emission, might fix this issue for you. If not, the best you can do is use illum 0 to make it so that the material isn't affected by lighting.
Source1 / Source2
Related
Background:
I have been eyeing writing an application which needs very basic but fast graphics (just drawing lines and squares), and I'm probably going to use a library such as GLFW, or Vulkano if i'm going with Rust.
I want to understand a specific, and I guess quite practical, detail of the Vulkan API. I understand that GPUs can be quite a complicated topic, but I want to emphasize that I don't have any background in low-level graphics or Vulkan, so I understand if my question cannot be answered, or if my question does not even make sense. I'll try my best to use the correct terminology. I have to admit, I'm not the best at skimming through and looking at large amounts of source code I don't quite understand and still grasp the overall concept, which is why I hope I can find my answer here. I've tried looking at the source code for Vulkan and Mesa drivers, but it bore no fruit.
ORIGINAL Question:
I want to understand how an API call is propagated to the GPU driver.
I have searched around, but couldn't find the specifics I am searching for. The closest posts I've found are these two:
https://softwareengineering.stackexchange.com/questions/279069/how-does-a-program-talk-to-a-graphics-card
https://superuser.com/questions/461022/how-does-the-cpu-and-gpu-interact-in-displaying-computer-graphics
They both mention something similar to "In order to make the GPU do something, you have to make a call via a supported API". I know that, but neither of the two dig into the specifics of how that API call is made. Hopefully, the diagram below illustrates my question.
MyVulkanProgram.c with "#include <vulkan/vulkan.h>"
|
| (Makes call via Vulkan API)
v
This is the part I don't understand!
|
v
Driver (Mesa, for example) takes the request sent via the Vulkan API.
|
| (Driver asks GPU to perform task)
v
GPU does task
I don't care what or how the GPU does something. Just how it is invoked through the API call via Vulkan and how it propagates through the system. Ideally what I'm looking for is a code-snippet or link to where in the Vulkan source code the actual request is sent to the driver.
Or have I gotten it all wrong? Is Vulkan more part of the driver than I realize? Is it maybe the case that the driver includes the same Vulkan header as my "MyVulkanProgram.c" and the driver is linked together with library files such as libvulkan.so et al? Is it more like the diagram below?
MyVulkanProgram.c with "#include <vulkan/vulkan.h>"
|
| (Makes call via Vulkan API)
v
Driver (Mesa, for example, which includes the vulkan headers and is linked with the Vulkan shared object-files) takes the request sent via the Vulkan API.
|
| (Driver asks GPU to perform task)
v
GPU does task
Might be a basic question, might not be, but I'm confused nonetheless. Very thankful for any answers!
UPDATED Question:
After having read the answer from #krOoze (answer from krOoze), and given the "Vulkan loader" overview figure in the mentioned document, I can more precisely express my question.
How does an application, making a call via the Vulkan API, reach the ICD via the Vulkan loader?
You are looking for the Vulkan-Loader/LoaderAndLayerInterface.md documentation.
The app interfaces with The Loader (sometimes called Vulkan RT, or Vulkan Runtime). That is the vulkan-1.dll (or so).
The Loader also has vulkan-1.lib, which is classic dll shim. It is where the loading of core version and WSI commands happens, but you can skip the lib and do it all manually directly from the dll using vkGetInstanceProcAddr.
Then you have ICDs (Installable Client Drivers). Those are something like nvoglv64.dll, and you can have more of them on your PC (e.g. Intel iGPU + NV). The name is arbitrary and vendor specific. The Loader finds them via config files.
Now when you call something to a command obtained with vkGetInstanceProcAddress (which is everything if you use the *.lib only), you get onto a loader trampoline, which calls a chain of layers, after which the relevant ICD (or all of them) are called. Then the callstack is unwound, so it goes the other direction until the returned to the app. The loader mutexes and merges the the input and output to the ICD.
Commands obtained with vkGetDeviceProcAddress are little bit more streamlined, as they do not require to be mutexed or merged and are meant to be passed to the ICD without much intervention from the Loader.
The code is also at the same repo: trampoline.c, and loader.c. It's pretty straightforward; every layer just calls the layer below it. Starts at the trampoline, and ends with the terminator layer which in turn will call the ICD layer.
I am using a Keygen application (.exe). There are two input fields in it's GUI:
p1 - at least 1 digit, 10 digits max - ^[0-9]{1,10}$
p2 - 12 chars max - uppercase letters/digits/underscores - ^[A-Z0-9_]{0,12}$
Pressing generate button produce a key x.
x - 20 digits exactly - ^[0-9]{20}$
For each pair (p1,p2), there is only one x (in other words: f(p1,p2) = x is a function)
I am interested in it's encryption algorithm.
Is there any way of reverse engineering the algorithm?
I thought of two ways:
decompiling. I used snowman, but the output is too polluted. The decompiled code probably contains non-relevant parts, such as the GUI.
analyzing of input and output. I wonder if there any option to determine the used encryption algorithm by analyzing a set of f(p1,p2) = x results.
As you mentioned, using snowman or some other decompiling tools is probably the way to go.
I doubt you would be able to determine the algorithm just by looking at the input output combinations, since it is possible to write any kind of arbitrary algorithm, that can behave in any way.
Perhaps you could just ask the author what algorithm they're using ?
Unless it's something really simple, I'd rule out your option 2 of trying to figure it out by looking at input and output pairs.
For decompiling / reverse engineering a static binary, you should first determine whether it's a .NET application or something else. If it's written in .NET you can try this for decompilation:
https://www.jetbrains.com/decompiler/
It's really easy to use, unless the binary has been obfuscated.
If the application is not a .NET application, you can try Ghidra and/or Cutter which both has pretty impressive decompilers built in:
https://ghidra-sre.org/
https://cutter.re/
If static code analysis is not enough, you can add a debugger to it. Ghidra and x64dbg work really well together, and can be synced via a plugin installed in both.
If you're new to this, I can recommend both that you look into basic assembler for the x86 platform so you have a general idea of how the CPU works. Another way to get started is "crackme" style challenges from CTF competitions. Often there great write-ups with the solution, so you have both the question and answer available.
Good luck!
Type in p1 and p2. Scan the process for that byte string. Then put a hardware breakpoint for memory access on it. Generate the key, it will hit that hardware breakpoint. Then you have the address which accesses it and start reversing from there in Ghidra(Don't forget to use BASE + OFFSET) since ghidra's output won't have the same base as the running application. The relevant code HAS to access the inputs. So you know where the algorithm is. Since it either directly accesses it, or somewhere within that call chain is accessed relatively fast. Nobody can know without actually seeing the executable.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want to start learning Forth (like in the related Stack Overflow question Is it practical to learn and use Forth?). I see that there are many implementations. I would like to use a
ANS 1994 compatible version (if reasonable, but sticking to the standard might be good)
small and compact implementation, I don't want a full OS.
Windows
easy to use, I am new to Forth ;-)
What particular implementation can be recommended?
Win32Forth is really fantastic, as mentioned above. It has a nice integrated development environment and is a pretty modern implementation that seems to match up very well with the standards as well as including some more experimental but widely-accepted features.
I use Gforth, but I also use Vim to edit source files. :) Gforth is good and "classic" as far as the features it supports. It gives you a very "old school" Forth experience without being overly quirky to use. (Some free Forths do odd things with their command lines and such - I use Brodie's "Starting Forth" as the model of how a Forth interpreter should behave.)
I looked at SwiftForth, which is a very nice "high tech" Forth system that goes well beyond what the classic Forths offer in terms of language features and really brings Forth into the modern programming world. If you want to actually do Forth programs professionally, SwiftForth looks like it can handle just about anything you want to do with it.
Some time ago I evaluated 4tH, an implementation of Forth.
I think it meets all of
your requirements. For instance the compiler is only 61 KB. There is also full support for floating point numbers, important if you want to
try to use it for technical/scientific purposes.
4tH runs on most operating systems, including MS-DOS, MS-Windows (both 16 bit and 32 bit), Linux, Coherent, AIX, SunOS, BOS, BSD, Mac OS X, BeOS, RISC OS, etc. Download (Windows installer, 1.5 MB, includes the manual). Manual (PDF, 1.1 MB).
There is an active community centered around the Google Group 4tH-compiler.
For instance today I received two messages.
Please note that in 4tH you can't define your own defining words (words executing at compile time). This is not a serious
limitation, unless you want to cover advanced Forth features.
To get you started (as this is not very clear from the manual or the interactive compile), after installation copy the compiler, 4th.exe, to an empty folder, make two files in this directory, HelloWorld.bat and HelloWorld.4th, and run HelloWorld.bat:
HelloWorld.bat:
4th.exe cx HelloWorld.4th
pause
HelloWorld.4th:
: hello ." Hello from XYZ!" cr cr ;
hello
SwiftForth. It isn't self-consciously small and compact; it just happens to be. It's easy to use (LOCATE WH EDIT , a nicer than usual WORDS), comes with two books, and has an excellent mailing list with over a decade of archives. The evaluation version won't let you compile turnkey apps or DLLs; it still provides an excellent console for a student, and can support scripts in the usual ways. Quick Windows examples:
: sleep-monitor ( -- )
HWND_BROADCAST WM_SYSCOMMAND SC_MONITORPOWER 2 SendMessage drop ;
library dnsapi.dll
( ... DLL imports, constants ... )
variable results
: DnsQuery ( z -- res )
DNS_TYPE_A 0 NULL results NULL DnsQuery_UTF8 ;
: resolves? ( z -- f )
DnsQuery if false exit then
results # DnsRecordListFree true ;
\ an example use of the dialog compiler
\ this compiled DSL is an example of something that 4th
\ precludes with its "not ... serious limitation"
DIALOG (HELLO-ABOUT)
[MODELESS " About Hello" 10 10 120 70
(FONT 8, MS Sans Serif) ]
\ [class text id x y sx xy ]
[CTEXT " HELLO" -1 10 10 100 10 ]
[CTEXT " (C) 1997 Forth, Inc." -1 10 25 100 10 ]
[CTEXT " http://www.forth.com" -1 10 35 100 10 ]
[DEFPUSHBUTTON " OK" IDOK 35 50 50 14 ]
END-DIALOG
Download Gforth for PC and Android.
Tinker with it using it as a calculator, solving simple problems, Fibonacci, solving the quadratic a b c, etc.
I realise they might not meet all your requirements but the following Forth-like languages might also interest you from a learning perspective.
Factor
RetroForth
Additionally, I have found the Re-Factor blog to be a good introduction to Factor.
If you can find a copy of FORTH Inc's old polyFORTH, and an old x86 that can run it, this is the language used in Leo Brodie's original "Starting FORTH". It is a clean and very robust FORTH.
I recommend ciforth, as you're a Windows user the version built for Windows is known as wina: an MS-WIndows NAtive Forth.
ciforth is a small system written in NASM assembler, and comes with a similar interface for a wide variety of systems. It's small, fast, classic (blocks ftw), easy to use as it's old school, comes with a ton of documentation and a wordlist that isn't overwhelming like Gforth's (the wordlist for Lina is here, the only difference between lina and wina are in words that access the underlying OS: linux/MS-Windows).
Gforth has a lot of bloated definitions and some of Starting Forth won't work in it, for example.
The only thing the official release of ciforth lacks is a floating point stack, but Forth can deal with fixed point incredibly well (if one reads Starting Forth, one learns about how to use it).
wina versions can call dll functions just fine, in 32 and 64 bit, but can also make turnkey applications that call dll functions.
Beta releases have floating point as a loadable extension.
Win32Forth worked well for me.
durexForth is an ANS compliant C64 Forth and very small.
The goal of IDEs is increase productivity. They do a great job at that. Refactoring, navigation, inline documentation, auto completion help increase productivity immensely.
But: Every tool is a weapon. The very same IDE helps to produce chunk code. Some IDE features are an invitation to produce bad code: code generation, code formatting tools, refactoring tools.
IDE overuse tends to isolate developers from the necessary details. It is a good thing that you can start working but at some point in your career you have to be able to figure out how to start a process. You can ignore this detail for some time, in the end they are important to write a working product (vs. bolted together stuff that works 90% of the time).
How do you encourage positive behavior of other developers working with an IDE? This is a question as old as copy and paste.
To get the right impression: developers have to have the maximum freedom to mobilize their maximum creativity and motivation. They may use IDEs and all the related tools as they see fit. Nobody should impose draconian measures on them. I don't want to demotivate and force someone to do something. Good behavior has to be encouraged. It has to itch little a bit if you do the wrong thing. In the same line as the SO "accept rate" metric (and reputation). You can ignore it but life is better if you follow the rules.
(The solution should work in a given setting. You can ignore reviews, changing the staffing or more education as potential solutions.)
Train your IDE, instead of being trained by it.
Set up code formatting the way you (or your team) wants it. Heck, even disable it in cases where it makes sense. I've never seen an IDE align something like this with a sensible combination of tabs and spaces (where \t is obviously the tab character):
{
\tcout << "Hello "
\t << (some + long + expression +
\t to_produce_the_word(world))
\t << endl;
}
In languages like Java, you cannot avoid boilerplate. The best option you have is to check generated code, ensuring that it is the same as what you'd have written by hand. Modify it as necessary. Configure your IDE to generate the exact code that you need, if possible. Eclipse is pretty good at this.
Know what's going on under the hood.
Know that your IDE is actually invoking the compiler. Have some insight into the flags that it passes. Be able to invoke the compiler from the command line.
Know about the runtime system. Be aware of the flags that are used or needed to launch your program. Be able to launch the program from a command line.
I think before anyone uses a RAD tool of any type they should be able to write the application from scratch (scratch being wiring together the framework components) in notepad potentially on a computer that is 10 years older than current technology :P. Not knowing the ins and outs of a paradigm/framework leads to bad code from novice developers who only learn things at a mile high view of the platforms they develop for. Perhaps they should do this in a few technologies -- i.e., GTK programming is completely different to MVC which is then also different to SWING and .NET.
I think the end result should be a developer that thinks of the finer details of a problem before they jump to thinking of how they will write an interface to it in a specific RAD environment.
its an open ended question, but...
We have a Eclipse format file that everyone shares, so that we all format the code in the same manor. (Except the one lone InteliJ guy we have).
Everyone shares a dictionary file. It helps to remove all the red lines from the code. Making it look cleaner and more readable.
I run EMMA over the code to find out who isn't testing their code, and then moan at them.
The main problems we face is that most of the team don't know all the features/power of the IDE (eclipse). The didn't know about CTRL + O (twice), or auto code gen. All I can do as a 'hot key wizard' is keep sharing my knowledge with them to help them become more productive.
I look forward to the day when my problem is that they auto gen as much as possible.
Rather than me finding bugs where the wrong value is returned from a getter method due to a typo.
Attempt development (at least occasionally) using only a text editor and launching the compilation, testing, etc. from the command line.
Typing the commands will get tedious very quickly so create scripts or (even better) learn rake, ant, msbuild.
If the IDE does code generation for you and that code generation is really important (such as generating classes from xsd or proxy classes from wsdl), try to find out how to run the code generation from the command line - then hook the code generation into a build (so you'll never be tempted to edit the generated code).
The idea of autoformatting code is great but it usually just turns your code into a mess. If you have less code, minor formatting inconsistencies are just not a big deal.
Adding code quality tools into your build - style checks, class and method sizes, complexity, code duplication, test coverage, etc (complexian, simian, flog, flay, ndepend, ncover, etc.) will discourage IDE generated code.
I am dabbling in PHP and getting my feet wet browsing SO, and feel compelled to ask a question that I've been wondering about for years:
When you write an entirely new programming language, what do you write it in?
It's to me a perplexing chicken & egg thing to me. What do you do? Say to yourself Today I'm going to invent a new language! and then fire up. Notepad? Are all compilers built on previously existing languages, such that were one to bother one could chart all programming languages ever devised onto one monstrous branching tree that eventually grounded out at... I don't know, something old?
It's not a stupid question. It's an excellent question.
As already answered the short answer is, "Another language."
Well that leads to some interesting questions? What if its the very first language written for
your particular piece of hardware? A very real problem for people who work on embedded devices. As already answered "a language on another computer". In fact some embedded devices will never get a compiler, their programs will always be compiled on a different computer.
But you can push it back even further. What about the first programs ever written?
Well the first compilers for "high level languages" would have been written in whats called "assembly language". Assembly language is a language where each instruction in the language corresponds to a single instruction to the CPU. Its very low level language and extremely verbose and very labor intensive to write in.
But even writing assembly language requires a program called an assembler to convert the assembly language into "machine language". We go back further. The very first assemblers were written in "machine code". A program consisting entirely of binary numbers that are a direct one-to-one correspondence with the raw language of the computer itself.
But it still doesn't end. Even a file with just raw numbers in it still needs translation. You still need to get those raw numbers in a file into the computer.
Well believe it or not the early computers had a row of switches on the front of them. You flipped the switches till they represented a binary number, then you flicked another switch and that loaded that single number into the computers memory. Then you kept going flicking switched until you had loaded a minimal computer program that could read programs from disk files or punch cards. You flicked another switch and it started the program running. When I went to university in the 80's I saw computers that had that capacity but never was given the job of loading in a program with the switches.
And even earlier than that computer programs had to be hard wired with plug boards!
The most common answer is C. Most languages are implemented in C or in a hybrid of C with callbacks and a "lexer" like Flex and parser generator like YACC. These are languages which are used for one purpose - to describe syntax of another language. Sometimes, when it comes to compiled languages, they are first implemented in C. Then the first version of the language is used to create a new version, and so on. (Like Haskell.)
A lot of languages are bootstrapped- that is written in themselves. As to why you would want to do this, it is often a good idea to eat your own dogfood.
The wikipedia article I refer to discusses the chicken and egg issue. I think you will find it quite interesting.
Pretty much any language, though using one suited to working with graphs and other complex data structures will make many things easier. Production compilers are often written in C or C++ for performance reasons, but languages such as OCaml, SML, Prolog, and Lisp are arguably better for prototyping the language.
There are also several "little languages" used in language design. Lex and yacc are used for specifying syntax and grammars, for example, and they compile to C. (There are ports for other languages, such as ocamllex / ocamlyacc, and many other similar tools.)
As a special case, new Lisp dialects are often built on existing Lisp implementations, since they can piggyback on most of the same infrastructure. Writing a Scheme interpreter can be done in Scheme in under a page of code, at which point one can easily add new features.
Fundamentally, compilers are just programs that read in something and translate it to something else - converting LaTeX source to DVI, converting C code to assembly and then to machine language, converting a grammar specification to C code for a parser, etc. Its designer specifies the structure of the source format (parsing), what those structures mean, how to simplify the data (optimizing), and the kind of output to generate. Interpreters read the source and execute it directly. (Interpreters are typically simpler to write, but much slower.)
"Writing a new programming language" technically doesn't involve any code. It's just coming up with a specification for what your language looks like and how it works. Once you have an idea of what your language is like, you can write translators and interpreters to actually make your language "work".
A translator inputs a program in one language and outputs an equivalent program in another language. An interpreter inputs a program in some language and runs it.
For example, a C compiler typically translates C source code (the input language) to an assembly language program (the output language). The assembler then takes the assembly language program and produces machine language. Once you have your output, you don't need the translators to run your program. Since you now have a machine language program, the CPU acts as the interpreter.
Many languages are implemented differently. For example, javac is a translator that converts Java source code to JVM bytecode. The JVM is an interpreter [1] that runs Java bytecode. After you run javac and get bytecode, you don't need javac anymore. However, whenever you want to run your program, you'll need the JVM.
The fact that translators don't need to be kept around to run a program is what makes it possible to "bootstrap" your language without having it end up running "on top of" layers and layers of other languages.
[1] Most JVMs do translation behind the scenes, but they're not really translators in that the interface to the JVM is not "input language -> output language".
Actually you can write in almost any language you like to. There's nothing that prevents you from writing a C compiler in Ruby. "All" you have to do is parse the program and emit the corresponding machine code. If you can read/write files, your programming language will probably suffice.
If you're starting from scratch on a new platform, you can do cross-compiling: write a compiler for your new platform, that runs in Java or natively on x86. Develop on your PC and then transfer the program to your new target platform.
The most basic compilers are probably Assembler and C.
Generally you can use just about whatever language you like. PHP was written in C, for example. If you have no access to any compiler whatsoever, you're going to have to resort to writing assembly language and compiling it to machine code by hand.
Many languages were first written in another available language and then reimplemented in itself and bootstrapped that way (or just kept the implementation in the foreign language, like PHP and perl), but some languages, like the first assembler was hand compiled to machine code like the first C-compiler was hand compiled to assembly.
I've been interested in bootstrapping ever since I read about it. To learn more I tried doing it myself by writing my own superset of BF, which i called EBF, in itself. the first version of EBF had 3 extra primitives and I hand compiled the first binary. I found a two step rhythm when doing so. I implemented a feature in the current language in one release and had a sweet release where I rewrote the code to utilize the implemented feature. The language was expressive enough to be used to make a LISP interpreter.
I have the hand compiled version together with the source in the first release tag and the code is quite small. The last version is 12 times bigger in size and the code and allows for more compact code so hand compiling the current version would be hard to get right.
Edmund Grimley Evans did something similar with his HEX language
One of the interesting things about doing this yourself is that you understand why some things are as they are. My code was product if small incremental adjustments an it looks more like it has evolved rather than been designed from scratch. I keep that in mind when reading code today which I think looks a little off.
Usually with a general-purpose programming language suitable for systems development, e.g. C, Haskell, ML, Lisp, etc., but the list of options is long. Also, usually with some domain-specific languages for language implementation, i.e. parser and lexical analyzer generators, intermediate languages like LLVM, etc. And probably some shell scripts, testing frameworks, and a build configuration system, e.g. autoconf.
Most compiler were wriiten C or a c like program if not c then assembly lang is the way to go However when writing a new lang from scratch and you do not have a macro lib or source code from a prototype language you have to define your own functions Now in What Language? You can just write a Form "of source code called psedocode to the machine it looks like a bnf grammar from the object oriented structured lang spec like Fortran basic algo lisp. So image writing a cross code resembling any of these language syntax That's psedo code
What are programming languages in general?
programming languages are a just a way to talk to computers. roughly speaking at first because computers could only understand zeros and ones (due to the fact that computers are made of transistors as switches which could only take two states, we call these two states 0 and 1) and working with 0,1 was hard for us as humans so computer scientists decided to do a one-to-one mapping from every instruction in binary(0,1) to a more human readable form which they called it assembly language.
for example if we had an instruction like:
11001101
in assembly it would be called:
LOAD_A 15
which means that load the content of register a into memory location 15. as i said it was just a convention like choosing 0 and 1 for two states of the transistors or anything else in the computer.in this way having a program with 50 instructions , remembering the assembly language would be easier . so the user would write the assembly code and some program (assembler in this case) would translate the codes to binary instructions or machine language as they call it.
but then with the computers getting improved every day there was room for more complicated programs with more instructions, say 10000.
in this case a one-to-one mapping like assembly wouldn't work, so other high level programming languages were created. they said for example if for a relation with I/O devices for printing something on the screen created by the user takes about 80 instructions , let us do something in here and we could package all this code into one library and call it for example printf and also create another program which could translate this printf in here to the related assembly code and from there the assembly would do the rest. so they call it compiler.
so now every user who wants to just print something on the screen he wouldn't have to write all the instructions in binary or assembly he just types printf("something") and all the programs like the compiler and assembler would do the rest. now later other longer codes would be packaged in the same way to just facilitate the work of other people as you see that you could just simplify a thousands line of code into one code in python and pack it for the use of other people.
so let's say that you have packed a lot of different codes in python and created a module(libray, package or anything that you want to call it) and you call that module mgh(just my name). now let's say we have created this mgh somehow that any one who says:
import mgh
mgh.connect(ip,port.data)...
could easily connect to a remote server with the ip and port number specified and send the data afterwards(or something like that). now people could do all of it using one single line, but what that happens is that a lot of codes are getting executed which have been retrieved from the mgh file. and packaging it has not been for speeding up the process of execution but rather facilitating other programmers works. so in here if someone wants to use your code first he should import the file and then the python interpreter would recognize all the code in it and so it could interpret the code.
now if you want to create a programming language and you want to execute it , first it needs a translation, for example let's say that you create a program which could understand the syntax and convert it to c , in this case after it has been translated to c , the rest would be taken care of , by the c compiler , then assembler , linker, ... .
even though you would have to pay the price of being slower since it has to be converted to c first.
now one other thing that you could do is to create a program which could translate all the code to the equivalent assembly language just like what happens with c but in this case the program could do it directly and from there the rest would be done by the linker. we know that this program is called compiler.
so what i am talking about is that, the only code that the system understands is 0,1 , so somehow you should convert you syntax to that, now in our operating systems a lot of different programs like assembler, linker and ... have been created to tell you that if you could convert your code to assembly they could take care of the rest or as i said you could even use other programming languages compilers by converting your code to that language.
Even further binary ,or assembly operations must be translated into functions, thats the assemblers/compilers job, then into object,from data and functions, if you don't have a source file to see" how these objects functionality should be represented in your language implementation ,Then you have to recognize "see" implement, or define your own functions ,procedures, and data structures, Which requires a lot of knowledge, you need to ask yourself what is a function.Your mind then becomes the language simulation.This Separate a Master programmer from the rest.
I too had this question few months back. And I read few articles and watched some videos which helped me to start writing my own language called soft. Its not complete yet but I learned a lot of stuff from this journey.
Basic things you should know is how compiler works when it has to execute a code snippet. Compiler has a lot of phases like lexical analysis, semantic analyzer, AST(Abstract Syntax Tree) etc.
What I did in my new language can be found here - http://www.singhajit.com/writing-a-new-programming-language/
If you are writing a language for first time then all the best and you have a long way to go.