Thanks for the feedback.
Yes I realise an external data source will always be slower but will it be noticable?
If you were to use it instead of local variables, it will drag the frame rate into the ground, for sure. Think of the database as a replacement for any text files that you would normally use, but with the power of sql behind it.
As far as speed goes, remember that for every call, there are many floats being loaded, manipulated and translated on both sides of the call (inside Rad, and inside the dll). so there will be a processing overhead, though not
noticeable to the human eye.
Let's use an imaginary game, as see what happens..
1.. You load pre-saved information from the database at initialization, this can be the entire layout of a battle field, the placement and strength values for each soldier. At init, you wont notice the (perhaps) quarter second load of tons of data.
2.. During the game events unfold that you wish to store. eg the base has been overrun, and half your forces wiped out... So as each even happens, a quick update call to the database is unnoticed, because they are small quick calls.
3.. A Major catastrophe hits your forward platoon, and they all get wiped out, and the 200 soldier lose valuable points, and this effects your strategy. A single update call, updates all the soldier's records, even of there are hundreds of them, the call is done in the thread, so you see no change in the frame rate of your game. Just one "sql update" call from you, a blink of and eye.
4.. You finally manage to win the level, and you want to save a lot of new info. so you push through maybe 30-40 sql calls (imaginary) .. and they are not all done together, so it does not effect your framerate, but it does a bit of disk access. It is a level change, so nothing is noticed.
5.. Next level starts, and you load a heap of info..
6.. Using triggers, an sql feature that will update other tables when there is a change made to another, is all internal to the sql engine, and run in a separate thread, you let the database worry about all the work. So you can use complex logic even with your data, without it effecting frame rate
7.. The loop goes on, till you decide to save the game... Again, this is done when the game is idle, and frame rates are not an issue, so you can dump megabytes of save game info in a matter of seconds.
So in a nutshell, sql is perfect, as long as you don't use it to replace in game variables. But you can pump quick data from your variables to the database at any time, and retrieve them in another script, and use it as bridge for complex data collections between scripts. But rather use in-game logic with your own variables, which get their values from the database.
Disk access is always slower than memory access, no matter how fast a database may be.
How fast.. Well with the level of games written with 3d Rad, you wont ever load a meg of data anyway (game data, not meshes, textures, etc.), but it takes about 0.07 seconds to do so in the dll. and about 0.23 seconds to transfer that to 3D Rad through the script interface.. so look at about 0.3 seconds per megabyte.. these are rough figures based on some tests. And string conversion based on these figures is extremely slow (0.07 compared to 0.23).. that's why I once asked Fernando if there was a possibility of using string interfaces to dll's It is however negligible to the human eye.
Edit:
in comparison to using regular variables in a script
I've been thinking about your question...
Because the sql interface needs to extract the data from the string returned from RadSqLite.dll, this data is placed into a list. So you can use the data directly from the list, which is a local variable anyway. So you are
going to use script variables to manage your own data. The sql inteface pushes and pulls text info to the dll; which you need to convert to numbers to use. So you cant really use the database to replace variables, which ever way you look at it.
example:
string [] myresults(); //to store your info from sql query into a SCRIPT VARIABLE LIST
sql = "select soldier,battalion,allegiance,lifepoints from battlesquads where battalion = 'red team';";
doSql();
int count = getRecordcount();
for(int i=0;i<count;i++)
{
getRecord(i); //reads the data from the dll results buffer in dll memory
//always available till the next "select" query
//the data will look something like this: general;red team;player3;120;
//not very usable in this format.
myresults = split((sqlResult,";"); //extracts the data to your list
//Now you get the data out of the list into another list for internal use
soldier[i] = myresults[0]; //1st column from query
//battalion[i] = myresults[1]; // we don't need this data, but used for sql search
allegiance[i] = myresults[2]; //3rd column from query
lifepoints[i] = iStringVal(myresults[3]); //convert to internal numeric (4th col)
}
OR if you use a class
class SOLDIER
{
string rank;
string allegiance;
float lifepoints;
}
SOLDIER [] soldier(200); // .. or dynamic if you prefer
for(int i=0;i<count;i++)
soldier[i].rank = myresults[0];
soldier[i].allegiance = myresults[1];
soldier[i].lifepoints = iStringVal(myresults[3]);
}
As you see above, the data is returned as a single string, the
split function breaks it into a string list, but you have to take it out of the list to your own variables to use it logically in the game.
If you were using a text file, you would also have a little layer of data conversion in between. sql just gives you control of the the data you select.
Hope this all makes more sense.
Author
Topic: RadSqLite Released. (Read 9504 times)
RadSqLite.zip
(298.35 KB - downloaded 417 times.)
Image1.jpg
(13.59 KB, 355x341 - viewed 364 times.)
