New game project: Jetpac

[RXB]

 

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

From RXB you could use CALL IO(2,16,3,A,B) would return values for Control Key, Function Key, Shift Keys, Enter Key, Space Bar, Plus key and Equal Key.

Using a different CRU would also check that line of keys or multiple pressed keys.

CALL IO will also detect up to 4 keys pressed at same time and give you a value for each combination.

Edited September 12, 2015 by RXB

[+Lee Stewart]

Walid...

 

If you don't mind sharing, what is the ASM: ... ;ASM code for VSYNC and DATA[] ?

 

...lee

[+Vorticon]

Walid...

 

If you don't mind sharing, what is the ASM: ... ;ASM code for VSYNC and DATA[] ?

 

...lee

 

Lee, the VSYNC discussion and code can be found here http://atariage.com/forums/topic/240604-alien-invasion/?p=3280333 and it's fairly simple. I'll let Willsy chime in on the DATA[] part. It's part of the latest TF version but requires a library load, so I opted to include it in my program so as to avoid having the user do any extra loading. I just lifted it from the language reference section.

[+Lee Stewart]

Thanks! I have a special reason for always wanting to see the original code for words like these. I need to know that no word definitions were called that were not part of the kernel because that can come back to bite you. VSYNC is safe. Now, I need to see what DATA[] does. I will await his highness .

 

...lee

[Willsy]

Thanks! I have a special reason for always wanting to see the original code for words like these. I need to know that no word definitions were called that were not part of the kernel because that can come back to bite you. VSYNC is safe. Now, I need to see what DATA[] does. I will await his highness .

 

...lee

 

Hiya Lee

 

All is described here, sir! (scroll down a bit - it's updated)

 

Enjoy

[+Lee Stewart]

 

Hiya Lee

 

All is described here, sir! (scroll down a bit - it's updated)

 

Enjoy

 

Thank you, Sir. That one is also safe enough. I also needed the original code for a possible port to fbForth—with your permission, of course.

 

...lee

[Willsy]

Sure thing. Have at it! It's very useful indeed. Works on the command line too!

[+Lee Stewart]

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

 

I am working on converting the current version of Jetpac to run in fbForth—mainly as an exploration into the scope of the conversion project. I first needed to work out fbForth versions of DATA[ and ]DATA , which I have done. Because the Sprite Pattern Descriptor Table is not required to be coincident with the Pattern Descriptor Table for text characters, I not only needed to code DCHAR and limit it to the PDT, but also needed to code a separate word for the SPDT, SPDCHAR—both also done.

 

Back to the scope of the conversion: As Walid said, there are enough syntax variations between TurboForth and fbForth to make large-scale conversions rough. The incompatibilities are worst for graphics. Most of the stack effects of TurboForth graphics words are backwards from fbForth (and TI Forth before it). Except for the case of DATA[ et al. mentioned above, I have taken the tack of writing code for the TurboForth graphics words in terms of their fbForth counterparts rather than rewriting the Jetpac code. This is made marginally easier, even where the words are spelled the same, because Walid’s code has them in lowercase and fbForth does not have a case-insensitive mode. If these word conversions slow Jetpac down too much, I will rewrite them in fbForth Assembler. To give you some idea of the conversion problem, here are two such words with their stack effects:

 

TurboForth fbForth

------------------------------- --------------------------------

color ( chrset fgcol bgcol — ) COLOR ( fgcol bgcol chrset — )

hchar ( y x chr count — ) HCHAR ( x y count chr — )

 

And, here is my conversion code for them:

 

: color ROT COLOR ;

: hchar SWAP >R >R SWAP R> R> HCHAR ;

Though I am trying to avoid making major logic changes, I will probably change the keyboard part of the BEGIN ... UNTIL loop in the Jetpac word to use the keyboard directions, which will make the keyboard section exactly like the joystick section. The only difference will be the selector numbers for the OF ... ENDOF clauses. It should be possible to make the same change to the TurboForth code. I will include the fbForth code and the equivalent TurboForth code for the BEGIN ... UNTIL loop in a later post.

 

...lee

[Omega-TI]

Cool... will it be an "AUTO-STARTER"?

[+Lee Stewart]

Cool... will it be an "AUTO-STARTER"?

 

It can be. That is easily done in both TurboForth and fbForth. Autostarting after loading is done by simply including the program’s starting word as the last executable word. To autostart at boot time from a blocks file, that blocks file needs to be renamed “BLOCKS” (TurboForth) or “FBLOCKS” (fbForth) and have block #1 load and run the game.

 

...lee

[+Lee Stewart]

OK, here is the fbForth code for Jetpac with the modified keyboard section (Note that fbForth’s JMODE variable is used instead of input .):

 

 

 

: Jetpac ( -- )

SelectionScreen GameBackground

U1Top 4 55 48 16 15 sprite U1Middle 5 79 128 20 15 sprite

U1Bottom 6 167 168 24 15 sprite

4 0 DO

player 2 = IF

playerUp 1 = IF

2UpNormal

1UpNormal 5000 Delay 1UpInverse 5000 Delay

ELSE

1UpNormal

2UpNormal 5000 Delay 2UpInverse 5000 Delay

THEN

ELSE

1UpNormal 5000 Delay 1UpInverse 5000 Delay

THEN

LOOP JetmanInit

BEGIN

JMODE @ IF ( joystick mode if JMODE <> 0)

1 JOYST ( returns CRU bits for actual joystick #1)

CASE

16 OF Boost false ENDOF

18 OF BoostLeft false ENDOF

20 OF BoostRight false ENDOF

2 OF WalkLeft false ENDOF

4 OF WalkRight false ENDOF

0 to boostFlag

groundFlag 0 = IF

FreeFall

THEN false SWAP

ENDCASE

ELSE ( keyboard mode if JMODE = 0)

1 JOYST ( returns keycode, x-status and y-status)

DROP DROP ( don't need x-status and y-status)

CASE

( Keys shown in comments before each OF show both sides)

( of keyboard. Only left side is active here.)

5 ( E|I) OF Boost false ENDOF

4 ( W|U) OF BoostLeft false ENDOF

6 ( R|O) OF BoostRight false ENDOF

2 ( S|J) OF WalkLeft false ENDOF

3 ( D|K) OF WalkRight false ENDOF

0 to boostFlag

groundFlag 0 = IF

FreeFall

THEN false SWAP

ENDCASE

THEN

UNTIL ;

And, here is my mod of the TurboForth code:

: Jetpac ( -- )

SelectionScreen GameBackground

U1Top 4 55 48 272 15 sprite U1Middle 5 79 128 276 15 sprite

U1Bottom 6 167 168 280 15 sprite

4 0 do

player 2 = if

playerUp 1 = if

2UpNormal

1UpNormal 5000 Delay 1UpInverse 5000 Delay

else

1UpNormal

2UpNormal 5000 Delay 2UpInverse 5000 Delay

then

else

1UpNormal 5000 Delay 1UpInverse 5000 Delay

then

loop JetmanInit

begin

input 1 = if

$0100 kmode !

key? case

( Keys shown in comments before each OF show both sides)

( of keyboard. Only left side is active here.)

5 ( E|I) of Boost false endof

4 ( W|U) of BoostLeft false endof

6 ( R|O) of BoostRight false endof

2 ( S|J) of WalkLeft false endof

3 ( D|K) of WalkRight false endof

0 to boostFlag

groundFlag 0 = if

FreeFall

then false swap

endcase

else

0 joyst case

16 of Boost false endof

18 of BoostLeft false endof

20 of BoostRight false endof

2 of WalkLeft false endof

4 of WalkRight false endof

0 to boostFlag

groundFlag 0 = if

FreeFall

then false swap

endcase

then

until ;

 

 

 

...lee

[+Vorticon]

Just a word of warning: I have replaced all of the sprite to background collision checks with the new word UNDERSPRITE created by Willsy which will be part of the latest version of TF. Also I will be making a lot of optimizations to the code this week to better take advantage of the stack among other things before moving forward.

Still very much a work in progress

[+Vorticon]

Here's the optimized code for version 0.1a . I have eliminated most of the delay loops from Jetman's animations, tried to use the stack more to pass on some variables (I still think I am using too many variables and I'll need to keep that in mind as I keep developing the code) and simplified the main game loop. I am also taking advantage of the new UNDERSPRITE word for sprite to background detection. Firing has been added. While joystick control works quite well, keyboard control remains a bit problematic because of the multi-key detection problem. S and D are for left and right, L for boosting, K for firing. Boosting stops when firing in keyboard mode because of that issue. It's still very playable in that mode though.

Jetpac.txt

[+Lee Stewart]

... I am also taking advantage of the new UNDERSPRITE word for sprite to background detection.

 

In fbForth and TI Forth, COINCXY does what UNDERSPRITE does in TurboForth—though, perhaps, not in the same way. I'll have to look at @Willsy's code to see how he does it.

 

... keyboard control remains a bit problematic because of the multi-key detection problem. S and D are for left and right, L for boosting, K for firing....

 

Why not use the standard keys (left side: Q, W, E, R, S, D) for the joystick movement and firing that Jetpac uses? That will solve the motion problem, though not the lack of simultaneous motion and firing.

 

...lee

[+Vorticon]

 

In fbForth and TI Forth, COINCXY does what UNDERSPRITE does in TurboForth—though, perhaps, not in the same way. I'll have to look at @Willsy's code to see how he does it.

 

 

Why not use the standard keys (left side: Q, W, E, R, S, D) for the joystick movement and firing that Jetpac uses? That will solve the motion problem, though not the lack of simultaneous motion and firing.

 

...lee

 

Does COINCXY check only the upper left corner of a sprite? Undersprite does not have such a limitation and you can specify the horizontal and vertical offsets for pretty accurate detection.

 

Regarding the key choices, I have to use a split keyboard so Jetman can move and boost at the same time. However when an additional key is added for firing, then we are back to the simultaneous keypresses problem because now we need to detect 3 separate keys at the same time (movement, boosting and firing). There is no facility to do that in TF. As for the motion problem you mention, what problem is that? I'm not aware of any with my testing either with the joysticks or with the keyboard outside of boosting stopping when firing in keyboard mode...

[Willsy]

Regarding the key choices, I have to use a split keyboard so Jetman can move and boost at the same time. However when an additional key is added for firing, then we are back to the simultaneous keypresses problem because now we need to detect 3 separate keys at the same time (movement, boosting and firing). There is no facility to do that in TF.

 

Indeed. It's physically possible to do it (I mean, the hardware can do it) as long as the keys are on different columns (or is it rows? I always forget). We'd need to add a little machine routine to do it. Something that looks for all three keys and gives you a bit code:

 

1 = boost

2 = fire

4 = left

8 = right

 

or something like that.

 

Alternatively, you could make Jetman fire whenever he's boosting. When I used to play the game as a kid I would set the joystick on auto-fire and blast the sh*t out of everything!

[+Lee Stewart]

 

Does COINCXY check only the upper left corner of a sprite? Undersprite does not have such a limitation and you can specify the horizontal and vertical offsets for pretty accurate detection.

 

Yes, but it uses a tolerance, which is the pixel radius of a circle around that point.

 

 

Regarding the key choices, I have to use a split keyboard so Jetman can move and boost at the same time. However when an additional key is added for firing, then we are back to the simultaneous keypresses problem because now we need to detect 3 separate keys at the same time (movement, boosting and firing). There is no facility to do that in TF. As for the motion problem you mention, what problem is that? I'm not aware of any with my testing either with the joysticks or with the keyboard outside of boosting stopping when firing in keyboard mode...

 

The “motion problem” was my way of cataloging the problem of managing boosting simultaneously with motion. Boosting with motion is simple with the standard joystick keys. I used them in my mod of your code back a few posts. On the left side of the keyboard, ‘W’ is northwest (value is 4), so would be BoostLeft ; ‘E’ is north (value is 5) and, obviously, would be Boost ; and ‘R’ is northeast (value is 6), so would be BoostRight —one key for each condition.

 

...lee

[+Vorticon]

It should definitely be feasible in assembly to detect 3 keys simultaneously as long as they do not form the 3 corners of a square on the table below (per Nouspikel's site):

Here is the keyboard layout in terms of CRU:

.	Column	0	1	2	3	4	5	6	7	A-lock
R12 address	Pin #	12	13	14	15	9	8	J7	J2	6
>0006	5/J4	=	.	,	M	N	/	Fire	Fire
>0008	4/J5	Space	L	K	J	H	;	Left	Left
>000A	1/J9	Enter	O	I	U	Y	P	Right	Right
>000C	2/J8	
9	8	7	6	0	Down	Down
>000E	7/J3	Fctn	2	3	4	5	1	Up	Up	A-lock
>0010	3	Shift	S	D	F	G	A	

>0012	10	Ctrl	W	E	R	T	Q	

>0014	11	X	C	V	B	Z	

From that table, it looks like the L and S share the same column, and so do the K and D keys and they do not form a square, so no phantom key detections are expected. So a routine which first tests column 1 then column 2 and reports on the status of the rows in each should work just fine.

 

I kind of like the idea of continuously firing in keyboard mode, but unfortunately the laser beam renders rather slowly and will likely create a bottleneck when the other game elements are added...

[+Vorticon]

 

Yes, but it uses a tolerance, which is the pixel radius of a circle around that point.

 

 

The “motion problem” was my way of cataloging the problem of managing boosting simultaneously with motion. Boosting with motion is simple with the standard joystick keys. I used them in my mod of your code back a few posts. On the left side of the keyboard, ‘W’ is northwest (value is 4), so would be BoostLeft ; ‘E’ is north (value is 5) and, obviously, would be Boost ; and ‘R’ is northeast (value is 6), so would be BoostRight —one key for each condition.

 

...lee

 

Got you. I did actually consider something like that earlier in this thread, but opted against it because I felt that it would be too cumbersome because there still need to be keys for left and right on top of it. That's 5 keys to keep track of in the midst of the action in addition to the fire button! The current scheme is much more intuitive IMHO

[+Lee Stewart]

 

Got you. I did actually consider something like that earlier in this thread, but opted against it because I felt that it would be too cumbersome because there still need to be keys for left and right on top of it. ...

 

Not really (unless I misunderstand you). The values for the corresponding keys on the right side of the keyboard are exactly the same.

 

...lee

[+Vorticon]

What I meant was that I considered using a scheme similar to what you are describing, still using a split keyboard so as to be able to test for the fire key. The layout would have been:

 

Left keyboard:

W boost left

E boost up

R boost right

S go left (walking/free falling)

D go right (walking/free falling)

 

Right keyboard:

K fire

 

Still a lot of keys to juggle during play

[+Vorticon]

OK so I broke down and implemented the key scheme above with the final assignments as noted below:

 

• W boost left
• E boost up
• R boost right
• S move left
• F move right
• L fire

Using S and F instead of S and D for left/right movement provided better finger spacing and less potential for confusion when moving between the boost and move keys. This setup now is fully functional just like the joysticks with no issues with firing and boosting. It takes a little getting used to, but it's surprisingly quite usable. The updated source code can be found in the first post.

Right! Now moving on. I'm tempted to start working on the sound, but I'm going to instead focus next on having Jetman move the rocket pieces around and assemble it.

[+Lee Stewart]

To beat this dead horse one last time, Except for the convenience of using both hands and never using two players, the traditional fire button key for left|right keyboards is Q|Y.

 

...lee

[+Vorticon]

It is definitely for the convenience of using both hands. This horse is most definitely dead

[+Vorticon]

Progress! Version 0.2 is up. The playable listing is at the top of the thread.

New additions:

• Assemble rocket
• Fuel rocket
• Collect bonus objects
• Rocket takes off when fueled and boarded
• Rocket lands and resets game
• 2 player code in place
• Score board updates accordingly

 

Below is a video of current state:

 

https://youtu.be/v_IIiN1o-I8

 

No sound implemented yet, but OLD CS1 has kindly agreed to create the sound effects for Jetpac, and I'll include them when they are ready. Next: Monsters!

 

Note:

In Classic99, if PC joysticks are selected in settings but not connected, Jetpac runs very slowly. Not sure if it is an issue with Classic99 or TF. Very weird...