![]() |
Forum Index : Microcontroller and PC projects : Call for interest in MMBasic Challenge 2022
![]() ![]() ![]() ![]() |
|||||
Author | Message | ||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
4695 bytes. ;) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
jirsoft![]() Guru ![]() Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
I wrote my Tower of Hanoi opposite way, directly to restricted code. When I wanted after challenge expand the code to the readable form, that was challenge! Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
lizby Guru ![]() Joined: 17/05/2016 Location: United StatesPosts: 3378 |
Guilty. I was trying to see what was possible with the originally suggested limit of 50 lines of code. (And just copying/condensing VegiPete's code.) Maybe categories of limitations. For the unlimited category, Mauro would probably be likely to be the hands-down winner--if he has the time. PicoMite, Armmite F4, SensorKits, MMBasic Hardware, Games, etc. on fruitoftheshed |
||||
vegipete![]() Guru ![]() Joined: 29/01/2013 Location: CanadaPosts: 1132 |
The first contest was one editor page - 48 lines of 100 characters. Maybe expand that to an even 5000 characters? Imaging the awesomeness that can be added with those extra 200 characters! MMEdit has a crunch function, no? Does that also reduce variable and subroutine names? (I don't use MMEdit, Notepad++ does what I need.) ============ I wrote my programs mostly squashed, increasing density as more features were added. The expanded versions were created after the fact. YDMV (Your Density Might Vary) Visit Vegipete's *Mite Library for cool programs. |
||||
TassyJim![]() Guru ![]() Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
MMEdit's crunch in V5 removes most of the extraneous white space but does NOT automatically shorten variable names. That is something I continue to balk at. Many of the current crop of 'mites can work happily with line-endings of <LF>, not <CR><LF> so there is no real advantage of writing long unreadable lines if the rules state bytes rather than lines. MMEdit and Notepad++ and i expect most other editors can change the line-endings for you. Jim VK7JH MMedit |
||||
bigmik![]() Guru ![]() Joined: 20/06/2011 Location: AustraliaPosts: 2950 |
G'day Libby, All, Please don't take that as a criticism, in fact it is more of a compliment that a program could be written and debugged when the code was so compressed. That was the constraint we applied to the competition last year. I suggested that we relax the rules somewhat to make reading the code easier, although without comments this can be difficult in itself. We still need more interest in entering to make it viable. Regards, Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
bigmik![]() Guru ![]() Joined: 20/06/2011 Location: AustraliaPosts: 2950 |
Lads, Open to disagreement here but I would also like to see new programs entered rather than ones that have been entered in previous years unless there were major changes in its run-time experience and code. If allowed then I would pose that points for originality be reduced. I am also open to allowing C-functions although this might be a huge disadvantage to those who can't speak C (such as myself). Maybe a category of its own. Also what do you think of a Task based competition? What I mean is a task is set like calculate Pi to 100 places or sort 1000 data words with points for speed, accuracy, code compactness etc? Probably poor examples but I think between us we can come up with a suitable and interesting challenge. Just a suggestion so that we might even the field a little bit if we go the road of any MITE can enter. Regards Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
LeoNicolas![]() Guru ![]() Joined: 07/10/2020 Location: CanadaPosts: 504 |
I like the idea of a task base challenge. Maybe combining the task plus the size limitations? |
||||
jirsoft![]() Guru ![]() Joined: 18/09/2020 Location: Czech RepublicPosts: 533 |
I'm (slightly) against CSubs. They can bring the speed, but for me is this not MMBasic anymore (you can just write C program into CSub and MMBasic use just for start it). Or really put it into separate category. The task based challenge can be helpful (because of dropping necessity for program idea), but I think it should be very loosely defined, more as genre (shooting game, math problem solving etc.), else (with size limitation) will be the results too similar. I also agree with Mick, that the programs should be new ones, because it also expands the range of useful applications for CMM (and company). Jiri Napoleon Commander and SimplEd for CMM2 (GitHub), CMM2.fun |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hey folks, Since I started this thread I suppose I should comment even though I think that since only 4-5 people have expressed an interest this idea is a dead duck ![]() 1. An easily measurable size-limit 4-5K (possibly allowing multiple files this time - for graphics/sound assets) makes it more likely that people will enter and actually finish their entry, it also means this isn't simply a competion about who has the most free time. 2. I do not support the use of CSUBS as they are not portable. 3. I do not support the "task based" approach. My view is that the criteria for evaluating the form of any competition should be: a. does it encourage MMBasic development activity? b. does it create diverse new MMBasic content for enjoyment by all? c. does it generate material for a video to serve as out-reach for expanding the MMBasic community? I don't think a task based approach meets (b) and would provide poor material for (c). In truth, unless the task is one requiring hardware/micro-controller (which would be difficult to judge) I think the question I would be asking would probably be "Why are we using MMBasic for this task, there are other more appropriare tools" ![]() 4. I do not support multiple categories. It's a nice idea, but even first time around there were not enough active developers to make it viable. The judging criteria includes points for readability, originality and impressiveness and I would suggest that the latter provides the opportunity for the scores to reflect the relative merits and difficulties involved in writing programs for the various MMBasic platforms. 5. I also agree that all entries should be "new" programs (at least new to MMBasic), not just reworking of our existing catalogue. YMMV. Best wishes, Tom P.S. If the competition does go ahead (I'm thinking 10+ people saying they will enter) then I will match Mick's $50AU prize money with 27.50 GBP ... though I doubt money is the issue here. Edited 2022-03-15 20:32 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
Now I see your reasoning for 4, I agree with you. Also, I've come round to preferring a maximum number of bytes to measuring by lines. I like to see programs that are readable. It was fun though. :) Counting lines of n characters would no doubt be a pain for those using the built-in editor on a PicoMite VGA anyway. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
bar1010 Senior Member ![]() Joined: 10/08/2020 Location: United StatesPosts: 197 |
1. An easily measurable size-limit 4-5K (possibly allowing multiple files this time - for graphics/sound assets) makes it more likely that people will enter and actually finish their entry, it also means this isn't simply a competion about who has the most free time. Why do you think this? I would be more likely to enter the competition if there was NOT a size-limit restriction. |
||||
thwill![]() Guru ![]() Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Why do you think this? I would be more likely to enter the competition if there was NOT a size-limit restriction. Since you ask, IMHO a size restriction: - levels the playing field so it's not a competition about who has the most free time. - makes the competition more accessible for casual entry, how difficult is it to knock up 4K of BASIC ? - increases the chance that if someone starts a project then they will finish it in the given time. And finally to repeat a point I made earlier in the thread, if someone is going to write a "big" BASIC program then they were probably going to write it anyway irrespective of there being a competition. YMMV, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
I think it's important to point out that an entry doesn't have to be anywhere close to the size limit. If you can write a really neat and clever program, with good documentation in 2k then it may very well win. That should be the aim really. Having a maximum size limit shouldn't be a deterrent, but something has to be done to keep the program testing reasonable when judging. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Turbo46![]() Guru ![]() Joined: 24/12/2017 Location: AustraliaPosts: 1642 |
I have to agree with Tom on most of his points. But I suspect that trying to compress a great program into a small file size can be time consuming. What I really liked about the first competition was the quality of the programs. Maybe a rule for this one if it goes ahead is that the author should include an uncompressed version. What disappointed me was that, after the programs were entered, they were abandoned. Most of them could have been improved later by adding things like: - Opening splash screens with sound - More detailed graphics and sound - Success or winning splash with sound - Different levels of speed of play for different player skill levels Those things were not possible given the size restrictions and this is in no way a criticism of the submitted programs. They were, and still are excellent, examples of what can be done with the Maximites. Bill Keep safe. Live long and prosper. |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
There's no joy in trying to work your way through a compressed lump of code. As points are given for readability the compressed version also often makes some sacrifice there. Personally I think I'd like to see more importance put on the readability so that a readable program would usually score more than a compressed one. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5090 |
Honestly, I enjoyed crunching the code more than I enjoyed writing the algorythm in previous challenge. It is like the guy who made DOOM run on the pico. Finding innovative ways to make it fit is a challenge in itself, and teaches you alternative ways of doing things. The code feedback I got from Vegipete was very educating. But I do understand there is more benefit in readable code, so I support the new challenge rule. Volhout Edited 2022-03-16 21:05 by Volhout PicomiteVGA PETSCII ROBOTS |
||||
Volhout Guru ![]() Joined: 05/03/2018 Location: NetherlandsPosts: 5090 |
What disappointed me was that, after the programs were entered, they were abandoned. Most of them could have been improved later by adding things like: - Opening splash screens with sound - More detailed graphics and sound - Success or winning splash with sound - Different levels of speed of play for different player skill levels Bill I started this challenge from am empty sheet of paper, and jotted down an algorythm for the challenge game. While trying to fit a lot of functionality in small memory footprint, I had to cut corners, many corners. The result is something that works, but would need a re-write to large extend to add such features. And then I discovered that there was already a CMM2 game "Crate-Away" that was far superior and had all bells and whistles. So ... no "Ten Line Sokoban" with bells and whistles... Volhout PicomiteVGA PETSCII ROBOTS |
||||
Mixtel90![]() Guru ![]() Joined: 05/10/2019 Location: United KingdomPosts: 7937 |
I suppose it depends on what you like to do. Crunching the code gives you the opportunity to pack more program into the space but might lose you points on readability (I don't think you should be able to submit both readable and crunched versions of the same program, although providing a readable version *after* the winner(s) have been announced is ok). Submitting a readable program might lose you some program content, but will gain you some readability points. Getting the balance right could be important. :) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
Lodovik![]() Regular Member ![]() Joined: 17/05/2021 Location: CanadaPosts: 41 |
Just to say that I'm in for the 2022 challenge. I'm eager to participate. |
||||
![]() ![]() ![]() ![]() |
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |