BBC BASIC
General >> Support and Promote >> Example program challenge
http://bbcbasic.conforums.com/index.cgi?board=support&action=display&num=1481453738

Example program challenge
Post by Richard Russell on Dec 11th, 2016, 09:55am

The only example programs, supplied with BB4W, that make any significant use of structures do so in the context of calling the Windows API. Whilst this is indeed a valuable reason for structures to exist, it doesn't give the user any idea of how structures can be useful in ways that are independent of the Operating System.

So I would like to set the assembled user-base a challenge of writing an example program which illustrates the usefulness of structures other than in an API context. The program should:
My intention will be to distribute the 'winning' program with future releases of BB4W and BBCSDL, or even multiple submissions if they are good enough.

Get your thinking caps on! If you have an existing program which you think fits the bill you can of course submit that.

Richard.

Re: Example program challenge
Post by Richard Russell on Jan 14th, 2017, 8:52pm

Another area in which the current set of example programs leaves something to be desired is GAMES (probably reflecting my own relative lack of interest in that genre). Only four are supplied: ANIMAL, HANOI, RHEOLISM and SUDOKU - and HANOI isn't really a game it its current form.

So I would be very interested in supplementing this set with some more games, so long as they satisfy the criteria for example programs as outlined previously. That is, they should:That last point is particularly important, because I would want to include any new example programs with all editions of BBCSDL.

If anybody has, or fancies writing, a program that they think might be suitable please reply to this thread.

Richard.
Re: Example program challenge
Post by michael on Jan 15th, 2017, 01:51am

With 714 views since December 27, 2016 (just on BBC4W forum), RETROLIB 10 does have the interests of many. I have publicly offered it to everyone . I have expanded it further into version 12.( not seen here)

It has some premade objects that can be customized and works extensively with palettes and shading and graphics controls. It also has special input tools.

It is still being improved, but does provide some help for those who might want to slap stuff together fast.

I can modify it into 2 versions. One for BBC4W (which is what it works on..), and the reduced object assist version.

There is some testing to be done for the colour checking tools on BBCSDL.

I offer it once again.



Re: Example program challenge
Post by Richard Russell on Jan 15th, 2017, 09:49am

on Jan 15th, 2017, 01:51am, michael wrote:
I offer it once again.

Thanks for the offer, but I am not currently looking for libraries. Potential new users, evaluating BBC BASIC (e.g. using the trial version), may form a view on its capabilities and strengths by running the supplied example programs, which is why I am keen that they should give a good impression. Libraries are 'invisible' to such people so aren't really relevant to that concern.

The new BOUNCE program kindly provided by Howard (see the thread at groups.io) filled a gap in the coverage of BBC BASIC's features, in respect of structure arrays. I have also added a couple of new programs of my own recently, such as POLYFIT and SNOWSCENE. Looking across the set of examples as a whole it is apparent that the GAMES directory is very sparse compared with GENERAL and GRAPHICS.

I know that a lot of people, like me, are not very interested in games but nevertheless they can be colourful, dynamic, and - hopefully - a good demonstration of the capabilities of the language across the board. Also, many of the most spectacular programs ever written in BBC BASIC have been games (although too large and, probably, non-portable to be of direct relevance).

Richard.
Re: Example program challenge
Post by hellomike on Jan 16th, 2017, 2:52pm

Hi Richard,

Yesterday I added the BB4W version for the 2048 game Rosetta task.
See: http://rosettacode.org/wiki/2048

It's a very rudiment implementation. Just enough to meet the requirements of the task.
For example, I didn't adopt the recommended naming conventions, used local variables, added any comments or provided help for the user.

If you agree with the quality level, I could upgrade with a visually more attractive interface, add comments etc and then it would be an honor to donate it as an example game.

Just let me know.

Regards,

Mike
Re: Example program challenge
Post by Richard Russell on Jan 16th, 2017, 8:50pm

on Jan 16th, 2017, 2:52pm, hellomike wrote:
If you agree with the quality level, I could upgrade with a visually more attractive interface, add comments etc

You only need to look at the existing example programs to appreciate that the code quality is highly variable: many of them are poor from that point of view. So I wouldn't worry too much about that aspect, at least not as a priority.

The challenge is to give a good first impression, and it's hard to judge what that program could become if given a graphical interface. It's described as a "sliding block puzzle" so if it could be made photo-realistic (or close) it could well be the sort of thing I am looking for. It's perfectly acceptable for the program to need separate bitmap files if necessary.

David Marples (of the BB4W forum) has offered a vaguely similar program involving draggable 'gemstones', so it could be that they have too much in common for me to want to use both. I don't know whether some liaison might be desirable.

Richard.
Re: Example program challenge
Post by michael on Jan 17th, 2017, 04:34am

I could offer Volatile Vases game I recently made, which has code based board and vase design. I could improve the help screen and make it gather automatically after a swap.

Here is a link to the code and bmp files it created:

https://1drv.ms/f/s!AmYwmTjbmULXlDz300rujXJ6xSfI

It works on BBC4W. It would require modifications to make it work on BBCSDL (mainly replacing TINT type tracking with arrays) and I may need to use a diffrent technique for the sprites. Maybe redraws.
Re: Example program challenge
Post by Richard Russell on Jan 17th, 2017, 08:59am

on Jan 17th, 2017, 04:34am, michael wrote:
It would require modifications to make it work on BBCSDL (mainly replacing TINT type tracking with arrays)

That's a valuable reminder that TINT (and POINT) are very slow in BBCSDL (not my fault - all to do with the way OpenGL and SDL work), so should be avoided whenever possible.

Richard.

Re: Example program challenge
Post by hellomike on Jan 17th, 2017, 09:59am

Quote:
The challenge is to give a good first impression, and it's hard to judge what that program could become if given a graphical interface.

Well, I have something like this in mind: https://gabrielecirulli.github.io/2048/

which is what the game generally looks like. See also: https://play.google.com/store/search?q=2048

Note that I'm not that keen to include animated sliding though. Would be hard, I assume and would defy the purpose of serving as an example for newbie's in my opinion.

So if including such an implementation has a chance, let me know and then I start coding.

Mike
Re: Example program challenge
Post by Richard Russell on Jan 17th, 2017, 2:22pm

on Jan 17th, 2017, 09:59am, hellomike wrote:
Note that I'm not that keen to include animated sliding though. Would be hard, I assume and would defy the purpose of serving as an example for newbie's in my opinion.

The supplied programs have multiple purposes, only one of which is to serve as "an example for newbies". If that was their primary purpose we would not have mandel.bbc or teapot.bbc or sheet.bbc, none of which can by any stretch of the imagination be described as the sort of program that could be written or understood by a 'newby'!

Rather what I am looking for is a program or programs with the 'wow factor'. Elegance and simplicity are desirable, of course, but not at the expense of the impression they give of the capabilities and power of BBC BASIC.

In any case I wouldn't agree that animating a sliding block is hard:

Code:
      MODE 20 : VDU 5      w% = 240 : h% = 80      GCOL 11 : RECTANGLE FILL 0, 0, w%, h%      GCOL 0 : MOVE 16,60 : PRINT "Sliding block"      bx% = 0 : by% = 0      drag% = FALSE      MOUSE ox%, oy%, b%      REPEAT        WAIT 1        MOUSE x%, y%, b%        IF x% > bx% IF x% < bx%+w% IF y% > by% IF y% < by%+h% THEN          MOUSE ON 137          IF b% drag% = TRUE        ELSE          MOUSE ON 0        ENDIF        IF b% = 0 drag% = FALSE        IF drag% THEN          RECTANGLE FILL bx%, by%, w%, h% TO bx%+x%-ox%, by%+y%-oy%          bx% += x%-ox% : by% += y%-oy%        ENDIF        ox% = x% : oy% = y%      UNTIL FALSE 

Quote:
So if including such an implementation has a chance, let me know and then I start coding.

Definitely worth pursuing.

Richard.

Re: Example program challenge
Post by hellomike on Jan 17th, 2017, 7:25pm

Thanks for the reply.
Of course, "RECTANGLE TO". Keep forgetting about its power.

OK, I will give it a try.
Where should I post the beta for evaluation?

Mike
Re: Example program challenge
Post by Richard Russell on Jan 17th, 2017, 8:10pm

on Jan 17th, 2017, 7:25pm, hellomike wrote:
Where should I post the beta for evaluation?

I really don't mind. If you have some private webspace (a small amount is often bundled with a broadband package) you can put it there. Or if you've got a cloud storage account (Dropbox, OneDrive, Google Drive, iCloud etc.) they all, I think, provide publicly-accessible spaces - and even if you haven't you can open one for free!

Wherever you choose to put it, just post the URL in a message here so that anybody who wants to can download it.

Richard.
Re: Example program challenge
Post by Richard Russell on Jan 18th, 2017, 08:19am

on Jan 17th, 2017, 7:25pm, hellomike wrote:
Of course, "RECTANGLE TO". Keep forgetting about its power.

I should add that, because it involves 'reading back' from the screen, it shares with POINT and TINT that it is very slow in BBCSDL. If you are wanting to 'animate' a sprite that is easy to redraw (e.g. a BMP image) then you will probably find it faster to redraw it in the new position than to 'copy' it with RECTANGLE TO.

Richard.
Re: Example program challenge
Post by Richard Russell on Jan 21st, 2017, 9:45pm

on Jan 17th, 2017, 7:25pm, hellomike wrote:
OK, I will give it a try.
Where should I post the beta for evaluation?

Any progress on this front? The next release of BBCSDL is due in only 10 days time so there's a degree of urgency.

For my own peace of mind can you confirm that there are no IPR issues surrounding this game? Obviously I cannot distribute with BBCSDL any program that may raise questions of legality.

Richard.
Re: Example program challenge
Post by hellomike on Jan 23rd, 2017, 2:40pm

Richard,

Developing the graphical form for the game, I arrived at the infamous last 5% (taking 95% of the time).

Concerning licensing, as per the following Wikipedia link, the concept is free and open-source.
"https://en.wikipedia.org/wiki/2048_(video_game)"

I uploaded the unfinished beta for the game to Dropbox. Its location is:
https://www.dropbox.com/s/p8hfsq13m6vkn4w/2048beta.bbc?dl=0

Main concern to have this working with BBCSDL, is the font.

The original 2048 game uses open-source font "Clear Sans". I installed that in windows and then in BB4W, the display mimics the original game at https://gabrielecirulli.github.io/2048/ very close, although the score in not kept (yet) nor any animated sliding is implemented.
To be SYS "GetTextExtentExPoint" independent, values are kept in the TW&() and TH&() arrays.

The font is at:
https://www.dropbox.com/s/k8kyy0gt3zshk78/clearsans-1.00.zip?dl=0
In Windows, when this font isn't installed, the alternative chosen is okay-ish too but BBCSDL just states "No such font".

To overcome the font problem, I could delived a BMP file with the different squares in it and use the same technique as in "PacMan.bbc". However I'm not sure I then can make the deadline.

OK, well that's the current state.

Regards,

Mike
Re: Example program challenge
Post by Richard Russell on Jan 23rd, 2017, 6:17pm

on Jan 23rd, 2017, 2:40pm, hellomike wrote:
Main concern to have this working with BBCSDL, is the font.

The fonts currently supplied with BBCSDL are:

DejaVuSans.ttf
DejaVuSansMono.ttf
FreeMono.ttf
FreeSans.ttf
FreeSerif.ttf

I would hope that one of those would be suitable. If not, I would be prepared to include another font but obviously it would need to be 'free' and not governed by licensing conditions that I cannot meet.

You can copy the font-selection code from any of the other examples supplied with BBCSDL to ensure compatibility. There should certainly be no need to resort to a bitmap.

Richard.

Re: Example program challenge
Post by hellomike on Jan 24th, 2017, 08:04am

This is where I got the font from:
https://01.org/clear-sans

It does state that it is free to use.
To mimic the original gameplay as close as possible, including the font would help.

One of the BBCSDL font supplied might serve as an alternative, so I wouldn't mind having to add code similar to
Code:
IF (INKEY(-256) == &57) GUIFONT$="Clear Sans Bold" ELSE GUIFONT$="FreeSans" 


However I can't seem to get it to work.
In SDLIDE version 0.15a, I can change the display font without a problem (Options -> Set Font...) to e.g. FreeSans,Regular,18.

But when I run the following program I get a "No such font" error.

Code:
*FONT FreeSans,18 


Mike
Re: Example program challenge
Post by hellomike on Jan 24th, 2017, 08:14am

Oh wait....
Code:
      OSCLI "FONT """ + @lib$ + "DejaVuSansMono.ttf"", 18"      PRINT "TEST" 


OK, that works.
Re: Example program challenge
Post by Richard Russell on Jan 24th, 2017, 08:52am

on Jan 24th, 2017, 08:04am, hellomike wrote:
But when I run the following program I get a "No such font" error.

As I've explained before, there is no standardised font repository (comparable with the Windows Fonts folder) across the range of Operating Systems supported by BBCSDL. So, unlike in Windows, BBC BASIC does not know where to 'look' for a font, if you simply specify it by name. Also, as far as I know, the other OSes do not have anything like Windows' 'font mapper' that can locate a font without you having to know its exact filename.

So in BBCSDL the *FONT command requires you to specify the full path and filename of the .ttf file, so that it knows what to look for and where to find it. To reiterate, you only need to look in any of the supplied example programs that change the font (and several do) to discover the code you need.

One day I hope that BBCSDL will have its own dedicated documentation which will cover differences of this sort, but I am absolutely determined not to write this myself! I have asked, and I will continue to ask, for other people to take on various aspects of the development of BBCSDL, and documentation is one of them. Because of my 'waning powers' I must focus my efforts on things that only I can do.

As far as the specific typeface that you mention is concerned, the zip file to which you linked (ClearSans) actually contains eight different TTF files, for various weights and italic etc. Would you say that there is a sufficient difference between that typeface and the ones that are already supplied with BBCSDL to justify the inclusion of another 2 Megabytes of files in the distribution?

I notice that ClearSans doesn't support Arabic or Hebrew alphabets. That's not necessarily serious, but I'm uneasy about adding font files to the BBCSDL distribution that aren't reasonably 'international'.

Richard.
Re: Example program challenge
Post by hellomike on Jan 24th, 2017, 7:06pm

Since I have hardly any experience coding in BBCSDL, I indeed didn't know that the *FONT command required that.

By no means should you include the font just for the sake of this game.

As I mentioned before, using ClearSans just makes the game looks like a more exact clone than without. I added the "ClearSans-Bold.ttf" font to @lib$ myself, which size is 264K, not 2MB.

"2048" also works using the FreeSans.ttf supplied font. In that case, I will have to make slight changes to certain values in order for the characters to align correctly.

To the Dropbox cloud I uploaded a new beta. Apart from internal modifications, with the corrected *FONT statement it now works in BBCSDL and I have added the score to be displayed.

https://www.dropbox.com/s/p8hfsq13m6vkn4w/2048beta.bbc?dl=0

I hope you find it useful.

Mike

PS. I think, maybe I should add some kind of start screen mentioning its goal and how to play it.

Re: Example program challenge
Post by Richard Russell on Jan 24th, 2017, 7:32pm

on Jan 24th, 2017, 7:06pm, hellomike wrote:
I added the "ClearSans-Bold.ttf" font to @lib$ myself, which size is 264K, not 2MB.

If you just want the bold variant, yes, but if it was to be decided that the ClearSans typeface has some advantage over the existing supplied set, justifying its inclusion, I would expect to provide the full set.

Quote:
In that case, I will have to make slight changes to certain values in order for the characters to align correctly.

So long as you don't mind doing that I'll assume that's the way we'll proceed.

Quote:
I uploaded a new beta.

Thanks. The only obvious current issue is that it seems to require a keyboard (at least, if it can be driven using a mouse or touchscreen it isn't obvious how). As stated in the original requirements spec the program must "Be usable with a small touch screen, such as may be found on an Android phone or tablet".

But with that change it looks very promising.

Quote:
I think, maybe I should add some kind of start screen mentioning its goal and how to play it.

That would be nice, but a lower priority than the mouse/touch interface and there's only a week left!

Richard.
Re: Example program challenge
Post by Richard Russell on Jan 25th, 2017, 10:29am

on Jan 24th, 2017, 7:32pm, Richard Russell wrote:
The only obvious current issue is that it seems to require a keyboard

So I could do some testing on Android devices I used this code as a quick hack:

Code:
              Direction = INKEY(1) - 135 : REM Or "Direction = RND(4)" to simulate              MOUSE X%, Y%, B%              IF B% THEN                X% -= WW/2 : Y% -= WH/2                CASE TRUE OF                  WHEN X%<Y% AND Y%<-X% Direction = 1                  WHEN X%>Y% AND Y%>-X% Direction = 2                  WHEN X%>Y% AND Y%<-X% Direction = 3                  WHEN X%<Y% AND Y%>-X% Direction = 4                ENDCASE              ENDIF 

Polling the mouse like that isn't ideal, because you can miss very short clicks, but it does the job and is easier than using ON MOUSE.

Richard.

Re: Example program challenge
Post by hellomike on Jan 25th, 2017, 12:16pm

Wow, yes, that's fine.
Indeed it now also works using the mouse although it is rather sensitive.

Adding this line of code before the ENDIF seems to solve that.

Code:
              ...              REPEAT MOUSE X%, Y%, B% : UNTIL B% = 0            ENDIF 


Would this hack also trap swiping on an Android phone or tablet?
I have no idea or means of testing that.

Mike
Re: Example program challenge
Post by Richard Russell on Jan 25th, 2017, 1:03pm

on Jan 25th, 2017, 12:16pm, hellomike wrote:
Adding this line of code before the ENDIF seems to solve that.

OK, but it's really adding a hack on top of a hack! It would be better to use ON MOUSE, which detects the click/tap event rather than polling the state. This solves both the failure to detect a short click and the over-sensitivity to a long click.

Quote:
Would this hack also trap swiping on an Android phone or tablet?

I did wonder whether a 'swipe' would be more acceptable than a 'tap'; how do other versions work in that regard? If so, please feel free to make the necessary changes. As far as is possible, considering the short timescale, I would like the program to work in an 'optimum' fashion.

I see from the Wikipedia page that the original author is happy for people to create their own versions so long as they "add new, creative modifications to the game". Ending up with an inferior version is neither in the spirit of that desire, nor good for the reputation of BBC BASIC!

Quote:
I have no idea or means of testing that.

You certainly have the means: swiping with a finger is no different from swiping with the mouse! If you really have no idea, can I suggest that calculating the direction and distance from where the mouse button is pressed to where it is released ought to give you the information you need.

The only touchscreen actions which you cannot test with a mouse are 'multi-touch' gestures such as a pinch or a two-fingered drag: obviously a mouse cannot be in two positions at once! But I doubt that you would be wanting to use such gestures in the 2048 program.

Richard.

Re: Example program challenge
Post by Richard Russell on Jan 25th, 2017, 2:11pm

on Jan 25th, 2017, 1:03pm, Richard Russell wrote:
I did wonder whether a 'swipe' would be more acceptable than a 'tap'

I've now modified it for swiping using the method I described, and I think it is better.

Richard.

Re: Example program challenge
Post by hellomike on Jan 25th, 2017, 8:56pm

Since the game involves moving all tiles to either the far right, bottom, top or left, it feels more natural to swipe those tiles rather than tapping. Most (if not all) clones available from Google Play use swiping.

Quote:
calculating the direction and distance from where the mouse button is pressed to where it is released ought to give you the information you need.

I was already thinking in those terms but was not aware that coding that for the mouse would work as swiping on a Tablet so I have no working code yet.

Eventually I would make it work, having enough experience with BBC BASIC but I'm certainly not as knowledgable and fast as you are.

Quote:
Ending up with an inferior version is neither in the spirit of that desire, nor good for the reputation of BBC BASIC!

Indeed, my version is just a program having the same gameplay and, by using the same colours, dimensions and font, visually mimics the original. It doesn't have any extra's compared to the original.

Are you still interested in including my program with the next release of BBCSDL?

Regards,

Mike
Re: Example program challenge
Post by Richard Russell on Jan 26th, 2017, 12:13am

on Jan 25th, 2017, 8:56pm, hellomike wrote:
I was already thinking in those terms but was not aware that coding that for the mouse would work as swiping on a Tablet so I have no working code yet.

As I said in my later post I have 'swiping' working nicely here; I assumed there was little point listing the code if you don't have a touchscreen to try it on. It does mean that operation with a mouse is not as straightforward as it was (swiping isn't a 'natural' action with a mouse) but the keyboard is probably a better choice anyway on a machine that has one.

Basically all I'm waiting for now is a 'final' (non-beta) version that you are happy with. Things which I am aware of that need fixing are (1) The positioning of the text when the FreeSans font is used and (2) This code in FNScanbuttons which does not work on Android:

Code:
          color = TINT(x, y)        UNTIL color = &656E77 OR color = &F2F6F9 

You cannot use TINT like this if the display hardware does not support a 24-bit RGB888 display. Mobile devices almost invariably use a 16-bit RGB565 display.

Once you have let me have a 'final' version I will merge my code with yours. I'll then upload the program so you can check that you're happy with my additions and (hopefully) give me your approval for its inclusion.

You are evidently not an enthusiast for the LOCAL statement, since there's not a single one in the program! How would you react if I proposed adding LOCAL statements in order to make the program more compliant with 'good practice'? Doing so ought not to make any difference to the game logic.

Quote:
Are you still interested in including my program with the next release of BBCSDL?

Absolutely, indeed I thought it was decided. Are you having second thoughts?

Richard.

Re: Example program challenge
Post by hellomike on Jan 26th, 2017, 10:17am

No, I still want to proceed. Probably I misunderstood your statement about this version not improving on the original and so being inferior.

Quote:
I assumed there was little point listing the code if you don't have a touchscreen to try it on.

Well, I do have a few years old Samsung tablet running on Android 4.0.4, ARMv7. Can I somehow load BBCSDL on to it?

I will get rid of TINT() and fix the character alignment.
Be assured that I use LOCAL as much as possible in all of my programming but since my "2048" was started as a Rosetta Code source, I omitted it there to make the source small in size. I will now also add it to this project.

Instead of putting the code to the main program I advise you to put the user input code (scanning for keyboard and mouse and swiping) in a separate function and change
Code:
Direction = INKEY(1) - 135 
into something like Code:
Direction = FNGetdirection 


Expect the final version to be released before the weekend.

Mike
Re: Example program challenge
Post by Richard Russell on Jan 26th, 2017, 11:29am

on Jan 26th, 2017, 10:17am, hellomike wrote:
Probably I misunderstood your statement about this version not improving on the original and so being inferior.

What I meant was that I don't expect the final BBC version to be inferior! I've got the 'animation' code working really nicely, if a bit slowly (using RECTANGLE FILL ... TO as discussed) and will merge that with your 'final' version. With that enhancement, even if we can't argue that it's better than the original it's highly comparable.

Given plenty of time it would be nice to have an introductory page with instructions, and a high-score table saved to file, but those are luxuries that aren't directly related to game play.

Quote:
Be assured that I use LOCAL as much as possible... I omitted it there to make the source small in size.

Oh I see. Is there a size limit at Rosetta Code or was it just a 'cosmetic' thing?

Quote:
I advise you to put the user input code (scanning for keyboard and mouse and swiping) in a separate function

Good idea. I'm not as inclined as I should be to do that; it's laziness really:

Code:
      DEF FNGetDirection      LOCAL buttons%, direction%, X%, Y%, oldx%, oldy%      REPEAT        direction% = INKEY(1) - 135        MOUSE X%, Y%, buttons%        oldx% = X% : oldy% = Y%        WHILE buttons%          MOUSE X%, Y%, buttons%        ENDWHILE        X% -= oldx% : Y% -= oldy%        IF (X%^2 + Y%^2) > 10000 THEN          CASE TRUE OF            WHEN X%<Y% AND Y%<-X% direction% = 1            WHEN X%>Y% AND Y%>-X% direction% = 2            WHEN X%>Y% AND Y%<-X% direction% = 3            WHEN X%<Y% AND Y%>-X% direction% = 4          ENDCASE        ENDIF      UNTIL direction% > 0 AND direction% < 5      = direction% 

Richard.
Re: Example program challenge
Post by hellomike on Jan 26th, 2017, 7:55pm

I promised a final version before the weekend. As I still have 24 hours I decided for beta#3. laugh

Many improvements:

Quote:
Is there a size limit at Rosetta Code or was it just a 'cosmetic' thing?

No size limit but more an effort on my side to present a compact (though still readable) source in an attempt to tease the authors of the other sources for the same task, showing that it can be done better and more compact with BBC BASIC. wink

So Richard, feel free to comment on the updated source and then we can agree on the final version tomorrow.

https://www.dropbox.com/s/p8hfsq13m6vkn4w/2048beta.bbc?dl=0

Regards,

Mike
Re: Example program challenge
Post by Richard Russell on Jan 26th, 2017, 9:44pm

on Jan 26th, 2017, 7:55pm, hellomike wrote:
feel free to comment on the updated source and then we can agree on the final version tomorrow.

It seems fine on a quick test. I've only noticed one thing which may need attention: I copied ClearSans-Bold.ttf into my @lib$ folder, just to see the difference, but to my eyes the positioning looks a little low. See the image below.

Richard.

User Image

Re: Example program challenge
Post by Richard Russell on Jan 27th, 2017, 09:51am

on Dec 11th, 2016, 09:55am, Richard Russell wrote:
● Run in both BB4W and BBCSDL (so either not using any API functions, or ones that have an equivalent in both).

I'd like to clarify something that has the potential for a misunderstanding. Whilst the use of API functions is acceptable, when there are equivalents in both BB4W and BBCSDL, the objective should be to make the two versions behave as similarly as possible. I do not want example programs to favour one platform over another, so I definitely won't accept conditional code designed to exploit a feature that only a subset of the platforms have, to the detriment of the others.

Richard.

Re: Example program challenge
Post by hellomike on Jan 27th, 2017, 3:00pm

It indeed looks a bit like it.
The values in the TH&() array I obtained by calling "GetTextExtentExPoint" in the BB4W version, but maybe I made a thinking error.

For testing this, change the PROCPrint to
Code:
      DEF PROCPrint      LOCAL row%, col%, cell%, x0%, y0%, s$, b$, lpsize{}      DIM lpsize{w%,h%}      REM Clear header area and update score/best text.      GCOL  1 : RECTANGLE FILL 0, WH% - HEADER%, WW% , HEADER%      GCOL 15      RECTANGLE WW% - 480 - BORDER%, WH% - HEADER%, 240, 100      RECTANGLE WW% - 240 - BORDER%, WH% - HEADER%, 240, 100      OSCLI FONTCMD$ + "12"      MOVE WW% - 450, WH% - 20 + BASE%: PRINT "SCORE"      MOVE WW% - 190, WH% - 20 + BASE%: PRINT "BEST"      s$ = STR$Score%      b$ = STR$Best%      OSCLI FONTCMD$ + "20"      MOVE WW% - 360 - BORDER% - LENs$ * 14, WH% - 50 + BASE%: PRINT s$      MOVE WW% - 120 - BORDER% - LENb$ * 14, WH% - 50 + BASE%: PRINT b$      REM Refresh the matrix cell by cell.      FOR row% = 0 TO MAX%        FOR col% = 0 TO MAX%          x0% = BORDER% + col% * (AREA% + BORDER%)          y0% = BORDER% + (MAX% - row%) * (AREA% + BORDER%)          cell% = Board&(col%, row%)          COLOUR 2, R&(cell%), G&(cell%), B&(cell%)          GCOL 2 : RECTANGLE FILL x0%, y0%, AREA%, AREA%          IF cell% > 0 THEN            GCOL 15 + 15 * (cell% < 3)            OSCLI FONTCMD$ + STR$(44 + 12 * (cell% > 6) + 6 * (cell% > 9))            IF (INKEY(-256) == &57) THEN              SYS "GetTextExtentExPoint",@memhdc%,STR$(2^cell%),LENSTR$(2^cell%),0,0,0,lpsize{}              OSCLI FONTCMD$ + "10"              MOVE x0% + 20, y0% + 40 : PRINT "w = ";lpsize.w%;" h = ";lpsize.h%              TW&(cell%) = lpsize.w% : TH&(cell%) = lpsize.h%              OSCLI FONTCMD$ + STR$(44 + 12 * (cell% > 6) + 6 * (cell% > 9))            ENDIF            MOVE x0% + AREA% / 2 - TW&(cell%), y0% + AREA% / 2 + TH&(cell%) : PRINT ;2^cell%          ENDIF        NEXT      NEXT      ENDPROC 

If there is a similar call for that in SDL I would prefer that above using the TW&() and TH&() arrays of course.

Mike
Re: Example program challenge
Post by hellomike on Jan 27th, 2017, 3:05pm

and remove qq from this line in PROCSetup of course....
Code:
        FONTCMD$ = "FONT Cqqlear Sans Bold," 
::)
Re: Example program challenge
Post by Richard Russell on Jan 27th, 2017, 4:07pm

on Jan 27th, 2017, 3:00pm, hellomike wrote:
If there is a similar call for that in SDL I would prefer that above using the TW&() and TH&() arrays of course.

You should be able to use the SDL API TTF_SizeText (or TTF_SizeUTF8 or TTF_SizeUNICODE as appropriate). No more complicated than GetTextExtentPoint32 in Windows as far as I can see.

Richard.

Re: Example program challenge
Post by hellomike on Jan 27th, 2017, 6:42pm

Ah yes. If I knew sooner I would have used it avoiding the TW&() and TH&() arrays all together.
But like I said before, I had no experience with SDL other than playing with the example programs. Starting now would require new time testing etc. So lets stick to the current code.

The final version that I'm happy with is at:

But I will still be available to make modifications if needed before 0.16 is released.

https://www.dropbox.com/s/lpijt4pt3of5rwv/2048.bbc?dl=0

Thanks

Mike
Re: Example program challenge
Post by Richard Russell on Jan 27th, 2017, 8:00pm

on Jan 27th, 2017, 6:42pm, hellomike wrote:
But like I said before, I had no experience with SDL other than playing with the example programs.

Honestly, I think the trick is not so much having experience (I have little of that myself) but the knack of knowing what to search for. I guessed that it was a TTF_ function that you needed.

Quote:
The final version that I'm happy with is at:

Thanks. I'll merge in my additions and upload a release candidate.

Richard.

Re: Example program challenge
Post by Richard Russell on Jan 27th, 2017, 11:11pm

Release candidate here:

https://www.dropbox.com/s/7py74y8x81ej86v/2048rc1.bbc?dl=0

Richard.

Re: Example program challenge
Post by hellomike on Jan 29th, 2017, 09:16am

Yes. The animation makes it more fun to play.

The next link is candidate #2.
https://www.dropbox.com/s/79a2azuku11xfi9/2048rc2.bbc?dl=0

Few last minute changes / additions are:

If you're fine with it, lets release it.

Mike
Re: Example program challenge
Post by Richard Russell on Jan 29th, 2017, 1:00pm

on Jan 29th, 2017, 09:16am, hellomike wrote:
If you're fine with it, lets release it.

Yes, I'm happy with it. To be very pedantic (and it's clear that you share my preferences!) I might debate with you whether your new animate Boolean should have a global-variable-style decoration (Animate%) or a constant-style decoration (ANIMATE%). But this is splitting hairs.

Richard.

Re: Example program challenge
Post by hellomike on Jan 29th, 2017, 1:37pm

Yes, it actually is a constant.
But if that turns out to be the only 'flaw' in our program (code), I'm very proud of the result. grin

It was nice to cooperate like this and I'm looking forward to the release of BBCSDL 0.16.

Take care Richard.

Mike
Re: Example program challenge
Post by Richard Russell on Jan 29th, 2017, 2:25pm

on Jan 29th, 2017, 1:37pm, hellomike wrote:
It was nice to cooperate like this and I'm looking forward to the release of BBCSDL 0.16.

All being well it should be released on 1st February (Wednesday) for Windows, Linux (x86), Mac OS-X and Android.

Richard.

Re: Example program challenge
Post by hellomike on Jan 30th, 2017, 07:26am

I now see that, since MID$(s$,0,1) seems to work as MID$(s$,1,1), a bug is avoided in PROCSpawn.
Re: Example program challenge
Post by Richard Russell on Jan 30th, 2017, 11:15am

on Jan 30th, 2017, 07:26am, hellomike wrote:
I now see that, since MID$(s$,0,1) seems to work as MID$(s$,1,1), a bug is avoided in PROCSpawn.

Probably better not to rely on it though, because AFAIK it's undocumented behaviour. What modification would you suggest to make it 'kosher'?

Richard.

Re: Example program challenge
Post by hellomike on Jan 30th, 2017, 5:25pm

Since inline condition is already used elsewhere in the program, e.g. like in the line immediately following it, lets change Code:
i% = ASCMID$(zeros$, RND(LENzeros$), 1) 

to Code:
i% = ASCMID$(zeros$, RND(LENzeros$) - (LENzeros$ == 1), 1) 

Thanks

Mike

Re: Example program challenge
Post by Richard Russell on Jan 30th, 2017, 9:25pm

on Jan 30th, 2017, 5:25pm, hellomike wrote:
Code:
i% = ASCMID$(zeros$, RND(LENzeros$) - (LENzeros$ == 1), 1) 

OK, I've made that change.

I can't say I'm enthusiastic about deliberately passing a non-integer value as the second parameter of MID$() - it feels a bit kludgy - but at least the truncation to the next lower integer is a documented feature so it should be reliable.

Although it's not relevant in this case, because the parameter is always positive, perhaps I should take the opportunity to remind people that these two statements are not equivalent:

Code:
      a% = a      a% = INT(a) 

If a is negative (and not an integer) they will do different things. The first truncates towards zero so if a was -3.5 a% would be set to -3. However the second truncates towards minus infinity so if a was -3.5 a% would be set to -4.

This is documented behaviour for BBC BASIC (and several other languages) and ought always to be reliable, but in my experience not everybody is aware of it.

Richard.
Re: Example program challenge
Post by hellomike on Jan 31st, 2017, 08:29am

Thanks Richard.

Interesting reminder.

I was not aware of exactly the behavior however, if I knew the floating point variable could be negative I would surely do tests to assure its behavior and I would find out.

Re: Example program challenge
Post by Richard Russell on Apr 7th, 2017, 11:08am

on Jan 24th, 2017, 08:04am, hellomike wrote:
I wouldn't mind having to add code similar to
Code:
IF (INKEY(-256) == &57) GUIFONT$="Clear Sans Bold" ELSE GUIFONT$="FreeSans" 

I found I had to make a small change to make your program compatible with Windows 95 (you may well ask why I bothered in 2017....). The original had:

Code:
      FONTCMD$ = "FONT Clear Sans Bold,"      OSCLI FONTCMD$ + ",10"      SYS "GetTextFace", @memhdc%, 32, f%      IF $$f% <> "Clear Sans Bold" THEN        TH&() = 0, 70, 70, 70, 70, 70, 70, 48, 48, 48, 37, 37, 37, 37        BASE% = -6      ENDIF 

which relies on Windows substituting a 'sensible' font if Clear Sans Bold is not available. Unfortunately Windows 95 substitutes an entirely unsuitable symbols font so I have changed the code as follows:

Code:
      FONTCMD$ = "FONT Clear Sans Bold,"      OSCLI FONTCMD$ + ",10"      SYS "GetTextFace", @memhdc%, 32, f%      IF $$f% <> "Clear Sans Bold" THEN        FONTCMD$ = "FONT Arial,"        TH&() = 0, 70, 70, 70, 70, 70, 70, 48, 48, 48, 37, 37, 37, 37        BASE% = -6      ENDIF 

Richard.
Re: Example program challenge
Post by hellomike on Apr 7th, 2017, 8:21pm

Thanks for letting me know.