Kiwi Posted March 3, 2015 Author Share Posted March 3, 2015 Each shots has it own ID, x and y coordinates. Even with flickering, it should hits it target regardless. for a=0 to 5for b=0 to 2if lasy(b)>Eny(a)-3 AND lasy(b)<Eny(a)+3 then if lasx(b)>Enx(a)-3 AND lasx(b)<Enx(a)+3 then Lasa(b)=0:restore hitobject:SL=4:gosub GetSound:Lasy(b)=0:Lasx(b)=0:Enh(a)=Enh(a)-LasD(b):if Enh(a)>250 then e=0:Enh(a)=249:c=Enc(a):gosub AddScore:Ena(a)=20:EnB(a)=0:V4=10:W=0next bnext aThis works well but slows the game down way too much. It is similar to my software collusion for my Colecovision game. for(ID=0;ID<=5;ID++){if(quinnx>objectx[iD]-10 && quinnx<objectx[iD]+10){if(quinny>objecty[iD]-10 && quinny<objecty[iD]+10){if(objectID[iD]>=15){if(objectID[iD]==15){quinnMaxHP+=2;itemget+=1;quinnHP=quinnMaxHP;RemoveObject();}if(objectID[iD]==16){RemoveObject();quinnHP=quinnMaxHP;}if(objectID[iD]==17){RemoveObject();itemget+=2;Time+=20;DrawTime();}}else{play_sound(2);play_sound(3);quinnHP--;quinnInv=60;jumpcounter=10;}//ObjectGet();}}} I went with hardware collusion initially for pixel vs pixel collusion. So each shot have it pro and con like the laser you start off fires quickly but narrow. If you upgrade that to 3 laser then the collusion detection is wider and it fires at a slower rate. Software collusion wouldn't work well due to various enemy sizes. However, I wanted to try it and see what happens if it uses software collusion out of boredom. So I can see the result. I really should focus on adding new content now. 1 Quote Link to comment Share on other sites More sharing options...
intvnut Posted March 4, 2015 Share Posted March 4, 2015 (edited) Each shots has it own ID, x and y coordinates. Even with flickering, it should hits it target regardless. for a=0 to 5 for b=0 to 2 if lasy(b)>Eny(a)-3 AND lasy(b)<Eny(a)+3 then if lasx(b)>Enx(a)-3 AND lasx(b)<Enx(a)+3 then Lasa(b)=0:restore hitobject:SL=4:gosub GetSound:Lasy(b)=0:Lasx(b)=0:Enh(a)=Enh(a)-LasD(b):if Enh(a)>250 then e=0:Enh(a)=249:c=Enc(a):gosub AddScore:Ena(a)=20:EnB(a)=0:V4=10:W=0 next b next a This works well but slows the game down way too much. One trick I did in Space Patrol was to split certain checks across multiple frames. As long as your objects have big enough bounding boxes and aren't moving "too fast" (ie. more than their size over the course of 2 frames), you could check a subset each frame. For example, you could check a = { 0,1,2 } on even frames and a = { 3,4,5 } on odd frames. That would cut the cost of the code above in half. And, there may be tricky ways you can rewrite the bounding box compare to save further cycles. I haven't looked at the IntyBASIC output, but something goofy like this might work: . IF ( ( lasy(b) - Eny(a) + 3 ) AND $7FFF ) < 6 AND ( ( lasx(b) - Enx(a) + 3 ) AND $7FFF ) < 6 THEN ... . If IntyBASIC has a way to indicate "unsigned comparison", you could eliminate the "AND $7FFF" bits. Anyone catch the trick I'm using? Highlight for a spoiler hint ==> The AND instruction makes a negative number look like a large positive number. Interpreting the result of a subtraction as unsigned also makes negative numbers look like large positive numbers. <== EDIT: I just thought of a slight possible micro-optimization: . IF ( ( lasy(b) - Eny(a) + 3 ) * 2 ) < 12 AND ( ( lasx(b) - Enx(a) + 3 ) * 2 ) < 12 THEN ... . It'll only be 4 cycles faster per test, but hey... take what you can get, right? Taking this further, 'x' is more likely to be out of range than 'y', isn't it? I'm basing this on the screen being wider than tall, and little else. So if you do this as a nested IF-THEN as your original code had it.... . IF ( ( lasx(b) - Enx(a) + 3 ) * 2 ) < 12 THEN IF ( ( lasy(b) - Eny(a) + 3 ) * 2 ) < 12 THEN ... . ...that may be faster still. Edited March 4, 2015 by intvnut 1 Quote Link to comment Share on other sites More sharing options...
Kiwi Posted March 4, 2015 Author Share Posted March 4, 2015 I should share my youtube video of Aero Fighter I made in Super Dezaemon about 16 years ago. My goal is to make it like this version. Super Dezaemon is a bit restrictive on what you can do. I can't control what power up appears, such as I want the shield power up in specific spot. I can't change the weapon formation. The boss behavior can be change but they have specific pattern you can do. Same with the enemies, you can pick the pattern and shot formation. So this will be a multi-level game, at least 6 levels. Level 3 for the Intellivision will have tile vs ship collusion. I get to play with PEEK command Here are the videos of Aero Fighter. I'm thinking Area Fighter title name would make more sense. And Aero Fighter is known for plane to plane combat for the N64. It was also Starfighter, and that name is used for NES game, The Last Starfighter. Quote Link to comment Share on other sites More sharing options...
Kiwi Posted March 4, 2015 Author Share Posted March 4, 2015 (edited) One trick I did in Space Patrol was to split certain checks across multiple frames. As long as your objects have big enough bounding boxes and aren't moving "too fast" (ie. more than their size over the course of 2 frames), you could check a subset each frame. For example, you could check a = { 0,1,2 } on even frames and a = { 3,4,5 } on odd frames. That would cut the cost of the code above in half. And, there may be tricky ways you can rewrite the bounding box compare to save further cycles. I haven't looked at the IntyBASIC output, but something goofy like this might work: . IF ( ( lasy(b) - Eny(a) + 3 ) AND $7FFF ) < 6 AND ( ( lasx(b) - Enx(a) + 3 ) AND $7FFF ) < 6 THEN ... . If IntyBASIC has a way to indicate "unsigned comparison", you could eliminate the "AND $7FFF" bits. Anyone catch the trick I'm using? Highlight for a spoiler hint ==> The AND instruction makes a negative number look like a large positive number. Interpreting the result of a subtraction as unsigned also makes negative numbers look like large positive numbers. <== EDIT: I just thought of a slight possible micro-optimization: . IF ( ( lasy(b) - Eny(a) + 3 ) * 2 ) < 12 AND ( ( lasx(b) - Enx(a) + 3 ) * 2 ) < 12 THEN ... . It'll only be 4 cycles faster per test, but hey... take what you can get, right? Taking this further, 'x' is more likely to be out of range than 'y', isn't it? I'm basing this on the screen being wider than tall, and little else. So if you do this as a nested IF-THEN as your original code had it.... . IF ( ( lasx(b) - Enx(a) + 3 ) * 2 ) < 12 THEN IF ( ( lasy(b) - Eny(a) + 3 ) * 2 ) < 12 THEN ... . ...that may be faster still. I should try this. Last night I duplicated the engine code 3 times and then edit it so stuff would happen in frame 1 and then more stuff happen in frame 2, and the rest of the stuff in frame 3. Luckily I saved that code and going to retry software collusion again. The enemies task list in the current single frame version are split up task so 2 enemies run their stuff in a frame. EDIT: I'll keep the single frame version. 1 player's ship, 3 multiplex'd bullets, 6 enemy ships/shots. Enemies and their shots can be multiplex'd if I needed it to. Now on to building this game. Edited March 4, 2015 by Kiwi 2 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.