Jump to content
IGNORED

Number Blaster & Generic Shump Game


Kiwi

Recommended Posts

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.

 

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.

  • Like 1
Link to comment
Share on other sites

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 by intvnut
  • Like 1
Link to comment
Share on other sites

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 :D

 

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.
Link to comment
Share on other sites

 

 

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 by Kiwi
  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...