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

[Extremely short] No multishell & TLCO -- Kills multishell, runs normal shell as the top-level coroutine.

Started by Geforce Fan, 21 February 2015 - 01:21 AM
Geforce Fan #1
Posted 21 February 2015 - 02:21 AM
The Window API has slowed ComputerCraft down dramatically. However, with this simple line of code:
term.redirect(term.native())
you bypass the window API and write directly to the screen. I whipped up a short program that runs an instance of shell without multishell. The shell then checks for the startup script, and finds this again. However, this script sees that multishell is already dead, and, instead, runs the file "newStartup". If you want a startup script while using this, use newStartup. Here's the entire code:

if window or multishell then
  sleep(0)
  --tlco
  local a = _G.printError
  function _G.printError()--when the bios goes to print the error, we run our code
	_G.printError=a
	--no multishell
	term.redirect(term.native())
	multishell=nil
	--no window
	term.setTextColor(colors.yellow)term.setBackgroundColor(colors.black)
	term.clear()term.setCursorPos(1,1)
	write"Multishelless Top-level "
	os.run({},"rom/programs/shell")
  end
  os.queueEvent"terminate"--cause the shell to terminaye
else
  shell.run"newStartup"
end


As you can see, it's pretty short. Just run:

pastebin get aAvvij3f startup

to install.
Games should dramatically increase in performance. Slower games become playable!
Edited on 01 March 2015 - 04:49 AM
oeed #2
Posted 21 February 2015 - 02:55 AM
Huh. Not sure how I haven't seen that. I'll certainly be adding that to OneOS/Bedrock.

Edit: Wow. That really does make it much quicker and smoother.
Edited on 21 February 2015 - 01:59 AM
Geforce Fan #3
Posted 21 February 2015 - 05:26 AM
you wheren't already doing this with OneOS?
I heard about it from BlombBlake. I was amazed at things' performances without the Window API!
One great thing about this is that it won't error if multishell/the window API doesn't exist(because they where on an older version or something)

You shouldn't add this to bedrock. term.redirect(term.native()) disables the window api, meaning they couldn't fg or bg it–if they tried to click on a different tab, the next time it drew to the screen, it would just draw over what they're on on the other tab.
In other words, it breaks multishell's ability to prevent apps from writing to the screen while not focused. OneOS,on the other hand, should not be ran in multishell–it's an OS for pete's sake.
I'm going to try OneOS without the window api
Wow… OneOS runs EXTREMELY smooth without the window API. I'm really blown away, I remember your OS as laggy and slow, and with 2 lines of code it's suddenly zipping around like insertanalagyhere!
Edited on 21 February 2015 - 04:38 AM
dueckers5 #4
Posted 21 February 2015 - 05:45 AM
Wow dude great program. I'm currently in the making of an os (not as advance as OneOS btw cool OS like it :D/>) And i might use this for mine. P.S 'it dosent have a task bar. But it has a start button. Would this interfere it?
Geforce Fan #5
Posted 21 February 2015 - 05:48 AM
I don't think you quite understands what this does if you think a start button would interfere with it. Just my opinion, but you might want to hold off on an OS if you're not sure how this works.
You can use it though, it's fine. It will speed your OS up. Just stick:

term.redirect(term.native())
multishell = nil--optional, probably not necessary if you never return to the shell, but you have problems include this.
at the top of the startup script
Edited on 21 February 2015 - 04:48 AM
oeed #6
Posted 21 February 2015 - 06:54 AM
You shouldn't add this to bedrock. term.redirect(term.native()) disables the window api, meaning they couldn't fg or bg it–if they tried to click on a different tab, the next time it drew to the screen, it would just draw over what they're on on the other tab.
In other words, it breaks multishell's ability to prevent apps from writing to the screen while not focused. OneOS,on the other hand, should not be ran in multishell–it's an OS for pete's sake.
I'm going to try OneOS without the window api
Wow… OneOS runs EXTREMELY smooth without the window API. I'm really blown away, I remember your OS as laggy and slow, and with 2 lines of code it's suddenly zipping around like insertanalagyhere!
Hmmmm, yeah I didn't think about that actually… I wonder if there's a way to detect if it's within multishell or not.
Geforce Fan #7
Posted 21 February 2015 - 07:05 AM
You shouldn't add this to bedrock. term.redirect(term.native()) disables the window api, meaning they couldn't fg or bg it–if they tried to click on a different tab, the next time it drew to the screen, it would just draw over what they're on on the other tab.
In other words, it breaks multishell's ability to prevent apps from writing to the screen while not focused. OneOS,on the other hand, should not be ran in multishell–it's an OS for pete's sake.
I'm going to try OneOS without the window api
Wow… OneOS runs EXTREMELY smooth without the window API. I'm really blown away, I remember your OS as laggy and slow, and with 2 lines of code it's suddenly zipping around like insertanalagyhere!
Hmmmm, yeah I didn't think about that actually… I wonder if there's a way to detect if it's within multishell or not.
multishell.setFocus, then if multishell.getFocus() is 2, they're running at least 2 tabs, meaning they're running it within a multishell tab.
edit: or just multishell.getCount(). :\
Edited on 21 February 2015 - 06:06 AM
MKlegoman357 #8
Posted 21 February 2015 - 12:21 PM
Hmmmm, yeah I didn't think about that actually… I wonder if there's a way to detect if it's within multishell or not.

multishell.setFocus, then if multishell.getFocus() is 2, they're running at least 2 tabs, meaning they're running it within a multishell tab.
edit: or just multishell.getCount(). :\


if not multishell then
  print( "Hey, guess what? I'm not running in multishell!" )
end
Edited on 21 February 2015 - 11:22 AM
Geforce Fan #9
Posted 21 February 2015 - 07:04 PM
Hmmmm, yeah I didn't think about that actually… I wonder if there's a way to detect if it's within multishell or not.

multishell.setFocus, then if multishell.getFocus() is 2, they're running at least 2 tabs, meaning they're running it within a multishell tab.
edit: or just multishell.getCount(). :\


if not multishell then
  print( "Hey, guess what? I'm not running in multishell!" )
end
Or, you could just check if it's an advanced terminal.
This will say it's in multishell regardless of weather you have tabs open or not.
I don't think you understand what we're trying to do. We're checking if they're running in a tab or not.
Edited on 21 February 2015 - 06:04 PM
MKlegoman357 #10
Posted 21 February 2015 - 07:18 PM
Or, you could just check if it's an advanced terminal.
This will say it's in multishell regardless of weather you have tabs open or not.
I don't think you understand what we're trying to do. We're checking if they're running in a tab or not.

Regardless of the number of tabs running, if a program is running in multishell it is running in a multishell tab - inside a window object, so whenever there are more tabs opened multishell could just resize the current program's window. So checking if it's running in multishell should be enough.

EDIT: oh, and a good OS IMO should be running TLCO anyways, not as a shell program.
Edited on 21 February 2015 - 06:23 PM
Geforce Fan #11
Posted 21 February 2015 - 10:33 PM
Or, you could just check if it's an advanced terminal.
This will say it's in multishell regardless of weather you have tabs open or not.
I don't think you understand what we're trying to do. We're checking if they're running in a tab or not.
Regardless of the number of tabs running, if a program is running in multishell it is running in a multishell tab - inside a window object, so whenever there are more tabs opened multishell could just resize the current program's window. So checking if it's running in multishell should be enough.
It's true that it's always running in multishell, but that's not what matters. I'm saying, check if OneOS is running in a tab, as in they want to keep CraftOS open or something, and if it is, don't override it. When there's only one tab, the menu bar is gone, and you can only open another tab either using the multishell API, or by quitting the program and using fg. So the user won't notice a different when it overrides the window api, except for better performance.

EDIT: oh, and a good OS IMO should be running TLCO anyways, not as a shell program.
This is completely untrue. TLCOs are easily broken by CC updates. It really doesn't affect preformance.
Edited on 21 February 2015 - 09:37 PM
MKlegoman357 #12
Posted 22 February 2015 - 08:10 AM
And what if I have multishell running in multishell? It's not gonna work then. I think Bomb Bloke made a good point about the whole window and multishell things - leave it to the user. If he/she wants it they can do it themselves. Well, I don't really remember how any of the CC update broke a TLCO. And no, it's not about performance. But running an 'OS' as a program of another OS (CraftOS) just looks like running Linux on a Windows machine in a VM. Remember that by running the 'OS' that way you can also catch any errors that may happen in rednet or shell/multishell, which a good 'OS' should be catching and dealing with. You wouldn't be able to do that without TLCO.
Edited on 22 February 2015 - 07:11 AM
Creator #13
Posted 22 February 2015 - 11:30 PM
WOW astonishing
Geforce Fan #14
Posted 22 February 2015 - 11:47 PM
And what if I have multishell running in multishell? It's not gonna work then. I think Bomb Bloke made a good point about the whole window and multishell things - leave it to the user. If he/she wants it they can do it themselves. Well, I don't really remember how any of the CC update broke a TLCO. And no, it's not about performance. But running an 'OS' as a program of another OS (CraftOS) just looks like running Linux on a Windows machine in a VM. Remember that by running the 'OS' that way you can also catch any errors that may happen in rednet or shell/multishell, which a good 'OS' should be catching and dealing with. You wouldn't be able to do that without TLCO.
no, it won't. But if the user has at least 5% of a brain, they won't do stupid things like that.
For OneOS, I don't think it should be left to the user. it's an os for pete's sake, it's SUPPOSED to overwrite the existing one!
Honestly, having a shell run your OS makes a lot of sense, it acts as a net if things get totally broken.
Linux boots to a terminal(well, some distros)! I really don't think TLCO is necisary, although it's definitely cool and, if you can get it to work, go ahead and do it.
CC updates have broken Nevercast's TLCO, AND ElvishJerrico's.
Anyway, I'm going to see if I can kill multishell all together.
—-
Updated. This now completely kills off the Multishell AND the Window API, and runs at top-level. Basically, running this at startup restores computercraft to its pre-multishell state.
Another update: Fixed the issue with running this at startup. Essentially, when it fired up the shell, the shell would the startup script(it) and run it, causing an endless loop. This now checks if the multishell and window has been killed yet before executing.
Hi… It's me again… Just letting you know I updated this AGAIN to now run newStartup when the normal shell is done starting up. Thanks!
Edited on 22 February 2015 - 11:23 PM
Wojbie #15
Posted 01 March 2015 - 05:37 AM
Could you explain reasoning for removing windows api along with Multishell? Without multishell it will not get used unless program someone wants to use uses it. Just curiou.
Geforce Fan #16
Posted 01 March 2015 - 05:48 AM
I honestly don't know why I did that. I started running into problems while using this on my os. Fixed.
Edited on 01 March 2015 - 04:48 AM
MineRobber___T #17
Posted 11 November 2017 - 08:51 AM
-snip-
CC updates have broken Nevercast's TLCO, AND ElvishJerrico's.
-snip-

Actually, ElvishJerrico's TLCO still works. Just replace:

os.queueEvent('modem_message')
With:

os.queueEvent('modem_message',0)
Dave-ee Jones #18
Posted 23 November 2017 - 03:14 AM
Tempted to try out Dodj with this on, see how fast my characters move around the screen.