Related
I want to bind a different programming language to the Godot game engine. Is there an instructional document or video on this topic? For example, how was this project done: godot-rust. If I can learn the basics, I can succeed in working in a different language. Thanks.
In this answer I show you the different approaches to add language support in Godot 3.x (the situation will be somewhat different with Godot 4.0 and GDExtension - which replaces GDNative and hopefully means less custom builds), and I mention some languages that are supported by each of these approaches. However, this is not an exhaustive list of the languages.
First of all, Godot has official build-in support for GDScript and Godot's VisualScript (and Godot's shading language and its visual counterpart if those counts for you).
There are a few ways to use C++:
You can use it to create GDNative scripts (which are basically a wrapper around native calls that allow you to use them as scripts in Godot).
Or you can create modules (which are static libraries you can add in a custom Godot build).
And since Godot source is in C++, you don't have to restrict yourself to making modules if you are making custom builds.
In web builds Godot can interface with JavaScript via the JavaScript class. However, this approach does not allow you to add JavaScript scripts to Nodes, and so on.
Then there are languages that can only be added in custom builds of Godot, which is currently the official support for C#.
There are other non-official custom builds that offer language binding for languages such as Lua, Kotlin, TypeScript and JavaScript (this time allowing you to make scripts).
If you need to add a runtime, you would probably do this.
Some language take advantage of the fact that Godot's has official Mono support in order to support C#. This way you can, for example, use F# and Clojure.
They start by adding a C# project and then modify it so it uses another language. This is viable if your language already compiles to .NET.
Some other languages can be added as plugins that implement the PluginScript class via GDNative. This is the case of Python and Lua (again) which you can get from the asset library.
This is the most user friendly way to add language support to Godot, but it is limited to what you can do with PluginScript.
Addendum: Gil Barbosa Reis, author of the aforementioned Lua bindings, has an article series about its implementation stuffed away in the repository (in English and Portugueses): godot-lua-pluginscript/extras/articles/. It is probably the most comprehensive tutorial to date.
Other languages are added by means of taking advantage of GDNative (They basically mimic what you would do with C++). This is the case of Nim, Rust, D, Haskell, Go, Swift…
So that's how godot-rust works: make native libraries using rust and the godot-rust create and add them as if they were made in C++. For any language for which there are the means to make native libraries already, this is a good option.
Finally there is another way to add support for a language: a transpiler from that language to GDScript, which can be automated with an addon that might also be written in GDScript. This is the case of Lisp.
This last approach is mostly used for domain specific languages.
The official docs here provide your answer:
Godot officially supports GDScript, C/C++, C#.
Some 3rd party languages that can be used are: Rust, D, Python, Nim, and Go.
I'm part of team working on SDK that is exposed with several programming languages - currently ObjC, C#, ActionScript, Java (Android) and later we'll have even more languages.
We want to have documentation which is made up of two parts:
Human readable documentation
API Reference
There are links between the two parts: from human readable docs we have links to specific classes or methods and from the API reference we may link to a document that explain the context in which the class or method is used.
We are currently use a combination of sphinx for human readable documentation and language specific tools for API such as doxygen or asdoc
I saw in LeapMotion they were able to generate a complete documentation for multiple programming-language (not human language) with cross links between programming-languages.
The Question
Does someone know how to accomplish such documentation system in a way we'll not have to duplicate each change in human readable docs to every language and have cross links between the languages?
I put together the Leap Motion documentation. I use Sphinx to create the package of docs and Breathe, a Sphinx plug-in, to basically import XML files generated by Doxygen into the Sphinx project for the doxygenated API references (C++, C#, Java, and Objective-C). For links from the so-called "human-readable" pages to the API references, I generate RST substitutions from the .tag files which Doxygen will generate for you. Links from the API reference to the "human-readable" pages are normal, relative hyperlinks (which I should add more of).
I use the conditional content features of Sphinx to generate a separate set of docs (both "human-readable" and API) for each programming language. Thus these articles can be customized for each programming language where needed and have the correct code examples for the current language. Because each doc set has the same structure, it isn't hard to switch from one language to another.
I did add some custom JavaScript to the page templates to help switch between languages.
tl;dr: Sphinx, Breathe, Doxygen and a small amount of custom JavaScript.
If you would like to discuss this further, you can post a question to our (Leap Motion) developer forum. I'll see it (Stackoverflow isn't the proper place for an ongoing discussion).
Hi Ido Ran,
Tools which you've specified are best in industry for documentation purpose,I am afraid there is no such tool yet which could provide both human and as well as API reference.Out of all my personal best is doxygen which is slighly of multi-use (human and API)..Hope this helps.
We are in mid of a project where we have used an extended Dojo 1.1.1 to meet the customer requirement and add richness.
But there are quite some bugs and performance problems with this version of Dojo and
we are looking ahead to migrate the Dojo version to overcome both the issues, but the migration cycle seems to be quite painful and may not be yield expected result.
The concern we have is with the various extension which we have created with the version of Dojo for components that were provided in 1.1.1 and the impact on them after migration.But, the advantage we see are equally important.
As per Dojo , they have kept some level of compatibility with version 1.1.1 but i have not seen any discussion around this anywhere.
Has any body else previously done
migrated between Dojo version?
Will the components like Grid will
work as expected or will i need to
carry out a refactoring exercise?
Do we have any commercial support
available as the forum seems to
deprecated?
Any help or suggestions are welcome
Dojo has had a policy of freezing and supporting public APIs since 1.0. Migrations prior to 1.0 were extremely painful. Now, it should be much better, provided you use only public APIs. Code written for stable JS APIs in Dojo or Dijit in 1.1 should largely still work. Exceptions are noted in the release notes, which you should explore (good luck finding them... unfortunately the site is a bit of a mess)
If you wrote any custom widgets, you're probably in for some extra work. dojox.grid was not particularly stable at that point, and it has also seen a major rewrite since then (there is an old 'compat' layer you may wish to use)
Regarding for forum, like the note says, you can either use the active dojo-interest mailing list or post questions here at SO. There are some firms which offer commercial support, but that's outside of the scope of Dojo as an open source project. (try googling 'Dojo commercial support' or asking on dojo-interest)
I have done 5 dojo migrations now (from 0.2 -> 1.4) over the last few years. Although the API does not change, you will often have coded in workarounds that no longer work after upgrading. Things I have noticed:
quality in 1.4 is VERY good and worth
upgrading to (even from 1.3)
although
the API does not change, little
things that are not public often
change slightly (diji.Tree
itemNodeMap -> itemNodesMap in 1.4)
build options are usually added each
release but not always publicised -
strage really as they are always
useful improvement
since you are 1.1.1, you should change all your set attribute calls to 'attr' - this could take a while to do.
As for commercial support, you could try Sitepen
As already discussed in "Lua as a general-purpose scripting language?" Lua currently probably isn't the best scripting language for the desktop environment.
But what do you think about the future? Will Lua get so popular that there will soon be enough libraries to be able to use it like Python, Ruby or something similar?
Or will it simply stay in it's WoW niche and that's it?
I think it has a great future, a lot of projects are starting to adopt it for it's simplicity and usefulness.
Example: Awesome WM (Window Manager)
The project recently released version 3, incorporating a new configuration system completely written in Lua. Allowing you to literally write your configuration file as a program, loops, booleans, data structures.
Personally I love the syntax and the flexibility of such a system, I think it has great potential.
I wouldn't be surprised if it became more popular in the future.
Brian G
I suppose the answer starts with 'It depends how you want to use it...'.
If you're writing the common business app (fetch the data from the database, display the data in a web page or window, save the data to the database), Lua already has what you need.
The Kepler Project contains goodies for web development. Check out their modules to see some of the available libraries - there's network, MVC, DBMS access, XML, zip, WSAPI, docs...
As an example web app, check out Sputnik.
For desktop UI, there's wxLua - Lua hooks for wxWidgets.
ORM is conspicuously missing but that didn't stop people from developing in other languages before ORM was available.
If you're looking for specialized libraries - scientific, multimedia , security - don't count Lua out before you check LuaForge.
When it comes down to it, there's nothing in Lua's design that prevents general purpose use. It just happens to be small, fast, and easy to embed... so people do.
Uh? I would say instead WoW is a niche in the Lua ecosystem... The world of Lua doesn't revolve around WoW, there are lot of applications, some big like Adobe Lightroom (to take a non game), using Lua.
Lua is initially a scripting language, in the initial sense, ie. made to be embedded in an application to script it. But it is also designed as an extensible language, so we will see progressively more and more bindings of various libraries for various purposes.
But you will never get an official big distribution with batteries included, like Python or Perl, because it is just not the philosophy of the authors.
Which doesn't prevent other people to make distributions including lot of features out of the box (for Windows, particularly, where it is difficult to build the softwares).
Lot of people already use it for general system-level scripting, desktop applications, and such anyway.
There are more and more libraries for Lua.
If you are a Windows user, have look at Lua for Windows. It comes with "batteries included" (wxLua, LuaCURL, LuaUnit, getopt, LuaXML, LPeg...).
Very usefull!
It's 2017, 9 years after this question was first asked, and lua is now being heavily used in the field of machine learning due to the Torch library.
I really like it as an embedded language. It's small, very easy to use and embed and mostly does what I need right out of the box. It's also similar enough to most languages that it has never really been an issue for me. I also like how easy it is to redefine and add base functions and keywords to the language to suit whatever needs my application has.
I have used it in the WoW area but I've also found it useful as a generic scripting language for a number of different applications I've worked on, including as a type of database trigger. I like Ruby and Python and other more full-featured scripting languages but they're not nearly as convenient for embedding in small applications to give users more options for customizing their environments.
being comfortable as a shell language has nothing to do with being a great general purpose language.
i, for one, don't use it embedded in other applications; i write my applications in Lua, and anything 'extra' is a special-purpose library, either in Lua or in C.
Also, being 'popular' isn't so important. in the Lua-users list periodically someone appears that says "Lua won't be popular unless it does X!", and the usual answer is either: "great!, write it!", or "already discussed and rejected".
I think the great feature of Lua is, that it is very easily extensible. It is very easy to add the Lua interpreter to a program of your own (e.g. one written in C, C++ or Obj-C) and with just a few lines of code, you can give Lua access to any system resource you can think of. E.g. Lua offers no function to do xxx. Write one and make it available to Lua. But it's also possible the other way round. Write your own Lua extension in a language of your choice (one that is compilable), compile it into a native library, load the library within Lua and you can use the function.
That said, Lua might not be the best choice as a standalone crossplatform language. But Lua is a great language to add scripting support to your application in a crossplatform manner (if your app is crossplatform, the better!). I think Lua will have a future and I think you can expect that this language will constantly gain popularity in the long run.
Warhammer Online, and World of Warcraft use it for their addon language I believe.
I think it's hot! I'm just no good at it!
Well, greetings from 2022.
It is already a general purpose language. Today you can even serve pages using OpenResty, extend games, read databases or create scripts as shellscript replacements.
There are a plenty of libraries "modules" for Lua, many ways to achieve what you are wanting and Lua 5.4 is even faster.
The "extendable and extensive" nature of Lua, accostumed people to think it should only be used as plugin or extension. In Linux, by example, you can shebang a file with lua-any, make it executable and run like any system script. Or you can make a folder app like Python or virtualenv using Lupe. Lua 5.3 also gained impressive performance improvements.
Also there are many good tools like IUP to create native windows in Lua for Mac, BSD, Linux and Windows and side environments like Terra that lets you use Lua with its counterpart Terra and write compiled programs. Lua now, is more than a extension language, it has its own universe.
I've been making my way through The Little Schemer and I was wondering what environment, IDE or interpreter would be best to use in order to test any of the Scheme code I jot down for myself.
Racket (formerly Dr Scheme) has a nice editor, several different Scheme dialects, an attempt at visual debugging, lots of libraries, and can run on most platforms. It even has some modes specifically geared around learning the language.
I would highly recommend both Chicken and Gauche for scheme.
PLT Scheme (DrScheme) is one of the best IDEs out there, especially for Scheme. The package you get when downloading it contains all you need for developing Scheme code - libraries, documentation, examples, and so on. Highly recommended.
If you just want to test your scheme code, I would recommend PLT Scheme. It offers a very complete environment, with debugger, help, etc., and works on most platforms.
But if you also want to get an idea of how the interpreter behind the scenes works, and have Visual Studio, I would recommend Tachy. It is a very lightweight scheme interpreter written in c#. It allows you to debug just your scheme code, or also step through the c# interpreter behind the scenes to see what is going on.
Just for the record I have to mention IronScheme.
IronScheme will aim to be a R6RS conforming Scheme implementation based on the Microsoft DLR.
Version 1.0 Beta 1 was just released. I think this should be good implementation for someone that is already using .NET framework.
EDIT
Current version is 1.0 RC 1 from Oct 23 2009
Google for the book's authors (Daniel Friedman and Matthias Felleisen). See whether either of them is involved with a popular, free, existing Scheme implementation.
It doesn't matter, as long as you subscribe to the mailing list(wiki/irc/online-community-site) for the associated community. It's probably worth taking a look at the list description and archives to be sure you are in the right one.
Most of these are friendly and welcoming to newcomers, so don't be afraid to ask.
It's also worth searching the archives of their mailing list(or FAQ or whatever they use) when you have a question - just in case it is a frequent question.
Good Luck!
Guile running under Geiser within Emacs provides a nice, lightweight implementation for doing the exercises. Racket will also run under Geiser and Emacs, though I personally prefer Guile and Chez Scheme a bit more.
Obviously installation of each will depend on your OS. I would recommend using Emacs version 24 and later since this allows you to use Melpa or Marmalade to install Geiser and other Emacs extensions.
The current version of Geiser also works quite nicely with Chicken Scheme, Chez Scheme, MIT Scheme and Chibi Scheme.
LispMe works on a Palm Pilot, take it anywhere, and scheme on the go. GREAT way to learn scheme.
I've used PLT as mentioned in some of the other posts and it works quite nicely. One that I have read about but have not used is Allegro Common LISP Express. I read a stellar review about their database app called Allegro Cache and found that they are heavy into LISP. Like I said, I don't know if it's any good, but it might be worth a try.
I am currently working through the Little Schemer as well and use Emacs as my environment, along Quack, which adds additional support and utilities for scheme-mode within Emacs.
If you are planning on experimenting with other Lisps (e.g. Common Lisp), Emacs has excellent support for those dialects as well (Emacs itself can be customized with its own dialect of Lisp, appropriately named Emacs Lisp).
As far as Scheme implementations go, I am currently using Petit Chez Scheme, which is an interpreted, freely distributable version of Chez Scheme (which uses a compiler and costs money to obtain a license).