Everything you mentioned is what QB64 is all about....by (no login)SXO-XD: "Some QB compatibility is missing, but I doubt QB64 will ever add all this compatibility.For example, ON KEY and ON TIMER go to a certain line number or label when triggered; how does QB64 plan to do this? ON TIMER could easily work in a separate thread, but then how will it GOTO / GOSUB, as opposed to calling a certain SUB?" A thread isn't the only way to implement an ON TIMER or ON KEY equivalent. That can be accomplished without threads. But even if he did use threads, within the thread it can probably be managed pretty easily. But this is what QB64 is all about, to implement these things and so far Galleon has shown that he's taking this aspect of QB64 very seriously. So I for one am not worried by what hasn't been done yet because what has been done yet speaks for itself. XO-XD: "Once QB64 is somewhat complete, which will be in a very long time, problems like this will keep QB64 from being any more QB-like than FB." I want a copy of your crystal ball man. But first off, What makes you think they are problems to begin with? Did Galleon state that? Did you email him to ask him about these issues? Did you read somewhere, from him (Galleon) that he had yet to figure those out and wasn't sure what to do about it? I'm not saying you're right or wrong about this, the only one that can really answer this is Galleon. But so far he hasn't had a problem going after what was next on his list. If he does one of these (or all of them) and you try it and it doesn't work as expected (IE works as it does in QB) then you can come here and state something like this. But right now it's not implemented, so only a crystal ball like yours can come to this kind of conclusion without much to back those conclusions up. Sure seems easy to comment on what hasn't been done yet isn't it. <-- Pete's pop Stand --> ;-) hehe XO-XD: "So to wait for QB64 instead of FB is quite laughable, IMO - especially since Galleon will probably be tired of this in another year, and hasn't found anyone to keep the project going without him." Clearly you haven't done very big (read huge) projects that make use of QB's specifics. It's been said before, some people have very large QB programs that work the right way because they used QB specific things that just can't be found in FB (under and -lang switches). Some are multiple executables some pushed that forward to the PDS and use overlays. The point is, it's not that hard to make a several thousand lines of code for a QB app (even if it was broken down into more than one exe to get the job done). It's not very enticing for these authors to sit down and "update" their code to compile under any other compiler (fb included but any other). To them, porting would become more hectic than just sitting down and redesigning/rewriting their programs from scratch just to make that program work optimally in the new language (whichever that language may be). To these people (and there are more than you probably think) porting is not the best option. They'll either rewrite them from scratch or wait till they can compile it under QB64 Because of all the specific QB coding they had to use to get their program to run optimally in QB (and I'm not just talking game projects either, applications too). As far as Galleon getting tired and not finding anyone to keep the project going without him. So far, that's not part of his plan clearly. But it's open source, so should a day like that happen, I don't think it will be that hard for anyone to get familiar with the code and keep it going. And since QB64 is self compiling right now, continuing the project doesn't even specifically mean having to code in C++ to do so. hence, you were saying? ;-). Commenting on what hasn't been done yet like this post of yours did is very counter productive to the project. It has no constructive or helpful purpose. Since QB64's goal is to be QB compatible to a much higher level. Whatever is in QB and isn't in QB64 yet will be in. So until galleon has tried to put it in there's no point in commenting on it. It's that simple. So far, in 6 demos (6.1 demos) QB64 is proving itself to be on the right track with the set goals. That's all I need to know right now. MystikShadows The American Express of the QB/FB community...Accepted Everywhere. ;) from IP address 69.205.201.142 |
| Response Title | Author and Date |
| Thanks MystikShadows | on Mar 13 |
| You missed the point of my argument. | XO-XD on Mar 13 |
| Nah, I know you're point...The point is not the problem. | on Mar 13 |
| * You mean "I know your point" | Grammar Police on Mar 13 |
| * His POINT is on top of his freaking numbskull brain! | on Mar 13 |
| * The EXE is public domain -- disassemble it if you want | qbguy on Mar 13 |
| * It is public domain, but as XO said, it certainly can't be called "open source". | rpgfan3233 on Mar 13 |
| *"It's taken QB64 an entire year to compile itself;"? It's been sixth months | on Apr 3 |