Jump to content
IGNORED

Lunar Defense for INTV


vprette

Recommended Posts

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

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

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

lunar1.rom

Edited by vprette
  • Like 1
Link to comment
Share on other sites

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!

lunar2.rom

Link to comment
Share on other sites

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).

 

post-27318-0-82834100-1417084748_thumb.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. :)

 

post-27318-0-80901200-1417085002_thumb.gif <- Click to enlarge

 

Link to comment
Share on other sites

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

 

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.

  • Like 1
Link to comment
Share on other sites

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:

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 3 years later...

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...