> Will Red get direct access to Android's (and IOS later) camera, location, gyroscope, etc features?
> Absolutely, our GUI engine already features a camera widget (in our Windows backend). The work on Android backend in 0.6.x version will bring wrappers to all the common hardware features.
So yeah, I guess the plan would be to support all mobile features.
Right now, it only compiles to 32 bit binaries (which can run on both 32 and 64 bit OS).
64 bit support will come after the compiler is bootstrapped.
> and cross compiles
Yup, easy cross compilation. You do not need different cross compilers for different platforms a la llvm and gcc, a single 1 mb binary can produce binaries for all supported platforms.
I looked over the code to guage how big this 32-bit problem is. It's going to be a lot of work. 32-bit is hardcoded everywhere. Compiler, linker, libc calls.
So, on one hand, there's massive cross-platform support. On the other hand, those platforms are all obsolete, or about to be. Even the mobile and embedded ones have all gone 64-bit.
Maybe backwards compatibility will be maintained for a few years. But it ruins the embed-red-in-C story already.
The current compiler was written with the aim of quick development till 1.0 is reached (because in the initial development phase, there are obviously many other important things to focus on). So, yeah the toolchain has some issues, eg. there are very few (if any) optimizations. Also, only 32 bit is supported.
There are AFAIK no plans to add 64 bit support before bootstrapping phase because the current toolchain architecture isn't that great and will be heavily improved during 1.x cycle.
64 bit processors (and their OS platforms) will retain backwards compatibility to 32 bit apps for the forseeable future. There are too many situations where 32 bit apps are better for that not to be the case (smaller binary size and better cache performance).
For mobile and desktop, sure 32 bit is fading, but embedded 32 bit is so far from obsolete. I don't know how you can even claim that when even 8 bit platforms still have a huge market share.
ARM cortex-M (32 bit) has only recently been able to chip away at 8 bit platforms and gain major use
Yes, but the embedded platforms that are interesting for high-level scripting are mostly phones. Worse than desktops, they won't bother with 32-bit compatibility layers.
Using the other meaning of embedded (I embedded a Lua script in my C application), compatibility libraries don't help. It simply won't link.
> No timeframe until we find someone to work on it. Though, we should be presenting Red at the GNOME global conf in China on October, so I hope we can find someone motivated and skilled enough there to work on it.
Familiarity with hardware would be a good starting point - the author explained how he can made use the three tables used by the PPU to pick out objects and textures. There is a lot of information about the NES online which would be useful references.
Then a good set of debugging tools, which is possible for NES games as there are many different emulators written in all sorts of languages which would make for a good learning resource.
To get more involved, investate open-source emulation projects - building them yourself. Then get more involved - try to fix an open issue - which will help you get familiar with the project. Read up on reverse engineering and ask questions!
With just a bit of Google-foo and some persistence, you can have working emulators of the 8-bit systems by the end of the summer if you put your mind to it.
While I've not used it, this website seems pretty solid: http://www.codeslinger.co.uk/pages/projects/gameboy.html (You may want to make other choices; personally I'd go straight to the gameboy because it was a real console and skip the Chip8, but your mileage may vary.)
It's an excellent project. Great on a resume, too; if I saw a fresh grad show me their Gameboy emulator they wrote from scratch my head would be turning. I personally would expect you followed a site like that and know it's perhaps a deceptively simple project compared to what most would expect, but I'd still be quite impressed, and you have a pretty decent chance of hitting an interviewer who quite overestimates its difficulty too :)
And the power differential between the Gameboy and a modern computer is so vast you can even use Javascript in a browser if you like. Use whatever language you like. C/C++ is still not necessarily a bad choice or anything, but don't fall into the trap of thinking you need their performance in this case. You've got gobs of power, you can afford any current language you like or would like to learn.
Having started, but not completely finished (time constraints) a GameBoy emulator, I would actually say it's deceptively difficult.
The "easiest" part is emulating the basic Z80 CPU operations, but even that implies the individual (truly) understands how a CPU works: registers, op codes, timing, MSB/LSB, addressing, program counters/jump instructions etc.
Now, you have to add on how cartridges work: the various memory bank controller types, bank switching, save states, etc.
Then, you have code to display video, emulate audio, and controls.
Putting all that code together, in a nice OO organization, is top 5% coder level stuff. Anyone that did that would almost certainly get a 'hire' vote from me. It's probably 10-20X the complexity of most demo projects I've seen.
> Now, you have to add on how cartridges work: the various memory bank controller types, bank switching, save states, etc.
There must be some subset of games that don't have a mapper. It's good to know when you start that it's something you might want to do later, but you can get tetris going with out it.
And the link I pointed at also just punts on sound, for another example of a corner that you can cut.
I actually whacked a paragraph about how said emulator will not be the fastest emulator and it won't be a perfect emulator, but you'll certainly have some running games, and for that all the things I said will still be true. Making an emulator that exactly matches the console is hard, but making an emulator that more-or-less runs a game isn't that hard.
Sorry, i haven't looked at the website yet, so what I may be asking might be pretty vague and far from reality.
Is the bots api available over http (get/post/whatever)? If no, will it be possible to have one? It will allow a whole lot of programming languages to be used. Just authenticate your bot using some token generated by the website, and then run the bot on your own pc or some server. It will allow us to play with the website with our favourite programming language even if you guys don't officialy support it.
For eg. currently my favourite programming language is Red. It is still in alpha, and is relatively unknown to people, so I don't think that there are any chances to get it supported on the website. But api over http would allow me to play with it as well.
All communication is done through standard IO between your bot and the server. Opening sockets in your bot is currently not allowed, as this could lead to unfair advantages for players with faster computers.
We're always looking to add more programming languages, so if you come up with a starterbot in Red, we will consider adding support for the language.
Probably that could be done, but for each round you get X milliseconds. If you would run your bot on your pc via api, you could have an unfair advantage, because you could run it in a 64 core cpu (for example) and you have more "time" to do calculations. I really like their idea. It's easy and fair. Also, they do support a lot of programming languages
1) Red - Small in size; Readable, compact and concise code. Its a powerful All-in-One Package with lots of great features as well as easy for newcomers. It can be used for low level as well as high level programming.
2) Rust - Its powerful concepts of borrowing and ownership, and its tight security features are just great. But its kinda verbose.
3) Nim - Clean, readable code. Fast compile times as well as compiled code. Lots of good ideas in it. Different gc's for different use cases are great.
I am a big fan of Nim. It's one of the few languages that gets me excited lately as it feels like you can do pretty much anything that you could do in C++ but in simplified code and shorter dev times.
The current 0.6.0 release contains only Windows GUI. Linux and OSX support are a work in progress. Lots of stuff implemented, lots still missing. You can download qtxie's branch with the WIP code here -
https://github.com/qtxie/red/tree/MacOSX-GUI?files=1
Read the Readme file for instructions on how to compile red code using sources. For any questions -
https://gitter.im/red/red
Elixir is great. Simple and powerful. I just wish the size of the Erlang distribution was small so that I could use Elixir for desktop apps as well, as currently it would require a 100 mb VM for people to run even a 10 line script.
I have not used Elixir for anything big. I would really love to try elixir someday for bigger apps. Is there a Elixir-to-JS compiler somewhere? Nodejs is much smaller in size than BEAM. So distributing Elixir apps would be easier.
Yes, most of the examples look very limited compared to Lisp but there is Rebol / Red (http://www.red-lang.org/) which is atleast as powerful as Lisp in terms of homoiconicity (as well as in other things), if not more. Red/Rebol don't use sexps, don't look like this (((())))), are highly dynamic and homoiconic.
> RE the learning curve: Do you think the APL family can exist without the terse syntax?
So yes, I think that the APL family could exist without the terse syntax, but well hey, everything has its tradeoffs and all this is subjective - everyone has his own thinking - there might be someone in this world who in love with the APL syntax :D
I do love APL's syntax. It's part of the appeal for me.
That said, Red looks like a godsend. I was looking for something I can use without much setup and learning costs, that is small, elegant, efficient, fast, gets the job done, and is long-term maintainable. Red seems to fit the bill. I'm still evaluating it and it still looks good.
Yes it was true. But not in this sense. The current IO support is minimal and temporary (IO is scheduled for 0.7.0). Also, the gui support is currently windows only (more OSes to come soon). So dockimbel and others meant that we should avoid over-exposure else it would lead to negative attention as there is a large bunch of devs on Linux and OSX platforms as well. The point is that lots of planned features are missing right now.
Although my personal opinion is that it is a good time to jump into Red because it is expected that Red 1.0 release date near about 1 year. So, learning Red, and finding bugs in it is gonna help you and both the project to advance further quickly and get ready for prime time action.
> Will Red get direct access to Android's (and IOS later) camera, location, gyroscope, etc features?
> Absolutely, our GUI engine already features a camera widget (in our Windows backend). The work on Android backend in 0.6.x version will bring wrappers to all the common hardware features.
So yeah, I guess the plan would be to support all mobile features.