12-26-2022, 12:35 AM
Welcome to the forums.
Lua could be less like Python, except for the pressure to "OOP". You need to get your priorities in order. Learning BASIC isn't going to increase your aptitude about Lua, and the other way around. QB64(PE) is a totally different world from what you might have seen and it's going to lead to more frustration if you don't take the time to learn, if you don't accept the important differences between QB64 programming system and an interpreter's programming system helped by a large number of libraries.
The two worlds aren't compatible. If you want to program a game with QB64(PE) you have to throw away what you have done with a different programming language, which doesn't belong in a beginner's tutorial such as class definitions and module dependencies. It's because QB64(PE) aims to be compatible with a commercial product sold in the late 1980's which then unfolded into an interpreter packaged with a different commercial product, for an operating system way more limited than Windows, Macintosh, Linux and even Free/Open/NetBSD.
One thing I must warn you about is that QB64(PE) does not support functions created by the program, which supports an unknown number of parameters. A function may not have the same name as another declared function nor a reserved word (cannot overload a function nor operator). It does not support more than one variable to assign on LHS, like Lua and Python could. QB64(PE) could support OOP in the future, in the style of Freebasic. For the moment, you may not declare functions and arrays inside an user-defined type (UDT, which is like "struct" in C, less like "class" in C++). If you need an array badly inside an UDT, you have to declare a _MEM variable and take the trouble yourself allocating its extent and getting and setting the data. The string handling in QB64(PE) is as good, if not better than that of Lua and Python. This is most important to cover up ommissions like the inability to overload a function with the number of parameters to pass it. Arrays in QB64(PE) are as limited as they are in C/C++, not like the complex and slow structures but which are convenient in the interpreted languages. One programming in Python doesn't even have to think about writing a hash table library -- it is "built in". With QB64(PE) there are implementations by different people, including one which is part of the source code of the programming system.
The way to do graphics, input method, music, threads and other things is different from Python strung with third-party libraries. That's why many programmers have given up doing ports, trying to choose what is most similar and changing the least amount of code lines and source files possible.
I don't know what you're trying to do with the game you're building. It might be possible in QB64(PE) to build a program that creates sliders and text fields and stuff like that, for user input. The problem is that the main way to communicate with other programs is with "SHELL" statement which is inefficient and contains a slight security risk. If you're unwilling to do the whole game in QB64(PE) then I suggest you continue studying into one of those interpreted languages, so you could finish your project. There is a way to interface between QB64(PE) and the third-party libraries but very few coders have attempted it, and the function prototypes have to be known (ie. name of function, what are the parameters, what is the return value, what is the expected duty of that function and more).
Lua could be less like Python, except for the pressure to "OOP". You need to get your priorities in order. Learning BASIC isn't going to increase your aptitude about Lua, and the other way around. QB64(PE) is a totally different world from what you might have seen and it's going to lead to more frustration if you don't take the time to learn, if you don't accept the important differences between QB64 programming system and an interpreter's programming system helped by a large number of libraries.
The two worlds aren't compatible. If you want to program a game with QB64(PE) you have to throw away what you have done with a different programming language, which doesn't belong in a beginner's tutorial such as class definitions and module dependencies. It's because QB64(PE) aims to be compatible with a commercial product sold in the late 1980's which then unfolded into an interpreter packaged with a different commercial product, for an operating system way more limited than Windows, Macintosh, Linux and even Free/Open/NetBSD.
One thing I must warn you about is that QB64(PE) does not support functions created by the program, which supports an unknown number of parameters. A function may not have the same name as another declared function nor a reserved word (cannot overload a function nor operator). It does not support more than one variable to assign on LHS, like Lua and Python could. QB64(PE) could support OOP in the future, in the style of Freebasic. For the moment, you may not declare functions and arrays inside an user-defined type (UDT, which is like "struct" in C, less like "class" in C++). If you need an array badly inside an UDT, you have to declare a _MEM variable and take the trouble yourself allocating its extent and getting and setting the data. The string handling in QB64(PE) is as good, if not better than that of Lua and Python. This is most important to cover up ommissions like the inability to overload a function with the number of parameters to pass it. Arrays in QB64(PE) are as limited as they are in C/C++, not like the complex and slow structures but which are convenient in the interpreted languages. One programming in Python doesn't even have to think about writing a hash table library -- it is "built in". With QB64(PE) there are implementations by different people, including one which is part of the source code of the programming system.
The way to do graphics, input method, music, threads and other things is different from Python strung with third-party libraries. That's why many programmers have given up doing ports, trying to choose what is most similar and changing the least amount of code lines and source files possible.
I don't know what you're trying to do with the game you're building. It might be possible in QB64(PE) to build a program that creates sliders and text fields and stuff like that, for user input. The problem is that the main way to communicate with other programs is with "SHELL" statement which is inefficient and contains a slight security risk. If you're unwilling to do the whole game in QB64(PE) then I suggest you continue studying into one of those interpreted languages, so you could finish your project. There is a way to interface between QB64(PE) and the third-party libraries but very few coders have attempted it, and the function prototypes have to be known (ie. name of function, what are the parameters, what is the return value, what is the expected duty of that function and more).