New game project: Jetpac

[Willsy]

Try changing the keyboard mode to the split mode. See KMODE.

 

Yes TF uses the console keyboard routine which is a MAJOR hog. I'd suggest replacing that with assembler code that looks for keys via CRU.

[+Vorticon]

Looks good.

 

Does his antenna move when he walks in the original ?

 

Much as what Rasmus said. When I walk on the ground I can't take off.

 

 

Well, I guess TurboForth is using KSCAN as does TI Basic, and then there's a problem with 2 simultaneous keypresses. But movement with a joystick and a keypress works fine. Surely something like this must be possible with TurboForth ?

 

100 CALL KEY(0,K,S)
110 CALL JOYST(1,X,Y)
120 PRINT K;X;Y
130 GOTO 100 

 

 

Sure it is, but since it works fully well with joysticks, why would you want to use a combination of joysticks and keypresses? Besides, it would really be difficult to move the joystick and press a key at the same time short of gluing the joystick to the desk

Now is there a way in assembly to detect 2 simultaneous keypresses? Since TF can easily embed assembly code, this might be an option if possible...

As for the antenna moving, I had completely not seen that! Going back to the patterns, it is indeed shifting back and forth with walking. Easy enough to add. Thanks for the observation

[+Vorticon]

Try changing the keyboard mode to the split mode. See KMODE.

 

Yes TF uses the console keyboard routine which is a MAJOR hog. I'd suggest replacing that with assembler code that looks for keys via CRU.

 

Split keyboard might work... I really need to crash now but I'll try it out tomorrow (err... later today)

[Willsy]

 

Now is there a way in assembly to detect 2 simultaneous keypresses? Since TF can easily embed assembly code, this might be an option if possible...

As for the antenna moving, I had completely not seen that! Going back to the patterns, it is indeed shifting back and forth with walking. Easy enough to add. Thanks for the observation

 

Yes, but only if the keys are on different rows (or is it columns?). Sometimes is a guru as this stuff! Clever thing, he is

[sometimes99er]

Sure it is, but since it works fully well with joysticks, why would you want to use a combination of joysticks and keypresses? Besides, it would really be difficult to move the joystick and press a key at the same time short of gluing the joystick to the desk

Okay. Here's what I think happened. I pressed 4 to go to Joystick, and pressed a few times, but it did not switch. It's not really responsive here. I see now that I have to hold it for a while to make the switch.

 

So I was indeed using S and D to move, and couldn't take off (using the spacebar while walking).

 

Now, the game doesn't have to support the keyboard. Maybe commercial games did support the console without joysticks, but you don't explicitly have to (support keyboard).

 

[sometimes99er]

Sometimes is a guru as this stuff! Clever thing, he is

Hehe. Nope.

 

All I've done all along is to use Thierry Nouspikel's website. Now he must be clever.

 

[sometimes99er]

Yes, but only if the keys are on different rows (or is it columns?).

I guess you could study Thierry's site on the matter. You can read the state of many keys (not all in a single instruction), but, the keyboard is wired in a grid and strange things may happen (well, they're not strange) and when you hit something like three keys then a ghost key may be detected.

 

Phantom keys

 

We can now explain the phenomenon known as "phantom key": when you press three keys together, the console may detect a fourth key, even if it isn't pressed. This occurs when the keys you pressed occupy the three corners of a square in the above table: the phantom key is the one on the fourth corner.

 

For instance, suppose you pressed Ctrl-Shift-S. When the processor tests column 0, it brings pin 12 low. Since both <Shift> and <Ctrl> are pressed, both pin 3 and pin 10 will be low and CRU bits 8 and 9 read as 0. So far, so good. But let's see what happens when testing column 1. Pin 13 goes low and, since <S> is pressed, so does pin 3 thus bit 8 reads as 0. BUT, since the <Shift> key is placed on the same row, column 0 will also go low, and since <Ctrl> is down, pin 10 goes low and bit 9 reads as 0. Which creates the illusion that <W> was pressed. See what I mean?

 

All this is due to the fact that electrons can flow back from a row to a column. To prevent this from happening we would need to install a diode at each key. That's something you should consider if you ever wanted to create a piano keyboard for the TI-99/4A. On a piano it is very common that 3 or more keys are pressed. On a computer on the other hand, it is rare to press more than two keys, so we can live with the phantom key problem. Also note that some multiple key combinations are ok, if the three keys are aligned on the same column (Ctrl-Shift-=), on the same row (1-2-3), or do not form a square (Ctrl-Shift-1).

Edited September 11, 2015 by sometimes99er

[sometimes99er]

I don't think you can travel through the platforms like this.

 

[Opry99er]

Looking really good, Vorticon! For an early beta it is quite impressive.

[+Vorticon]

I don't think you can travel through the platforms like this.

 

 

Ah yes. The classic problem of sprite location being tied to the left upper corner... I can fix that though. I should have an updated source file with all of the mentioned issues fixed later tonight. One solution to the keyboard problem is to simply use separate keys for boosting left, up and right instead of just having the spacebar. So S and D would be for right and left walking/free falling and W, E and R would be for boosting. I don't know if that would be too cumbersome for real play use.

[+Vorticon]

I'm still waiting to hear from Willsy regarding the ability to change keyboard mode in TF. I think that using a split keyboard should solve the problem of simultaneous keypresses as I should be able to poll both sides of the keyboard very quickly.

In the mean time, the antenna now wiggles! And I improved the checks for sprite coincidence with the background. A couple of things I decided to do differently from the original game are:

- Jetman's feet actually touch the ground rather than float 2 pixels above it

- I did not display the rocket jet when Jetman is free falling as I thought this would be more realistic given that he is not thrusting. I don't think this will detract from gameplay at all. If however there is an overwhelming feeling from you guys that there should be a rocket jet even in free fall, then it will be easy enough to add.

 

Attached is the updated source file minus the keyboard fix. Please give it another try if you can (preferably with joysticks) and let me know how the animations feel overall as compared to the original.

Jetpac.txt

[Willsy]

For split keyboard mode just set the keyboard mode via KMODE

 

E.g. 2 KMODE !

 

Then KEY? and friends will use that mode (well, they *should* do!)

 

Since TF uses the TI ROM KSCAN routine, the mode values are the same as TI BASIC or XB (I can't remember them offhand). I do know that by default TF runs in mode 5 which is upper and lower case.

[+Vorticon]

For split keyboard mode just set the keyboard mode via KMODE

 

E.g. 2 KMODE !

 

Then KEY? and friends will use that mode (well, they *should* do!)

 

Since TF uses the TI ROM KSCAN routine, the mode values are the same as TI BASIC or XB (I can't remember them offhand). I do know that by default TF runs in mode 5 which is upper and lower case.

 

I tried that (see TF thread) and it does not work unfortunately... The mode does not change regardless of what value is assigned to KMODE because the returned ASCII values with KEY or ASCII remain the same.

[Omega-TI]

Upon completion, is there a chance that this game could one day see the light of day on fbForth too?

[+Vorticon]

Upon completion, is there a chance that this game could one day see the light of day on fbForth too?

 

That one I will leave to Lee While both Forth versions share a substantial common functional core, there are enough syntax variations to make such an endeavor difficult on a large program. Also I don't have comparative performance benchmarks between the two...

[Willsy]

 

I tried that (see TF thread) and it does not work unfortunately... The mode does not change regardless of what value is assigned to KMODE because the returned ASCII values with KEY or ASCII remain the same.

Okay I'll check it out. You're the first person to use that feature I think so there may be a problem.

[Willsy]

Just had a thought. Try putting the mode in the high byte, like this:

 

$0200 kmode !

 

Worth a try...

[+Vorticon]

Just had a thought. Try putting the mode in the high byte, like this:

 

$0200 kmode !

 

Worth a try...

 

Nope. No dice here either...

[Willsy]

Weird... This works for me just fine:

 

 

: left-kb
  $0100 kmode ! begin key . again ;
 
: right-kb
  $02 kmode ! begin key . again ;

 

Try them. In the first, only the left half of the keyboard returns a value. Note: The value returned is *not* the ASCII value. It's something else. No idea what. We're running KCSAN from the TI ROM. You would get identical results in TI BASIC.

[Willsy]

The description given in the XB Manual is clearly wrong:

 

 

The KEY subprogram assigns the code of the key pressed to return-variable. The value
assigned depends on the key-unit specified. If key-unit is 0, input is taken from the entire
keyboard, and the value placed in return-variable is the ASCII code of the key pressed. If no
key is pressed, return-variable is set equal to - 1. See Appendix C for a list of the ASCII
codes.

 

 

At least, it's wrong in the context of the 4A. I think it was written for the /4. This is telling...

 

 

If key-unit is 1, input is taken from the left side of the keyboard. If key-unit is 2, input is
taken from the right side of the keyboard. The possible values placed in return-variable are
given in Appendix J. Values of 3, 4, and 5 are reserved for possible future uses.

 

They're claimed to be 'reserved' but they are recognised modes on the /4A. TF uses mode 5 which is a "full open" scan where CTRL keys, FCTN keys etc. all return values.

Edited September 12, 2015 by Willsy

[+Vorticon]

Weird... This works for me just fine:

: left-kb
  $0100 kmode ! begin key . again ;
 
: right-kb
  $02 kmode ! begin key . again ;

Try them. In the first, only the left half of the keyboard returns a value. Note: The value returned is *not* the ASCII value. It's something else. No idea what. We're running KCSAN from the TI ROM. You would get identical results in TI BASIC.

 

OK I figured it out. It seems that kmode works only when declared within a word definition, not in immediate mode. And yes, it requires the value in the high byte. The values returned are the ones described on page II-88 of the TI User's Reference Guide for the split keyboards. Everything is fine now Thanks!

[+Vorticon]

The description given in the XB Manual is clearly wrong:

 

 

 

 

At least, it's wrong in the context of the 4A. I think it was written for the /4. This is telling...

 

 

 

They're claimed to be 'reserved' but they are recognised modes on the /4A. TF uses mode 5 which is a "full open" scan where CTRL keys, FCTN keys etc. all return values.

 

The accurate description is found starting on page II-87 of the TI User's Reference Guide. Forget the one in the XB manual...

[Willsy]

 

OK I figured it out. It seems that kmode works only when declared within a word definition, not in immediate mode. And yes, it requires the value in the high byte. The values returned are the ones described on page II-88 of the TI User's Reference Guide for the split keyboards. Everything is fine now Thanks!

Us that's correct. TF will reset KMODE to 5 when on the command line. I'll update the online docs to be more clear on this. The page for KMODE also doesn't state that the value should be in the high byte.

[+Vorticon]

OK the keyboard issue has been solved using the split keyboard mode. Now you can boost directly while walking. The S and D keys are for left and right, the L key is for boosting. I have attached the updated source file to the top of this thread. Let's call it version 0.1 and move on Thank you all for the suggestions, observations and help More to come.

[Willsy]

OK the keyboard issue has been solved using the split keyboard mode. Now you can boost directly while walking. The S and D keys are for left and right, the L key is for boosting. I have attached the updated source file to the top of this thread. Let's call it version 0.1 and move on Thank you all for the suggestions, observations and help More to come.

 

Sorry for the confusion. The page for KMODE has now been updated