@1 C O D E C l i n i c @3 Is the Game, Lee Bambers the Name --------------------------------- @1 CC> What's the prob, dude? @4 PP> When using the Dual Playfield it keeps distorting the background screen. I used it like this: Load Iff "[a 960X200,8 colour screen] into Screen 0 Load Iff "[a 320X200,8 colour screen] into Screen 1 Dual Playfield 0,1 @3 AA> I know where of you speak. I had similar problems with my AMOSEyes when I wanted a backdrop for my Instruction Manual Reader. I just blamed it on AMOS and did something else, but upon reflection, it should not have happened, and I wanted by backdrop, so I got it sorted. The answer to your pain lies in the time it takes AMOS to load in an IFF picture and the time it takes to settup a dual playfield screen. Or so I hypothosised. In fact, I tried every smegging command under the sun until I used WAIT VBL between the last Load Iff and Dual Playfield command. Your code should read: Load Iff "[bla bla bla]",0 Load Iff "[whatever...]",1 Wait Vbl Dual Playfield 0,1 I true AZ style, I did more than just propose a possible solution, I went into AMOS and tried out your code. Something that isn't mentioned in the AMOS manual is that when you are creating dual playfield screens of larger sizes, both screen need to match and/or exceed the size of the screen. Your 320 wide screen didn't and the dual playfield probably ignored the actual size in order to create a screen which would fill a complete a single raster line. In short, you need your second screen to be at least 352 pixels wide. That's two words bigger than your standard size screen. Incidently, this is the size you'd find most commercial games using. Think about it, do you see borders in your typical 'bigboy' game? Nope. Because I'm such a nice guy, I've included an AMOS program which shows you what I'm slavering about. I'd come round your house and hit your computer with my rubber wrist rest if I thought it could help but my mother won't give me the key. So heed my advice and play nicely. @1 CC> Righty, onto our next troubled sole, what's up? @4 PP> I have a coding problem. You have two objects each have there own x & y variables. I want to have a procedure that will take in the 4 variables x1,y1 & x2,y2 of the two objects, and return an angle that will face the first object in the direction of the second object,i.e A lock on missile after a ship. The return value should be from 0 to 359. Now for the annoying bit, the routine can't use any floating point maths so careful thought is needed. @3 AA> I'm afraid this one is a toughy. If you can't use floating point number systems, you can rule out the use of the Amos commands that will do this in an instant. I can only assume your neurotic about saving variable space or ultimately going to write it in m/c. The case of using integer numbers for homing routines has turned up before in my own creations. I had no half-way method of doing something, I end up binding everything into a single routine. So the homing routine would not need an angle of 0-359 degrees, it would automatically assign x/y increments at points along the cycle. This is the natural alternative to floating point homing routines. Lets say you had this line, using floating point maths: SHIPX@3#@3=SHIPX@3#@3+0.5 In 10 cycles, it would have travelled 5 pixels along the X axis. Using point integer increments, the code would read: If SHIPXCOUNT=2 SHIPXCOUNT=0 SHIPX=SHIPX+1 End If SHIPXCOUNT=SHIPXCOUNT+1 This would convert easily to machine code, assuming some settings, as: CMP @3#@32,SHIPXCOUNT(a0) BNE JUMP1 MOVE.W @3#@30,SHIPXCOUNT(a0) ADD.W @3#@31,SHIPX(a0) JUMP1: ADD.W @3#@31,SHIPXCOUNT(a0) Now if you can grasp that, the next step is to generate the number to compare with the shipcount. This number will be created using the distance between the two objects. I've included the source code to the above example. Generating the point number is another story entirely. But trying to obtain angles without FP numbers is like trying to eat without fingers. If anyone can prove me wrong, please try. For now, it would seem you have a simple choice. a) Change the idea enough to allow a different approach to the code, or b) Sit down, and work out your own angles: I say this for the very reason I'm a programmer. I would say it is very possible to create your own system where the distance can be given a finite defenision within a circle from a base object, and this then can be used to approximate an angle. A quick (and crude) example, is: Procedure LOCK[x1,y1,x2,y2] ' If X1 You there, need any help? @4 PP> How do you simulate the hands on a clock, at the correct angle? @3 AA> Easy. Read the maths chapter of the Amos manual about SIN & COS. Now look up the junior book for telling the time. When you have the number of figures on a clock, find out how many minutes in an hour. Yes, it's very easy. Whether you want a simple clock or a commercial quality clock is two different considerations. For the sake of time and space, I'll give you the simple version: Basically, a circle has 360 points around it. 0 and 360 are the same point and the points are consecutive around the circumference. So 180 would be half way round, 350 would be nearly all the way round, etc. Their are 60 seconds in a minute and the SECONDS HAND on a clock will go round inside this 60 seconds. So for every second, the SECONDS HAND will need to move in steps until the sixtyth move will have moved the hand back onto the 0/360'th point. How many points must be jumped to get 360 points covered in 60 steps? 360 / 60 = 6 so thats 6 pixels This method of deduction must be applied to the hours hand which only completes a circle in (60*60*12) seconds. @3 The CC-Solution-3 program showns you how this can be achieved. It's a simple routine, with many points worth improving. The most important factors for improvement are graphics and size. A smaller clock is vital if you want it fast. Graphics would have to include the hands. Anything other than lines will have to be considered for drawing. This may not be practical with 360 possibilities! @3CC> Well, I'm done here. Any other problems can be sent to my address below and I'll answer them in these pages. Bye! @1 ADDRESS: Lee Bamber, Dept. AZCC. 'Rockville', Warrington Road, Lower Ince, Wigan, Lancashire, WN3 4QG. @4 As per usual, any correspondance will be replied to and I'll even put in one of my prized Info Sheets! Now how's that for nicey-ness-ness? @1 End.