DATA statements?

[AndyH]

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.

[Kitty Hello]

Phew... Say, when you have this:

Code (glbasic) Select Expand

RESTORE two:
READ number

one:
DATA 1,1,1
two:
DATA 2,2,2What will you get? 1 or 2? How does restore work?

[AndyH]

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).

[PeeJay]

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!

[shaf]

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

[Kitty Hello]

So, if you were able to get an update that includes a DATA command, all complaints would stop immediately, right?
Well, I know you're just baiting me, but have it anyway.

[AndyH]

Thanks Gernot

[Ian Price]

Cheers gernot

[PeeJay]

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! )

[Achim]

Danke Gernot ! Genau DAS hat mir noch gefehlt in GLB

CYA !

[PeeJay]

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

Code (glbasic) Select Expand

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!

[Ian Price]

Some people are never satisfied, are they?

I do agree though, not that it's that big a deal to use multiple "Read" commands.

[Kitty Hello]

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.

[AndyH]

READ now accepts multiple parameters, thanks Gernot!

 

[PeeJay]

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)