Author |
Topic: Example program challenge (Read 4024 times) |
|
hellomike
Junior Member
member is offline
Gender: 
Posts: 55
|
 |
Re: Example program challenge
« Reply #25 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
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Example program challenge
« Reply #26 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.
|
|
|
|
hellomike
Junior Member
member is offline
Gender:
Posts: 55
|
|
Re: Example program challenge
« Reply #27 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 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 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.
|
|
Logged
|
|
|
|
hellomike
Junior Member
member is offline
Gender:
Posts: 55
|
|
Re: Example program challenge
« Reply #29 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. 
Many improvements:
Correct font alignmentSupport for the ClearSans-Bold.ttf font, if presentAll variables have appropriate type like integer, byteAll variables have correct upper/lower case depending on its useAll variables that are not global are LOCALFNScanButtons() 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. 
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 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.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Example program challenge
« Reply #31 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.
|
|
Logged
|
|
|
|
hellomike
Junior Member
member is offline
Gender:
Posts: 55
|
|
Re: Example program challenge
« Reply #32 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
|
|
Logged
|
|
|
|
hellomike
Junior Member
member is offline
Gender:
Posts: 55
|
|
Re: Example program challenge
« Reply #33 on: Jan 27th, 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 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.
|
|
Logged
|
|
|
|
hellomike
Junior Member
member is offline
Gender:
Posts: 55
|
|
Re: Example program challenge
« Reply #35 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
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Example program challenge
« Reply #36 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.
|
|
Logged
|
|
|
|
hellomike
Junior Member
member is offline
Gender:
Posts: 55
|
|
Re: Example program challenge
« Reply #38 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:
Remark giving you credit for the animation codeRemoved 'IF Direction% > 0 AND Direction% < 5 THEN' from the main code because that test is now done in FNGetDirectionAdded a BB4W% constantNew code for PROCSpawn as the previous wasn't random enoughAdded Animate% boolean
If you're fine with it, lets release it.
Mike
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 803
|
|
Re: Example program challenge
« Reply #39 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.
|
|
Logged
|
|
|
|
|
