[Project Idea]Matrix Code/Digital Rain

Pharap, on 09 March 2013 - 12:10 PM said:

Are we talking about Matrix: a film or Matrix: a mathematical concept commonly used in 3D render engines for vertex translations?

Pharap, on 09 March 2013 - 12:57 PM said:

You mean the digital rain? http://en.wikipedia....ix_digital_rain

Pharap, on 09 March 2013 - 01:14 PM said:

Right, glad that clears that up, best edit the first post so as to not to confuse others lol

term.clear()
term.setCursorPos(1,1)
while true do
term.setTextColor(32)
print (math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999))
sleep(0.2)
end

AnthonyD98™, on 09 March 2013 - 01:20 PM said:

term.clear()
term.setCursorPos(1,1)
while true do
term.setTextColor(32)
print (math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999))
sleep(0.2)
end

Something a bit like this?

Pharap, on 09 March 2013 - 01:24 PM said:

AnthonyD98™, on 09 March 2013 - 01:20 PM said:

term.clear()
term.setCursorPos(1,1)
while true do
term.setTextColor(32)
print (math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999), " ", math.random(1000000,9999999))
sleep(0.2)
end

Something a bit like this?

A bit more advanced than that I should think.
If the aim is an effect like this: [media]http://www.youtube.com/watch?v=DLyPvuSx7qA[/media]

SuicidalSTDz, on 09 March 2013 - 01:25 PM said:

That is the aim, yes. Needs to be colored; white for the last char in the line and green for the rest.

local size={term.getSize()}
local tPixels={}
for x=1,size[1]-1 do
tPixels[x]={}
for y=1,size[2] do
tPixels[x][y]=' '
end
end
local function render()
term.clear()
term.setCursorPos(1,1)
for y=1,#tPixels[1] do
if y~=1 then
print('')
end
for x=1,#tPixels do
write(tPixels[x][y])
end
end
end
local function cycle()
for x=1,#tPixels do
for y=#tPixels[x],2,-1 do
tPixels[x][y]=(tPixels[x][y-1]==' ' and ' ') or ((tPixels[x][y]~=' ' and tPixels[x][y]) or string.char(math.random(32,126)))
end
--[[for x=1,#tPixels do
local intC=nil
for y=2,5 do
if tPixels[x][y]==' ' then
intC=true
end
end
if not intC then
tPixels[x][1]=' '
end
end]]
end
end
local function create()
tPixels[math.random(1,#tPixels)][1]=string.char(math.random(32,126))
tPixels[math.random(1,#tPixels)][1]=' '
tPixels[math.random(1,#tPixels)][1]=' '
end
local bRunning=true
while bRunning do
cycle()
create()
render()
	local timer=os.startTimer(.1)
while true do
local sEvent, param = os.pullEvent()
if (sEvent=='timer' and param==timer) then
break
end
end
end

erronjason, on 09 March 2013 - 06:24 PM said:

local size={term.getSize()}
local tPixels={}
for x=1,size[1]-1 do
tPixels[x]={}
for y=1,size[2] do
tPixels[x][y]=' '
end
end
local function render()
term.clear()
term.setCursorPos(1,1)
for y=1,#tPixels[1] do
if y~=1 then
print('')
end
for x=1,#tPixels do
write(tPixels[x][y])
end
end
end
local function cycle()
for x=1,#tPixels do
for y=#tPixels[x],2,-1 do
tPixels[x][y]=(tPixels[x][y-1]==' ' and ' ') or ((tPixels[x][y]~=' ' and tPixels[x][y]) or string.char(math.random(32,126)))
end
--[[for x=1,#tPixels do
local intC=nil
for y=2,5 do
if tPixels[x][y]==' ' then
intC=true
end
end
if not intC then
tPixels[x][1]=' '
end
end]]
end
end
local function create()
tPixels[math.random(1,#tPixels)][1]=string.char(math.random(32,126))
tPixels[math.random(1,#tPixels)][1]=' '
tPixels[math.random(1,#tPixels)][1]=' '
end
local bRunning=true
while bRunning do
cycle()
create()
render()
	local timer=os.startTimer(.1)
while true do
local sEvent, param = os.pullEvent()
if (sEvent=='timer' and param==timer) then
break
end
end
end

erronjason, on 09 March 2013 - 06:24 PM said:

local size={term.getSize()}
local tPixels={}
for x=1,size[1]-1 do
tPixels[x]={}
for y=1,size[2] do
tPixels[x][y]=' '
end
end
local function render()
term.clear()
term.setCursorPos(1,1)
for y=1,#tPixels[1] do
if y~=1 then
print('')
end
for x=1,#tPixels do
write(tPixels[x][y])
end
end
end
local function cycle()
for x=1,#tPixels do
for y=#tPixels[x],2,-1 do
tPixels[x][y]=(tPixels[x][y-1]==' ' and ' ') or ((tPixels[x][y]~=' ' and tPixels[x][y]) or string.char(math.random(32,126)))
end
--[[for x=1,#tPixels do
local intC=nil
for y=2,5 do
if tPixels[x][y]==' ' then
intC=true
end
end
if not intC then
tPixels[x][1]=' '
end
end]]
end
end
local function create()
tPixels[math.random(1,#tPixels)][1]=string.char(math.random(32,126))
tPixels[math.random(1,#tPixels)][1]=' '
tPixels[math.random(1,#tPixels)][1]=' '
end
local bRunning=true
while bRunning do
cycle()
create()
render()
	local timer=os.startTimer(.1)
while true do
local sEvent, param = os.pullEvent()
if (sEvent=='timer' and param==timer) then
break
end
end
end

AnthonyD98™, on 10 March 2013 - 10:54 AM said:

There is flickering in that code :(/>

tesla1889, on 10 March 2013 - 10:59 AM said:

AnthonyD98™, on 10 March 2013 - 10:54 AM said:

There is flickering in that code :(/>

its a pretty high-demand request, as every pixel needs to be redrawn every cycle, and Lua isn't a great graphics platform, so thats just how it is

Pharap, on 10 March 2013 - 11:23 AM said:

It's not lua's fault, it's how the graphics are handled.
Not saying CC handled graphics badly, just saying that how graphics are handled is more important than the scripting language used.

SuicidalSTDz, on 10 March 2013 - 11:27 AM said:

True, Lua outside of CC is generally more "Graphic Freindly", however, there are other languages that handle graphics better. Not saying I don't like Lua ^_^/>

SuicidalSTDz, on 10 March 2013 - 11:38 AM said:

On my phone so I can't go into much detail but anything really, C#, C++, etc

Pharap, on 10 March 2013 - 11:43 AM said:

SuicidalSTDz, on 10 March 2013 - 11:38 AM said:

On my phone so I can't go into much detail but anything really, C#, C++, etc

Those are compiled languages, not scripting languages.
Lua runs on a VM implemented in languages like C# and C++, meaning lua is constrained to the graphical functions passed to it/set up by the lower languages (like C# and C++).

SuicidalSTDz, on 10 March 2013 - 11:56 AM said:

Pharap, on 10 March 2013 - 11:43 AM said:

SuicidalSTDz, on 10 March 2013 - 11:38 AM said:

On my phone so I can't go into much detail but anything really, C#, C++, etc

Those are compiled languages, not scripting languages.
Lua runs on a VM implemented in languages like C# and C++, meaning lua is constrained to the graphical functions passed to it/set up by the lower languages (like C# and C++).

I always keep forgeting Lua isn't compiled. I guess that makes Lua preferrably superior than the other scripting languages. FORTH is one of the worst (Possibly others that may be worse)

AfterLifeLochie, on 10 March 2013 - 12:00 PM said:

SuicidalSTDz, on 10 March 2013 - 11:56 AM said:

Pharap, on 10 March 2013 - 11:43 AM said:

SuicidalSTDz, on 10 March 2013 - 11:38 AM said:

On my phone so I can't go into much detail but anything really, C#, C++, etc

Those are compiled languages, not scripting languages.
Lua runs on a VM implemented in languages like C# and C++, meaning lua is constrained to the graphical functions passed to it/set up by the lower languages (like C# and C++).

I always keep forgeting Lua isn't compiled. I guess that makes Lua preferrably superior than the other scripting languages. FORTH is one of the worst (Possibly others that may be worse)

Lua is, in fact, a compiled language - at runtime, unlike Java, which is pre-compiled. Invoking string.dump yields a Lua bytecode "chunk" which is invoke-able using loadstring(chunk) later on.

SuicidalSTDz, on 10 March 2013 - 12:02 PM said:

AfterLifeLochie, on 10 March 2013 - 12:00 PM said:

SuicidalSTDz, on 10 March 2013 - 11:56 AM said:

I always keep forgeting Lua isn't compiled. I guess that makes Lua preferrably superior than the other scripting languages. FORTH is one of the worst (Possibly others that may be worse)

Lua is, in fact, a compiled language - at runtime, unlike Java, which is pre-compiled. Invoking string.dump yields a Lua bytecode "chunk" which is invoke-able using loadstring(chunk) later on.

This is why I get confused so much. One person says one thing then another says another thing ^_^/>/>/> So, let's get this straight, Lua is a Compiled language, correct?

AfterLifeLochie, on 10 March 2013 - 12:04 PM said:

SuicidalSTDz, on 10 March 2013 - 12:02 PM said:

AfterLifeLochie, on 10 March 2013 - 12:00 PM said:

SuicidalSTDz, on 10 March 2013 - 11:56 AM said:

I always keep forgeting Lua isn't compiled. I guess that makes Lua preferrably superior than the other scripting languages. FORTH is one of the worst (Possibly others that may be worse)

Lua is, in fact, a compiled language - at runtime, unlike Java, which is pre-compiled. Invoking string.dump yields a Lua bytecode "chunk" which is invoke-able using loadstring(chunk) later on.

This is why I get confused so much. One person says one thing then another says another thing ^_^/>/>/> So, let's get this straight, Lua is a Compiled language, correct?

Lua programs are not interpreted directly from the textual Lua file, but are compiled into bytecode which is then run on the Lua virtual machine. The compilation process is typically transparent to the user and is performed during run-time, but it can be done offline in order to increase loading performance or reduce the memory footprint of the host environment by leaving out the compiler.

Lua is compiled. :P/>

AfterLifeLochie, on 10 March 2013 - 12:00 PM said:

Lua is, in fact, a compiled language - at runtime, unlike Java, which is pre-compiled. Invoking string.dump yields a Lua bytecode "chunk" which is invoke-able using loadstring(chunk) later on.

Pharap, on 10 March 2013 - 12:19 PM said:

AfterLifeLochie, on 10 March 2013 - 12:00 PM said:

Lua is, in fact, a compiled language - at runtime, unlike Java, which is pre-compiled. Invoking string.dump yields a Lua bytecode "chunk" which is invoke-able using loadstring(chunk) later on.

Bytecode, but not machine code.
It still has to run on a VM.
The point being it doesn't have direct hardware access, it has to be given access to a rendering system by the system managing the VM.
The graphical code is entirely dependant on the implementing platform, therefore it's not lua that causes graphical manipulation to be easy or hard, it's the implementing platform.

AfterLifeLochie, on 10 March 2013 - 12:20 PM said:

Pharap, on 10 March 2013 - 12:19 PM said:

AfterLifeLochie, on 10 March 2013 - 12:00 PM said:

Lua is, in fact, a compiled language - at runtime, unlike Java, which is pre-compiled. Invoking string.dump yields a Lua bytecode "chunk" which is invoke-able using loadstring(chunk) later on.

Bytecode, but not machine code.
It still has to run on a VM.
The point being it doesn't have direct hardware access, it has to be given access to a rendering system by the system managing the VM.
The graphical code is entirely dependant on the implementing platform, therefore it's not lua that causes graphical manipulation to be easy or hard, it's the implementing platform.

Of course, that's not what I'm saying. What I'm saying is that Lua *is* a compiled language - as someone told SuicidalSTDz otherwise.

Shnupbups100, on 10 March 2013 - 12:23 PM said:

I am SO going to make this one of the screensavers in my next version of CCScreensaver…

Pharap, on 10 March 2013 - 12:24 PM said:

As new languages arise with their own rules and systems

Pharap, on 10 March 2013 - 12:24 PM said:

AfterLifeLochie, on 10 March 2013 - 12:20 PM said:

Pharap, on 10 March 2013 - 12:19 PM said:

AfterLifeLochie, on 10 March 2013 - 12:00 PM said:

Lua is, in fact, a compiled language - at runtime, unlike Java, which is pre-compiled. Invoking string.dump yields a Lua bytecode "chunk" which is invoke-able using loadstring(chunk) later on.

Bytecode, but not machine code.
It still has to run on a VM.
The point being it doesn't have direct hardware access, it has to be given access to a rendering system by the system managing the VM.
The graphical code is entirely dependant on the implementing platform, therefore it's not lua that causes graphical manipulation to be easy or hard, it's the implementing platform.

Of course, that's not what I'm saying. What I'm saying is that Lua *is* a compiled language - as someone told SuicidalSTDz otherwise.

Ok then, let's put it this way, it's not low level, it's high level and must be implemented in a lower level language.
When the programmers I usually work with talk about compilation, it's almost always to machine code.
As new languages arise with their own rules and systems, the classification of language becomes ever more difficult.

Kingdaro, on 10 March 2013 - 01:20 PM said:

Here's my overly complicated attempt. (advanced computers only)

AfterLifeLochie, on 10 March 2013 - 12:54 PM said:

Pharap, on 10 March 2013 - 12:24 PM said:

Ok then, let's put it this way, it's not low level, it's high level and must be implemented in a lower level language.
When the programmers I usually work with talk about compilation, it's almost always to machine code.
As new languages arise with their own rules and systems, the classification of language becomes ever more difficult.

It's always to machine code. Java uses the JVM and it's own bytecode, C#, VB.NET, J#, Lua, Perl, Python and a long list of others use their own internal VM and bytecode formats. Bytecode *is* machine code - it's just interpreted by a unique VM. All these VMs are reliant on a low level execution platform.

Lua is dynamically typed, so of course it's higher-level than bytecode. It still requires a VM because it's not pure ASM.

Pharap, on 10 March 2013 - 01:27 PM said:

AfterLifeLochie, on 10 March 2013 - 12:54 PM said:

Pharap, on 10 March 2013 - 12:24 PM said:

Ok then, let's put it this way, it's not low level, it's high level and must be implemented in a lower level language.
When the programmers I usually work with talk about compilation, it's almost always to machine code.
As new languages arise with their own rules and systems, the classification of language becomes ever more difficult.

It's always to machine code. Java uses the JVM and it's own bytecode, C#, VB.NET, J#, Lua, Perl, Python and a long list of others use their own internal VM and bytecode formats. Bytecode *is* machine code - it's just interpreted by a unique VM. All these VMs are reliant on a low level execution platform.

Lua is dynamically typed, so of course it's higher-level than bytecode. It still requires a VM because it's not pure ASM.

The fact the LVM is running on the JVM means it's not direct to machine code.
With things like the JVM it's much closer to the hardware so it can go near enough straight to native machine code, but if you're running a VM on top of a VM its unlikely to convert straight to native machine code.


Now enough of all this, it's off topic.
The point at the heart is that it's not lua's fault, it's the system managing the VM that decides lua's access to graphics.
In the current context of a matrix digital rain system for the computercraft computers: the graphics are what matters.