I was recently asked for guidelines about the process for contributing to QB64's source code/core functionality.
I am supportive of ANY change to QB64 which:
1) Will not break existing functionality in any way
2) Is multi-platform compatible
3) Does not grossly/negatively interfere with the QB64 programming experience
4) Does not contain any known bugs
5) Is/Will be clearly documented so others can use it (either on the forum or in the WIKI)
6) Does not allow mixed language/CPU specific command integration (such as inline C++ code, assembly, etc)
7) Is not malicious in any way
Does your idea meet all of the above criteria? If so your next steps are...
1) Code it! (make sure you note any files you change and where for your own reference)
2) Submit it.
i) If you are a QB64 repository contributor, grab the latest version of the repository, make your changes and push them (I and the community will test the next dirty build [which is automatically created from the repository] and as long as it works, job done!) or...
ii) Become a repository contributor by asking me on the Q&A forum
Everybody has a different opinion about what QB64 can/should be. But unless we make it what the individuals in our community want it to be then we all lose. So even if we personally don't want/need things like...
- Path finding
- Sorting
- A suite of string commands
- University-degree level math operations
- A circle fill command
- ODBC functionality
- OOP
- Name spaces
- Option explicit
- Web server interoperability
- Nullable/Reference types
...someone does.
My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all. And if someone implements something incredibly stupid/unnecessary (such as a _HELLOWORLD command) the beauty of a repository is that it can always be rolled back later. Because of this philosophy, you won't see me standing in the way of any changes.
Does not allow mixed language/CPU specific command integration (such as inline C++ code, assembly, etc)
As for me i'd rather see type definitions that support arraysThat would be quite awesome.
Personally, I lack the ability. Let's hear from the community and my fellow developers.
Everybody has a different opinion about what QB64 can/should be. But unless we make it what the individuals in our community want it to be then we all lose. So even if we personally don't want/need things like...
- Path finding
- Sorting
- A suite of string commands
- University-degree level math operations
- A circle fill command
- ODBC functionality
- OOP
- Name spaces
- Option explicit
- Web server interoperability
- Nullable/Reference types
...someone does.
My new philosophy is to let QB64 be what the community want it to be. Even if we end up with 1000s of commands that barely get used by the majority, it is better than QB64 not being used at all.
'// Pure C Code allowed inside a Qb64 program would look like this and I am not a fan!
SCREEN _NEWIMAGE(800, 600, 32)
DO
_LIMIT 30
_DISPLAY
LOOP UNTIL INKEY$ = CHR$(27) '// Loop until ESC is pressed
SUB _GL
gdk_gl_sphere 100,50,50,false
END SUB
$CStart
#include <glu.h> // Include GL Utilities library
inline void GDK_GL_SPHERE(double Rad, int Slices, int Stacks, int Texture)
{
GLUquadricObj *x = gluNewQuadric();
if (Texture == 1 || Texture == -1)
gluQuadricTexture(x, GL_TRUE);
gluSphere(x, Rad, Slices, Stacks);
}
$CEnd
Well, i figured i'd see what it looked like and even at a most simple level I hate the way it looks! I've got no problem keeping my C/C++ code in .h files (once the linking problem is fixed i'll be a happy bunny).
Here's what i threw together (if we had the cross comaptabilty this would render a sphere...)
Unseen
Only thing I think which might be an issue with that approach is matching variable types. Even with streamline C, you'd probably need a DECLARE LIBRARY to set the types in QB64.