Phew! A
couple of questions!
Apologies for the couple of bugs. I added the code to centre the play area horizontally and missed updating the boundary checks. Updated code attached.
First things first. If you haven't already got them, grab these downloads:
AMOS Pro User Guide 1st Edition AMOS Public Domain Release 2AMOS is not an easy language to just jump into. I strongly recommend reading and working through the Basics section of the AMOS Pro User Guide. There's also the Tutorials section in your installation.
For any instructions you don't understand, just highlight it in the editor and click on the [H] icon (or press the [Help] key if it's an Amiga or the [F5] key if it's WINUAE running on a PC). That will bring up the help for that instruction. They're brief but usually give you the info you need. The User Guide also has an index to the instructions at the very end.
I'm assuming you're using AMOS Pro V2.0. If not you can download it here
AMOS Pro V1.0 AMOS Pro V2.0 UpdateA warning though. The AMOS development team rushed out the final release of AMOS (Pro V2.0) and there are some mistakes and errors in both the Help Files and the original User Guide. We're gradually working towards a redevelopment of AMOS Pro with the few bugs fixed and the documentation fixed. As you can imagine, this is a very big task for spare time work. So it's taking a while...
Okay, having got that out of the way.
What is the function right underneath the Wait Vbl right here:
Code: [Select]
If DC=0
Locate 10,23
Print Chr$(7);
Dec DC
Else If DC>0
Dec DC
End If
I do not understand what the command keyword Dec mean and what it does exactly...
The
Repeat ... Until loop executes once every 1/50th of a second (every 1/60th for an NTSC machine). So this code just counts down the
DC variable. When it reaches zero, it clears the "Invalid Action!" message by printing
Chr$(7) which clear to end-of-line. The variable is set to a value of 50 (1 second) when the message is first displayed.
The
Dec instruction subtracts 1 from a variable. Its partner
Inc adds 1. You'll also come across
Add variable, expression which does just what it says, it adds the result of
expression to the
variable. These instructions are much faster than using the usual
X=X-1 types of expression.
The other part of the code right underneath If MC=%1
Code: [Select]
X=X Screen(X Mouse)
Y=Y Screen(Y Mouse)
What is the purpose of this code?
The mouse coordinates are in hardware coordinate units. The
X Screen() and
Y Screen() functions convert these to screen coordinates. The code following uses instructions that recognise screen coordinates. So the mouse coordinates must be converted before you can use them.
For the CP, FH and FD part of the code I do NOT understand exactly what they mean and represent....second ...in this part of the code:
Code: [Select]
If CP=1
FH=False
If FD
' First dot to be hit, so no fancy checks needed:
Bell 80
Paint X,Y,2
FH=True
FD=False
How did you guarantee that FH would not be false again after you set it to true when CP=1? Wouldn't CP always equal to 1 when you do the click? Then wouldn't FH will always equal to false? So what is the point of setting it to true when CP will equal to 1 when you press the mouse button?
CP is the colour of the pixel given by
Point(X,Y). Used to check what the user has just clicked on.
FH is a flag used to indicate that a hit has been processed. Without it, the hit check code would be repeated up to four times, once for the each adjacent dot check, each time making a bell sound! Once a hit has been checked as okay,
FH is set to
True so that the other adjacent dot checks can be skipped to avoid this.
FD is a flag to indicate that nothing has happened yet. So it it's
True, no checks are necessary for adjacent dots (which is what the comment tells you!). When that first dot has been hit,
FD is set to
False so that the adjacent dots checks are done instead.
Another part of the program I am confused about is below this code
Code: [Select]
X1=X-8
Y1=Y
If X1>0 : Proc _CHECK_HIT[X,Y,X1,Y1] : End If
If Not FH
X1=X
Y1=Y-8
If X1>0 : Proc _CHECK_HIT[X,Y,X1,Y1] : End If
End If
If Not FH
X1=X+8
Y1=Y
If X1>0 : Proc _CHECK_HIT[X,Y,X1,Y1] : End If
End If
If Not FH
X1=X
Y1=Y+8
If X1>0 : Proc _CHECK_HIT[X,Y,X1,Y1] : End If
End If
Is the above line of code designed to check if a dot is adjacent to the second dot and if it is go ahead and put a dot there adjacent to that dot? It is a genius and much polished method of code than the way I have being doing it. Can you please explain how it works for me so I can learn in the future to do a better coding style and equation? Another question I want to ask you...why in every If statement you have you made them all If X1>0 : Proc _CHECK_HIT[X,Y,X1,Y1] : End If instead of some of them Y1 >0 or Y1<0 or X1 <0 or X1>0?
Sorry, I goofed on these lines after I'd added the
XO variable to centre the play area. The correct code is in the attached file. It's supposed to just check that the pixel we're checking is within the play area (and within the screen area!).
From you final comments, I can now see what sort of game you're trying to write. It would be better to go back to your original concept of using arrays to hold the playing area so you can make the necessary checks for a two-player game. It gets complicated at that point
but you'll work it out. Just dimension the arrays as (31,20)
not as an array for every dot on the screen! Each element in an integer array takes up 4 bytes. So 32 x 21 x 4 = 2,604 bytes (all arrays in AMOS Basic start at element 0). Your original array would have taken up over 175,000 bytes! Always be careful declaring two-dimensional arrays as they can quickly consume vast amounts of memory.
I'm not going to write the game for you as I'm up to my neck in re-writing AMOS Pro and its documentation. The sample code was just to get you headed in the right direction. But don't let that stop you asking questions. The replies may be a while in coming, but they will come
. But try spending a while working through the User Guide first. It explains a lot that would take me ages to tell you on the forum.
Author
Topic: Problem with click response.... (Read 6329 times)