GPL i think, defo no royalties to be paid!!
Google for it ;)
Printable View
GPL i think, defo no royalties to be paid!!
Google for it ;)
www.lua.org , I believe. It is open source, and several commercial games have already used it.
Z.
You'll be pleased to know im re-writing the TOW Editor in VB.NET
Starting now...
You're in VB.NET too, eh? I love it :)
Well things are going slow seen as im new to .NET and im trying to get my head around all the new things :s
Multithreading and interoperability are the best. Also, unsigned 32- and 64-bit longs are a plus for things like CRC checking :). Gonna be fun :D I'm also just getting my head around it.
heh, havent heard of interoperability before, thats something to do with mixing the .NET components and the old COM ones isnt it ?
ive ordered a book so :)
No, it's that (I believe) you can have a solution with C#.NET, C++.NET, and VB.NET projects in it, all working together (haven't tried this but it's the general word).
Yeah, thats the idea behind .NET. Everything compiles down to the same bytecode, so you can write the various modules in various languages, kind of like Java.Quote:
Originally posted by Sastraxi
No, it's that (I believe) you can have a solution with C#.NET, C++.NET, and VB.NET projects in it, all working together (haven't tried this but it's the general word).
Got Lua to link with the engine last night, but before I go and start to integrate it, I need to write a composite file library. Simply enough, a bunch of files in one file =). Im not making it full fledged, so once the file is created, it wont be able to be modified (ie, im not going to write output functions for this, just input). The final idea is that a map file will contain its heightmap, tilemap, and various scripts all in one file.
Z.
Ok, I think I have the composite file input stuff done... just need to write the file maker, and test it out.
Z.
I can't wait :) The first step to scriptedness! :D
Yes sir! It should be a pretty flexible system... for instance, a file in the composite called "triggers", which gives the names of other files int he composite for map triggers... othe fun stuff... sounds like fun?Quote:
Originally posted by Sastraxi
I can't wait :) The first step to scriptedness! :D
Z.
Sounds like a linux-type construct. I like linux-type constructs :D
Well, after you finish this up it's my turn >=). Today I'll design a GUI; tomorrow I'll take over the world! :)
Oh, it is =). The compiler(im just going to call the composite file maker the compiler from now on =) will read from a config file that controls the file compilation =).Quote:
Originally posted by Sastraxi
Sounds like a linux-type construct. I like linux-type constructs :D
Well, after you finish this up it's my turn >=). Today I'll design a GUI; tomorrow I'll take over the world! :)
Z.
what happened to divinity script thing that we had ages ago ?!
I'm not sure. I was thinking that Lua gave access to your C++ objects and variables and stuff from whatever script language you were making.
No, lua is a language all its own...Quote:
Originally posted by Sastraxi
I'm not sure. I was thinking that Lua gave access to your C++ objects and variables and stuff from whatever script language you were making.
DScript was just too much, for the little I was planning to use it, and it wasnt flexible enough...
Z.
Alright, thats fine! Just think about the good stuff:
- Many already know Lua
- People would be more inclined to learn the language if they could use it elsewhere
- More flexible and proven in the field
So, I suppose this is just as good as we had :) On my end, I got a new, sleek, Logitech MX500. The reason why I bring this up (other than necessary bragging rights ;)), is a question. Can you map button combinations to mice, or assign mouse buttons beyond the 5th in Divinity? If not, it's a feature I'd like to see implemented.
This mouse has 10 buttons: left, right, scroll, scroll up, scroll down, cruise up, cruise down, task switch, back, and forward. Most mice have 5 nowadays: left, right, scroll, scroll up, scroll down. Many have 3 (left, right, middle), and some have 2 (left, right). We should be able to accomodate all types of users.
4 buttons, scroll up and down, for now... I think I can change that to 8 buttons, though.
Z.
Yes, a correction, it is actually only 8 buttons. The cruise up/cruise down buttons are the same as wheelup/down. Since I don't think any mice at this time have more than that many, I think this would be a safe amount to shoot for, okay?
Sure thing =). DInput only supports a max of 8 anyway =).Quote:
Originally posted by Sastraxi
Yes, a correction, it is actually only 8 buttons. The cruise up/cruise down buttons are the same as wheelup/down. Since I don't think any mice at this time have more than that many, I think this would be a safe amount to shoot for, okay?
Z.
Ok, the compiler works, and reading from the resulting composite file works. Right now Im just trying to work out a format for the configuration file =).
Z.
The file format I am using right now looks like this:
the output tag can go any where in the file, while file_title MUST follow input.Code:input: <filename>
file_title: <title>
intput: <filename>
file_title: <title>
....
output: <final file name>
input: <filename>
file_title: <title>
Also thinking about this:
more like a makefile, which is a format that I like =).Code:input:
<filename>
file_title:
<title>
input:
<filename>
...
output:
<filename>
simpler.Code:input:
<filename>
<filename>
<filename>
file_title:
<title>
<title>
<title>
output:
<file>
This last one is really different, but mcuh more like a makefile....
Would allow one config file to build multiple composite files... dunno, you guys pick =).Code:<output name>:
output = <filename>
<title> = <filename>
<title> = <filename>
<title> = <filename>
<output name>:
output = <filename>
<title> = <filename>
....
Z.
I like the one from the 2nd last. However, have you thought of XML configs?
Alright, ill use that one...
I hadnt thought of XML, maybe ill look into it later...
Z.
heh, i been readin all this but i been busy.
i think a better way would be to tag it like
Code:
<title:whatever>
<input:input_file>
<output:output_file>
<title:whatever>
<input:input_file>
<output:output_file>
<title:whatever>
<input:input_file>
<output:output_file>
XML would be more like:Code:<CONFIG>
<INPUT>
<FILE SRC="<filename>" TITLE="whatever">
<FILE SRC="<filename>" TITLE="whatever">
<FILE SRC="<filename>" TITLE="whatever">
</INPUT>
<OUTPUT>
<FILE SRC="<filename>" TITLE="whatever">
</OUTPUT>
</CONFIG>
Im not a huge fan of markup languages like that.... and I shudder to write the parser in pure C =).
Z.
It wasn't a suggestion ;). Plus, I wouldn't have even brought it up had I known you were using pure C!
Yup, Im using original C style file IO for this, so we have calls like c_open, and fc_open, etc. I just decided that I might as well write it in C =).
Got the format you guys want working:
the file_title section must come after the input section, simple because the input section actually counts the files, and allocates memory for them.Code:output:
<output file>
input:
<input file>
<input file>
<input file>
file_title:
<title>
<title>
<title>
Z.
Jorj and I (mostly Jorj though on the idea side) have created a method for textures in ToW. Instead of making textures, tiling them, etc. (ex. the normal stuff), we store data for texture generation (enough data to make real time generation fast). With this texture data ANY texture can be created, allowing extremely easy texture changes.
Plus, with this randomisation (and I've just thought of this now), we can change the "properties" of the terrain at that point. This means during texture info generation (where we generate the data used to make these real-time textures), we can make properties that make it erode differently, make it rich in x minerals, etc. This will help us on all fronts. As a texture artist, I can create templates (ex. ice, snow, grass, dirt, etc) and these will simply be how to transform the data into texture data.
It won't require much memory, because no large textures have to be moved around (only the data). Furthermore, it will allow for users to easily create their own terrain, though the use of templates. It will take less disk space as to make ToW more redistributable.
On the point of distribution, I have a few more ideas and would like to see how well-recieved they would be.
1. Have an internet-based installation, where an installer is downloaded and data is taken from the 'net. This installer can create static installs, which download the requested parts of ToW and package them into a data file. This data file can be given with the installer to allow for machines without internet access to install ToW.
or
2. Create a fully-featured ToW package management program, ala. many Linux distributions. It would download the base packages, keep the ToW directory and registry keys under management, and allow you to download modifications as packages which can be easily installed (and more importantly, easily uninstalled). You could also package up your own modifications easily for distribution. Also, packages could be pre-downloaded and installed from local pkg files (ala. Debian GNU/Linux).
The choice is up to you. In my opinion, the 1st is easier to code but the 2nd is more flexible.
Sounds good to me, Sas, on the texture thing. I like it.
We can use the composite file thing to do the distribution... I would prefer option #1.
Im uploading the compiler... its a console program, so run it in a console window =).
Z.
So this compiles Lua code?
No, this creates the package file type thing. I would then compile a bunch of lua scripts so they are one file, and then I can load them in the engine.Quote:
Originally posted by Sastraxi
So this compiles Lua code?
Z.
Im not sure which of your install options this comes under but remember i made an installer way back that would take a script and then install the files fromt he web. the installer remained so that it was a central hub for donwloading the actual game, mods, mod management, uninstalling and also starting the gamebased upon a tow://game: command.
The texture idea sounds cool. a kind of procedural texture. :)
Ive downloaded the compiler :) havent looked at it yet, not sure what im gonna do with it lol :)
Let me upload the lib and the .h for you, and you can play with the actual file stuff. If youve done C style file IO, itll look familiar.
Z.Code:extern "C" {
#include "compf"
}
int main()
{
C_FILE* cf;
FC_FILE* fcf;
cf = c_open("c:\\some_composite.comp");
fcf = fc_open(cf, "file_in_composite");
char buff[100];
fc_read(buff, 1, 100, fcf);
if(fc_eof(fcf))
{
fc_seek(fcf, 0, SEEK_SET);
}
fc_close(fcf);
c_close(cf);
return 0;
}
And here is the library...
Z.
What's more, it would make caustic textures trivial to create ;).
And about the install, yes, I remembered the multi-purpose launcher. With a bit of modification, it could easily fit in exactly with spec. 1.
And we are scripting =).
Z.
okay, ill revive up the installer some time soon now that my exams are over. i think ill do it in .NET either vb or C#.
i was just thinking that when i create the installer again ill make it so that it checks if they have direct x, if not ill give it an option to download it.
also if its in .net they'll need the runtimes which could be a *****. im thinking of some kind of loader splash coded in C++ that should do some pre install checks.