There's no DATA statement in GLB is there? (unless I've missed them).
Would be handy to have them so I can embed some data in the code and load/create TYPE'd arrays without having to store in an external file and load it in.
RESTORE -label-
READ a|a$[ , ... ]
DATA constant|constant$[ , ... ]
It's missing (to me too).
I use external files instead and READBYTE, READLONG etc...
Yes, I would prefer to not use file all of the time. Sometimes yes, but sometimes it would be real nice to keep it simple (stupid as the saying goes ;)). You can initialise arrays with a list of values, so this is a similar thing.
This is the kind of thing I'd like to be able to do (any chance of an update Gernot ? ;)):
TYPE tWibble
a;b;c$
ENDTYPE
DIM test[] AS tWibble
RESTORE mylist
LOCAL t as tWibble
FOR i=1 to 3
READ t.a, t.b, t.c$
DIMPUSH test[], t
NEXT
// YAY- I now I have an array with three tWibbles defined with values.
mylist:
DATA 0,0,"Hello"
DATA 0,10,"World"
DATA 50,50,"Bye"* note I may have made some typo's as I've not got GLB here at work to check.
Actually on the subject of reading from files, I've got a routine that loads in my language txt file. I read a line at a time into a string, split it and create an array element. I've noticed that this takes a long time, I need to look through when I have time to see what is slowing it down. I'm working on the level editor of my game at the moment, and I'll be using the read/write BYTE commands when it comes to saving and loading the levels so I'll probably be able to see what might be causing my slowdown then.
See DIMDATA. It's much faster than the READ commands from other BASICs, but it's a tiny bit more awkward.
Good for simple arrays, but doesn't really allow you to do the same as a READ with DATA statements which you can choose how to load+use.
I have to admit, I'm with Andy on this one - being able to hardcode data into a program is something I have used quite a bit in the past, and does seem quite a big omission in the language
"Data", use files and read em into arrays. That way no runtime memory is wasted by storing the information twice... once in the actual DATA statement, once in the actual array...
Files are not ideal but neither are DATA statements both have their plus and minuses but even if we had DATA statements, Id still stick to files because its a superior method IMHO.
I'd still use files where they are necessary. However I have some scenarios where it's just over kill.
For example, I have a type on my title screen sequence where I have four characters. Each character does something and I need some values stored in the type for each one. When the title code starts I create a type array for them, and then manually load their starting values (each is different). A simple DATA statement would make this a little more elegant and easier to read. Less messy code.
I also have a level editor. I've some hotspots for mouse click and controls. I'm loading these up into an array of my custom type and have to specify each hot spot. While I could put this into a file its a little bit of an overkill to do so.
Having the DATA statements will be a useful feature to have for those that want to use them. If you don't want to use them then just don't :) But without them you've not got much choice. I think they would be a welcome addition to GLBasic.
Hard coding configuration data into the game source makes editing that little bit harder IMHO, requiring a recompile each time as opposed to a little config edit. This kind of flexability can be a godsend for third party users.
Also, its a bit like GOTO, if its there there's a temptation to use it... lazyness may say just stick it in a DATA statements as opposed to more efficiently store it in an external file... or maybe that's just a reflection on my laziness! :P
I like the current command set and I'm generally opposed (Although its no killer if its added) DATA being added. Why? Well, I initially did not like DATA being missing but after using DIMDATA, INI file routines, text file and various typed files IO routines... I realise the current command set FORCES neater coding styles, DATA and code should be seperate... again though, this could just be me! ;)
One thing though I do think typed records in files, would be a valuable addition.
I don't understand the fascination to hold GLB where it is? If GLB didn't move forward it would still be DiNGS. GLB is great, but it's got plenty of room to grow.
DATA is not a dirty word like GOTO (which funnily enough I see GLB supports) ;) You don't need or see a use for READ/DATA then don't use it.
I don't need some data to be external and exposed to users to change. Just looking for a simple method of doing a simple thing. The reasons above are still valid in my mind.
Hmm... And then what data types? like this?
RESTORE test
READ a
READ b$
READ c
test:
DATA 5, "phoo", 7
Yes, that'd do it. Similarly types or a single array element (fred.a or foo[4]) could be used as the destination although I'd imagine this is implied.
TYPE tPhooHolder
a
b$
c
ENDTYPE
GLOBAL MyPhoo AS tPhooHolder
RESTORE test
READ MyPhoo.a
READ MyPhoo.b$
READ MyPhoo.c
test:
DATA 5, "phoo", 7
Quote from: AndyHI don't understand the fascination to hold GLB where it is? If GLB didn't move forward it would still be DiNGS. GLB is great, but it's got plenty of room to grow.
I'm not trying to hold GLB where it is for the sake of it, I do believe, in this instance, that the addition of "DATA" would not be a positive one for the reasons I've already stated.
It would not be a 'disaster' for me personally for "DATA" to be added to the command set but I felt I'd express my opinion on it, like you say Andy I could still ignore it if it was added, just like GOTO.
I personally feel that if it helps users to have a command from days of yore, then why not include it?
You don't have to use it if you don't want to, but you never know when it might come in handy and it can make it easier for new GLB users to make the switch from another language.
Data satements can be incredibly useful, although for the most part I rarely use them, preferring arrays and external .dat files for holding my information.
I also don't think that by not having data statements that GLB is being held back though - there are alternatives and you can live without them, but their use is still valid and pretty much every language I've ever toyed with still uses them. They are yet another tool for developers.
Data statements? Wow, that's ... well it's been a while since I saw them last :-) But they can come in handy for someone converting old games, they are used a lot for some reason. I myself haven't used them since I learned what arrays are. If it's fast done then by all means add it but don't put too much time into it, there are probably other things that will bring GL Basic forward with bigger steps.
I wouldn't want GLB to become bloated, but equally on the other hand I would want to worry about adding new features because of that.
I'm using arrays of types and also memory banks (from the inline code Gernot created) to store medium to large chunks of data and these are fed from files. I just see a use for DATA statements for set up of smaller blocks of data, eg: the hotspots or initialisation. If a user finds other uses for it (wether right or wrong) that's up to them but at least it is there. What they produce at the end of the day is all that really matters, not how they did it :) It's not as if most GLB users have to worry about working in an Enterprise environment you're taking into account teams and compliance of standards.
Phew... Say, when you have this:
RESTORE two:
READ number
one:
DATA 1,1,1
two:
DATA 2,2,2What will you get? 1 or 2? How does restore work?
You get "2"
Restore sets a pointer to the next nearest Data statement to the supplied label. Read will read the next DATA item and move the pointer to the next (might be in the data statement or might be another data statement further down).
The one thing I dreaded when I converted my Manic Miner code over from Blitz to GL was that I could not use Data statements - all the level info was hard coded - type elements, variable values, strings - all sorts in there, and it was a major pain in the butt converting it all to an external file - even more so with the fact that external files can't hold -ve values (where you don't have that limitation in a DATA statement.) This was further compounded with the fact that in order to hide the level data, and incorporate it into the shoebox, I then had to convert it again into a binary bitmap.
Okay, I agree, most of the time an external file is preferable, but there are occassions when it isn't, trust me! ;)
I had to do this months ago when I attempted to convert an old Basic Program from the mid 1980's to work in GLbasic. It was a lot of work to get the arrays formatted properly but eventually I got everything straightened out.
Then I decided that the code was too much spagetti and am attempting to write the code to be more modular.
Shaf
So, if you were able to get an update that includes a DATA command, all complaints would stop immediately, right? :D
Well, I know you're just baiting me, but have it anyway.
Thanks Gernot :)
Cheers gernot :)
An excellent and welcome addition - many thanks for this (except for the fact that now I want to change all my code back to using the more efficient DATA statements! :D)
Danke Gernot ! Genau DAS hat mir noch gefehlt in GLB :)
CYA !
Woohoo, all works great - Manic Miner now has it's level data in DATA statements where it belongs :)
The only comment I would make is about the possibility of multiple variables under one READ command - thus
RESTORE dat
READ a,b,c
STARTDATA dat:
DATA 1,2,3
ENDDATAbut that is something very minor. Thanks again Gernot - you're a star!
Some people are never satisfied, are they? :P
I do agree though, not that it's that big a deal to use multiple "Read" commands.
Oh boy. I've never used DATA in my whole life. Please forgive me for being stupid.
Update soon. READ with one variable only makes no sense.
READ now accepts multiple parameters, thanks Gernot!
(http://www.microscopy-uk.org.uk/mag/imgdec05/LetterA.jpg) (http://www.tsl.state.tx.us/ld/projects/trc/2006/manual/illos/star.jpg)
Ooops, something has gone wrong - compiling Manic Miner with the new version, even without changing to multiple parameters on one READ command, throws up a series of errors (nothing specific or useful in bug hunting though)
Same here... this error for me, but makes no sense (not changed my code):
*** Configuration: WIN32 ***
precompiling:
GPC - GLBasic Precompiler V.2008.072 - 3D, NET
Wordcount:1159 commands
compiling:
C:\Users\AndyH\AppData\Local\Temp\glbasic\gpc_temp0.cpp: In function `DGInt __GLBASIC__::LoadLanguageStrings()':
C:\Users\AndyH\AppData\Local\Temp\glbasic\gpc_temp0.cpp:1286: error: `LINE' was not declared in this scope
*** FATAL ERROR - Please post this output in the forum
_______________________________________
*** Finished ***
Time: 6.1 sec
Build: 0 succeeded
*** 1 FAILED ***Also notice two new fields in the project settings cmp and lnk which I'd not seen before. What are they for?
Reverted back to build 198 and it runs fine (yay for the backups!).
AH!!!! You have to define a LOCAL for the variables you're reading. I'll fix that!
Oooh, can this be changed? After all, it is entirely possible you want to read a value into a GLOBAL variable .....
It's already fixed. Get an update, sleepy head! ;)
Thanks Gernot :)
Thanks hugely - works a treat now :)
Can't thank you for how much easier it is to set up some simple tables of data now. Thanks for this.
Could I possibly ask one more tiny enhancement...
Could you allow an offset to added to the RESTORE label command. eg:
RESTORE scoreValueList // this points the READ at the start
READ val // returns 1
RESTORE scoreValueList + 5 // this skips ahead 5 DATA values
READ val // returns 6
STARTDATA scoreValueList:
DATA 1,2,3,4,5,6,7,8,9
ENDDATA
If we're going for non-standard enhancements, being able to resore to a variable string would be incredibly useful - for example:LOCAL d$="LEVEL"+lev
RESTORE d$
STARTDATA LEVEL1:
DATA 1,2,3
ENDDATA
STARTDATA LEVEL2:
DATA 3,4,5
ENDDATA
STARTDATA LEVEL3:
DATA 6,7,8
ENDDATA
etc
Good idea Peejay. It's not actually a totally non-standard way as I used a BASIC in the past where you could do this. I guess you could do your level trick without the extra labels using the offset,
eg:
GLOBAL offset = (level-1) * sizeOfLevel
RESTORE LEVELS + offset
Hey Gernot, if RESTORE label+offset is too wierd for the language, something like this could work also : RESTORETO label, offset
You could do it with the offset in the example I gave, but only if all the levels held the same amount of data. Since I have a habit of having a continual loop until reaching a termination flag, it wouldn't then work - for example:
LOCAL d$="LEVEL"+lev
RESTORE d$
WHILE TRUE
READ b
IF b<>-1
//do something
ELSE
BREAK
ENDIF
WEND
STARTDATA LEVEL1:
DATA 1,2,3,-1
ENDDATA
STARTDATA LEVEL2:
DATA 3,4,5,-1
ENDDATA
STARTDATA LEVEL3:
DATA 6,7,8,9,10,11,12,-1
ENDDATA
etc
True, and I still think your suggestion is a very good idea. Just thinking about other ways too. I guess you could always have another Data block to index your start positions, or an array, but I guess that's just making more GLB runtime code that could perhaps be done simpler if GLB natively supported what you wanted anyway.
When I tried to use Data statements at the "StartData label:" I get a syntax error. It changes to the command colour after typing it but to white after compiling it.
How about:
STARTDATA common:
data 1,2,3
ENDDATA
STARTDATA special:
DATA 1,2,3
ENDDATA
RESTORE common
ReadCommon()
RESTORE special
ReadSpecial()?Or make your own "SkipData: n" function.
The only problem with making a skip data function would be the need to sequentially read through n number of data statements before you could get to the right point.
I was thinking a RESTORETO command would allow me to treat the DATA as static memory, so I could grab data from any point within (from the offset) quickly without the need to load the DATA into another format (membanks or array) in order to do that.
Help !
I have no idea why, but I`m getting an error when I set up my data statement.
STARTDATA dataitems:
DATA 1,"PLAY ",-1,0,0
DATA 1,"OPTIONS ", 2,0,0
DATA 1,"QUIT ",-2,0,0
DATA 2,"LEVEL ", 3,0,0
DATA 2,"VOLUME ", 4,0,0
DATA 2,"BACKDROP", 5,0,0
DATA 2,"BACK ", 1,0,0
DATA 3,"EASY ", 2,1,0
DATA 3,"MEDIUM ", 2,1,1
DATA 3 "HARD ", 2,1,2
DATA 4,"100% ", 2,2,100
DATA 4," 75% ", 2,2,75
DATA 4," 50% ", 2,2,50
DATA 4," 25% ", 2,2,25
DATA 4," 0% ", 2,2,0
DATA 5,"ON ", 2,3,0
DATA 5,"OFF ", 2,3,1
ENDDATA
Thats the code, but it just throws up a syntax error at the STARTDATA statement, and for the life of me I cant see why ;( Am I missing something trivial ?
And the error message is? :-)
(944) error : syntax error
Try this :
STARTDATA dataitems:
DATA 1,"PLAY ",-1,0,0
DATA 1,"OPTIONS ", 2,0,0
DATA 1,"QUIT ",-2,0,0
DATA 2,"LEVEL ", 3,0,0
DATA 2,"VOLUME ", 4,0,0
DATA 2,"BACKDROP", 5,0,0
DATA 2,"BACK ", 1,0,0
DATA 3,"EASY ", 2,1,0
DATA 3,"MEDIUM ", 2,1,1
DATA 3, "HARD ", 2,1,2
DATA 4,"100% ", 2,2,100
DATA 4," 75% ", 2,2,75
DATA 4," 50% ", 2,2,50
DATA 4," 25% ", 2,2,25
DATA 4," 0% ", 2,2,0
DATA 5,"ON ", 2,3,0
DATA 5,"OFF ", 2,3,1
ENDDATA
You had missed a comma :)
MrTAToad, many thanks. Thats the badger. Sometimes you just need a fresh pair of eyes looking at things to notice the blindingly obvious ! Since it was throwing up the error at the STARTDATA statement I never looked any further down my list to see what was wrong !
Oh, the old good days, copying endless lists of datas from magazines on the c64, with "out of data" when you miss a comma, or change it with a dot... So hard to find...
:)