Jump to content
IGNORED

New game project: Jetpac


Vorticon

Recommended Posts

 

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

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

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.

Link to comment
Share on other sites

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

 

...lee

  • Like 1
Link to comment
Share on other sites

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

 

...lee

 

Hiya Lee

 

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

 

Enjoy :)

Link to comment
Share on other sites

  • 2 weeks later...

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

Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

  • Like 3
Link to comment
Share on other sites

  • 3 weeks later...

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

  • Like 9
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...