Can't Combine Title.bas and Game1.bas code in SDK

[blainelocklair]

Hello, everyone!

 

I'm working on a game project that will require some of the code from the title.bas file generated by the SDK and the game1.bas code. I can compile them both separately and run them just fine. If I put the title code on the top of a new file and then the game1 code underneath it, it will not compile. The compiler complains about the x variable at like 170 and any other variables in game1 not being previously defined.

 

Any ideas on why this is happening? I've saved my works up to this point as their own text files with the intentions of bringing in the code in lumps. Title screen, gameplay, music code, BMPs, etc. I can't get off the ground with it, though, because the title screen and game1 sample don't mesh.

 

What am I doing wrong?

 

Thanks!
Blaine

[+nanochess]

Hi.

 

Probably there is a statement saying OPTION EXPLICIT, this forces IntyBASIC to choke on any variable not declared previously.

 

The way to solve it is to remove OPTION EXPLICIT or add at start of your source:

 

DIM var1,var2,var3
DIM x
...etc...

for each variable before it's used.

[blainelocklair]

Yes, it sure does say that in the code. I will remove it and see what happens. What does that code line mean?

 

Thanks for being so helpful with my learning journey. I really appreciate it. I hope to pay it back and pay it forward soon with some fun games and helpful knowledge for others.

 

Thanks!
Blaine

[+nanochess]

Yes, it sure does say that in the code. I will remove it and see what happens. What does that code line mean?

It's an option for advanced developers as a way to know what variables are used and to avoid using unknowingly variables with grammatical errors..

 

I prefer to not show beginners OPTION EXPLICIT at start because in my humble opinion it slowdowns the learning curve.

[blainelocklair]

Excellent. Thanks again for your help! I'll keep plugging away and learning. Grateful to have such good folks to help me along.

 

Blaine

[+DZ-Jay]

Hi.

 

Probably there is a statement saying OPTION EXPLICIT, this forces IntyBASIC to choke on any variable not declared previously.

 

The way to solve it is to remove OPTION EXPLICIT or add at start of your source:

 

DIM var1,var2,var3
DIM x
...etc...

for each variable before it's used.

 

 

Blaine,

 

The IntyBASIC SDK includes the directive "Option Explicit" on new projects. This directive forces the declaration of all variables before utilizing them. This is considered good practice, for it makes the program code more deterministic, and easier to troubleshoot and debug when all your variables in use are declared. It also lets you catch silly typos: if all variables are properly declared, then the one that fails is probably misspelled.

 

Like nanochess said, you should use the "DIM" statement to declare all variables prior to using them. A good practice is to do this at the top of each module or procedure, to make it clear which variables are in use within that scope.

 

One alternative is to remove the "Option Explicit" directive. I personally, wouldn't recommend this, but it is up to you. What this will do is allow for "loose" use of variables: they do not need to be declared before using them. In my experience, this leads to spurious errors which are difficult to track when subtle typos are not caught. It also can hide variables which get buried deep in the code, where you have to scan the entire source in order to find which variables are in use.

 

Contrary to nanochess, I prefer to teach and encourage good programming practices to beginners because it leads to cleaner code that is easier to reason through, to maintain, and to troubleshoot. We've had several decades of computer science and discipline, so there is no need to go back to the cowboy days where everybody had to fend for themselves and figure out what works or not.

 

Like I said, it is up to you, but the SDK encourages the use of good practices, such as the use of constants, the separation of program functions into modules, and the proper declaration of variables.

 

I hope this makes it clear.

 

-dZ.

Edited December 1, 2018 by DZ-Jay

[blainelocklair]

Well, darn. I pulled out OPTION EXPLICIT from the start of the title screen, and the compiler went bonkers. Complained of constants,bas problems from about line 48 to line 48 to line 741. Complained primarily about redefined constants and invalid extra characters. Hundreds of errors listed in the compiler. I guess the title screen is dependant on the OPTION EXPLICIT requirement.

 

How do I go about combining the two, now that we have this info? Are the two sets of code just not compatible because of the need for OPTION EXPLICIT? I just tend to think of the coding in terms of modules. Sound is a module, title screen a module, game a module, and so forth. This way, I can focus on one at a time and keep them cataloged separately in case all of the code breaks soemwhere and just import them back into a new file without repeating any work.

 

How do I make them work together? Excited to see things starting to come together a bit in my brain with it all.

 

Thanks!
Blaine

[+DZ-Jay]

Well, darn. I pulled out OPTION EXPLICIT from the start of the title screen, and the compiler went bonkers. Complained of constants,bas problems from about line 48 to line 48 to line 741. Complained primarily about redefined constants and invalid extra characters. Hundreds of errors listed in the compiler. I guess the title screen is dependant on the OPTION EXPLICIT requirement.

 

How do I go about combining the two, now that we have this info? Are the two sets of code just not compatible because of the need for OPTION EXPLICIT? I just tend to think of the coding in terms of modules. Sound is a module, title screen a module, game a module, and so forth. This way, I can focus on one at a time and keep them cataloged separately in case all of the code breaks soemwhere and just import them back into a new file without repeating any work.

 

How do I make them work together? Excited to see things starting to come together a bit in my brain with it all.

 

Thanks!

Blaine

 

Nothing "depends" on the "Option Explicit" statement. It is a directive that enables a variable declaration constraint. When removed, the constraint is disabled.

 

What is it that you are trying to accomplish? Perhaps if you post some of your code we may be able to help.

 

-dZ.

[+nanochess]

I suppose you included two times the file Constants.bas

 

Remove the second mention of INCLUDE

[blainelocklair]

I'm just trying to figure out how to combine a title screen and the actual gameplay after it. I've tried several ways, but they all seem to fail. Basically, I just want to use a stock IntyBASIC SDK title screen, then move on to the game1.bas gameplay. I can write all the modules I want, but if I can't put them together, they're not worth a lot. Trying to solve the small stuff before jumping in to making a complete project.

 

I've attached a sample of what I'm trying to do. It's just the title.bas code with the game1.bas code right after it. I know I need to add the DIM statements, and will, but it seems to fail more than the few variables in the game1 code. I must be putting something in the wrong order or something simple like that. If it's just a matter of the DIM statements, I'll try them again. Tried it once but it didn't impace the error codes. I may have used them incorrectly, though.

 

Again, thanks for all of your help!

 

Blaine

aatest01.bas

[blainelocklair]

Ok, I got it! I removed the 2nd reference to constants.bas and added the DIM variables statement in a single line of variables right before they are used. Worked exactly as expected. I'd just need to set the background color to black after the title screen and all will work exactly as expected.

 

You guys rock! Thanks for putting up with me while I'm on the learning curve. I'm sure I'll have some more questions along the way, but I think I might be starting to string this stuff together in my melon. See, you can teach a Sneetch, in spite of what Dr. Seuss said.

 

Just as a quick note for future use for others searching or reading, I wrote the DIM statement for game1 directly before the X = 10 variable with this line of code:

 

DIM X,S,WAVE,STATE,BY,BX,EY,EX

 

Once they were defined as being variables, the assembler rolled right through the process with zero errors.

 

Thanks!
Blaine

[+DZ-Jay]

Blaine,

 

In the SDK, the expectation is that you create a new project and it already includes its own title module, imports the "constants.bas" module, and provides a "main" module where everything is set up and ready for you to add your own code. You can then create additional modules by "including" them from the "main" one.

 

However, if you take two different projects which have already been created to stand on their own (like you were trying to do), you can't just munge them together blindly -- you have to see what dependencies and commonalities exist between them. First and foremost, you must remove any duplicate references to the "constants.bas" and review any variable and constant declarations to make sure there are no duplicate clashes.

 

Perhaps it wasn't obvious to you, so let us make it explicit here:

The "constants.bas" is a global library of useful constants. The names of each constant and variable in a project must be unique. Therefore, you can only import a single "constants.bas" in your project. Multiple references to any module within the same project is bound to cause errors, since duplicate names may collide.

 

My recommendation is to keep all the "include" statements in the main module. That way you can plainly see that if any other module has an "include" statement, it'll probably cause trouble.

 

 

 

Just as a quick note for future use for others searching or reading, I wrote the DIM statement for game1 directly before the X = 10 variable with this line of code:

 

DIM X,S,WAVE,STATE,BY,BX,EY,EX

 

 

 

Keep in mind that since IntyBASIC is compiled, there is no constraint on the size of the source code. That is, you do not have to combine multiple lines together and remove whitespace for the sake of saving memory, like you would do with an interpreted BASIC.

 

That said, you should look for ways that make the code readable to you and easy to follow. Remember, you may know what it says and does today, but a week or two from now, it'll probably look like Chinese. We always should be mindful of our "future self," who's tasked with maintaining our code later on.

 

A few recommendations:

• Use good names for variables that are easy to reason through and whose functional meaning is obvious.
• Try to avoid variable names which are too long, a single mnemonic word or two should suffice.
• Avoid using multiple variable names which only differ by a single letter (e.g., PLAYER, and PLAYERS will be easily confused when reading the code).
• Avoid combining functionality on the same line, try to make each statement do one single job.
• Use white-space (with plenty of empty lines and indentation) to separate functionally distinct blocks of code, while keeping together related codes.
• Use comments judiciously throughout your code. Make sure to describe algorithms and functional aspects clearly, inline. Do not necessarily say what a line is, but what it does. (e.g., avoid "Sets x to 10" in favor of "Initializes horizontal position of sprite to middle of the screen."
• Whichever patterns you pick, make sure to be consistent.

I personally, like to use "DIM" per group of related variables. This not only makes it more readable for me, but allows me to make comments for each one individually that provides useful information. For example, instead of that long "DIM" statement you used, I would do:

DIM X          ' Horizontal position
DIM S          ' Something, something
DIM WAVE       ' A wave, whatever it is
DIM STATE      ' Current state
DIM BY,BX      ' Bullet coordinates
DIM EY,EX      ' Enemy coordinates

Of course, it is always all up to you, and there are no real rules, as you may noticed from all the examples. However, well written, organized, commented code is always easier to maintain and follow, and leads to less errors in logic. The most important thing is to be consistent in your patterns.

 

-dZ.

Edited December 1, 2018 by DZ-Jay

[blainelocklair]

Wonderful advice, DZ, and very much appreciated! It's been a while since I coded in BASIC, mostly HTML in recent years to get specific things done on an already existing web page or site. Glad to have your knowledge and wisdom as a part of my learning journey.

 

I think I am getting close to putting something together to play. I will keep plugging away and should have something fun to try out soon. I'll keep everyone posted.

 

Thanks!
Blaine

[+DZ-Jay]

Sure thing. Feel free to ask any questions, post your code, or report any errors.

 

-dZ.