Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

DarkBASIC Professional Discussion / DBPro Integrated Scripting language - what do *you* want

Author
Message
IanM
Retired Moderator
18
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 6th Jul 2003 23:07
Hi guys,

I'm currently looking at putting together a scripting language to be used within DBPro, and it just occurred to me that if I want you to use it, I'd better find out what you want it to be capable of and what you want to do with it.

So, this is your chance

Give me your ideas on how complex you need it to be, and how tightly it should integrate to DBPro, but bear in mind that I'm not planning to replace the DBPro language, or spend the rest of my life coding it
Fallout
18
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 6th Jul 2003 23:28
Can you clarrify for us that dont understand what you mean by a scripting language? I mean, I'd understand the context in terms of a computer game like operation flashpoint etc - in essense a programming language to allow you to better control operation flashpoint. I just dont understand how a scripting language works with a programming language? Cheers.

Machine: P4 2200, 1GB RAM, GeForce4 64MB, Audigy Platinum
http://www.breakbeat-terrorism.co.uk
(It's not all about the coding)
heartbone
18
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 7th Jul 2003 00:06 Edited at: 7th Jul 2003 00:07
IanM isn't a scripting language supposed to be used at the OS level? (As a note in XP I don't know if a true scripting language will even be possible.) In general I don't know of any scripting language that is a cooked into a computer programming language. Just the opposite is the case, scripts coordinate and customize the calling of modules built in various languages.

The more you see, the more you know.
The more you know, the more you see.
MrTAToad
18
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 7th Jul 2003 00:08
The ability to pass and return values, strings etc; file i/o (general access and the ability to run the script from a file in the background); ability to resolve calculations...

Good news everyone! I really am THAT good...
http://www.nickk.nildram.co.uk/ for great plug-ins and other exciting things - oh my, yes!
MrTAToad
18
Years of Service
User Offline
Joined: 26th Aug 2002
Location: United Kingdom
Posted: 7th Jul 2003 00:46
You could always try getting an interface to Lua (or even REXX) up and running. I tried the former (but it kept crashing), and thought about the latter (but couldn't be bothered).

Good news everyone! I really am THAT good...
http://www.nickk.nildram.co.uk/ for great plug-ins and other exciting things - oh my, yes!
Rob K
Retired Moderator
18
Years of Service
User Offline
Joined: 10th Sep 2002
Location: Surrey, United Kingdom
Posted: 7th Jul 2003 01:20
- The ability to record data in variables (integers,dwords,strings) and use common operators

- The ability to call DBP commands, if the language could be designed in such a way that it was not limited to commands in the DBP core DLLs and those at the time of release (ie. so it could call commands from plugin DLLs for example), that would be very useful

- The ability to interact with DBP eg myvar=Extract("ScriptingLangVar")

Do you want Windows menus in your DBP apps? - Get my plugin: http://snow.prohosting.com/~clone99/downloads/tpc_menus_103.zip
IanM
Retired Moderator
18
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Jul 2003 01:45 Edited at: 7th Jul 2003 01:58
Fallout/Heartbone: Scripting can be useful at all levels. For example, if your AI was scripted, you could quickly change it without recompiling, or even add a new 'entity'. Also, given the correct details, others could provide mods for your games.

It's how games like QuakeIII, NWN and others are written.

As a primitive example, do you remember AMAL in AMOS?

MrTAToad: I thought about LUA, but the main reason I decided against it was that it was too different for most users of DBPro.

Besides, I want to write my own and it would be a matter of a couple of hours to get the code together to get all the symbols from the C++ interface loaded into the assembler.
Fallout
18
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 7th Jul 2003 02:00
I get ya, but with db being a little tight on cycles, isnt it going to slow down cpu intensive stuff? I mean, yeah, it'd be more convenient and make things like editor progs etc. easier to make, but wouldnt it be slower than hardcoding scripting?

Machine: P4 2200, 1GB RAM, GeForce4 64MB, Audigy Platinum
http://www.breakbeat-terrorism.co.uk
(It's not all about the coding)
IanM
Retired Moderator
18
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Jul 2003 02:17
The scripts will be compiled to pure machine code, so the impact won't be as great as you might think - I hope
Fallout
18
Years of Service
User Offline
Joined: 1st Sep 2002
Location: Basingstoke, England
Posted: 7th Jul 2003 02:45
I thought you meant they'd be interpretted by a seperate program module, which I thought would've been a little slow. If they get compiled and run, that'd be bad ass, I'm sure.

Machine: P4 2200, 1GB RAM, GeForce4 64MB, Audigy Platinum
http://www.breakbeat-terrorism.co.uk
(It's not all about the coding)
Shadow Robert
18
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 7th Jul 2003 04:15
sounds like what your doing is adding the plugin ASM then adding a script extension to it

pretty sweet idea, especially for complex 3D scenes using Ai and such were you don't really want to resort to Shaders

DrakeX
18
Years of Service
User Offline
Joined: 26th Aug 2002
Location:
Posted: 7th Jul 2003 04:24
what the fu...?! a green pikachu with clothes and guns? what are you smoking raven??

"The scripts will be compiled to pure machine code"

i'm a bit unclear on just how that will work.. so will these be EXEs or DLLs or what? because if it's pure machine code it can only run as a DLL or EXE and as an EXE it'd be pretty difficult to mesh the DBP program with the other running prog.. as a DLL it'd be somewhat easier but wouldn't that mean a different DLL for every script? seems kinda odd. just the whole 2 progs running at the same time thing. i guess it'd only update the script when called by the DBP prog.. but how would the script call functions like POSITION OBJECT or whatever? wouldn't that be impossible?

it's a good idea but i'm not sure how useful a "one scripting language fits all" would work out.. what if you needed the script to call your own functions which were written in DBP code?

i'm looking at yooooou!
Shadow Robert
18
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 7th Jul 2003 05:02
DrakeX think of it more like Shaders... only less limited to pure 3D and reliant on Hardware. You can run the parallel to your main program and as they're usually only single instruction sets, they'll run pretty quickly in a single pass

i oftenly use asm in C++ specficially for getting system information around the windows system... so you could make drivers specifically for DBP - or access certain areas of the memory circumventing the OS - or even take data which has been processed by DBP and alter it before its used.

very very useful stuff, as long as you know what your doing

IanM
Retired Moderator
18
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Jul 2003 20:19
DrakeX: The machine code will be generated on-the-fly to a buffer in memory. The code can then be executed simply by fooling the C compiler into calling it as if it were a function.

The code cannot be saved for use later, as the code produced is effectively hard-wired into that area and linked to system/DBPro functions at the time of generation.

Anyway, that's an implementation detail, which mean's that it's my problem to deal with it

Just to show that I can do this, have a look at the assembler thread in the Beta Anouncements, and keep your eyes on the Program Anouncements forum over the next few days


Raven: Yep, except I'll be using some more functions of the assembler that (hopefully) should take advantage of the peephole optimiser that's built into the library
empty
18
Years of Service
User Offline
Joined: 26th Aug 2002
Location: 3 boats down from the candy
Posted: 8th Jul 2003 00:08
Hmmm, interesting concept.

I awoke in a fever. The bedclothes were all soaked in sweat.
She said "You've been having a nightmare and it's not over yet"
Shadow Robert
18
Years of Service
User Offline
Joined: 22nd Sep 2002
Location: Hertfordshire, England
Posted: 8th Jul 2003 00:23
Oooh (^_^) well that should make things more interesting then.
i'd be very interested to see how your going to setup the scripting syntax - a simplified basic or something, cause a realtime processor to asm will be hard if the language is as complex/long-winded as dbp is.

so what functions you'll actually be allowing and setting up for scripting as well the input/output will be pretty important

heartbone
18
Years of Service
User Offline
Joined: 9th Nov 2002
Location:
Posted: 8th Jul 2003 21:52
IanM As a primitive example, do you remember AMAL in AMOS?

I sure do. Good luck with it.

The more you see, the more you know.
The more you know, the more you see.

Login to post a reply

Server time is: 2021-06-10 15:07:37
Your offset time is: 2021-06-10 15:07:37