use Lua in place of torquescript

#1 No not currently, take a look at Demolishun's ScriptT3D resource tho, it provides a base for a bunch of scripting languages (although it only supports Python ootb). It's only a base tho if you want to use it for anything except Python you are going to do some development yourself.

Why is it exactly Lua you need tho? Why doesn't TorqueScript, Python or C# fulfill your needs? (Just curious, I don't try to say anything with that question)

#2 Out of the box, no. But enterprising community memebers out there have replaced TorqueScript with languages suach as Python, Lua, and C# before.

#3 I want to script my game in assembly.

#4 Nah man, Cobol all the way!

Actually, the Neko VM would rock.

It is taking a completely different direction than statically typed VMs. The potential is many different languages using the same VM at the same time. Potentially TS could run on the VM as well.

The only thing I don't really like about it is the LGPL license, but it could still be made to work with the Torque engines for any kind of project.

#5 Pft plebes.
Are you all telling me you HAVEN'T been writing in machine code? Kids these days ;)

Also, Neko sounds pretty interesting Demo. I hadn't heard of it before.

#6 @Jeff,
It might be a momentary lack of judgement on my part. I like the "idea" of changing out the core scripting technology in T3D, but when I go to actually look at the core I start to wish I was in the my "happy place". It is scary in there. Though I did look at it again today and realized there might be a simple way to change it out. So who knows, maybe some day. If I do take that on down the road I will certainly template it or something to make it easier for the next idiot who wants that kind of brain damage.

#7 @Demolishun, Cobol! Waaah! *shudder*, I'll take Assembler over Cobol any day..

Never got around to PC Assembler, was always a huge step backwards compared to 68k Assembler. maybe with the 64bit opcodes it may have improved? you still have to page the first 64k in and out?

#8

Quote:I want to script my game in assembly.

...because Lua is pretty much the same as assembly, of course...

;P

#9 C'mon, Danny - it's "Lua," not "LUA" - Portugese for "Moon."

Actually, I'm using it in a project at work to help manage a needlessly complex build environment.

#10 @David,
You have not had to page anything in an x86 processor since the 386. Even the 386 had the ability to do a flat memory model in non-protected mode. Though it was not officially a mode it was supposed to be in. But since hundreds of DOS games utilized it Intel had to make sure it was supported in later chips. Of course now every modern OS in x86 is now protected mode with a flat memory model. Okay, the bios might still be paging crap on bootstrap, I dunno for sure. But I don't have to anymore!

And David, you are the only one actually saying Assembler correctly.

#11 Oh?

Now, "correctly" is a matter of reference when talking about words and languages - Indeed, historically "assembly languages" were referred to as "assembler languages" but English she is a-drifting. Many fairly definitive texts use either/or. Just 'cause you're old-school.... ;p

I'm arguing for that either/or approach myself, though the following agrees with what I was taught in '83:

Quote:An assembly language is a low-level programming language for a computer, or other programmable device, in which there is a very strong (generally one-to-one) correspondence between the language and the architecture's machine code instructions. Each assembly language is specific to a particular computer architecture, in contrast to most high-level programming languages, which are generally portable across multiple architectures, but require interpreters or compiling.

Assembly language is converted into executable machine code by a utility program referred to as an assembler; the conversion process is referred to as assembly, or assembling the code.

- abashedly from Wikipedia, admittedly a dubious source....

#12 Whoops, you're right. Fixed!

Isn't an assembler the software that translates assembly language to machine code?

...ninja'd by Richard.

#13 That's why I'm not very picky about it - essentially each assembler had its own language so "assembler language" works as well as "assembly language" in my book.

#14 @Richard,
I think you are right. I think the correct term is assembly language when referring to the code. I think to be safe I will just start saying assemblery to refer to both the tool and the language.

#15 Hah! It's all cool - I'm an irremidial jackass so don't take anything I say too seriously....

#16 I'm going to call it assemblery too now. ;)

#17 @Demo, no you don't have to page, because the os does it for you anymore. You just write your happy code as if nothing else exists and if the os deems necessary it'll page the memory in and out as it sees fit. Still happens to this day, and always will until memory is cheap enough that every program can have all the memory it needs without having to share.

Lua is compact, fast and compiles on just about any platform you'd want your game on. Considering how much lua is used, I'd say that's why the OP is askin about it.

For anyone else who doesn't know what the neko vm is you can also check out haxe.org/, though I'd still stick with a complete ts rewrite than to go that route.

#18 @Smally,
This is mixing apples and oranges. Segmentation is what was used to access 64K at a time in a 1MB address space. That is 8088/80286. The 80386 introduced paging where the entire address space of 4GB could be accessed and you could use virtual memory. This is a flat memory model when all the main memory registers are set to the max address space. Just about every OS sets the address space to max. Now with 64 bit processors a lot more memory can be addressed. Now most OSes don't even deal with paging or deal very little with it. They let the processor handle this. The processor can swap memory from your hard drive (virtual memory). Linux does this on any system it runs on that is why it generally needs an MMU. One of the exceptions are file systems that are marked read only in embedded systems that generally employ flash based drives. Using paging and virtual memory is not a failing of the architecture. I would rather have that then "out of memory" messages. I can at least shut things down and get my memory back.

Just one ref:
programmers.stackexchange.com/questions/100047/why-not-segmentation

Quote:always will until memory is cheap enough that every program can have all the memory it needs without having to share.

If you are running Windows there will never be a time that the OS does not want almost all of your RAM. I could see this happening on Linux or OSX, but not Windows. When I ran Linux all the time I rarely experienced a time when it did any significant amount of paging to virtual memory.

I have never understood the this CPU is better arguments. Harvard architecture VS Berkley or whatever kind of crap. I can guarantee that if there are significant advantages of any one CPU architecture it has been use to some advantage in most modern CPUs. I mean most people don't know that Intel and AMD x86 processors are now internally RISC. They have a CISC interface that reduces the instruction into RISC instructions via microcode. So they are leveraging advantages of the CISC and RISC architectures in the same chip.

#19 The hardware is going to generate an interrupt that the os will trap when memory needs to be paged and page fault occurs. If the os doesn't have a strategy in place for this (swapping older, least used frames), you won't page anything. The CPU (in effect) calls the os when this needs to be done and how that's ultimately handled is still up to the os itself. The os itself has to setup the memory model and the page tables and deal with the hd; writing / reading on whatever fs layer there is. So, yes demo, it's the os handling this with the help of the CPU and MMU. Linux suffers from this as much as windows does. It's not mixing apples and oranges there and this is waaaay off topic. I kept my original comment short as less technical for a reason lol.

en.wikipedia.org/wiki/Virtual_memory
www.sal.ksu.edu/faculty/tim/ossg/Memory/Memory.html


As for the OP, if you want to do a complete replacement of torquescript with lua and keep the same functionality, your basically going to create a lua vm instance and bind what you need to the vm instance. Your going to have to recreate every console function from torquescript in lua. Just bind only what you need at the time and work your way through it. You'll have to step through little by little this way, but you'll end up with a deeper understanding of how it's all put together to a better degree. Outside of that though, there isn't a ready to go setup for lua at the moment, as far as I know.

#20 It might not be that bad if you can tweak the console binding macros to bind to Lua instead of TorqueScript - after replacing the TS VM with Lua, of course. It would be a more primitive version of LuaBind, essentially.