QB64 Feature Request Listby qbguy (no login)I. Complex Numbers -- Scheme has complex numbers, FORTRAN has complex numbers, FreeBASIC^H^H^H^H^HCOBOL has complex numbers. Why doesn't QBASIC have complex numbers? I mean who doesn't want their computer to know that LOG(-1)/SQR(-1) = PI ? II. Pointers -- C has pointers and FORTRAN (but only Fortran 90 and higher) has pointers. The C people seem to want to use pointers to add two numbers together. Look at Fortran 90's -- http://www.personal.psu.edu/faculty/j/h/jhm/f90/lectures/42.html -- and then put in QB64 -- or just use C++'s pointer syntax. |
* LOL Nice use of the backspace key.by rpgfan3233 (no login) |
Comon pal, let Galleon get QB done before you start asking for a C type language! Apparently you are so far advanced that QB is getting too easy for you! (sure lol) Learn C, code C, play with C all you want! Just let the man do what he started to do without your great(?) ideas! Personally, WHOGAS what you think? And if you keep tossing out arsehole answers to newbies I will jump all over your ass too! Ted
|
Here's something for DEMO 5 -- ASCII PONG!!!by qbguy (no login)' This work has been released into the public domain by the copyright ' holder. This applies worldwide. ' ' In case this is not legally possible: ' The copyright holder grants any entity the right to use this work for any ' purpose, without any conditions, unless such conditions are required by ' law. DEFINT A-Z DIM SCORE AS LONG, DELAY AS SINGLE, T AS SINGLE SCREEN 12 ' This is just to make it full screen SCREEN 0 ' Screen 0 rules WIDTH 40 CLS X = 50: Y = 50: X2 = 130: Y2 = 150 PSPEED = 5: XADJ = 1: YADJ = 1: DELAY = .05 DO CLS PRESS$ = INKEY$ LOCATE Y \ 8 + 1, X \ 8 + 1 PRINT "o" LOCATE Y2 \ 8 + 1, X2 \ 8 + 1 PRINT STRING$(4, 219) LOCATE 1, 1 PRINT SCORE IF Y <= 20 THEN YADJ = 1 IF Y >= 180 THEN YADJ = -1 IF X >= 300 THEN XADJ = -1 IF X <= 20 THEN XADJ = 1 SELECT CASE PRESS$ CASE CHR$(0) + CHR$(75) IF X2 > 1 THEN X2 = X2 - PSPEED CASE CHR$(0) + CHR$(77) IF X2 < 290 THEN X2 = X2 + PSPEED CASE CHR$(27) END CASE CHR$(0) + CHR$(72) DELAY = DELAY - .002 CASE CHR$(0) + CHR$(80) DELAY = DELAY + .002 END SELECT X = X + XADJ Y = Y + YADJ IF Y < Y2 + 8 AND Y > Y2 - 8 AND X < X2 + 32 AND X > X2 THEN YADJ = -1: SCORE = SCORE + 1 END IF IF Y > Y2 + 10 THEN PRESS$="" DO WHILE PRESS$ <> "" PRESS$ = INKEY$ COLOR INT(RND(1) * 16) PRINT "GAME OVER", LOOP END END IF T = TIMER + DELAY WHILE T > TIMER: WEND LOOP |
*niceby mennonite (no login) |
|
OK... Lawyer Joke Time...by qbguy (no login)A Dublin lawyer died in poverty and many barristers of the city subscribed to a fund for his funeral. The Lord Chief Justice of Orbury was asked to donate a shilling. "Only a shilling?" said the Justice, "Only a shilling to bury an attorney? Here's a guinea; go and bury 20 of them." ----- A man walking along the beach found a bottle. When he rubbed it, lo and behold, a genie appeared. "I will grant you three wishes," announced the genie. "But there is one condition. I am a lawyer's genie. That means that for every wish you make, every lawyer in the world gets the wish as well -- only double." The man thought about this for a while. "For my first wish, I would like ten million dollars," he announced. Instantly the genie gave him a Swiss bank account number and assured the man that $10,000,000 had been deposited. "But every lawyer in the world has just received $20,000,000," the genie said. "I've always wanted a Ferrari," the man said. "That's my second wish." Instantly a Ferrari appeared. "But every lawyer in the world has just received two Ferraris," the genie said. "And what is your last wish?" "Well," said the man, "I've always wanted to donate a kidney... ----- A man walked into a bar with his alligator and asked the bartender, "Do you serve lawyers here?". "Sure do," replied the bartender. "Good," said the man. "Give me a beer, and I'll have a lawyer for my 'gator." ----- It's been getting so cold lately, a saw a lawyer with his hands in his OWN pockets. ----- "You seem to have more than the average share of intelligence for a man of your background," sneered the lawyer at a witness on the stand. "If I wasn't under oath, I'd return the compliment," replied the witness. ----- At a convention of biological scientists one researcher remarks to another, "Did you know that in our lab we have switched from mice to lawyers for our experiments?" "Really?" the other replied, "Why did you switch?" "Well, for three reasons. First we found that lawyers are far more plentiful, second, the lab assistants don't get so attached to them, and thirdly there are some things even a rat won't do. However, sometimes it very hard to extrapolate our test results to human beings." ----- |
IF laugh > &H64 THEN PRINT "HAHAHAHAHAHAHA"by rpgfan3233 (no login)HAHAHAHAHAHAHA 'I laughed a lot while reading those. They were very funny! |
*you meant <by mennonite (no login) |
* D'oh! How'd I miss that typo? I'm usually great at fixing those right after typing them.by rpgfan3233 (no login) |
Been too busy playing Akalabeth to work on QB64 today!by (no login)It'd have to be one of the best basic games of its time and was even distributed commercially. Because it is hard to get a copy I've posted it in the "big programs" forum. It works fine in QBASIC without any modifications though it's more like GWBASIC code. http://www.network54.com/Forum/190883/message/1200048268/Aklabeth+%28The+precursor+to+the+famous+Ultima+series%29 It also works fine in QB64 too! Check out some screen-shots of me playing... http://img140.imageshack.us/img140/8663/qb64aklapd7.png I'm going away on a nice holiday for a week so don't expect any responses from me throughout this time, but for now... ...back to playing Akalabeth! Galleon PS. All of the nice little programs in 9liners.zip found on Antoni's website( http://www.geocities.com/antonigual/qbasic.html )now also run perfectly without any modifications except for one which requires that you comment out a line containing the word "ffix". The vertical retrace checking (WAIT &H3DA,8) in CUBEROT.BAS works beautifully. PPS. Can't wait to release the next Demo, thanks for the support everyone! |
Enjoy your holiday Galleon...you deserve it.by (Login MystikShadows)R You've been putting alot of work into QB64 so yeah a little break like that will be great for ya. When you get back, or, if anyone happens to know, I'm wondering or suggesting (depending) if QB64 has a _DIR$ function or if one is in the big picture. ;-) In my case it's one of the first things that pushed me to wards the PDS and VB-DOS for most tools/apps a _DIR$ function of some sort would save a lot of stress ;-). Just a suggestion hehe. I can't wait for demo #5 like I'm sure most here can't wait either. hehe. |
|
qb64 feature list (*url)by mennonite (no login)http://www.network54.com/Forum/190883/thread/1199858084/qb64+feature+list+works+in+qb64+and+qbasic |
Nice features list program! (Well worth trying for anyone interested in QB64)by (no login)99% right! I noticed a couple of incorrect colors but I think I'll wait till Demo #5 is released before fixing this up. Thanks for providing a good reference everyone can have fun using. |
Here's another features list of things added over the past few days for Demo #5!by (no login)CINT/CLNG/CSNG/CDBL/INT/FIX/_ROUND OPTION BASE CSRLIN DATE$ (both function & statement implemented) TIME$ (both function & statement implemented) TAN ATN LOG EXP Of course, that's just what's been coded over the past few days, Demo #5 has so much more! PS. _ROUND rounds numbers to integers as appose to CINT which rounds numbers to INTEGERs. Make sense? Anyway _ROUND is faster and works on a much wider range of numbers (it can return signed or unsigned INTEGER64 values) but provides no overflow checking. |
About the _ROUND function :-).by (no login)I'm just curious as to which rounding algorithm you used. as you might have read in Moneo's rounding tutorial there's more than one way to round a number :-). The way you describe _ROUND here seems to be a 64bit replacement for the CINT() or INT() functions would round allow to say round to 2 decimal places for example? or does it always round to the nearest integer value. I assume the latter since you said it returns a 64 bit signed or unsigned integer. :-). Perhaps a rounding function that allows to define the number of decimal places to round to might be fun. :-). Just a suggestion hehe. |
Aww.... Why'd ya have to go and ask that, Mystik! Now I'm curious too!by rpgfan3233 (no login)I like my rounding method, which implements symmetric arithmetic rounding (aka "round-half-up"): DEF FNround(x) = FIX(x + 0.5 * SGN(x)) or DEF FNround(x) = INT(x + 0.5 * SGN(x)) In some typical C code: #define ROUND(x) ((int)(x + 0.5 * ((x < 0) ? -1 : 1))) Yeah, functions are better (they have type-checking and such), but the macro and DEF FN was simplest. Shoot me. Err... No, wait! SUE ME! SUE ME! *the MPAA comes in* Aww, man! unsigned int n = 0xffffffffUL; printf("I have %u pirated movies.\n", ++n); /* thank goodness for the behavior of C */ |
*right now i just use dim a as integer, - .5 from a and it's like int(a) for a > 0by mennonite (no login) |
of course here's how i would do a round functionby mennonite (no login)'public domain here's locate: locate y locate y,x locate ,x locate y,x,v here's roundnum: round(n) round(n, -1, 10) the default, round(n) is like using round(n,0,1) n is the numeric you're rounding, the next is -1 (up) or 1 (down) or default 0 (nearest) and the next is the nearest what- so round(n,1,100) would round 147 to 200. round(n,0,1) would work like dim n as integer, and round(n,-1,1) would be much like or exactly like int(n) |
um, yeahby mennonite (no login)it would actually be called roundnum() and -1 would be round down, and 1 would be round up, but other than that, yeah. |
About _ROUND(...)by (no login)The problem with CINT and CLNG is they are specific to a particular data type and also require range checks for compatibility with QBASIC. QB64 contains more data types so it was necessary to add a new function. If it were called _CINT64 then you'd expect it to return a value which is a signed 64 bit integer, however this would have been misleading because it you pass it an unsigned value it returns it as is. I also wanted a simple rounding function which would round a float to an integer value quickly and this meant skipping range checking. How does it round? The same way QBASIC automatically rounds floating point numbers to integers. Consider the following code. a!=1.6 b%=a! print b% It prints 2. In the same way the following code... print _ROUND(1.6) ...would also print 2. What about other rounding methods? I really like the idea of extending the _ROUND function or perhaps making a different function which can round using a variety/combination of rules. The rules I see as important are: 1. The direction it rounds positive and negative numbers 2. How many decimal places it rounds the number to 3. The decimal fraction which is the pivot point around which a rounding decision would be made (typically 0.5) or indeed if there is no pivot point and it always rounds up/down. 4. How it rounds a number ending with the pivot point fraction. Consider the following... a%=0.5 a%=0.51 a%=0.59 The 4th rule above would make a big difference to the number a% becomes If anyone can come up with a really simple function format which could do all of the above I'm sure I'd find a way to include it. |
i really like mine although there's one thing i can't think of a way to expressby mennonite (no login)_roundnum(n) would by default be like _roundnum(n,0,1) which would be like dim a as integer. i like to truncate, and usually let int() do this for me, even though int(-0.5) will actually be -1, it's okay. i never use any of the other rounding, int is popular and "good enough." but for rounding, i like being able to round nearest, up, or down, that's the 0: _roundnum(n,0,1) nearest _roundnum(n,-1,1) round down _roundnum(n,1,1) round up and the 1 there is so you can _roundnum(8200,1,500) and it will round up to the nearest 500: 8500 so it has a certain number of options you can use, but too many, it's like line or locate. the one thing it won't do is say you want to always round up... and you consider _roundnum(-0.4) well rounding that up would be -1. or would it be 0? should there be another option for which is up, or should the best option be chosen? that i wish people could tell me. |
i do want to add this to what i saidby mennonite (no login)i like the idea of _roundnum() a lot, and it's being offered to you as a favor, but i don't think you need to include it. if int() works as you say it will (qb compatible) i will be happy. i mention _roundnum() because you're trying to figure out an improved statement. i'm trying to help you do it. the statements you add should be for now at least, up to you i think. _roundnum() is your option, and if you "mess it up" i can call it something else if i want it in another basic language, no worries. |
Simple and to the point. If the user needs to round up or down, he can make his own FUNCTION to do that. No need to mess with the number in the rounding Function itself. For instance, Moneo objected to an old post that rounded up by adding .5 to the number before making it an integer using INT(). He thought it should have been done another way. Fine! That is up to the programmer........ Ted |
I thought INT was like the mathematical Floor function - it rounds down every time.by rpgfan3233 (no login)Implementations of modern rounding algorithms in QBasic: DEF FNceil (x) = FIX(x + SGN(x)) DEF FNfloor (x) = INT(x) 'INT rounds down every time, so INT = Floor DEF FNroundHalfUp (x) = FIX(x + .5 * SGN(x)) 'also known as Symmetric Arithmetic Rounding DEF FNroundHalfDown (x) = FIX(x + (ABS(x - FIX(x)) > .5) * SGN(x) * -.5) I'm a FIX master, mainly because symmetry works well with me. For that reason, I don't like INT nearly as much. However, the floor function has been very handy in other languages, and for that reason I do not ignore the fact that it exists. Also, I really can't ignore it because of the fact that "(int)variable" type-casts some variable as an int, in which case it is like the FIX function. That would be so confusing to a beginner! Anyway, I could have done the floor function with FIX instead of using the built-in INT function: DEF FNfloorAlternate (x) = FIX(x + (SGN(x) = -1)) It is amazing what you can do with logical operations that can be used as integers instead of being strictly-typed boolean values. :) |
someone researched it before i wrote my tutorialby mennonite (no login)it truncates unless the value is negative. moneo has an article about these, but i don't know when it came up before i wrote my intro to qb. the example output in my tutorial is from actual code. |
I think that symmetry works in opposite directions on each side of 0. FIX is symmetric without adding a number to the value. Adding .5 would round up in some cases. But INT would do that too. Really, I think it is a matter of what you are trying to do. Such as payroll or banking. Moneo and I got in an argument about your method. He found a posted thread from 4 years earlier and said it was misleading. In Tricks Forum. His recent essay is in Big Programs. That is why I like Galleons Round Function because not everybody agrees on the method. Keep in mind that it will be using number ranges above QB's. Later he can make new FIX and CINT functions perhaps. Ted |
QB Help recommends FUNCTION because DEF Fn needs you to assign it to a variable if you want to manipulate the value. Also DEF Fn cannot be used recursively(defined more than once in a program). That limits it's usefulness in programs doing the same routine twice. DEF Fn is a legacy compatability from the GW Basic days. Ted
|
Some on DEF FNby (no login)With the DEF FN function, you can define up to 26 functions in a set of code. Not being able to reuse DEF FNA(X), for example, is not all that much of a drawback. If you need another, use DEF FNB(X). I'm for putting DEF FN into the QB64 package. It may not be as elaborate as other languages, but it is wonderful as a teaching tool, because of its simplicity. QB64 geniuses--give us DEF FN. |
You can rationalize it all you want, but EVEN M$ recommends using a REAL FUNCTION!
|
thanks, your corrections are welcomeby mennonite (no login)took a bit of research, but there were a couple i wasn't even sure about. although i tried out a lot of stuff in 3 and 4. for demo2, there were things that were not features of demo2, but they were in the program you wrote in basic to make demo2, etc, so i assumed they were already part of qb64 by then. |
Of course, QB has some inconsistencies, but dwelling on them at this point is not really necessary. I would make the stuff to work using the rules of the help index. Although some may not be very clear, I don't understand going to extremes to test them at this point. As long as they work using common sense coding practices, why worry about someone who is a lamebrain to begin with? Once again, no applause is necessary! Ted
|
Because BASIC is BASIC ;-).by (no login)Not that I'm one of those, but remember that BASIC was invented so that the non scientific and non engineering community could make computers do things without scientific theories and hypothesis and big complex notions. It's what makes BASIC what it is and what makes QB as popular as it was and actually still is today. Ignoring these quirks is not the way to go I honestly believe. Now if you're saying it's too early in the project to focus on the quirks, I still have to disagree (that's my professional advice) because adding these quirks after is gonna be hectic at best if done after it's one thing to add quirks to a 300 line project, it's another if you have to do the same in a 200,000 project, believe you me. Maybe each demo will be delayed right now by a day or a week but after the demo is released well we know it was done the right way. What you're suggesting should be used if and only if there's no possible way in 32bits to achieve what the 16 bit QB does. Then you might think of making it follow the rules as described in the online help or manuals. For example, in windows you can't call interrupt 10h (direct video) directly, in the command prompt's that's emulated. Now do we want him to thunk in a 16 bit ASM code in some way? or do we just want him to do (using what means windows API or SDL allows) mimic what QB does when you call an interrupt? That's just an example, LPRINT can be another. ;-). Along with a few others of course. My two cents ;-). |
EVERY command or function can be abused by somebody not familiar with some syntaxes. That will be the job of a compatable compiler/ide to figure out and that is not gonna be done for a while. I realize that the code has to be tested and Galleon's findings are important in that regard. I like that he has been documenting acccidental findings also. But I would draw the line at stuff like trying to enter TIME$ = "00". The next thing I see is a post that you can do that in PDS. PDS is not even on the drawing board and as far as the added functions in it, I would rather see Galleon work on Qbasic stuff first. It would be nice information for anybody who wishes to make the IDE/Compiler however. I am sure bugs will be found by some of our more enthusiastic coders anyhow. :>) Ted |
Yeah there's a fine line between...by Anonymous (no login)What the languages allows one to do versus what the user can choose to do to get his job done. BASICs should allow one and the other coding practices, not enforce on or the other on the user. ;-) But I do see what you're saying and in that context coding it once and coding it right I think is still the best approach. What defines the "coding it right" aspect of it I think galleon has the right approach on this. so how it should work, how it can work, what's allowed that shouldn't be etc...even if it was never used in coding the routine would still give him one awesome insight on what QB is really all about and ease his deciision making process on the "quirks" that should or should not be. But like he said, 100% compatibility is a must, if it compiles in QB it should compile in QB64, and well that's the golden rule, the prime directive so to speak ;-). So if this is the QB64 path, then he might as well do it right and all the way. :-). |
That was me above...by (no login)Not sure what happened, but I think this post is gonna have my name like it's supposed to. lol |
that's what they said at fb.netby mennonite (no login)fb has basic syntax, (well, some of it) it's the quirks that make it so that no qbasic program works in fb. keep in mind they think a cursor in screen 12 is a quirk. well you said we should use the help index as a standard. the help index says locate's full syntax is: locate row,col,vis,start,finish the last three have to do with the cursor. there's nothing about whether it works in screen 12 or not, that's the syntax for the locate statement. originally you were like, let's not add anything. now you're basically saying, let's not even bother with compatibility. do you think it would be a bad thing if it was more compatible? you probably call things quirks other people will have to code around. if i say color 0,1:cls that clears the screen and makes it blue. otherwise i have to print 2000 spaces to the screen every time i use cls or my only option is a black background. galleon will be working on that "quirk" among many next. so tell me, what's a "quirk?," or does it mean what it means at fb.net? "a native feature we're too 1337 to care about" |
The way I see itby Iain (no login)I haven't been around for a few months, so all this is new to me. However, it seems to me that if a program that compiles with QB, say 4.5, then it should compile with this new version. Otherwise, what is the point? I should be able to compile my slightly broken Enigma program and get the same weird output. |
Some QB "quirks" are a very important part of QBASICby (no login)I think it's important to make a distiction between bugs/errors in QBASIC vs specifics. Take the TIME$="00" bug I quoted on the forum. That's a bug. I take the time to research each command and note any unexpected behaviour. If I see the unexpected behaviour as a bug then I fix the bug in QB64. So QB64 allows TIME$="00" If I see the unexpected behaviour as reasonable, like adding trailing "garbage" to the string passed to TIME$ eg. TIME$="01:01:01d[va\nmb3298sda" still working then I make sure QB64 can handle this in the same way too. Sometimes I take an ecentricity and make it more general so that it can be explained in a simple rule. So I've made QB64 also allows trailing "garbage" if only hours or hours&minutes are specified whereas QBASIC does not. Recently I implemented the PAINT statement with its string tiling option. Because the QBASIC help documentation is vague and its behaviour very specific I opted for implementing it with 100% compatibility and 100% of the same restrictions. My goal is to code it once and code it right. It may not be using the fastest possible C++ code (although I always try to make it very effecient) but it works the way it is supposed to. Having said this, I'm sure there will be little bugs to fix in Demo #5 when it is released, especially because so much has been added since Demo #4. I agree with MystikShadows. Ignoring these quirks would only mean things have to be coded again. It would also mean that programmers wanting a 100% compatible version of QBASIC would be very disappointed, including me. There's no point rushing QB64 and having it turn into something less than what it could have been, Galleon PS. I doubt Demo #6 will be anything more than improvements to the already implemented features of Demo #5! |
* Looks goodby qbguy (no login) |
Here are portions of the compiler change log that specifically target QB compatibility related issues since the addition of "-lang qb" in version 0.17 through 0.18.4: - added the -lang command-line option, to allow language compatibility without keeping FB from progress, see the migrating.txt file (v1c) - lang qb: DATA should be allowed inside compound-statements (v1c) - lang qb: MKI/CVI now return 16-bit sized results (counting_pine) - lang qb: INTEGER (%) and LONG (&) are now, respectively, 16- and 32-bit wide (v1c) - lang qb: default numeric literals are now assumed to be INTEGER or SINGLE (v1c) - lang qb: symbols with the same name as keywords are now allowed: dim left as integer: const dim$ = "" etc (v1c) - lang qb: all data types and functions/keywords not present in QuickBASIC were removed (v1c) - lang qb: SLEEP(n) expects seconds (feature request #1718012) (jeffm) - lang qb: INKEY$ returns CHR$(0) as the extended character (feature request #1718012) (jeffm) - SCREEN now follows the QB syntax in -lang qb (v1c) - RND is now 100% compatible with QB in -lang qb mode (patch written by counting_pine) - ERASE is now compatible with QB, that is when ERASE is called on a variable-length array, the bounds information is reset in addition to the data being destroyed (cha0s) - -lang qb now skips UDT alignment by default (cha0s) - LOCATE will now accept a full 5 args to be compatible with QB, however the final 2 args have no effect (cha0s) - STR will now pad positive numbers with a single space, as in QB, but ONLY if -lang qb is used (cha0s) - OPEN now is more compatible with QB, the file/device is parsed at runtime (cha0s) - fixed #1790722 - INPUT wasn't prompting with a '?' if no prompt string was given (cha0s) - lang qb: STICK(n) and STRIG(n) functions (jeffm) - added error when NEXT var does not match FOR var (jeffm) - added First version of COM/serial support for DOS, W.I.P. (jeffm) - cursor support for INPUT/LINE INPUT in GFX modes (v1c) - 'PCOPY [srcPg] [, dstPg]' and 'SCREEN [, activePg] [, visiblePg]' for non-graphic, console, screen 0 mode - for DOS and Windows only (v1c)
|
QB compatability in FB 0.19by mennonite (no login)what are we being flamed/trolled/"ignored"/banned about today? |
This is the QB64 forum Cheech! Don't bother posting here again!by (no login)Who cares what exact features they've changed in FB to try and make it more compatible with QBASIC? I always keep a copy of the latest version of FB on my computer just to test it and despite some improvements (with the -lang QB option) it will never even come close to the level of compatibility QB64 offers. |
*new bug, demo 4: q$="$dynamic"by mennonite (no login) |
*it's ok if it doesn't start with $, workaround is "$"+"dynamic"by mennonite (no login) |
|
*pt1=bug report, pt2=workaround if foundby mennonite (no login) |
*your compiler stops at chr$(26) but that's probably 7.1,!=resolved until it self compilesby mennonite (no login) |
*also chr$(250)by mennonite (no login) |
So how hard can doing this really be? SOD - Either that's DOS written backwards or Stupid Old Dude, take your pick. ---------------------- Kiddig aside, good luck with your current release. I'm looking forward to testing some WP apps on it when the time comes. Pete |
|
* You ought to call it 640K -- then no one can complain!by Bill Gates (no login) |
Useless Screen Saver for QB64 Demo #5by qbguy (no login)REM THIS PROGRAM IS IN T3H PUBLIC DOMAIN SCREEN 12 LINE (0, 0)-(640, 480), 15, BF DO X = INT(RND(1) * 640) Y = INT(RND(1) * 480) Z = INT(RND(1) * 50) + 10 COLOUR = INT(RND(1) * 14) + 1 COLOR COLOUR CIRCLE (X, Y), Z, COLOUR PAINT (X, Y), COLOUR IF INKEY$ = CHR$(27) THEN EXIT DO LOOP |
*the would really be better than t3hby mennonite (no login) |
The PAINT statement has been fully coded!by (no login)Here's a screenshot of using the PAINT statement to tile a circle with the 8x8 image of the letter A. The source for this program can be found in my post about research on the PAINT statement. QB64's PAINT statement is 100% compatible with QBASIC's (just as it should be). http://img221.imageshack.us/img221/6649/paintcx7.png Whilst coding this routine I often had "wouldn't it be good if I allowed it to..." such as being about to accept more than 64 vertical rows for the tile and/or having it loop around after the bottom of the screen and become a second horizontal row. I opted against this and went for a 100% pure implementation of the PAINT statement with all its restrictions. In all honesty, the tiling feature is extremely difficult to use and the people who created BASIC should have either left it out or designed it better. QB64 may eventually have an easier to use paint tiler but it'd be included as a separate function. |
This may be a good ideaby (Login Tusike)I'm sure many people have wanted to paint something in that had many different colors on it's border. PAINT only looks at one color as the border. RRRRRRRGGGGGGGBBBB WRRRRRRRRRRRRRRRRR W0000000000000000R W0000000000000000R W0000000000000000R W0000000000000000R WRRGGBBBBBBBBBBBBR Let's say I wanted to PAINT all the 0's to (Y)ellow. I wouldn't be able to do that using PAINT, since the border consists of 4 colors (Red, White, Green and Blue). I think something like this may be useful: PAINT (5, 5), 14, 4 'this would paint everything yellow until it reaches the border color, 4 NOT PAINT (5, 5), 14, 0 'this would paint only color 0's, and everything else would be the border. Sorry if I'm posting too many ideas for new features that I think qb64 should have. The main goal is to get it working like Qbasic after all. -Tusike |
oh yeah, qb64 ought to have a new paintby mennonite (no login)i mean here's what paint means everywhere else: paint (x,y),c 'fill every adjacent pixel that is the color found at x,y before fill and here's what it is in basic: paint (x,y),c 'fill every adjacent pixel and don't stop until you reach a border of color ? but i respect that you stayed compatible. i would happily use _this to use a real paint routine. nice work. |
We can paint it later. Maybe we'll take it to Earl Scheib. He'll paint any app for only 39.95... RRRRight! Pete
|
i didn't mean nowby mennonite (no login)the first rule of qb64 is qb64 will be compatible with qb. the second rule of qb64 is qb64 will be compatible with qb. no one understands that more than i do, it's the thing that makes qb64 special. but we can still talk about the future of it, and he already planned to add to it, i think the fewer promises galleon makes about ideas irrelevant to qb the easier it will be for him to do what he's trying to do. we can still talk about other features, as long as we remember the first two rules of qb64. |
|
|
oh i've got plenty of ideas, tedby mennonite (no login)for the same reason pete thinks we should go easy on those, i already try. i'm not talking about every idea i have for qb64, because i don't think it's the right time to talk about all of them. but i do think it's the right time to talk about some of them, particularly when a feature like paint comes up, and, tusike already mentions it. then i agree with him, and might even talk a moment about it. |
and since qb64 is basic, my own posts will also take these into account:by mennonite (no login)1. Be easy for beginners to use. 2. Be a general-purpose programming language. to me this means not just for cgiscripts, and not just for gaming, but you could make a gaming language based on basic, at least give it a name like "gamebasic" (someone already did) 3. Allow advanced features to be added for experts (while keeping the language simple for beginners). 4. Be interactive. gwbasic and qbasic are interactive, i'm not certain this excludes compilers, but it's an interesting idea that would at least suggest an ide is always a good idea. 5. Provide clear and friendly error messages. 6. Respond quickly for small programs. 7. Not to require an understanding of computer hardware. 8. Shield the user from the operating system. of course there are some things in basic meant to give the user access to the operating system. shell is one example, it lets the user give commands directly to the os. another is asm. however with these exceptions, i see basic as a language that ordinarily does not require any knowledge of the operating system. see the third principle if i'm unclear. it was myst that introduced me to these, amd alluded to them in his article in qbe #19. you can find this list at http://en.wikipedia.org/wiki/Basic_%28computer_language%29#History |
*and, not amd, see me in my office!by spelling principle (no login) |
|
*that's alright son, we'll take it from here.by context police (no login) |
In 1975, MITS released Altair BASIC, developed by college drop-outs Bill Gates and Paul Allen as the company Micro-Soft (who started today's corporate giant, Microsoft). The first Altair version was co-written by Gates, Allen and Monte Davidoff in a burst of enthusiasm and neglect of studies. Versions of Microsoft BASIC (also known then, and most widely as M BASIC or MBASIC) was soon bundled with the original floppy disk-based IBM-PC computers. Eventually tens-of-thousands of copies and variants were in use because of the success of the IBM-PC. Because of the portability factor, it also became one of the standard languages on the Apple II, which was based on a different microprocessor, the 6502 MPU. By 1979, Microsoft was talking with several microcomputer vendors, including IBM, about licensing a BASIC interpreter for their computers. A version was included in the IBM PC ROM chips and as a result, PCs without floppy disks automatically booted into BASIC just like many other small computers. Newer companies attempted to follow the successes of MITS, IMSAI, North Star and Apple, thus creating a home computer industry. Meanwhile, BASIC became a standard feature of all but a very few home computers. Most came with a BASIC interpreter in ROM, thus avoiding the problems with not having (or being able to afford) a disk. Soon there were millions of machines running BASIC variants around the world. This was likely a far greater number than all the users of all other languages put together at that time. How soon Bill forgets! Eventually fewer people got involved as Windows no longer required a knowledge of DOS programming and M$ is now trying to get money from the programmers that are left. VB.NET can cost over $1000 easily! Ted
|
Personally, I welcome any FB programmers!by (no login)As long as they respect that this forum is about QBASIC and QB64. It is inevitable that programmers will mention the names of programming languages they often use or have used. The context of their mention should be constructive and any criticisms of QB64 made by comparing the two should only be made if their goal is constructive to QB64's development. Comments like "QB64 is dumb because it doesn't have subs or functions yet" are nonconstructive and unwelcome. Comments that either promote or link to another site to promote it without my prior permission are also unwelcome. If you want to "flame" QB64 do it somewhere else. If you come here to create ill will towards those who are enthusiastic about QB64 you are also not welcome here. Galleon PS. Everyone gets a bit edgy when they perceive QB64 as being unduly criticized, especially as it is at such an early stage of development. I can take constructive criticism, even when I don't necessarily agree with someone's point of view I try and appreciate where they are coming from. Don't expect me to enter a "flame war", as I don't approve of adding fuel to fires. I also apologize for some posts which I will not/have not responded to where I feel the answer should have been obvious. I also refrain from continuing to reply to posts from people if I have given them my point of view on a topic and my opinion has not changed. |
But that's OK, The Rock likes Pi. :) Pete |
That's a good attitude to have, Galleonby (no login)Any user is a good user, end of story. The attitude expressed by some of the people on this forum is similar to the two signs the US now has on the border with Mexico: "Keep Out!" and "Help Wanted". I hope you're not implying that I insulted QB64 for not having function support, because I did not. I had previously said that it is brainless to add (and it is, or at least it is when you're converting BASIC to C). At the time, I had absolutely no interest in supporting your compiler. However, I am rather unpredictable, and what I will or will not support can change, unlike most humans who set their issues in stone and refuse to budge. I offer my support for QB64, and since I do have a lot of previous experience in compiler design, I will offer you any assistance you might need in bringing QB64 to maturity. I extended the same hand of help to the FB team back in the day, and for all intents and purposes, had it slapped away. That's one of the reasons I developed BSDBASIC and NeoQB. But I digress. I think QB64 has a future, but you're going to have to keep your admirers under control if you want that future protected. A project's community can bury that project long before the project is usable; it happens all the time on sourceforge. |
The duck likes 4 * ATN(1#) for accuracy! Good idea Galleon, make a Pi function. Ted |
OKby (Login dean.menezes)R FUNCTION PI() PRINT " 3.141592" PRINT " 653589793" PRINT " 23 84" PRINT "6 2 64" PRINT " 3 38" PRINT " 3 27" PRINT " 9 50 2" PRINT "8 8 4197" PRINT " 16 93 QB64" PI=3.14159265358979323846264338419716939937510 END FUNCTION #define _ -F<00||--F-OO--; int F=00,OO=00;main(){F_OO();printf("%1.3f\n",4.*-F/OO/OO);}F_OO() { _-_-_-_ _-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_-_-_-_-_ _-_-_-_-_-_-_-_ _-_-_-_ } char _3141592654[3141 ],__3141[3141];_314159[31415],_3141[31415];main(){register char* _3_141,*_3_1415, *_3__1415; register int _314,_31415,__31415,*_31, _3_14159,__3_1415;*_3141592654=__31415=2,_3141592654[0][_3141592654 -1]=1[__3141]=5;__3_1415=1;do{_3_14159=_314=0,__31415++;for( _31415 =0;_31415<(3,14-4)*__31415;_31415++)_31415[_3141]=_314159[_31415]= - 1;_3141[*_314159=_3_14159]=_314;_3_141=_3141592654+__3_1415;_3_1415= __3_1415 +__3141;for (_31415 = 3141- __3_1415 ; _31415;_31415-- ,_3_141 ++, _3_1415++){_314 +=_314<<2 ; _314<<=1;_314+= *_3_1415;_31 =_314159+_314; if(!(*_31+1) )* _31 =_314 / __31415,_314 [_3141]=_314 % __31415 ;* ( _3__1415=_3_141 )+= *_3_1415 = *_31;while(* _3__1415 >= 31415/3141 ) * _3__1415+= - 10,(*--_3__1415 )++;_314=_314 [_3141]; if ( ! _3_14159 && * _3_1415)_3_14159 =1,__3_1415 = 3141-_31415;}if( _314+(__31415 >>1)>=__31415 ) while ( ++ * _3_141==3141/314 )*_3_141--=0 ;}while(_3_14159 ) ; { char * __3_14= "3.1415"; write((3,1), (--*__3_14,__3_14 ),(_3_14159 ++,++_3_14159))+ 3.1415926; } for ( _31415 = 1; _31415<3141- 1;_31415++)write( 31415% 314-( 3,14),_3141592654[ _31415 ] + "0123456789","314" [ 3]+1)-_314; puts((*_3141592654=0 ,_3141592654)) ;_314= *"3.141592";}
|
* This forum needs formatted textby qbguy (no login) |
* shell "cmd /c start www.piday.org/million.php"by qbguy (no login) |
* Or shell "start www.piday.org/million.php" on WIN98 OR LOWER!!!by qbguy (no login) |
*<insane>That's my favorite site of every year! I'm not kidding either...</insane>by rpgfan3233 (no login) |
Follow your own advice, eh?by (no login)I've seen you flaming plenty of people, so for you to tell someone else to stop flaming people is a bit of ironic hypocrisy. Fortunately, I haven't seen you flame anyone recently. Maybe you're changing for the better. Here's hoping. |
I need help RE: the last parameter in the PAINT statementby (no login)I'll try and solve this myself tonight but... PAINT (x,y),[color|patternstring],[backgroundcolor],[maskstring] patternstring was difficult enough for me to investigate but I've got in figured out except for 4 color modes. maskstring has me totally baffled but I haven't investigated it enough yet. Anyone an expert on this...? Thanks, Galleon PS. In all honestly I didn't know PAINT accepted string parameters until yesterday! If you don't know what I'm talking about try this... SCREEN 13 PAINT (0,0),"ABCDEFGHIJKLMNOPQRSTUVWXYZ" 'taste the stripy rainbow! |
Interesting -----^^0^^by (Premier Login iorr5t)Forum Owner I note that CLS is required before every PAINT that is to be honored. Mac SCREEN 13 FOR i = 1 TO 26 PAINT (0, 0), LEFT$("ABCDEFGHIJKLMNOPQRSTUVWXYZ", i) SELECT CASE INPUT$(1) CASE "c", "C": CLS CASE CHR$(27): EXIT FOR END SELECT NEXT i SYSTEM QBasic rules. |
Research on PAINT statement complete! (valuable QBASIC info here +examples)by (no login)I've spent (wasted?) a good number of hours investigating string arguments for the PAINT statement and am confident I have understood how it works. (x,y),[color|patternstring],[backgroundcolor],[maskstring] Important points: The patternstring contains bit-data identical to that stored by a graphics GET statment of an image to tile whilst painting, just without the width or height specified. The width depends on the screen mode: 256 color modes: width 1 pixel 16 color modes: width 8 pixels 4 color modes: width 4 pixels 2 color modes: width 8 pixels The height of the tile depends on how many pixels worth of data are represented in the string. Example #1: SCREEN 7 PRINT "A" DIM a(1 TO 18) AS INTEGER GET (0, 0)-(7, 7), a(1) FOR i = 3 TO 18 p$ = p$ + MKI$(a(i)) NEXT CIRCLE (160, 100), 80 PAINT (160, 100), p$ There are some catches that apply when tile painting: 1. If you don't specify the background color, it is white or whatever you have selected as the current QBASIC color. The tiling will ALWAYS stop at this color and you cannot override this. 2. There is another reason why tiling can stop. It stops IF THE PIXEL IT WILL SET IS ALREADY THE COLOR IT WILL SET IT TO. This only applies to tile painting! The mask-string effectively specifies only 1 single colour despite storing its data in a string containing what could potentially be 100s of pixels (I have tried many ways to prove this fact wrong!). If it gets to a pixel of this color on the screen it WILL SKIP CHECK 2 mentioned above for that particular pixel but still perform check 1. Specifying this color varies depending on the screen mode: 256 color modes: m$=CHR$(maskcolor) 16 color modes: m$="" if maskcolor&1 then m$=m$+CHR$(255) else m$=m$+CHR$(0) if maskcolor&2 then m$=m$+CHR$(255) else m$=m$+CHR$(0) if maskcolor&4 then m$=m$+CHR$(255) else m$=m$+CHR$(0) if maskcolor&8 then m$=m$+CHR$(255) else m$=m$+CHR$(0) 4 color modes: if maskcolor=0 then m$=CHR$(0) if maskcolor=1 then m$=CHR$(128+32+8+2) if maskcolor=2 then m$=CHR$(64+16+4+1) if maskcolor=3 then m$=CHR$(255) 2 color modes: if maskcolor=0 then m$=CHR$(0) if maskcolor=1 then m$=CHR$(255) Example #2: SCREEN 13 PAINT (160, 100), CHR$(1) + CHR$(2), 15 PRINT "The pattern" DO: LOOP WHILE INKEY$ = "" CLS LINE (0, 50)-(319, 50), 1 PRINT "A line" DO: LOOP WHILE INKEY$ = "" PAINT (160, 100), CHR$(1) + CHR$(2), 15 PRINT "The pattern is blocked by the line even though the border color is white because the destination pixel was already the color the pattern would have set it to!" DO: LOOP WHILE INKEY$ = "" CLS LINE (0, 50)-(319, 50), 1 PRINT "The same line" DO: LOOP WHILE INKEY$ = "" PAINT (160, 100), CHR$(1) + CHR$(2), 15, CHR$(1) PRINT "The pattern was able to paint over the blue line and continue because a background string was specified!" I hoped this helped someone. To my knowledge this is the only post on the net where you can find any technical information about the background string. Cheers, Galleon |
I could have told you that!by Earthborn (no login)This is fairly common knowledge for people who ever read a GWBasic manual when CGA resolutions were the rage. It was primarily used to fill stuff with patterns on monochrome screen resolutions. Here is a good description of how it works: http://www.ojodepez-fanzine.net/network/qbdl/GW-MAN/PAINT.html (thanks to the GWBASIC user's manual: http://www.ojodepez-fanzine.net/network/qbdl/GW-MAN/PAINT.html) Still striving to get QB64 to respond exactly the same as QBasic? Read this: http://support.microsoft.com/kb/79046 |
Thank you very much Earthborn!by (no login)I already knew about the Microsoft link to the problem which causes an error and other Microsoft pages about the PAINT statement. I didn't know about the gwbasic site's information about the PAINT statement. It's by far the best description (however still not nearly as clear as it could be) of how the background string works that I've found. Although it didn't give me any new information as such, it clarified a lot of my research. I'm surprised I was able to deduce as much as I have correctly purely through investigation. I'm particularly happy it validated my observations that the background string only really defines one color. One statement in the gwbasic site's info still baffles me: "You cannot specify more than two consecutive bytes in the tile string that match the background attribute. Specifying more than two results in an "Illegal function call" error." I can understand what they are saying and can make this error happen but my question is WHY this should cause an error? Any ideas? Thanks again, Galleon PS. Now I can actually begin coding again! |
Any plans for an IDE?by (no login)Probably already been mentioned before, but what are the plans, if any, for an official IDE? |
You see that's the beauty of it; we already have one.by Pete (no login)It's called QB 1.1, 4.5, or PDS. All run in Vista. When you are 100% QB compatible, you don't need an new IDE. I can run up to 300K programs in the 4.5 IDE, just fine. If anyone makes single programs larger than that, then they would have to write it in a different editor. Either way, all code would have to be saved and compiled from the command line or an easy to program QB64 compiler utility. Pete |
*you've gotta be kiddingby mennonite (no login) |
Well, that's not so badby (no login)although a proper implementation wouldn't hurt either. Not everyone's going to want to use that clunky old blue-screen-of-slowness and are going to want a more modern IDE made for their OS of choice. |
oh i like the lookby mennonite (no login)i like the one in freepascal, too. but the idea of qb64 is to run where qb can't, right? i would like to see qb64 running in a variety of ide's but come with a native one very similar to qbasic. being interactive is actually one of the things that makes basic basic, but the ide is the smallest of the important issues, in my opinion. to other people it matters more. i'm also looking forward to qb64 being less limited than qbasic, but i think compatibility should be the first issue. |
Not kidding...by Pete (no login)And if I was Galleon with my finished compiler, I'd tell the first person who asked: Hey, where's the IDE? To take his keyboard, turn it sideways, and I'm sure you know the rest. Getting the compiler is a must. Getting an IDE would be a neat project for someone else to do, unless Galleon feels he is up to it. Until then, I'll use the QB IDE and compile my programs from the command line or use one of my command line SHELL routines to compile my programs in QB64. That is if I code in QuickBasic, QB64, or any other language in the near or distant future. Pete |
"where's the ide" is a valid question, thoughby mennonite (no login)qbasic just wouldn't be qbasic without "run." hell, even rom basic for the pcjr had that. you and i have both been doing this for more than 20 years, but you've forgotton what it's like to learn basic, and sound like one of the guys at fb.net. even nek posted something more open minded, although i figure he doesn't think it's a requirement either. oh i could make something that was suitable for my own use in qb64 or even dos batch if there was no ide, but there's a reason people ask. |
and as far as criticism from eponasoft goesby mennonite (no login)i'm glad someone fairly reasonable is here to offer intelligent criticism. i may only agree with some of the conclusions he reaches, and some of his arguments, but there are probably a few things we can learn from him, and even from fb, even if i think fb will likely have more to learn from qb64. then again i think eponasoft probably underestimates galleon. i think a number of people are telling him things he already knows, but i'm willing to also. i also don't have the galleon=god thing that many people have for v1c. so far though, galleon is pretty awesome. as i mentioned, i was feeling the way you were, until i tried qb64. it's already fun. |
Everyone's a critic :-)by (no login)I don't underestimate Galleon (it's against my philosophies to underestimate a fellow programmer), but I'm afraid he's underestimating the level of work he's getting himself into. It's great to have ambition, but ambition isn't enough; it has to be backed up with the means of bringing those ambitions to fruition. A compiler is a *massive* project that requires a high level of technical ability, especially if you're trying to develop one on-par with a Microsoft effort. As far as the Galleon vs v1c "who is god" thing...well, I see it in both places (fb.net and here), and it irritates me equally in both places. That's why I rarely post at fb.net, and that's why I have a major problem with the ass-kissing here. QB64 won't be "fun" for me until it gets some basic (pun unintentional) features that it should already have; I think I've mentioned what they are enough times. And even then, coding for me is all business; the fun is only in the finished product. By the way...don't count on the FB developers learning much from QB64. Remember that 100% QB compatibility is the goal of THIS project, not theirs. However, expect some fierce competition from them in the coming months; the FB project has several highly skilled developers working on it, all with past experience. While I didn't originally think a real competition would break out between the two, now it seems inevitable. Galleon's going to need help eventually, and not in the form of parrots and zealots spamming up other forums. |
But parrots are fun... They can bite your worst enemy's fingers off!by rpgfan3233 (no login)On a more serious note, Galleon <> "God" as far as I'm concerned. However, I do agree that he has chosen a very difficult project. Considering the fact that he is working on it himself, only using others as bug testers and the like, I'd say that he's pretty far along already. I'm no suck-up, but I do congratulate someone when they deserve it, even if I get a bit too enthusiastic. ^_^ Okay! Back off-topic! Who knew that one could represent so many emotions just by typing them, using text to create smilies or to shape the mood of the words like a story? ^_^ Go, Kirbies! (>^.^)><(^.^)><(^.^<) |
long reply about people and crap like that (*url)by mennonite (no login)this was meant to be a few paragraphs, i ended up writing more. i'm certainly not going to try to make anyone go here: http://www.network54.com/Forum/183705/message/1199448642 |
RE: IDE for QB64by (no login)IDE or DIE? That is the question... =================================== 1. QB64 will need an IDE 2. There is no point having an IDE until the compiler is primarily complete. 3. There are benefits in regards to instant debugging info without noisy file access and the ability to update the IDE as the compiler develops easily by having the IDE as a program written in QB64 as a MODULE which COMPILE.BAS could optionally be compiled with to create an integrated IDE such in QBASIC. If I write an IDE, it would be of this type. 4. Nothing is stopping anyone else from writing an IDE for QB64. If it's good, I'll include in on the official QB64 site (which doesn't exist yet). |
*that's basically what i figuredby mennonite (no login) |
|
What do you plan to add beside all QB commands?by (Login Tusike)I mean are you going to have a function for loading bmps or midi files, or the mouse? And what will the highest screen resolution possible be, 640 * 480 or higher? I got interested in this project. -Tusike |
* The current plans are to just get QB commands working. Extras can be worked in later.by Do you know the Plan9 Man? (no login) |
*I thought soby (Login Tusike)* |
|
|
*Any ideas? What should I code, if I can?by (Login Tusike)* |
Hrmby (no login)The intention is true QBASIC compatibility, which means 640x480 would be supported with 16 colors (SCREEN 12). That's the best you're going to get for hi-res natively. On a more personal note though, I'd hate to see MIDI supported unless someone had plans to use it for its intended purpose: MIDI hardware. Besides, there are always libraries that can be used for music playback, such as Bass, FMOD, dumb, mikmod, etc. Once QBASIC is fully implemented (harder than it sounds), I just hope Galleon has the foresight to allow external libraries to be linked in (this won't be hard whatsoever, a mere afterthought even...it's really *that simple*, and I speak from experience). The icing on the cake would be full support for OOP libraries; I'm personally longing for a BASIC compiler that can handle Irrlicht natively without getting stupid (*cough* DarkBasic). Since QB64 compiles to C++, this shouldn't be a problem down the road. Once QB64 has proper function support (why it doesn't yet is beyond me), I'm going to write some QB lib remappers for people who might want to port old QB games. Since there's no way in hell QB64 is ever going to be able to support things like DirectQB natively, a library to remap its functions would be in order. That way, people could recompile their lib-laden QB games in QB64 without a hitch. I've already got a working prototype of a GDM playback library for Windows that could also be easily ported to *nix. |
I see no reason why SCREEN 12 or any other screen mode would only be able to use just 16 colors. If more colors are made available, old code would still be compatable and new code could do much more. SCREEN 13 uses the same first 16 colors after all. Compatability just means that any new functions will be under different names when they are added. Ted
|
Sure it wouldby (no login)If you try assigning more colors in a mode that doesn't support it, you get an ILLEGAL FUNCTION CALL. Go ahead and give it a try; do a SCREEN 12 and then do something like PALETTE 19, 2 and tell me what you get. You would have to write new code to take advantage of new features anyways, which means that the core functionality of SCREEN would have to change by either taking on additional parameters or adopting new screen modes. SCREEN 12 *can never support more than 16 colors* when implemented 100% accurately to QBASIC's limitations. It's a hard fact. Using a 640x480 graphics mode in more than 16 colors is no longer SCREEN 12. |
limits vs. incompatibilityby mennonite (no login)there are times when extending the limits of something makes it incompatible, and generally i'm in favor of using new statements to extend what a language can do, so long as it doesn't keep existing code from working. i can easily imagine code that could have a problem if mid$() suddenly accepted negative variables, a lot more easily than i can imagine it being a problem if you can now color 47 in screen 12. or what if you could color screen 47, 250? in screen 12, background colors are not accepted. by the way, color 19 is a color in screen 0, but i'm not absolutely sure that you can use palette on it. i should actually say it's an attribute, it's color 3 blinking. in screen 12, if you use a color past 15, you get white or black. a program that would use that would suddenly find it is showing more colors, so you're right. but within reason, it's possible to extend the language and be compatible enough, although people should be too careful. it's a lot more possible than if you try to rewrite the language before it's implemented, or consider extending the language (or feature requests) more important than the first goal of the project. i think qb64 will be closer to 100% than freebasic, because that's the first goal of the project. it will be 99% at most, but it matters which 99%. it's clear that galleon understands priorities, but you're right to warn him. if you look at my post about mid$ and space$ i did too. no one should really use the number 100%, ever, but we do- because it's what some of us are aiming for. can you extend and also aim for 100%? oh sure. absolutely, even if it means you won't get there. but compatibility is still *the* thing, not lack of features. you're right that it's a compromise. hopefully qb64 will have the right 99% mix, and never stray below 98, or deprecate compatibility. |
and if that's not close enoughby mennonite (no login)then he always has the option of creating _color and _palette and _screen i found another project that uses his naming scheme, there was some code on the autoit forum that uses _playsound, a custom routine. playsound is a routine that exists native to autoit or an extension that _playsound uses. of course i think rather than add more colors in screen 12 or 13, galleon should just make a screen 14 and 15. i used to use a loop, error handling, and screen variable to find which screen modes were available in qb. |
SCREEN extensionby (no login)What I had suggested to v1ctor in the early days of FB was to extend SCREEN to include VESA modes. Seems no one liked my idea very much though, but it made perfect sense to me since I had already been using VESA in pure QB for ages. In any event, here's a list of the available VESA modes: http://en.wikipedia.org/wiki/VESA_BIOS_Extensions By the way, my PALETTE example would set palette index 19 to RGB(2,0,0) (remember that SCREEN 12 is a VGA mode, therefore uses RGB rules [B<<16 + G<<8 + R] rather than the built-in 16 color palette). In SCREEN 12, this generates an ILLEGAL FUNCTION CALL. It works fine in SCREEN 13 though, since 19 is a perfectly legal palette entry. |
no one likes vesa, do they?by mennonite (no login)i don't have to tell you that i'm not an expert with stuff like that, all i know is that arachne worked beautifully on so many dos machines using vesa modes. but that was vesa 2, right? and if fb uses any vesa, it's vesa 3? there's all kinds of stuff you need to know to make graphics reliable. arachne knew, qbasic knew, and hopefully galleon will listen to someone that knows if he ever makes qb64 work with a real console. right now i assume he's only working with sdl, but that's about as reliable (very) as qbasic in dosbox, and a lot faster. |
VESA and whatnotby (no login)I would assume that the MSDOS port of gfxlib2 uses VESA. But my idea was to simply use the numbering scheme VESA adopted prior to 2.0. It's clean and doesn't require SCREEN argument changes. I'm personally not a fan of using SDL whatsoever, but if it works, then it works. Clearly it's going to be the easiest method available, since SDL exists on all the major platforms (even FreeBSD, my Unix of choice). |
sdl isn't my choice, but of things that aren't my choice, it's greatby mennonite (no login)it's a choice for compatibility with many environments. i hate to see a total lack of console support in qb45, how do you copy and paste text? but despite that, it's running and well. perhaps there will be a way to enter an actual console mode, without syntactic doo like _console.print. i'd be happy with screen -1 or even _screen -1, but sdl will be easier once you can write files in demo 5. by the way, ever set a window screen mode for 1024x768 and get a window plus almost 1024 and almost 768? |
Wait a second...by (no login)There's no console mode? |
all i know is that screen 0 appears to be sdl stillby mennonite (no login)i mean screen 0 works beautifully, but you can't copy text like from a real console in windows. pete makes a really good case for sdl, mentioning that vista (one of the reasons for qb64) won't show any console apps fullscreen. i haven't tried alt+enter. last time i did that in sdl/dosbox/supertux i had to restart windows and change the resolution. |
Really in QB all console mode is really all there is...by Pete (no login)What's the other mode, well Windows of course so I really don't understand your question. Galleon has the SDK that allows QB64 to run a screen zero text application in FULL SCREEN in Vista. That is more then FreePascal or FreeBasic has been able to accomplish. From a prior Eponasoft post: >"I have a major problem with the ass-kissing here."< My response, up yours! No one is kissing anybones behind at this forum. You came here from that idiotic FreeBasic site, so maybe you don't know any better than to make such a stupid statement here. Pete |
mennonite defends fb?by mennonite (no login)no, one of the main differences between fb and qb64 is i actually like qb64 (another is basic.) eponasoft is from fb.net, but most of fb.net is from here, or somewhere that used to be like here. just like you do pete, eponasoft has his own idea of what bs is, and dislikes it, just like you and i do. apart from that one time (or two, i dunno) that he attacked me on fb.net (i'm not pretending we're friends anyway) eponasoft makes a lot of sense. we don't always agree, but if we did, that would be odd. there's got to be something that a person earns for being one of the more reasonable people to go to fb.net and leave. respect? highly priced around here, i can't even afford the counterfeit variety from pete berg and his team of experts that live with him and tell him what fb is (he's never used it.) decency? well, we all argue sometimes. how about a slightly open mind? contrary to popular myth, i like to offer that whenever possible. i think eponasoft has earned at least that just by being intelligent and not spewing hivemind at us, whatever my opinion means. but i've always tried to be honest, and honestly, i don't think eponasoft is being totally unreasonable. 50% reasonable? more? i dunno, but reasonable enough. as for freebasic, it works great in the console, and freepascal is even better with that. qbasic is better still, until you want more than 80 columns. you can blame eponasoft when he corrects you for being unfair, but you can't blame him for being wrong. fb does what it does. it's not what you or i want, but except for pcopy (in earlier versions,) working with the console is not one of fb's shortcomings. i know, i've written a lot of stuff for the console in fb, for what, a year or two? |
Ass-kissing? I'm not going to put up with that crap here at all. You can if you want to, but not me. And FB and FP do not run full screen console apps in Vista, period. QB64 does. I don't really give a rot13-ascii about the lines of resolution in any of them. Pete PS Yeah, you were open-minded alright - which cost you a waste of time FBing around for the past year. I'll stick with my closed-mindedness, because at least it recognize a piece of absolute crap when it sees it. |
|
But LOL, you made me laugh. You know though, when I was a kid, I wished the Los Angeles Rams would move to Tijuana. They did move south, but South East, oh well. I've always been a Niners fan for the most part, Joe Montana days. Long story short, I like winners. FB is not a winner. QB64 is a much better idea. Galleon has a lot of work, that's for sure. I can't help him. I don't know enough C. I can only write keyboard routines, etc. in C. Again, of little to no help. I do have experience with making large apps though, so I'm not going to yack about it's too big to do. It isn't, it just takes a lot of dedication, focus, time, and tenacity. Galleon can finish it. It's just a question of when he can finish it. As far as this IDE stuff goes, I hope Galleon can appreciate what I'm doing for him here. It amazes me how when someone works night and day on a huge programming project, some other senseless bozo comes along and expects the next thing before the first thing is even anywhere near completion. "One damn minute Captain," to quote Mr. Spock from the best Star Trek movie, ever. (The whale should have won the best actor award, but that's just my opinion.) Pete |
man i hate it when you go elitist. senseless bozo?by mennonite (no login)explain this pete, how is someone a "senseless bozo" for asking about a feature that the project leader was and is actually planning? no one asked you to code anything, in fact no demands were made of anyone, IT WAS JUST A QUESTION! also explain how someone is supposed to use the ide from qb (as you suggested was a reasonable solution) if one of the the points of the project is to work in vista without dosbox, when said ide will not always work without dosbox? |
As long as it is 32-bit Vista. 64-bit anything, then no. What I hate is when people get unreasonable expectations. My apologies if you were the senseless bozo that wanted the IDE. I'm not keeping track of who said what about it. Pete |
IT DOESNT MATTER WHO SAID ITby not really the rock (no login)it was a reasonable request. "64-bit anything, then no." what the **** is the project called, pete? |
|