OrbWorks Community Forum

by **shurcooL** on Sun Aug 24, 2003 1:58 am

wow, i was surprised to not find a DBcopy or something of the sort function. ;\ i need this for a level editor for my game.

surely, i can probably write this myself, store the contents of an opened DB to a huge array, then create a new DB and put it all back in there... but i was hoping this would have already been done. :p

if it is, please tell me how i can do it, if not, are u planning to add this, or maybe you have other ideas on how to do it (in a better way).

thanks,
shurcooL

by **shurcooL** on Tue Sep 23, 2003 9:34 pm

please... this is kinda 'pausing' my game's development. any info will be greately appreciated (ie. no, if it's impossible).

meanwhile i'll look into Pilot-DB source code and see how they did it.

thanks in advance.

ps. is there any kind of buffering for reading fields from a DB? say if i need the speed and have to access a field a lot of times... would it be much faster to just copy its value to a local var and use that?

thanks,
shurcooL

by **jstadolnik** on Tue Sep 23, 2003 11:56 pm

Well, the core problem is that the PalmOS does not have a database copy function.

It's possible to do, but it's a pain-in-the-neck, as every record must be copied over individually. It is currently possible to copy a database by loading it into an array in PocketC and then re-dumping it to a new database. It might be hair slow, but I wouldn't expect database copy operations to be a frequent operation.

I'll consider this for some future release, but I think speeding up the Pilot-DB interface (int and float read/writes) as being a much higher priority.

<blockquote id="quote">quote:<hr height="1" noshade id="quote">
ps. is there any kind of buffering for reading fields from a DB? say if i need the speed and have to access a field a lot of times... would it be much faster to just copy its value to a local var and use that?
<hr height="1" noshade id="quote"></blockquote id="quote">

Sure, just load it in into a PocketC array, it will definitely be faster. The technique of keeping your most frequently used data in a fast access area is called "caching".

Joe

The PToolboxLib guy.
http://www.geocities.com/retro_01775/PToolboxLib.htm

by **shurcooL** on Wed Sep 24, 2003 1:11 am

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by jstadolnik
 It is currently possible to copy a database by loading it into an array in PocketC and then re-dumping it to a new database. It might be hair slow, but I wouldn't expect database copy operations to be a frequent operation.
<hr height="1" noshade id="quote"></blockquote id="quote">

that's perfect. for some reason i never thought of this when originally trying to figure it out. i don't remember much now as it's been a exactly month (hehe) since that post... will have to look over the docs again hopefully figure out how to do that (i remember DBopen opens a database, now i'll just have to find a DBsaveas-type function). shouldn't be too hard assuming such a function is in the docs, so don't worry.

<blockquote id="quote">quote:<hr height="1" noshade id="quote"><blockquote id="quote">quote:<hr height="1" noshade id="quote">
ps. is there any kind of buffering for reading fields from a DB? say if i need the speed and have to access a field a lot of times... would it be much faster to just copy its value to a local var and use that?
<hr height="1" noshade id="quote"></blockquote id="quote">

Sure, just load it in into a PocketC array, it will definitely be faster.<hr height="1" noshade id="quote"></blockquote id="quote">

what i meant was just one record, not field... my bad, i forgot all the terms. in other words, just one value (or a record, i guess).

because... i'll quickly explain why i need this.

basically, i have some data that i use a lot all over the place, but it's always at the top of my DB. what it is, is just the number of rooms (1st record) and then follow the locations (offsets from origin) of each one of those rooms. i use those values quite often.

however, each time i create a room, i have to increment my room count, and add another room location to the bottom of the list.

the way i did it at first was have it all (room count, room loctations) in an integer and a PToolboxLib Array(), respectively.

the problem is that every time i do that, i have to update my database. meaning, change the 1st record to the new room count, and insert another room location after the last room (there are many many records following that - the actual tiles).

so... it's kinda pointless to have this int/Array since i have to change the database each time another room is added (or removed, etc.) anyway...

but i *do* use 'em in calculations quite often, so it wouldn't be smart to call DBgetrec (is that the command for getting a value from a DB? i'm talking about that one) so often.

i guess i should keep it the way it is right now - a DB and a separate int/Array. it's a pain keeping 'em in sync though, but i guess it's necessary since i'll be using their value a lot per frame (some frames only, actually, like when the room changes or something).

is that what you would recommend?

<blockquote id="quote">quote:<hr height="1" noshade id="quote">The technique of keeping your most frequently used data in a fast access area is called "caching".<hr height="1" noshade id="quote"></blockquote id="quote">

yeah, i knew that, just forgot the right word.

taking coding breaks is hell. :\ hehe.

ps. damn it, lol, so much for a short post... AGAIN! :[ i'm sorry...

edit: just wanted to say thanks for helping me and putting up w/ all these wordly and not-so-straight-to-the-point posts. 'preciate it very much.

by **jstadolnik** on Wed Sep 24, 2003 12:46 pm

<blockquote id="quote">quote:<hr height="1" noshade id="quote">
is that what you would recommend?

<hr height="1" noshade id="quote"></blockquote id="quote">

I would suggest keeping the first record's data around in an array, and only saving it to the database when your app exits.

Joe

The PToolboxLib guy.
http://www.geocities.com/retro_01775/PToolboxLib.htm

by **shurcooL** on Wed Sep 24, 2003 6:15 pm

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by jstadolnik
 I would suggest keeping the first record's data around in an array, and only saving it to the database when your app exits.<hr height="1" noshade id="quote"></blockquote id="quote">

i'll assume u mean both the 1st integer (room count) and the room locations following (Array() of nRoomCount size).

now... that gives me an idea. perhaps i should also keep the rest of the DB, the actual tiles, in an Array() too? ie. load it all up on start up, work w/ the map in memory (instead of DB) and then save the changes or not, depending on what the user wants on app exit...

however, each room is 24*19 (456) tiles, each one is a record. there are 3 fields: two integers, and a string (for misc stuff: such as level name in 1st rec, and scripting stuff for tiles)... so would that make the Array too big? a big map would have at least like 10 rooms... meaning an array of 4560 elements * 2ints+1string.

what do u think?

because i think getting (when drawing the room) and changing (in the level editor) the value for each tile from the DB is a bottleneck in the main loop (be it the game or the level editor loop).

once again, sorry for bugging you so much. and thanks for help.

thanks,
shurcooL

by **shurcooL** on Wed Sep 24, 2003 10:01 pm

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by jstadolnik
 Well, the core problem is that the PalmOS does not have a database copy function.<hr height="1" noshade id="quote"></blockquote id="quote">isn't that like Windows not having a copy file feature? [:0]

*never mind - edited out*

edit: on second thought, i don't really need this if u answer "yes, use Array() it will handle that much data well" to my previous post, so please concentrate on that one first. thanks.

edit2: never mind... i totally misread what you said, now i feel stupid. all i need now is an answer to my previous post.

thanks,
shurcooL

by **jstadolnik** on Thu Sep 25, 2003 2:46 am

Using a big Ol' array might work, however having to save the whole thing when the app exits which could take a while.

Also, for what you are doing I don't think pilot-db databases are a good fit. For one thing, if any user of your app has the Pilot-DB palm app installed, they will see all these bizzare databases related to your game and have no clue what do with them. Second you can likely come up with a more customized database scheme using PocketC's built-in database functions (one room per record, where each record is filled with an array of data describing each tile or something).

The real advantage of Pilot-DB is that there are desktop tools which interface with them, as well a rather powerful PDA based app to create, view, and modify them.

Also, each record in a Pilot-DB database has a fixed number of items in it, which can be quite limiting storing a dungeon/maze type structure. Finally, each Pilot-DB record has a header which indicates where in the record each item it contains is located. For what you are doing this header is taking up unnessary space.

Joe

The PToolboxLib guy.
http://www.geocities.com/retro_01775/PToolboxLib.htm

by **shurcooL** on Thu Sep 25, 2003 7:54 pm

oh, ok, well, thanks a lot for the advice.

[offtopic] i never really looked at (or tried to use) PocketC's native DB functions because i've always though of PToolboxLib as a replacement for PocketC's built-in stuff. reason being is that it's very well documented (:)) and i thought that whatever both PocketC and PToolboxLib can do, PToolboxLib can do it better (and faster).

when i tried to use the built-in graphics commands i got nowhere, so maybe that's why. i have no idea when to use functions from one or the other, because it never really says anywhere (ideally, this should be covered in your docs) how they work regarding each other. iirc, u only mention that graph_on() must be called before anything else, and that's pretty much all. there isn't much left, but still... things like drawnative(int bNative), pushdraw() and popdraw(), etc. - do i need to use 'em when using PToolboxLib's gfx methods? [/offtopic]

anyway, back to what i'm trying to do (dungeon/maze structure is an accurate description). i'll check out the built-in DB commands and see what i can do. according to you, it's possible to keep an entire room in one record - which is great. in fact, it'd be best for me if i could just purely write to a file, but since from what i've heard about Palm OS <6, u can't... only way to store things is through databases. and i'll have to assume that built-in DB functions are just as slow as Pocket-DB ones. meaning i'll give a big Array() a try. oh, and can i have a non-DB-design (ie. same colums for each record; therefore same number of vars and same types of vars throughout the whole DB) using PocketC's built-in DB functions? that would rock.

now, about cluttering the users system w/ Pocket-DBs... i thought u could append *.pdbs to your *.prc, ie. using par (http://www.djw.org/product/palm/par/). or am i wrong? or you can change the DBs creator id to that of the .prc, in order to have Palm 'group' the .prc and all the .pdbs together? please correct me if i'm wrong.

and, as always, thank you very much for your help. :oops:

thanks,
shurcooL

by **jstadolnik** on Thu Sep 25, 2003 8:21 pm

<blockquote id="quote">quote:<hr height="1" noshade id="quote">
when i tried to use the built-in graphics commands i got nowhere, so maybe that's why. i have no idea when to use functions from one or the other, because it never really says anywhere (ideally, this should be covered in your docs) how they work regarding each other. iirc, u only mention that graph_on() must be called before anything else, and that's pretty much all. there isn't much left, but still... things like drawnative(int bNative), pushdraw() and popdraw(), etc. - do i need to use 'em when using PToolboxLib's gfx methods?
<hr height="1" noshade id="quote"></blockquote id="quote">

There's actually a small overhead assocated with native library access, so an equivalent PocketC function is likely faster then a PToolbox one (but not by much). Though with the exception of the new color, buffer, and bitmap functions, there is very little overlap in functions between PocketC and the PToolboxLib. There are still differences though even in these similiar functions. For example, the PToolbox allows for grayscale support on <OS3.5 devices, lock&load bitmaps draw faster, you can use SetPallet to customize colors, CopyRect has zoom and rotate capabilites, etc.

drawnative() and SetScale() are near equivalent, though SetScale offers a little more.

pushdraw and popdraw are compatible with the PToolboxLib.

<blockquote id="quote">quote:<hr height="1" noshade id="quote">
now, about cluttering the users system w/ Pocket-DBs... i thought u could append *.pdbs to your *.prc, ie. using par (http://www.djw.org/product/palm/par/). or am i wrong? or you can change the DBs creator id to that of the .prc, in order to have Palm 'group' the .prc and all the .pdbs together? please correct me if i'm wrong.
<hr height="1" noshade id="quote"></blockquote id="quote">

.pdb files cannot be appended to .prc files (well, they actually can be but you wouldn't be able to acces the data from PocketC because it only allows for .pdb access). If you change the creator ID and/or type of a pilot-DB database, the PToolboxLib will no longer be able to access it with it's database functions. Essentially, changing the creator ID makes it not a Pilot-DB database anymore.

Joe

The PToolboxLib guy.
http://www.geocities.com/retro_01775/PToolboxLib.htm

by **shurcooL** on Thu Sep 25, 2003 9:19 pm

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by jstadolnik
 .pdb files cannot be appended to .prc files (well, they actually can be but you wouldn't be able to acces the data from PocketC because it only allows for .pdb access). If you change the creator ID and/or type of a pilot-DB database, the PToolboxLib will no longer be able to access it with it's database functions. Essentially, changing the creator ID makes it not a Pilot-DB database anymore.<hr height="1" noshade id="quote"></blockquote id="quote">

all right, but can i do either one of those with a PocketC-created DB (i think it has a special creator id too, because it shows up in that menu on PocketC main screen)?

<blockquote id="quote">quote:<hr height="1" noshade id="quote">oh, and can i have a non-DB-design (ie. same colums for each record; therefore same number of vars and same types of vars throughout the whole DB) using PocketC's built-in DB functions? that would rock. ie. how is it (design?) different from Pilot-DBs, seeing how you recommened for me to use these DBs...<hr height="1" noshade id="quote"></blockquote id="quote">

so can i? [:p]

thanks,
shurcooL

by **jstadolnik** on Thu Sep 25, 2003 10:15 pm

<blockquote id="quote">quote:<hr height="1" noshade id="quote">
all right, but can i do either one of those with a PocketC-created DB (i think it has a special creator id too, because it shows up in that menu on PocketC main screen)?
<hr height="1" noshade id="quote"></blockquote id="quote">

Those are applet .pdb files. You probably want to release your app as a .prc file.

<blockquote id="quote">quote:<hr height="1" noshade id="quote">
so can i?
<hr height="1" noshade id="quote"></blockquote id="quote">

PocketC provides a generic database interface. It's up to you do define your database's internal record structure. Pilot-DB databases on the other hand have a specific record format structure. You can actually use PocketC's database functions to create Pilot-DB databases, but doing slow is terribly slow. The PToolboxLib handles all the Pilot-DB's special formating natively for you so it's faster, but the fixed formating makes these special purpose databases at best.

Joe

The PToolboxLib guy.
http://www.geocities.com/retro_01775/PToolboxLib.htm

by **shurcooL** on Fri Sep 26, 2003 12:57 am

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by jstadolnik
 Those are applet .pdb files. You probably want to release your app as a .prc file.<hr height="1" noshade id="quote"></blockquote id="quote">

i'm not quite sure what u mean by that...

are you saying that there's no way to append a .pdb database to a .prc executable? because i know for sure u can add executable .prcs to a .prc (right? isn't that what you do when embedding PToolboxLib into a .prc?), as well as font, bitmap and resource databases (which are saved in .prc format for some reason).

when using an app that came with my Clie to transfer files between the pda and a memory stick, i see lots of applications that have databases sort of 'attached' to them. they're not in the actual .prc file... meaning, when i installed that app, i had to manually install a .prc file and some .pdb files. but when i see them using that app, it's all 'grouped' together. i thought i could do that by setting a .pdbs creator id to that of the .prc?

i'm sorry if i'm asking the same thing again, but i don't quite get this palm file system and its capabilities. if there's a page which explains this in detail, please do point me toward it.

thanks.

thanks,
shurcooL

by **jstadolnik** on Fri Sep 26, 2003 1:23 am

<blockquote id="quote">quote:<hr height="1" noshade id="quote">
i'm not quite sure what u mean by that...

are you saying that there's no way to append a .pdb database to a .prc executable? because i know for sure u can add executable .prcs to a .prc (right? isn't that what you do when embedding PToolboxLib into a .prc?), as well as font, bitmap and resource databases (which are saved in .prc format for some reason).
<hr height="1" noshade id="quote"></blockquote id="quote">

It's possible to merge the contents of two .prc files together, but a .prc (resource database) and .pdb (record database) file cannot be merged.

<blockquote id="quote">quote:<hr height="1" noshade id="quote">
when using an app that came with my Clie to transfer files between the pda and a memory stick, i see lots of applications that have databases sort of 'attached' to them. they're not in the actual .prc file... meaning, when i installed that app, i had to manually install a .prc file and some .pdb files. but when i see them using that app, it's all 'grouped' together. i thought i could do that by setting a .pdbs creator id to that of the .prc?
<hr height="1" noshade id="quote"></blockquote id="quote">

Unless you use a special file utility (zLauncher, powerrun, flyzip), .pdb files don't normally follow .prc files (with the same CID) when you copy them to VSF memory. However, if you delete a .prc file all other .pdb files which share the same CID as the .prc will also get deleted.

Joe

The PToolboxLib guy.
http://www.geocities.com/retro_01775/PToolboxLib.htm

by **shurcooL** on Fri Sep 26, 2003 10:02 am

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Originally posted by jstadolnik
 It's possible to merge the contents of two .prc files together, but a .prc (resource database) and .pdb (record database) file cannot be merged.
<hr height="1" noshade id="quote"></blockquote id="quote">

ah, ok, that clears it up. thanks.

<blockquote id="quote">quote:<hr height="1" noshade id="quote">Unless you use a special file utility (zLauncher, powerrun, flyzip), .pdb files don't normally follow .prc files (with the same CID) when you copy them to VSF memory. However, if you delete a .prc file all other .pdb files which share the same CID as the .prc will also get deleted.
<hr height="1" noshade id="quote"></blockquote id="quote">

yeah, that's what i figured, but it's still better than nothing. also, you're right, the standard built-in Palm launcher doesn't do that (i still see many dbs and prcs separately), but since most start w/ the same letters it's easy to see what db belongs to what app. but that's ok, because there's no way around that unless i were to hard-code all my levels in my code, which is so totally not an option.

now i'll just have to look at some examples on using PocketC's db functions and see what i can get out of them. so i guess i'm good to go them, thank you for all the help, and You will definitely get a big shoutout in the credits.

thanks,
shurcooL

OrbWorks Community Forum

Copying DBs

Who is online