Heh ...you open discusion on qb45 site and why not on qb64 forum...
is there forbiden or something?
Looking for former QBasic people to visit the qb64.net site.
-
E.K.Virtanen
- Posts: 785
- Joined: May 28, 2005 9:19
- Location: Finland
Both, FB and QB64 are great tools in what they are made for and has huge potential. Both are freezed due good reasons.
How about stop competing, but instead start to think what these two great tools could offer for each other?
There is times when everyone should stop themself and consider what they are doing. Might produce some good and updated ideas ;)
p.s As long as these two tools works, im happy and i dont care a s**t how they do it.
How about stop competing, but instead start to think what these two great tools could offer for each other?
There is times when everyone should stop themself and consider what they are doing. Might produce some good and updated ideas ;)
p.s As long as these two tools works, im happy and i dont care a s**t how they do it.
Do you like Visual Basic?roook_ph wrote:There is a gui program that good in fb? Tell me!Things who are missing in QB64 is the ability to create windows,buttons
editBox etc...
If yes, you can try with FireFly Visual Designer for FreeBASIC.
http://www.freebasic.net/forum/viewtopic.php?t=15796
There's already discussion going on at qb64.net I thought it would be good to meet on common ground (qb45.com is both for freebasic and qb64). I have posted the link to qb45.com also in that discussion.
I agree E.K.Virtanen, it would be nice to cooperate instead of competing, it's all BASIC after all.
I agree E.K.Virtanen, it would be nice to cooperate instead of competing, it's all BASIC after all.
Ok, in the download for Windows version it says 32-bit and 64-bit, I guess it's simply 64-bit compatible. Perhaps he is planning on a seperate version that is pure 64-bit? The Linux download says only 64-bit so that might be pure 64-bit already. Either way it says QB64 because it is intended for 64-bit systems as well as 32-bit and I guess that a pure 64-bit version isn't that far away.Plasma wrote:I don't know about Linux, but the Windows version certainly isn't 64-bit.Cyperium wrote:Plasma; QB64 is 64-bit, at least on Windows and Linux. It was named QB32 before the intention to make it 64-bit.
I just downloaded the latest version and ran it. Note the highlighted qb64.exe process. The *32 next to it indicates that it is a 32-bit process. Also note the 3dballs.exe process at the top. This is one of the QB64 samples compiled and running. It is also 32-bit.
-
659richard
- Posts: 5
- Joined: Aug 14, 2010 13:13
@Fmx
I use it for long now ( since i use Fb).
That was for QB64 Galleon will normally put those developments in a next futur of QB . I prefer to have those instructions in nativ QB64 langage than going by dll.
I use also Panoramic and i dont see why we should make war or discriminating one langage FB QB64 or Panoramic each of those have quality
and it up to us to use one or another in a new development.In fact it is up our
skill not the langage.
I use it for long now ( since i use Fb).
That was for QB64 Galleon will normally put those developments in a next futur of QB . I prefer to have those instructions in nativ QB64 langage than going by dll.
I use also Panoramic and i dont see why we should make war or discriminating one langage FB QB64 or Panoramic each of those have quality
and it up to us to use one or another in a new development.In fact it is up our
skill not the langage.
I suppose @Fmx is for me @fxm, but I do not understand the connection with my previous posts.659richard wrote:@Fmx
I use it for long now ( since i use Fb).
That was for QB64 Galleon will normally put those developments in a next futur of QB . I prefer to have those instructions in nativ QB64 langage than going by dll.
I use also Panoramic and i dont see why we should make war or discriminating one langage FB QB64 or Panoramic each of those have quality
and it up to us to use one or another in a new development.In fact it is up our
skill not the langage.
A 64-bit version that is trying for close compatibility with 16-bit real-mode QuickBASIC, so a small number of "old dogs" can avoid learning new tricks. I think it's time for a reality check.Cyperium wrote: Either way it says QB64 because it is intended for 64-bit systems as well as 32-bit and I guess that a pure 64-bit version isn't that far away.
I find it difficult to see QB64 being more beginner-friendly than FreeBASIC, as it exists and is designed primarily to run legacy QB code out of the box. This has forced some odd-looking code, like prefixing QB64-specific keywords with an underscore (what do beginners know or care about QB ?). Would be better to make those things optional for beginners and give the QBers a command-line option, but I don't think the dev has plans for this.
Another difference is that QB64 uses a graphic window for all screen modes, even the default text mode 0. So, traditional command-line and other text-mode apps aren't possible (I don't think there's currently a way to read/write stdin/out/err).
It's a bit unclear how QB64 will support multi-module programs and user-created libraries. Its ability to include arbitrary C++ (but can currently only use external C procedures) in the compilation has a neatness factor to it, but is sometimes necessary due to lack of pointers and UDT returns (I don't think you can pass UDT values or references -- at least I got g++ compilation errors when I tried -- and PEEK/POKE only access the emulated 16-bit memory). I imagine beginners will have a good ol time working with both the 16-bit and 32-/64-bit memory schemes if/when pointers are implemented. ;)
Another difference is that QB64 uses a graphic window for all screen modes, even the default text mode 0. So, traditional command-line and other text-mode apps aren't possible (I don't think there's currently a way to read/write stdin/out/err).
It's a bit unclear how QB64 will support multi-module programs and user-created libraries. Its ability to include arbitrary C++ (but can currently only use external C procedures) in the compilation has a neatness factor to it, but is sometimes necessary due to lack of pointers and UDT returns (I don't think you can pass UDT values or references -- at least I got g++ compilation errors when I tried -- and PEEK/POKE only access the emulated 16-bit memory). I imagine beginners will have a good ol time working with both the 16-bit and 32-/64-bit memory schemes if/when pointers are implemented. ;)
-
659richard
- Posts: 5
- Joined: Aug 14, 2010 13:13
Stylin; You do make good points, things in QB/QB64 aren't always simpler and I agree that making programs for 16-bit in a 32-bit environment might seem absurd (and that's probably also one of the reasons why it is so much slower than FreeBasic I might add, and why the exes are bigger too).
Still, there's a lot of things that a beginner will NOT have to worry about that a beginner would have to worry about in almost any language. Learning QB64 will enable them to learn the basic principles of programming without the frustration of "valid" code not working because it has to be setup a certain way, use a graphical screenmode and all the graphical functions will work, the only thing to worry about is that the _RGB functions only apply to 32-bit modes, set a= 3 and it will be = 3, you don't need to define it or anything. Galleon has talked about supporting pointers and I think it is on his to-do list (I even think he has reserved the @ symbol for that purpose but that's only my hunch).
(this is also for MichaelW:)
QB64 has plenty of space to evolve to more advance programming without breaking QB compatibility, and I personally think it's neat that it can support 16-bit ways of doing things. Galleon has talked about a _MEMCOPY command that will deal with 32-bit memory. So my feeling is that much of the advanced features not available will be available in the future.
I might also add that the 16-bit ways of doing things (to be compatible with QB) also work seamlessly with the 32-bit ways of doing things, you can get very far without any 16-bit ways though if you want to, it's simply a matter of how you use the language, people that have 16-bit code in QB can extend it to use 32-bit technology, etc. they can make their games into something that never would have been possible before without having to remake them completely in another language.
Also; Stylin; I guess that you've figured out my intentions with posting this thread here already, Unseen left because (as far as I can tell, and as I interpret it) the atmosphere was getting bad. I think we need some fresh ideas in the QB64 forum, I'm not trying to steal members here, I believe it's fully possible to exist in two forums without much fuzz.
As I've mentioned before I started a thread on qb45.com where it is more appropriate to discuss comparisons between QB64 and FreeBasic. So we should continue the discussion there FreeBasic AND QB64
To Richard (if you're reading this); I did try to "move" the discussion on common ground (qb45.com), my intent on continuing to mention QB64 is simply to answer others replies about it. I did understand the message long ago which is why I suggested to discuss it at qb45.com.
Still, there's a lot of things that a beginner will NOT have to worry about that a beginner would have to worry about in almost any language. Learning QB64 will enable them to learn the basic principles of programming without the frustration of "valid" code not working because it has to be setup a certain way, use a graphical screenmode and all the graphical functions will work, the only thing to worry about is that the _RGB functions only apply to 32-bit modes, set a= 3 and it will be = 3, you don't need to define it or anything. Galleon has talked about supporting pointers and I think it is on his to-do list (I even think he has reserved the @ symbol for that purpose but that's only my hunch).
(this is also for MichaelW:)
QB64 has plenty of space to evolve to more advance programming without breaking QB compatibility, and I personally think it's neat that it can support 16-bit ways of doing things. Galleon has talked about a _MEMCOPY command that will deal with 32-bit memory. So my feeling is that much of the advanced features not available will be available in the future.
I might also add that the 16-bit ways of doing things (to be compatible with QB) also work seamlessly with the 32-bit ways of doing things, you can get very far without any 16-bit ways though if you want to, it's simply a matter of how you use the language, people that have 16-bit code in QB can extend it to use 32-bit technology, etc. they can make their games into something that never would have been possible before without having to remake them completely in another language.
Also; Stylin; I guess that you've figured out my intentions with posting this thread here already, Unseen left because (as far as I can tell, and as I interpret it) the atmosphere was getting bad. I think we need some fresh ideas in the QB64 forum, I'm not trying to steal members here, I believe it's fully possible to exist in two forums without much fuzz.
As I've mentioned before I started a thread on qb45.com where it is more appropriate to discuss comparisons between QB64 and FreeBasic. So we should continue the discussion there FreeBasic AND QB64
To Richard (if you're reading this); I did try to "move" the discussion on common ground (qb45.com), my intent on continuing to mention QB64 is simply to answer others replies about it. I did understand the message long ago which is why I suggested to discuss it at qb45.com.
I came to FreeBASIC through the QBASIC 'backdoor' so to speak. Maybe the front door!? IDK. Anyhow, I had the most fun I've ever had in a programming language with good'ole QBASIC 1.1. Having said this, I believe that FreeBASIC is the place to be for anyone dissatisfied with QBASIC. I haven't tried QB64 yet and I don't intend to. However, If QB64 was indeed better, then I would say I would have found it first and fell in love with it instead of FreeBASIC.
QB eventually got old, as I expect FreeBASIC will soon enough. When that happens I'm not going to cling to it and be crippled with it for the rest of my life. Maybe I'm not sentimental enough. Programming languages are not people, therefore, they do not have hurt feelings. The only people that have hurt feelings, are the people using the programming languages who do not feel the need to move on and chart a new era in the history of programming languages.
Cyperium: You are doing a great job, and I hope that people interested in QB64 will open an account over there(if they haven't done so already), and contribute to some lively and profitable discussion. QB64 probably hits the spot for someone out there, and I don't want them to be driven away just because some noob with a pseudonym of 'qbworker' says that QB64 is not the way to go.
QB eventually got old, as I expect FreeBASIC will soon enough. When that happens I'm not going to cling to it and be crippled with it for the rest of my life. Maybe I'm not sentimental enough. Programming languages are not people, therefore, they do not have hurt feelings. The only people that have hurt feelings, are the people using the programming languages who do not feel the need to move on and chart a new era in the history of programming languages.
Cyperium: You are doing a great job, and I hope that people interested in QB64 will open an account over there(if they haven't done so already), and contribute to some lively and profitable discussion. QB64 probably hits the spot for someone out there, and I don't want them to be driven away just because some noob with a pseudonym of 'qbworker' says that QB64 is not the way to go.
You seem to miss the core premise of Stylin's post, namely that true beginners don't have 15 year old QB codebases.Cyperium wrote:Stylin; You do make good points, things in QB/QB64 aren't always simpler and I agree that making programs for 16-bit in a 32-bit environment might seem absurd (and that's probably also one of the reasons why it is so much slower than FreeBasic I might add, and why the exes are bigger too).
I also tried to point that out to you, namely that QB64 seems to target mostly "1990's beginners".
-
kiyotewolf
- Posts: 1009
- Joined: Oct 11, 2008 7:42
- Location: ABQ, NM
- Contact:
I'd go into a long back & forth over a LONG list of statements, pointing out why cross-pollinating versions of BASIC, that is ANSI BASIC, is meaningful.
Why do we re-write retro games as FB, or QB64? Because we look at code written in the past.
If we forget the code we wrote in the past, how can we know if an algo works or not.
~Kiyote!
This is stupid that we can't play nice in the same sandbox, whether there are idiots in the forums or not.
Those posts that were critical of FB excerpted from the QB64 forum, WHO CARES. One person with THEIR OPINION, or a small sect of people who share the same perspective.
There are people, who on a fundamental level, respond to
10 PRINT "HELLO WORLD"
20 GOTO 20
and
DO
PRINT "HELLO WORLD"
LOOP
and
TYPE HELLO_WORLD
HELLOWORLD.CONSTRUCTOR
HELLOWORLD.DESTRUCTOR
END TYPE
... <insert a correct OOP example here of a Hello World.>
QB = DOS / GWBASIC WITH NO LINE NUMBERS
FB = UNIX / C WITHOUT PROPER INHERITANCE
FB is a hack of C type functionality.
QB is a hack of GW-Basic without line numbers.
WE'RE ALL A BUNCH OF PROGRAMMERS IN FRONT OF TV'S WITH TAPE RECORDERS AND RETRO COMPUTERS DEEP DOWN INSIDE.
Why can't we just say "hey, that <type of> BASIC <ANSI BASIC variant> algo is cool!" and be happy that they didn't write it in psuedo code instead.
At least we WRITE our programs to WORK out of the door.
We don't sit there and shell out psuedo code to n00bs, and expect them to fill in the blanks, because if we did, they wouldn't get it anyways.
What would you guys do if I started using line numbers in FB AND QB64?
Probably shoot me, but I'd just say instead,..
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
... infintatum
Why do we re-write retro games as FB, or QB64? Because we look at code written in the past.
If we forget the code we wrote in the past, how can we know if an algo works or not.
~Kiyote!
This is stupid that we can't play nice in the same sandbox, whether there are idiots in the forums or not.
Those posts that were critical of FB excerpted from the QB64 forum, WHO CARES. One person with THEIR OPINION, or a small sect of people who share the same perspective.
There are people, who on a fundamental level, respond to
10 PRINT "HELLO WORLD"
20 GOTO 20
and
DO
PRINT "HELLO WORLD"
LOOP
and
TYPE HELLO_WORLD
HELLOWORLD.CONSTRUCTOR
HELLOWORLD.DESTRUCTOR
END TYPE
... <insert a correct OOP example here of a Hello World.>
QB = DOS / GWBASIC WITH NO LINE NUMBERS
FB = UNIX / C WITHOUT PROPER INHERITANCE
FB is a hack of C type functionality.
QB is a hack of GW-Basic without line numbers.
WE'RE ALL A BUNCH OF PROGRAMMERS IN FRONT OF TV'S WITH TAPE RECORDERS AND RETRO COMPUTERS DEEP DOWN INSIDE.
Why can't we just say "hey, that <type of> BASIC <ANSI BASIC variant> algo is cool!" and be happy that they didn't write it in psuedo code instead.
At least we WRITE our programs to WORK out of the door.
We don't sit there and shell out psuedo code to n00bs, and expect them to fill in the blanks, because if we did, they wouldn't get it anyways.
What would you guys do if I started using line numbers in FB AND QB64?
Probably shoot me, but I'd just say instead,..
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
HELLO WORLD
... infintatum
-
BasicCoder2
- Posts: 3906
- Joined: Jan 01, 2009 7:03
- Location: Australia
kiyotewolf wrote:
IMHO
JohnC
All code should be properly documented and explained in a natural language. I know how, for example, common algorithms like the Bresenham algorithm works and can code it in any language I know. Back when I was an assembler fanatic I had no trouble translating from Z80 to 6502 to 68000 to 8085 because I translated down not across. The best book I had at the beginning on assembler had no assembler code in it! But it did show how to translate high level pseudo code down to any assembler language.If we forget the code we wrote in the past, how can we know if an algo works or not.
Well I wish the old basic code was written out in psuedo code and properly documented it would have been a lot easier to translate.Why can't we just say "hey, that <type of> BASIC <ANSI BASIC variant> algo is cool!" and be happy that they didn't write it in psuedo code instead.
IMHO
JohnC