This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
1lann's profile picture

Anyone Interested In A Javascript (Web/html5) Version Of A Cc Emulator?

Started by 1lann, 17 August 2013 - 09:19 AM
1lann #1
Posted 17 August 2013 - 11:19 AM
So… Me and gravs (mostly gravs) wanted to make a CC emu, but we wanted it to be multi-platform. Currently gravs has made a CC emu in C++,
Spoiler
but we were thinking of something more. So we were thinking of either practically re-writing CC in Javascript, so you can add like a "Test out this program online" button to program submissions so you can test out people's programs instantly, (it would most likely be riddled with bugs) or to just continue writing in C++ or some other native code language (Second option is Python). But writing in Javascript will poses a problem that Gravs just doesn't like, which is that you won't be able to edit code in sublime text, then run it straight off in the emu, and instead you would need to copy and paste the code, or use an in-browser editor (ace editor). So yeah, we want your opinion on whether you would use this or not, or would you rather just have a native (lightweight) cc emu.

tl;dr: We were planning to make a CC emu. Javascript/Online (Requires copying/pasting of code or online editing), or a lightweight native app?

Well since there is no poll option for the general section for some reason, post your opinions/suggestions below!
reububble #2
Posted 17 August 2013 - 11:37 AM
I like this idea! There's been a few times that I've not been bothered to open up CC simply to find out if my code runs.
It could be on this site if everybody is nice enough, then imagine how well the ask a pro and tutorial sections would work!
DaGamer12345 #3
Posted 17 August 2013 - 01:07 PM
Do you know what this means? We will finally have an Android/iOS CC emulator for the out-and-about (or just mobile) coders. People have been waiting for something like that.
M4sh3dP0t4t03 #4
Posted 17 August 2013 - 01:24 PM
I would like it in JavaScript, cause you could also use it on iOS/Android/Windows Phone devices.
nutcase84 #5
Posted 17 August 2013 - 01:59 PM
This is what I've been looking for all this time. +1!
GravityScore #6
Posted 17 August 2013 - 02:05 PM
Mobile device support would more a lot of extra work, but entirely possible (maybe just a single computer for a phone, everything else would be too big - tablet support would be really useful).

So far it looks like Javascript is the way to go. Is anyone else interested in a more lightweight native desktop application though? I for one would use it (as I currently use my own, which is no where near the stage of releasing - it's currently very OS specific and requires all its dependencies to be manually installed and in very specific places, plus I'd need to get permission from dan to redistribute the computercraft.jar file with it). CCDesk is quite an engineering feat, but quitting it causes a kernel panic (yes, it shuts down and shows this screen) on my retina display mac, so I can't use it (I've not bothered to report this because I seem to be the only one with the problem, and didn't think it would be worth Lochie's time just for one potential user. My mac seems to hate all things Java, apart from Minecraft).
Engineer #7
Posted 17 August 2013 - 06:37 PM
I didnt really read through the replies on this post, but as you know you need to design a website anyway. You could possibly make it like that, that you can bind programs to an account. It really helps but can be iffy. First of all because we would need to refresh the page if we uploaded something, because I dont think you can save it in a database and get it in the runtime withoit refreshing.

However, I want to note that this comes from a unexperienced javascript coder, I have no idea if you can fetch files from a database with JS.
GravityScore #8
Posted 17 August 2013 - 10:30 PM
I didnt really read through the replies on this post, but as you know you need to design a website anyway. You could possibly make it like that, that you can bind programs to an account. It really helps but can be iffy. First of all because we would need to refresh the page if we uploaded something, because I dont think you can save it in a database and get it in the runtime withoit refreshing.

However, I want to note that this comes from a unexperienced javascript coder, I have no idea if you can fetch files from a database with JS.

Writing the fs API would be annoying. There are a couple of options: store the files in the database, and just upload the changed files to a database every 30 seconds or so asynchronously, which would be a lot of annoying work to protect against spammers; store the files in HTML5 localStorage, which has a max size of 5MB, so you could only open 2 - 3 computers; store the files in memory, and have them not persist across sessions, or have the user download a single data file, which they could then supply to the website upon reload or something; upload the files to the database at the end of the session, or have a manual save function that saves the session to a database.

Also as far as editing files, we would probably include an ace editor in browser so you can easily modify and copy/paste into it, and allow you to save files to any of the computers.
Sorroko #9
Posted 17 August 2013 - 11:41 PM
I've thought about this before and it seems quite appealing however… The biggest issue is that javascript is asynchronous however the lua vm is synchronous, this poses a problem, how do you make the vm wait for user input (coroutine.yield)?

Well you can't, the only way to get input currently is via a prompt() (which is blocking), this is extremely inconvenient. I believe repl.it has a hacky solution which might make it possible (HTML5 web workers I think). lua.vm.js also looks quite promising.

I'll be interested to see how you get on. ;)/>
ElvishJerricco #10
Posted 18 August 2013 - 12:22 AM
I've thought about this before and it seems quite appealing however… The biggest issue is that javascript is asynchronous however the lua vm is synchronous, this poses a problem, how do you make the vm wait for user input (coroutine.yield)?

Well you can't, the only way to get input currently is via a prompt() (which is blocking), this is extremely inconvenient. I believe repl.it has a hacky solution which might make it possible (HTML5 web workers I think). lua.vm.js also looks quite promising.

I'll be interested to see how you get on. ;)/>

It's easier than you'd think if you use WebWorkers. WebWorkers basically let you run a JavaScript file in another thread that has zero access to UI stuff. Put the VM in a web worker and send messages between the main thread and the worker whenever the display updates or events happen, and you've got an emulator. The bigger problem is getting the Lua VM working in JavaScript. I know it's been done with emscripten and asm.js but most browsers don't support accelerating asm.js so it might be slow.



Personally, I'd be more interested in seeing an emulator written for a regular terminal. So I can open up the terminal on my mac, or cmd on my pc, and run a command. Whatever my working directory is acts as the root directory for the computer that begins to emulate using my terminal window as its screen.
Sorroko #11
Posted 18 August 2013 - 12:29 AM
-snip-

running the lua vm in a webworker (i.e. lua.vm.js) it will still however not pause for input from the main thread, currently in cc calling os.pullEvent calls coroutine.yield which pauses execution until java returns an event. Javascript is not capable of pausing execution because it is asynchronous. There might be something I'm missing here but from my experiments it hasn't gone well :D/>.
ElvishJerricco #12
Posted 18 August 2013 - 01:37 AM
running the lua vm in a webworker (i.e. lua.vm.js) it will still however not pause for input from the main thread, currently in cc calling os.pullEvent calls coroutine.yield which pauses execution until java returns an event. Javascript is not capable of pausing execution because it is asynchronous. There might be something I'm missing here but from my experiments it hasn't gone well :D/>.

WebWorkers don't run continuously. JavaScript is mostly event based actually. You never write any while (running) types of loops in javascript. Same goes for WebWorkers. You don't run loops. You create the worker, and in your worker's code, you define a function to be called when the main thread sends a message to the worker. Then, you can send a message back to the main thread. Of course to receive that message, you just set the onmessage value in the worker object to some function. It's asynchronous, yes. But still event based.
Sorroko #13
Posted 18 August 2013 - 02:02 AM
The lua vm in javascript ported via emscripten is blocking… and while executing lua code it will freeze your browser (assuming you dont use workers). And javascript is asynchronous, check on wiki if you dont believe me ;)/>/> event systems are used because it is asynchronous.
M4sh3dP0t4t03 #14
Posted 18 August 2013 - 02:51 AM
I don't know anything about JavaScript and other web development, but wouldn't it be possible for the fs API to store the data on the local computer via cookies?
GravityScore #15
Posted 18 August 2013 - 02:52 AM
I don't know anything about JavaScript and other web development, but wouldn't it be possible for the fs API to store the data on the local computer via cookies?

A cookie has a max size of 4KB, which is basically useless for storing files :P/>
ElvishJerricco #16
Posted 18 August 2013 - 02:56 AM
The lua vm in javascript ported via emscripten is blocking… and while executing lua code it will freeze your browser (assuming you dont use workers). And javascript is asynchronous, check on wiki if you dont believe me ;)/> event systems are used because it is asynchronous.

My last sentence was basically exactly what you said here =P Except the emscripten thing. And you're right. But I'm not sure the details on how emscripten calls code that would normally wait on user input. I'm sure there's a way to make it work.
AfterLifeLochie #17
Posted 18 August 2013 - 02:58 AM
I don't know anything about JavaScript and other web development, but wouldn't it be possible for the fs API to store the data on the local computer via cookies?
You can store a seriously limited and unreliably cleared quantity of data in the local-storage.

The biggest physical problem is the fact Javascript is purely asynchronous and has no concepts of threads or workers, nor any reasonable stacks, so this project requires inventing things which even I cannot think of a practical, sane solution to - the only really sure-fire way to ensure events occurs is to act entirely reactively, which from a technical standpoint is going to be extremely chaotic and possibly lag-inducing for the user, and events are still not guaranteed to fire. I can also think of plenty of ways the Lua VM would cause the browser to panic uncontrollably. Long running Javascript can, and will, cause modern browsers to fling their arms in the air or even totally crash in the event you're still an Internet Exploder user.
ElvishJerricco #18
Posted 18 August 2013 - 03:09 AM
The biggest physical problem is the fact Javascript is purely asynchronous and has no concepts of threads or workers, nor any reasonable stacks, so this project requires inventing things which even I cannot think of a practical, sane solution to - the only really sure-fire way to ensure events occurs is to act entirely reactively, which from a technical standpoint is going to be extremely chaotic and possibly lag-inducing for the user, and events are still not guaranteed to fire. I can also think of plenty of ways the Lua VM would cause the browser to panic uncontrollably. Long running Javascript can, and will, cause modern browsers to fling their arms in the air or even totally crash in the event you're still an Internet Exploder user.

Again, I point to WebWorkers. And still, I'm sure there's a way to make a non-blocking VM. No concrete evidence on this because that would take much more research than I'm willing to put into a project I'm not building, but the emscripten VM is capable of using setTimeout and other call-back based JS functions.
Mads #19
Posted 18 August 2013 - 03:11 AM
Mobile device support would more a lot of extra work, but entirely possible (maybe just a single computer for a phone, everything else would be too big - tablet support would be really useful).

So far it looks like Javascript is the way to go. Is anyone else interested in a more lightweight native desktop application though? I for one would use it (as I currently use my own, which is no where near the stage of releasing - it's currently very OS specific and requires all its dependencies to be manually installed and in very specific places, plus I'd need to get permission from dan to redistribute the computercraft.jar file with it). CCDesk is quite an engineering feat, but quitting it causes a kernel panic (yes, it shuts down and shows this screen) on my retina display mac, so I can't use it (I've not bothered to report this because I seem to be the only one with the problem, and didn't think it would be worth Lochie's time just for one potential user. My mac seems to hate all things Java, apart from Minecraft).

You could easily create a native Android app in C, and compile the Lua library(or port it, idk?) for ARM.
ElvishJerricco #20
Posted 18 August 2013 - 03:21 AM
CCDesk is quite an engineering feat, but quitting it causes a kernel panic (yes, it shuts down and shows this screen) on my retina display mac, so I can't use it (I've not bothered to report this because I seem to be the only one with the problem, and didn't think it would be worth Lochie's time just for one potential user. My mac seems to hate all things Java, apart from Minecraft).

I have the same problems. CCDesk is not mac compatible. Maybe it's just 10.8 and up or something but I've never been able to get it to work properly.
AfterLifeLochie #21
Posted 18 August 2013 - 03:30 AM
Again, I point to WebWorkers. And still, I'm sure there's a way to make a non-blocking VM. No concrete evidence on this because that would take much more research than I'm willing to put into a project I'm not building, but the emscripten VM is capable of using setTimeout and other call-back based JS functions.
WebWorkers are a solution, but they're not exactly supported widely (browsers which support HTML5, IE10+, none on Android afaik). While it's a solution, it's probably equally as tricky as others.

CCDesk is quite an engineering feat, but quitting it causes a kernel panic (yes, it shuts down and shows this screen) on my retina display mac, so I can't use it (I've not bothered to report this because I seem to be the only one with the problem, and didn't think it would be worth Lochie's time just for one potential user. My mac seems to hate all things Java, apart from Minecraft).

I have the same problems. CCDesk is not mac compatible. Maybe it's just 10.8 and up or something but I've never been able to get it to work properly.
The kernel-panic is a driver-related issue with LWJGL - and it's totally out of my control. I've been given a few dumps and I'm waiting for another semi-stable update to the LWJGL libraries to (hopefully) fix this totally. Mac support was okay for a while, and things just slid downhill due to a series of other UI bugs. They're being beaten out next weekend.
TheOddByte #22
Posted 18 August 2013 - 06:34 AM
+1 I like the idea very much since you could use you iOS/Android device to test a program etc.
oeed #23
Posted 18 August 2013 - 08:00 AM
Yes! Ever since I installed Mavericks (the beta OS X, which probably brought a new version of Java with it) I've been unable to use either CCDesk or CCEmu.

Is it possible to send me the C++ version? I'm running OS X, so if it's an app it shouldn't be hard, unless there are legal or similar issues of course. I'm interested in helping out either way, don't expect my offer to be taken, but it's on the table.
Sorroko #24
Posted 18 August 2013 - 09:36 AM
Writing the entire emulator in c and then porting to javascript with emscripten might be more viable. OpenTTD was ported to javascript in the same way: http://play-ttd.com
GravityScore #25
Posted 18 August 2013 - 11:39 AM
Yes! Ever since I installed Mavericks (the beta OS X, which probably brought a new version of Java with it) I've been unable to use either CCDesk or CCEmu.

Is it possible to send me the C++ version? I'm running OS X, so if it's an app it shouldn't be hard, unless there are legal or similar issues of course. I'm interested in helping out either way, don't expect my offer to be taken, but it's on the table.

I could send the C++ version to you easily :)/> but it needs to be distributed with a computercraft.jar file. I'm pretty sure I can distribute it privately to just one person, but it would be nice to have clarification for that. Or I can just say you're beta testing it for me :P/> It requires you to install a few dependencies currently, and its a bit buggy (top row can't receive mouse clicks, a bit flickery at times, no crash protection) but it has modems :D/> I'll PM you the details tomorrow when I'm not on my phone :P/>
Graypup #26
Posted 18 August 2013 - 02:44 PM
That idea is insane. You're running 1 programming language that isn't very fast on another not-very-fast programming language. Someone has done this, though I think they're crazy. https://github.com/kripken/lua.vm.js
M4sh3dP0t4t03 #27
Posted 18 August 2013 - 04:44 PM
That idea is insane. You're running 1 programming language that isn't very fast on another not-very-fast programming language. Someone has done this, though I think they're crazy. https://github.com/kripken/lua.vm.js
It isn't insane. There is even a gameboy emulator that is working perfectly with no lag written in HTML5 and JavaScript( https://github.com/grantgalitz/GameBoy-Online )
Sxw #28
Posted 18 August 2013 - 05:12 PM
Abstract it! http://haxe.org/
That would work if you want to have many platforms.
You could code the core emulator in haxe then a UI in whatever. ;P
GravityScore #29
Posted 18 August 2013 - 07:45 PM
Abstract it! http://haxe.org/
That would work if you want to have many platforms.
You could code the core emulator in haxe then a UI in whatever. ;P

I've done some games using NME and Haxe before. I don't think it's possible to run either java or Lua from it at all. Is this the case, or did I miss something when googling?
1lann #30
Posted 19 August 2013 - 06:12 AM
That idea is insane. You're running 1 programming language that isn't very fast on another not-very-fast programming language. Someone has done this, though I think they're crazy. https://github.com/kripken/lua.vm.js
Lua's pretty fast… And yes we are going to use a lua vm for this, specifically this one (because it uses lua 5.1): https://github.com/humbletim/ljs
Nevermind this one doesn't have 5.1 features… We'll be looking into doing something….

Although I'm aware running lua within javascript can become quite slow, but we'll see how it goes. I'll see if I can implement some functions and actually get it somewhat working. The main goal currently is to implement coroutines, since the one I'm using doesn't support coroutines.
Mitchfizz05 #31
Posted 19 August 2013 - 06:17 AM
This sounds like a brilliant idea!
1lann #32
Posted 20 August 2013 - 05:59 AM
Just a heads up, I'm quite busy, and not only that but I might not be capable of implementing all the features required, and figure everything out. It could take a longggg time and the project might be ditched (I'll try not to). Just a heads up.
GravityScore #33
Posted 20 August 2013 - 06:51 AM
Just a heads up, I'm quite busy, and not only that but I might not be capable of implementing all the features required, and figure everything out. It could take a longggg time and the project might be ditched (I'll try not to). Just a heads up.

On the up side, I'm most of the way through a nice implementation of a lightweight, cross-platformed emulator written in Python (but still using Java to run all the computercraft related stuff, making it easy to update :)/>). I'm fed up with C++ and its annoyingness (not because of the language itself, but because of my inexperience).
Zudo #34
Posted 20 August 2013 - 04:14 PM
You will be using the HTML5 <canvas> tag if it goes ahead, I assume?
1lann #35
Posted 20 August 2013 - 11:22 PM
You will be using the HTML5 <canvas> tag if it goes ahead, I assume?
Yes of course.
nutcase84 #36
Posted 22 August 2013 - 11:20 AM
I see an error thing at the top of the page.
Spoiler
GravityScore #37
Posted 22 August 2013 - 12:15 PM
I see an error thing at the top of the page.
Spoiler

So do I :/
Engineer #38
Posted 25 August 2013 - 09:31 AM
I see an error thing at the top of the page.
Spoiler

So do I :/
My assumption would be that those forums are not compatible with out modern browsers which supports html 5. I have it too, bit there is nothing we can do nor the admins. That is because the stuff with licenses and blabla.. in short, we will have to wait :P/>

but to be back on topic, maybe the idea of a web client is not in the right spot. Since you are currently coding in python, which is compatible with almost every platform to nu knowledge, you could possibly make it a standalone, lightweight emulator.
The idea of not having java installed but running such an emulator is awesome. But without knowing any python, I don't know if it is really possible and doable
nutcase84 #39
Posted 25 August 2013 - 07:14 PM
I have programed in python, but how would you put it on Android/IOS/Others? I found few python apps for android, but it can't do GUIs.
oeed #40
Posted 25 August 2013 - 10:14 PM
I have programed in python, but how would you put it on Android/IOS/Others? I found few python apps for android, but it can't do GUIs.

While it is possible to use Python on iOS I wouldn't advise it. There is a Lua interpreter for Lua, but your main problem is the absolute zero support for Java. So you'd have to write the whole thing yourself essentially. Your other problem is keyboard input. How do you know when to show they keyboard? What about arrow keys. Granted, you could make a keyboard interface, but it won't fit on a phone. Finally, who would actually use a CC emulator on their phone? Apart from the novelty value I can't really see a use.