BBC BASIC - Example program challenge

BBC BASIC

General

Support and Promote (Moderator: Richard Russell)

Example program challenge

« Previous Topic | Next Topic »

Pages: 1 2 3 4

Author

Topic: Example program challenge (Read 4000 times)

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #20 on: Jan 24^th, 2017, 7:32pm »

on Jan 24^th, 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.

Logged

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #21 on: Jan 25^th, 2017, 10:29am »

on Jan 24^th, 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.

Logged

hellomike
Junior Member

member is offline

Gender:

Posts: 55

Re: Example program challenge
« Reply #22 on: Jan 25^th, 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

Logged

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #23 on: Jan 25^th, 2017, 1:03pm »

on Jan 25^th, 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.

Logged

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #24 on: Jan 25^th, 2017, 2:11pm »

on Jan 25^th, 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.

Logged

hellomike
Junior Member

member is offline

Gender:

Posts: 55

Re: Example program challenge
« Reply #25 on: Jan 25^th, 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

Logged

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #26 on: Jan 26^th, 2017, 12:13am »

on Jan 25^th, 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.

« Last Edit: Jan 26^th, 2017, 01:15am by Richard Russell »

Logged

hellomike
Junior Member

member is offline

Gender:

Posts: 55

Re: Example program challenge
« Reply #27 on: Jan 26^th, 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

Logged

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #28 on: Jan 26^th, 2017, 11:29am »

on Jan 26^th, 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.

Logged

hellomike
Junior Member

member is offline

Gender:

Posts: 55

Re: Example program challenge
« Reply #29 on: Jan 26^th, 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:

Correct font alignment
Support for the ClearSans-Bold.ttf font, if present
All variables have appropriate type like integer, byte
All variables have correct upper/lower case depending on its use
All variables that are not global are LOCAL
FNScanButtons() works much better now without using TINT()
High-score field added and value saved to user file on exit

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

Logged

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #30 on: Jan 26^th, 2017, 9:44pm »

on Jan 26^th, 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

Logged

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #31 on: Jan 27^th, 2017, 09:51am »

on Dec 11^th, 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.

Logged

hellomike
Junior Member

member is offline

Gender:

Posts: 55

Re: Example program challenge
« Reply #32 on: Jan 27^th, 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

Logged

hellomike
Junior Member

member is offline

Gender:

Posts: 55

Re: Example program challenge
« Reply #33 on: Jan 27^th, 2017, 3:05pm »

and remove qq from this line in PROCSetup of course....
Code:

        FONTCMD$ = "FONT Cqqlear Sans Bold,"

::)

Logged

Richard Russell
Administrator

member is offline

Posts: 803

Re: Example program challenge
« Reply #34 on: Jan 27^th, 2017, 4:07pm »

on Jan 27^th, 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.

Logged

Pages: 1 2 3 4


« Previous Topic \| Next Topic »