Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.
|
Forum Index : Microcontroller and PC projects : CMM2 5.05.06 beta
Page 3 of 12 | |||||
Author | Message | ||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1085 |
Minor unexpected behaviour: pixel 100,100) doesn't generate an error, despite the extra ")"Visit Vegipete's *Mite Library for cool programs. |
||||
mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261 |
Ugh ok now with OPTION ANGLE and OPTION Y_AXIS this is going to once again cause problems for anyone trying to write reusable code/functions/libraries. How would one know which way they are set so as to do the proper thing??? There was a work around for OPTION MODE to find which way it was set, but how would one be able to check and determine which way these new options are set by the calling program? |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8604 |
Same approach as thwill's. A simple function to test the setting |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1085 |
page write 0 cls pixel 0,0,rgb(white) if peek(byte MM.INFO(PAGE ADDRESS 0)) then <y-down> else <y-up> if sin(30) = 0.5 then <degree mode> else <radian mode> (untested) Visit Vegipete's *Mite Library for cool programs. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
'option angle radians option angle degrees if sin(90) = 1 then print "Degrees" else print "Radians" Peter, If OPTION ANGLE DEGREES is set in a program, the option is not cleared when a new program is loaded. This will cause problems! It IS cleared with NEW, but should be reset to RADIANS at the start of any program, not just with NEW. Jim edit: it is also cleared if your programs ends with END Edited 2020-09-12 07:53 by TassyJim VK7JH MMedit  MMBasic Help |
||||
mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261 |
Great, so now every reusable library I write I'm going to have to include all of these checker functions (because it's not like I can call an include inside of an include..). There really needs to be a STANDARD consistent way to query the current setting of every option... I really wish you (matherp) would consider doing this. It's only going to get more and more of a headache as new options get added in... I know it's not sexy, and it doesn't seem like it's all that important, but as this community grows and tries to write more and more software it will make things a LOT easier in the long run for everyone. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
OPTION ANGLE and OPTION Y_AXIS are specific to the education area and it would be reasonable to assume that they are not used for 'normal' use. Students will learn (the hard way) that it is worth learning the standards. Jim VK7JH MMedit  MMBasic Help |
||||
mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261 |
Students will learn (the hard way) that it is worth learning the standards. Jim See, I normally would agree with you Jim, but in general the CMM2 being built around BASIC means it's intended for newbies and newbies will naturally pick up bad habits or work in a way that makes sense to them... (really no different than your kids do...) They start sharing code snippets and examples and then next thing you know we have a jumbled mess. I'm not against adding these sorts of flexibilities (although I worry about it causing a headache later) but there should also be ways to know which way its set so you can write code that can handle whichever way those things are set properly. 99% of the time it won't matter, but for somebody like me who wants to make and produce reusable code libraries to help folks build bigger apps faster, I have no way of knowing in advance which way the users of my libraries will set things up (how they like to work) so I really need to be able to detect and adjust how I do things in my library code to be sure I don't break, or worse, expect them to change how THEY like to work to use my library (which means they might not use it at all...) For example, I shouldn't write my library code in a way that requires them to use OPTION MODE 1, or break if they use OPTION MODE 0... If they set the OPTION Y_AXIS one way and I do drawing to the screen in my library expecting it the other way, wacky behavior happens... etc. If I can determine which way they have it set in advance of doing any work in my library, then I can do things in ways that will work regardless of how they set those OPTIONS. Edited 2020-09-12 09:48 by mkopack73 |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1085 |
Not a bug, but font #5 appears to have 1 pixel vertical alignment issue. Lower case letters are one pixel lower than everything else. cls for i = 33 to 126 text (i-33)*8, 200, chr$(i), "LT",5,1,rgb(white),-1 next i ? @(0,300) end Visit Vegipete's *Mite Library for cool programs. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
cls for i = 33 to 126 text (i-33)*8, 200, chr$(i), "LT",5,1,rgb(white),-1 next i ? @(0,300) end I will send Peter an updated font with the lowercase shifted up one pixel. Jim VK7JH MMedit  MMBasic Help |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1085 |
Look at the characters closely and decide what is best. I think the lower case letters are already 'at the top'. Compare the characters to the various bracket styles too. I would almost say the lower case letters could shrink one pixel down (bottom stays the same) and the upper case, digits, etc shift 1 pixel down. ()[]{}| stay as is. I'm happy to work on it if you like... Visit Vegipete's *Mite Library for cool programs. |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 5923 |
I'm happy to work on it if you like... Already done... VK7JH MMedit  MMBasic Help |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8604 |
I genuinely believe you are overthinking this. If you are writing re-usable routines then it is perfectly reasonable for you to define the settings that are required for them to work and in general these should always be the defaults. So your code should have a comment at the top that states OPTION BASE 0 OPTION ANGLE RADIANS OPTION Y_AXIS DOWN etc. Then if someone wants to use your code it is up to them to conform to your requirements. Edited 2020-09-12 20:55 by matherp |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3865 |
Except when your requirements conflict with their requirements and/or they wish to write code that uses multiple different libraries with conflicting sets of requirements. It's not an unreasonable enhancement request, which of course is not the same as it being possible to fulfill. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8604 |
If you use defaults then it is perfectly reasonable to expect users to follow them IMHO There is absolutely no valid reason to use non default settings. Personally I would remove OPTION BASE entirely but left it there for compatibility. The other two options are specifically there for educational use |
||||
Tinine Guru Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Then if someone wants to use your code it is up to them to conform to your requirements. +1 I was starting to think that I wasn't grasping the problem. Using 3rd party code libraries, one needs to be aware of what to pass to subs/functions, etc. What's the difference? Craig |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3865 |
The difference is that the CMM2 provides (at least) 3 pieces of global state that significantly alter the behaviour of parts of the BASIC language. This state can be set, but it cannot be read (except by looking for its side-effects), and this makes it more difficult than it should be to write reusable code. A reason for not providing read methods for this state that I could accept is "I don't want to", or "It isn't actually possible", but arguments that there isn't a problem with the current situation I find to be spurious. I suggest a uniform manner (presumably using Mm.Info) that all options are readable, whether it makes "sense" or not, thus avoiding this debate if another option is added. However if Peter doesn't want to do it and nobody else wishes to step up then that is kind of the end of it. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 3865 |
Yeah ... either OPTION BASE fixed permanently at 0 or 1 and array declarations giving the size of the array and not its highest index would have made things easier. However that is understandably not where we are at. So we have to write different versions of resuable code for "education use" ? However kudos and for responding to a user adding these features even if they do turn out to be a nuisance in the future. Best wishes, Tom Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261 |
If you use defaults then it is perfectly reasonable to expect users to follow them IMHO There is absolutely no valid reason to use non default settings. Personally I would remove OPTION BASE entirely but left it there for compatibility. The other two options are specifically there for educational use If the options exist, people WILL use them, plain and simple... As thwill stated, if you are wanting to make use of multiple libraries in your program how do you deal with one library expecting things one way and the next wanting completely opposite settings? The only way to remove this possibility is to write your library to detect and work properly no matter which way the settings are configured. It puts the burden on the library author but ensures the library works no matter what the user wants. Otherwise we can pretty much forget the code base on the CMM2 to ever really grow beyond small toy programs and smallish games, Mauro’s ports will likely end up being the exception rather than the norm. The whole point of having the ability to use includes is to allow for code reuse and not force everyone to reinvent the wheel in every program after all.. I know it seems like I’m harping on this, and I’m not trying to be a pain, but I want to see this platform grow and mature beyond just simple example code and to do that we have to consider what tools are needed to allow that to happen. All the various OPTIONS you provided were put i for very good reasons, and I don’t really have a problem with them being there - they can help the programmer write code they understand or port code in from other dialects. But that same flexibility also adds in the potential for a lot of confusion - “I did exactly what this other guys code did, why doesn’t it work??!” (Not realizing he didn’t have option XYZ set and you did, etc.) The various options provided modify the syntax of the language itself and can very quickly lead to confusion and mismatched code - “but it’s from another CMM2 program!?!?”. See what I’m getting at? Flexibility is great but it comes at a (unintended) price... Look if you don’t want to add it, fine I’ll live. But I state this as a warning - the more of these options that get added in in the attempt to make things simpler for the newbie, the more complex it actually will be for them in the long run. And the more Fragmented the code base will become. |
||||
mkopack73 Senior Member Joined: 03/07/2020 Location: United StatesPosts: 261 |
The difference is that the CMM2 provides (at least) 3 pieces of global state that significantly alter the behaviour of parts of the BASIC language. This state can be set, but it cannot be read (except by looking for its side-effects), and this makes it more difficult than it should be to write reusable code. A reason for not providing read methods for this state that I could accept is "I don't want to", or "It isn't actually possible", but arguments that there isn't a problem with the current situation I find to be spurious. I suggest a uniform manner (presumably using Mm.Info) that all options are readable, whether it makes "sense" or not, thus avoiding this debate if another option is added. However if Peter doesn't want to do it and nobody else wishes to step up then that is kind of the end of it. Best wishes, Tom Exactly. Let’s look at the following example. Let’s say I want to write a flight simulator program (ala something like the old Flight Simulator 2 for the C64). Not an easy task - you have 3D graphics, physics, a bunch of 2D graphics for the instrument panel, and maybe some drop down menus/windows on a UI to build. Ah, but wait, if there were libraries that somebody already wrote that do the 3D graphics that makes my job easier. Oh, and somebody else wrote a great physics library, awesome. Oh and this other person wrote a nice GUI toolkit library that does windows and menus. My job just got a LOT easier! Oh but wait, those authors were lazy and used competing OPTION settings. BALLZ! I could either spend a ton of time trying to figure out their code and fix it to use all the same option settings, or I could just start from scratch... ugh. Maybe I’ll just go do something else. Program never gets written... Understanding how to call functions and use an APi is quite a bit different than having to conform to a given language syntax only to have that syntax change and be modified by each library you want to use. No other language I’ve ever seen (and I’m up to something like 40 or 50 if you include all the various dialects at this point) has ever allowed this sort of syntactic modification that can have such code breaking results and still be considered the same language/dialect/version. |
||||
Page 3 of 12 |
Print this page |