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 / Thinking about File I/O operations.

Starshyne Emir
Years of Service
User Offline
Joined: 27th Nov 2016
Location: Porto Alegre, southern Brazil
Posted: 15th Mar 2018 21:14
This is not for advanced users, this is just something I am thinking about, that may be (or may be not) useful to someone.

Well, I was revisiting the file I/O functions that come with DBPro and many things came to my mind.

With FIRST TOKEN$() and NEXT TOKEN$() functions, I can store a string inside a file and then retrieve it and parse it to get different data and store it in different variables, like this:

Supposing that the retrieved string is something like this:

String$ = "$Name$Age$Address"

Name$= FIRST TOKEN$(String$,"$")
age = val(NEXT TOKEN$("$"))
Address$ = NEXT TOKEN("$")

And we took two strings and one integer from a single string. Great, it is kinda useful.

Now, suppose we want to store the same 3 variables back to the file, so we may do:

String$ = "$" + name$ + "$" + str$(age) + "$" + Address$
WRITE STRING file,String$

Right, we can use strings to everything and read or write them easily inside files, and this solves many problems related to how many different data types we can get.

This solved a problem I was facing: UDT arrays can't be saved properly - in fact, they can, but they cannot be loaded back, at least it seems so.

Transforming everything into strings makes UDT arrays saveable this way:

TYPE custom
name as string
age as integer
address as string

dim list(0) as custom

array insert at top list(0)
list().name = "John"
list().age = 35
list().address = "Main Street, 112"

String$ = "$"+list().name + "$" + str$(list().age) + "$" + list().address

Then just write the string and it is saved safe and sound.

And to retrieve the UDT array index, the same thing can accomplished with tokens - is this why I added some "$" in the strings.

READ STRING 1,string$
list().name = first token$(string$,"$")
list().age = val(NEXT TOKEN$("$"))
list().address = NEXT TOKEN$("$")

I know it is kinda silly, but I believe many people found issues trying to make stuff like this.

Now, there is something I need to figure out how to make properly:
RGB colors.

I store them as 3 separated fields - 3 numbers that range from 0 to 255 - like this: $255$255$255 - and then I retrieve all of them and store each one into an integer and then pass them to a dword using the RGB() function.
Is there a better way to store these values?
I tried an hex 0xFFFFFF but I could not rebuilt it after reading, because it comes as a string and the VAL() function simply ignores it. Why?

Color$ = "0xFFFFFF"
color1 = val(STRING$)
CLS color1

It should paint the white color, but it paints black, because color1 = 0, not 0xFFFFFF. Finding out how to transform "0xFFFFFF" into rgb(r,g,b) should save me some space and time.

Another - and this is not related to string parsing:

Since my native language is Portuguese, I need accents everywhere. We use letters like "á" or "ô" all the time.
What intrigues me is:

If a string has these characters, when I print it to the screen at sizes bigger than 30, the characters with accents are replaced by rectangles or corrupted characters. Why?

FOR size = 100 to 19 step 5
PRINT "Teste de acentuação " + str$(size)
NEXT size

With this you can see what I am talking about.

I tried setting the codepage to PTBR, but the result is the same. Strangely enough, a small number of fonts don't show this peculiarity and accents are shown properly regardless of the text size.

Well, that's all for now.

Sharing in here all my small findings and thoughts is what I can do to contribute in here. For advanced users, my stuff is useless, but I bet that some other newbies would find them inspiring.

Thank you. End of transmission.
[size=+2]Forever and one[/size]
DBPro Master
Years of Service
User Offline
Joined: 21st Nov 2007
Location: Austin, TX
Posted: 16th Mar 2018 16:10 Edited at: 16th Mar 2018 16:11
Quote: "It should paint the white color, but it paints black, because color1 = 0, not 0xFFFFFF. Finding out how to transform "0xFFFFFF" into rgb(r,g,b) should save me some space and time."

Matrix1 had the handy function for this:

myDWord = hex to decimal(myHexString$)

Also, be sure to include the alpha channel:


A single player RPG featuring a branching, player driven storyline of meaningful choices and multiple endings alongside challenging active combat and intelligent AI.
Years of Service
User Offline
Joined: 3rd Feb 2007
Location: Canada
Posted: 16th Mar 2018 20:12 Edited at: 16th Mar 2018 21:01
This is good and you can make a functional program doing this but these ways are not the best ways and you will find problems if you try to work with files not made with DBP.

Storing strings your method:

You are using two different characters in the actual file to separate strings. Confusing and messy for someone else writing an app to read the file. Additionally if someone types "$" into a string it will immediately corrupt the file you are saving. You'll end up with false string tokens that derail your loading of the file later. Even if you best case scenario and dodge that bullet you can't use that character in your strings.

Instead a more common and professional method is this.
[StringLength as byte][String1][StringLength as byte][String2][StringLength as byte][String3]

So read a byte into a string length variable. Then use a for loop and build the string.
Don't use Read String / Write String. Use Read Byte / Write Byte.
pseudo code:

Do yourself a big favor and wrap it into a function like this:

This is the way DBO files are packaged as an example. Other file formats do away with string length and simply expect a set string length.

Color$ = "0xFFFFFF" is really 0xFFFFFFFF == 0xAARRGGBB as Ortu mentioned.

You can use the Read DWORD command to load this into a variable properly. No need to convert to or from string. There are some cases where you want to have the user input the value or read the value as a hex but storing it in a file as a string is bad.
Byte = FF
Word = FFFF

Working from memory, this should be correct though.
Derek Darkly
Years of Service
User Offline
Joined: 22nd Sep 2011
Location: Whats Our Vector, Victor?
Posted: 16th Mar 2018 22:43

This is what I love about programming. Everything is either a string or a number, and each can be translated to the other.
For example, without any tutelage, I figured out I could send custom strings as multiplayer data and have the receivers parse the data into useful info on the other end.

There is an infinite simplicity to coding that seems to coincide with the infinite complexity of code than can be produced.
This is why I love this 20-Line chess code by Pasky, although his square colors may be reversed from traditional chess, not sure (it matters much) though.
Send your parents to noisy sprite demo hell... enter the D-Zone

Login to post a reply

Server time is: 2023-12-05 00:09:28
Your offset time is: 2023-12-05 00:09:28