Jump to content

Photo

Lunar Defense for INTV


12 replies to this topic

#1 vprette ONLINE  

vprette

    Stargunner

  • 1,347 posts

Posted Mon Nov 17, 2014 6:00 AM

early stage.. need to study collision detection, don't know if it would be a complex project or not... so I will post questions

:-)

 

lunar1

 

the idea is to have waves of missiles coming across the screen

what you do not shoot will hit the shield of the moon station, you score until shield is gone, or you resist 1000 missiles to win


Edited by vprette, Mon Nov 17, 2014 6:06 AM.


#2 vprette ONLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,347 posts

Posted Thu Nov 20, 2014 10:22 AM

title :-)

lunar T2

 

some details:

this is by far the more complex project I'm working to after tic tac, tris, mastermind and simon4...

The goal is to make a shooting game, that is much needed in the intv portfolio, with an original component: your ship will shoot the missiles coming from left of the screen before they reach the other side.

I plan for 3 different missiles and an enemy ship, each with different speed.

10 waves of 100 target each, each wave faster.

the concept is simple, the gameplay addictive in my plan.

lunar T3

Edited by vprette, Thu Nov 20, 2014 10:27 AM.


#3 vprette ONLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,347 posts

Posted Mon Nov 24, 2014 2:04 PM

enemy ship :-)

ship
 
background (running rom)
lunarmain

 

 


Edited by vprette, Mon Nov 24, 2014 2:08 PM.


#4 pimpmaul69 OFFLINE  

pimpmaul69

    River Patroller

  • 4,823 posts
  • INTV Brotherhood Technician
  • Location:Colorado

Posted Mon Nov 24, 2014 2:30 PM

Looking good so far

#5 vprette ONLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,347 posts

Posted Tue Nov 25, 2014 10:22 AM

intermission alien face menacing you

I mean to use the VOICE command here...

face2

Edited by vprette, Tue Nov 25, 2014 10:29 AM.


#6 vprette ONLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,347 posts

Posted Wed Nov 26, 2014 9:32 AM

ok, just the initial rom with title and the alien face :-)

I mean to animate a bit teh face and work on the Voice commmand to add a sentence

is it easy to make a "we will conquer you" sentence??

 

rom ends in the game screen but I have issues to fix there...

 

more comments: I improved the optimization of code and you see only 6 KB so far... can be optimized lot more but better than the 14K to 16K I got for tris :-)

Attached Files


Edited by vprette, Wed Nov 26, 2014 9:34 AM.


#7 vprette ONLINE  

vprette

    Stargunner

  • Topic Starter
  • 1,347 posts

Posted Wed Nov 26, 2014 2:15 PM

ok, just the initial rom with title and the alien face :-)

I mean to animate a bit teh face and work on the Voice commmand to add a sentence

is it easy to make a "we will conquer you" sentence??

 

rom ends in the game screen but I have issues to fix there...

 

more comments: I improved the optimization of code and you see only 6 KB so far... can be optimized lot more but better than the 14K to 16K I got for tris :-)

 

added VOICE calls

the title screen voice is not bad in my opinion... but I was not able to make a decent rendition of "we will conquer you" for the alien face... So I used the Klingon translation!

Attached Files



#8 mthompson OFFLINE  

mthompson

    Dragonstomper

  • 625 posts
  • Location:Northern Illinois

Posted Wed Nov 26, 2014 5:09 PM

lunar2.rom will not advance past the title screen for me.  :_(  lunar1.rom went all way to the game screen.

 

Looking forward to giving this a whirl. Looks like a good one.


Edited by mthompson, Wed Nov 26, 2014 5:10 PM.


#9 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Thu Nov 27, 2014 4:41 AM

lunar2.rom will not advance past the title screen for me.  :_(  lunar1.rom went all way to the game screen.

 

 

Same here.  Lunar one also did not stop at the menu: whenever a button is pressed from the title screen, it jumps to the menu*, then immediately to the alien face, and then directly into the game screen.  By the way, on the game screen, the planet is not showing up properly (see below).

 

shot0000.gif

 

* UPDATE:  It's like the input problem in your other games: depending on how you press the key, it may skip screens, or it may just take a single input.  If I press key "1," it will automatically choose level 1 (Normal).  If I press the disc, it will stop at the menu.  You should clear the buffer and wait for release before any key press.

 

The alien itself looks rather nice. :)

 

alien.gif <- Click to enlarge

 



#10 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,768 posts
  • Location:@R6 (top of stack)

Posted Sat Nov 29, 2014 4:04 AM

* UPDATE:  It's like the input problem in your other games: depending on how you press the key, it may skip screens, or it may just take a single input.  If I press key "1," it will automatically choose level 1 (Normal).  If I press the disc, it will stop at the menu.  You should clear the buffer and wait for release before any key press.

 

Maybe Valter should consider writing a routine he can GOSUB to for discrete keypresses that first waits for nothing to be pressed, and then recognizes a new keypress.  Or, even break it in two.  I found with my own code that a "waitnokey" routine was extremely helpful all by itself.  My "wait key" routine first did a "wait no key" before waiting for a key.  And by "key", I mean any controller input in this context.

 

You want to act on a controller input as soon as it's recognized and debounced.  And by acting on it, I mean drawing the next screen and setting things up to interpret new inputs in the context of a menu or title screen.  But, you don't want to interpret new inputs until you've seen the controller(s) go "idle", so you don't recognize the first input as more than one input.  I'm pretty sure that's the principle that dZ is highlighting above.

 

Once the game is live, that's a different story.  But for title screens and menus, you want to cater to more deliberate actions.

 

As far as debouncing goes:  The simplest algorithm works best for discrete inputs.  If you see something change, wait a millisecond or two and sample again.  If it's still the same, consider the input.  If it's not, wait a millisecond or two and sample again.  Loop until two consecutive samples are the same.  As long as your loop is at least a millisecond or two, that'll eat most glitches.  Just keep it below 16ms if you want to support 60Hz games.
 


Edited by intvnut, Sat Nov 29, 2014 4:05 AM.


#11 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Nov 29, 2014 6:10 AM

 

Maybe Valter should consider writing a routine he can GOSUB to for discrete keypresses that first waits for nothing to be pressed, and then recognizes a new keypress.  Or, even break it in two.  I found with my own code that a "waitnokey" routine was extremely helpful all by itself.  My "wait key" routine first did a "wait no key" before waiting for a key.  And by "key", I mean any controller input in this context.

 

You want to act on a controller input as soon as it's recognized and debounced.  And by acting on it, I mean drawing the next screen and setting things up to interpret new inputs in the context of a menu or title screen.  But, you don't want to interpret new inputs until you've seen the controller(s) go "idle", so you don't recognize the first input as more than one input.  I'm pretty sure that's the principle that dZ is highlighting above.

 

Once the game is live, that's a different story.  But for title screens and menus, you want to cater to more deliberate actions.

 

Yes, that's what I am referring to.  We have discussed this in Valter's other threads, and some have even posted ready-made code to address it.  I was just pointing out that it's the same problem, so that he may use the same technique as before.

 

 

 

 

As far as debouncing goes:  The simplest algorithm works best for discrete inputs.  If you see something change, wait a millisecond or two and sample again.  If it's still the same, consider the input.  If it's not, wait a millisecond or two and sample again.  Loop until two consecutive samples are the same.  As long as your loop is at least a millisecond or two, that'll eat most glitches.  Just keep it below 16ms if you want to support 60Hz games.

 

 

That's difficult to do with IntyBASIC, since your timer granularity is 50Hz, and all you have to control it is the "WAIT" statement.  I would imagine that the IntyBASIC runtime already performs signal conditioning, since that should be more of a feature of the low-level driver.

 

     -dZ.



#12 intvnut OFFLINE  

intvnut

    River Patroller

  • 2,768 posts
  • Location:@R6 (top of stack)

Posted Sat Nov 29, 2014 9:48 AM


That's difficult to do with IntyBASIC, since your timer granularity is 50Hz, and all you have to control it is the "WAIT" statement.  I would imagine that the IntyBASIC runtime already performs signal conditioning, since that should be more of a feature of the low-level driver.

 

     -dZ.

 

 

You can use a dummy FOR loop to get delays shorter than one frame time.  And no, there isn't any conditioning on the controller inputs.

 

Here's an example from "game2.bas" compiled with IntyBASIC 1.0.  It just reads the raw controller value every time you refer to CONT1/CONT2.

    ;[65]         ' Check for movement
    SRCFILE "game2.bas",65
    ;[66]   IF CONT1.UP THEN IF Y1>0 THEN Y1=Y1-1
    SRCFILE "game2.bas",66
    MVI 511,R0
    COMR R0
    ANDI #4,R0
    BEQ T21
    MVI V17,R0
    CMPI #0,R0
    BLE T22
    MVI V17,R0
    DECR R0
    MVO R0,V17
T22:



#13 DZ-Jay OFFLINE  

DZ-Jay

    Quadrunner

  • 9,838 posts
  • Triple-Stripe Mo' Bro
  • Location:NC, USA

Posted Sat Nov 29, 2014 10:53 AM

You can use a dummy FOR loop to get delays shorter than one frame time. And no, there isn't any conditioning on the controller inputs.

Here's an example from "game2.bas" compiled with IntyBASIC 1.0. It just reads the raw controller value every time you refer to CONT1/CONT2.

    ;[65]         ' Check for movement
    SRCFILE "game2.bas",65
    ;[66]   IF CONT1.UP THEN IF Y1>0 THEN Y1=Y1-1
    SRCFILE "game2.bas",66
    MVI 511,R0
    COMR R0
    ANDI #4,R0
    BEQ T21
    MVI V17,R0
    CMPI #0,R0
    BLE T22
    MVI V17,R0
    DECR R0
    MVO R0,V17
T22:


Oh! Then perhaps that's something nanochess can offer as an option when reading the controller. Perhaps a "GETIN" or "INPUT" functions, or both.




0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users