Adopt-an-Example-Program proposal

[Hated Moron]

Of all the sources of information about BBC BASIC available (e.g the Beginners' Tutorial, the Help Manual, the Wiki etc.) one of the most important is the set of Example Programs. There are about 160 example programs supplied with BBC BASIC for SDL 2.0!

The value of these is that they show how a real-world application can be constructed, which the documentation of individual keywords and library functions doesn't. You can see not only what something does but how it can be used in a practical context, the whole often being more than the sum of its parts!

But the trouble with the example programs is that they are not extensively documented. They vary greatly in that respect, those which were originally written with the objective of illustrating a particular technique (such as examples/games/cowboy.bbc) having more comprehensive REMarks than some others.

So my proposal is that as many people as possible choose to 'adopt' one (or perhaps more) of the example programs, preferably one that they are particularly interested in, with the object of learning about how it works in great detail. If there are any aspects of the code that they don't understand they can ask here and hopefully somebody - it may be the original author in some cases - will explain it.

This should ultimately result in a body of knowledge that could be invaluable to somebody wanting to write their own program. There could perhaps be a little database set up listing who has 'adopted' which program.

What do you think?

[Flatlander]

Great idea. I would find that very helpful.

[Hated Moron]

So my proposal is that as many people as possible choose to 'adopt' one (or perhaps more) of the example programs

Not a single taker (so far), how disappointing. Was it really such a silly idea?

We badly need to find a way to broaden the knowledge base, so that there are more people who can give advice on some of the more complex uses of BBC BASIC. I hoped that the adopt-an-example-program idea might be a relatively painless and fun way to acquire extra knowledge.

If anybody has a better idea, speak up.

[KenDown]

I'm not sure about the "not a single taker". The challenge inspired me to try what you suggested with the Jigsaw program. I'm working my way through it (and learning a lot in the process) but didn't want to announce what I was doing before I saw whether I could manage it (with regard to both time and skill). Others may be in the same situation - accepting the challenge but unwilling to put their heads above the parapet too soon.

[DDRM]

Agreed. I had a look at the graphics programs, and specifically the D3D ones. I could probably support most D3D8/9 queries, except the shader ones, but as admin here I am probably already "on the list" for most of them!

Best wishes,

D

[KenDown]

I've got up to PROCdropshadow and need a bit of help, please.

Despite the Help file stating that @vdu% variables should be read only, @vdu%!220 is written to, which I suppose is the only way of setting the font to a pixel size as opposed to a point size. (Perhaps this could be included in the Help file?) However why is the pixel size specified as a negative value? The results appear to be the same whether the value is positive or negative.

[Hated Moron]

However why is the pixel size specified as a negative value? The results appear to be the same whether the value is positive or negative.

It's explained at the Wiki here.

It may be that in BBCSDL it makes no difference whether a positive or negative value is specified, but it does (or at least can do) in BB4W.

[KenDown]

Thank you. I said it was a learning experience.

And you are correct; it makes no difference in SDL

Code: Select all

      VDU5
      @vdu%!220=40
      OSCLI("FONT "+CHR$34+@lib$+"DejaVuSans"+CHR$34)
      MOVE100,600:PRINT"KEN"
      @vdu%!220=-40
      OSCLI("FONT "+CHR$34+@lib$+"DejaVuSans"+CHR$34)
      MOVE260,600:PRINT"KEN"

That program produces the word "KEN" at two different sizes (with the -40 being noticeably larger) in BB4W whereas in SDL the output is the same size.

I don't know whether that is something that will change in future versions of SDL?

[Hated Moron]

I don't know whether that is something that will change in future versions of SDL?

They are moving onto SDL3 now (which isn't compatible) so SDL2 has entered a 'maintenance only' stage (currently at version 2.26.2). Consequently I don't think we'll see any more new features or functional changes, just bug fixes. You won't be surprised to learn that I actually like that, I prefer stability to constant change! Anyway it makes it highly unlikely that the behaviour of *FONT will change.

As it is, it's been difficult for me to keep all the various editions of BBCSDL up-to-date. Whilst the Windows and MacOS editions aren't too bad the Android, iOS and web editions are all at SDL 2.0.10 which is quite old now. With SDL2 stabilising I would like to bring everything up to the latest version (except Linux, which is out of my hands) but I know that updating the Android, iOS and (particularly) web editions will be far from straightforward.

Incidentally, as you will no doubt have realised, the jigsaw.bbc program wouldn't be coded like that now. When it was written the imglib library didn't exist, so there are quite a lot of direct SYS calls to SDL2 API functions. Now, the whole thing could probably be rewritten to use imglib, potentially gaining BB4W-compatibility at the same time. But on the basis that if it ain't broke, don't fix it there's no motivation to do that.

[KenDown]

Actually, I hadn't realised that. The brief was to provide explanatory REMs in the program, not to rewrite it - and I wouldn't dare muck about with your code anyway.