Jump to content
IGNORED

XB Game Developers Package


senior_falcon

Recommended Posts

Can CALL LINK("flick") be added to XB256?

I know it is not senior_falcon code, but it seems like Tursi would be okay with that?

 

I do every thing I can to avoid 5 sprites on a row...  But as we all know, you cannot always do that.

Hmm, might have to do a 6x4 space invader type demo? 

Even with that...  My ship and missile leaves only 2 sprites..  2 bomb drops / 1 plus ufo  still a pretty limited version.

5x4  might be better....

 

I have had zero inspiration of late.. trying to spark some creativity and desire to work on the TI99.

 

I have 3 projects started and some form of stuck on all of them. LOL

 

Link to comment
Share on other sites

6 hours ago, tmop69 said:

Another improvement could be the ability to turn the routine ON or OFF. If I peek at -31877 and there are 5 sprites on a row I can activate the routine, deactivate if not. This will reduce the general flickering of sprites added by this code (at least on LCD, not checked the effect on CRT on real iron). The ideal would be an automatic, interrupt driven, code, but not sure if it's feasible/integrable with XB and the compiler.

A flicker routine should not generate any flicker when there are 4 or fewer sprites in a row. In Archon the flicker routine also seems to make the sprites blink when there's only two sprites in a row, so maybe something is wrong?

  • Like 1
Link to comment
Share on other sites

12 hours ago, Asmusr said:

A flicker routine should not generate any flicker when there are 4 or fewer sprites in a row. In Archon the flicker routine also seems to make the sprites blink when there's only two sprites in a row, so maybe something is wrong?

 

If you look at Archon, in the title screen the first row at top has 5 sprites for tiles and 4 at bottom:

 

380 FOR I=1 TO 4 :: CALL SPRITE(#I,104+I*4,2,120,I*51) :: NEXT I
390 FOR I=5 TO 9 :: CALL SPRITE(#I,104+I*4,2,45,40+(I-4)*37) :: NEXT I

 

The 5 sprites are correcly showed with flicker and the 4 sprites at botton are without any flicker.

 

In the game, you have two columns of sprites at left and right and another one for the cursor. The sprites in the first two rows are flickering although there are less then 4 sprites in a row.
If you place 2 tiles in a row at bottom and the cursor is on the same line there is flicker, but you can see the 5 sprites. The same behaviour for the first row, except that if you move down the curson that line is flickering also with 4 sprites!

 

In the combat screen, there are only two sprites. If you move both on top of the screen they are flickering, but no flicker if they are both on bottom part of the screen. If you move only 1 sprite at the top, it's flickering...

 

 

Now, let's try to understand if there is something wrong related to the Archon code or with the routine with this simple test:


5 CALL LINK("flick")
10 CALL CLEAR :: CALL CHAR(128,RPT$("F",16)) :: CALL MAGNIFY(2)::CALL SCREEN(2)
20 FOR R=1 TO 3 :: FOR C=1 TO 5 :: CALL SPRITE(#((R-1)*10)+C,128,8+(C-R),64+(16*(R-1))+(4*(R-1)),64+(16*(C-1))+(4*(C-1))) :: NEXT C :: NEXT R
30 CALL DELSPRITE(#5,#25)
40 GOTO 40


It creates 3 lines of 5 sprites in the middle of the screen, then the 5th sprite on the 1st and 3rd line are removed. The first line is flickering with 4 sprites, the 3rd is not flickering with 4 sprites! The 2nd line is showing 5 sprites and is flickering.
Moreover, on the 1st line there is a small glitch (a line of pixels) sometimes in the position of the 5th sprite.

 

So, now let's the various assembly gurus have a look at the xb_flicker code to explain us what is happening... ?

 

 

In attachment the cart for this test.

 

XB_Flicker_Test_G.bin

  • Like 2
Link to comment
Share on other sites

20 hours ago, senior_falcon said:

That's a nice, concise distillation of the steps needed. Be sure CALL LINK("flick") uses lower case.

Tursi is right; the program uses random velocities. Sometimes the XB version has one or two stationary sprites and sometimes the compiled version. When the compiled version starts up, all 28 sprites are lined up so there is massive flicker at first until they move to different lines.

@Tursi, if you want to develop a more polished version, you should be able to use the edit/recall buffer v08C0 to v0957 for your buffer instead of using the disk buffer.

I am certainly willing to let you use the code for the compiler in any way that you like, but I don't intend to make any further updates. I'm not an XB wizard, I was hoping you'd have a way to safely reserve a buffer for it. ;) I would have to assume using the edit buffer means it would have to turn off when the program isn't running or an input happens? I don't know what's safe! :)

 

Link to comment
Share on other sites

20 hours ago, tmop69 said:

Another improvement could be the ability to turn the routine ON or OFF. If I peek at -31877 and there are 5 sprites on a row I can activate the routine, deactivate if not. This will reduce the general flickering of sprites added by this code (at least on LCD, not checked the effect on CRT on real iron). The ideal would be an automatic, interrupt driven, code, but not sure if it's feasible/integrable with XB and the compiler.

No, it will only perform unnecessary processing. If there are not 5 sprites on a line, then no sprites are invisible, therefore there is no flicker (even though the table is being rotated).

 

  • Like 1
Link to comment
Share on other sites

1 hour ago, tmop69 said:

It creates 3 lines of 5 sprites in the middle of the screen, then the 5th sprite on the 1st and 3rd line are removed. The first line is flickering with 4 sprites, the 3rd is not flickering with 4 sprites! The 2nd line is showing 5 sprites and is flickering.
Moreover, on the 1st line there is a small glitch (a line of pixels) sometimes in the position of the 5th sprite.

Then yes, there is a bug. It's probably injecting an extra sprite by accident. ;)

 

(edit) I looked into it, so what's going on in Classic99 at least is that the screen is being drawn during the visible part of the display.. I copied it over to hardware and found to my surprise that Classic99 has the scanlines pretty close.

 

Basically, for a brief period when the sprite table is being copied, on certain frames, more than 4 sprites are visible on the first row there - but it's fixed by the time the copy is done. It looks like it's finished about 2 scanlines into the second row... to prove this, if you start the first row of sprites at 84, you shouldn't see the effect at all.

 

So, the intent of this loop is that is needs to execute during the blank, but it looks like it takes long enough to get through the main interrupt routine that we're already finished the blank by the time the sprite table copy starts. 

 

I'm not sure how to fix this... the copy needs to happen earlier after the interrupt starts.

 

Edited by Tursi
  • Like 4
Link to comment
Share on other sites

  • 3 weeks later...
On 6/29/2021 at 5:17 AM, senior_falcon said:

Here is XBGDP20210628. the release version of the XB Game Developer's Package "Juwel"

Hi, is it just my setup or is F3 "Erase" not working in this version of XB 2.8?

 

I used to erase the suggested "OLD DSK" on startup when I didn't want to load something in XB. CALL KEY correctly reports 7 on F3. 

Link to comment
Share on other sites

1 hour ago, SteveB said:

Hi, is it just my setup or is F3 "Erase" not working in this version of XB 2.8?

 

I used to erase the suggested "OLD DSK" on startup when I didn't want to load something in XB. CALL KEY correctly reports 7 on F3. 

From the manual:

There are changes to the line editor to make programming easier. You can enter long XB lines with up
to 12 rows of code instead of the usual 5. The cursor repeat speed is faster. When editing a program line
the cursor appears in the usual place, but you can go left and change the line number. The
left/right/up/down keys function normally. Or you can hold down Ctrl and use the up/down/right/left
keys to easily navigate a lengthy program line. Right/left work normally and up/down will go up or
down one row in the line being edited. If you are on the last row, Ctrl+down goes to the end of the line.
If you are on the first row, Ctrl+up goes to the beginning of the line. Fctn 3 (clear) erases the line from
the cursor to the end of the line.

With standard XB,  erase erases the entire line from beginning to end. If you want to delete a line (let's say line 100) you can type 100 and down arrow. The line is displayed with the cursor flashing on the first byte of code. Erase removes all the code but leaves the line number. Press enter and line is erased.

But with GEM the line number is the first byte in the line. Erase would leave you with a blank line, thus line 100 would not be erased. By only erasing everything to the right of the cursor you can delete line 100 as described above. Also, by moving the cursor you can have better control of what is erased, giving more flexibility. If you want to get rid of "OLD DSK", you can cursor left to the beginning of the line, or use 'control up' to go to the beginning of the line, then press F3.

 

(Edit) I forgot that you can press F4 which will accomplish what SteveB wants to.

Edited by senior_falcon
  • Like 2
  • Thanks 1
Link to comment
Share on other sites

  • 1 month later...
On 6/28/2021 at 10:17 PM, senior_falcon said:

Here is XBGDP20210628. the release version of the XB Game Developer's Package "Juwel"

The zipped folder contains two folders. One is JUWEL which contains the latest versions of the compiler and XB256. Compiled programs can now use assembly support routines.

The other folder is XB28GEM,  which contains XB 2.8 G.E.M. and its documentation. This offers many improvements over XB 2.7.  and really unlocks the graphics potential of the TI-99/4A. XB can now use bit mapped graphics, 40 column text mode, 80 column text mode and XB256, all available from the main menu.

 

(edit 2 July) This new package contains a revised version of XB 2.8 G.E.M. that corrects a minor bug when loading EA5 programs.  Otherwise it is identical to the previous version.

 

XBGDP20210702.zip 4.29 MB · 8 downloads

I've just been trying out the XB Game Developer's Package. (Downloaded the above package.)

 

This is a fantastic collection of software!

 

JEWEL works great with Classic99.

I found what I believe is a problem with the JUWEL99 folder as initially unzipped.

 

JEWEL99 has files that continue to point to 8.3 filenames in the Compiler. 

BTW, I am running it on my Console with SAMs and TIPI sidecars.  I really want to try to use my real hardware as much as possible.

 

I tried several "fixes" that made it work more or less:

I loaded and modified the "COMPILER" in the original  JUWEL99 directory.  It was trying to run the RUNTIME'X'.TXT files and tacking on .TXT to the filenames among other things.  The LOAD program would crash after saving the MERGE file when trying to reload itself.  

 

BUT WAIT!!!

There is a file in the JEWEL99 directory: "JEWEL99ARC".  I uncompressed it.  The files in the archive work perfectly!

 

Thanks,  senior_falcon.  I truly appreciate your work! 

 

David G

 

 

 

  • Like 1
Link to comment
Share on other sites

Glad you like it! I'm not quite sure what you mean by this:

"JEWEL99 has files that continue to point to 8.3 filenames in the Compiler." 

Judging by the date and time stamp, it looks like the compiler in JUWEL99 is exactly the same as the compiler in the normal package for Classic99.

This would be wrong because the compiler must be adapted to work with the TI format files using -S and -O, not .TXT and .OBJ

Glad that the arc'd one works. I will look into this.

 

Link to comment
Share on other sites

10 hours ago, senior_falcon said:

Glad you like it! I'm not quite sure what you mean by this:

"JEWEL99 has files that continue to point to 8.3 filenames in the Compiler." 

 

 

Opps, my old brain inserted "8.3" for the old MSDOS filename system (8 character filename with period/dot and 3 character suffix).  The only part of that concept that is accurate in todays PC world is the ".3" as in .TXT etc.  ?

Link to comment
Share on other sites

  • 2 months later...

It seems that passing arrays to SUB routines is not working. With:

 

1150 CALL LOOK(BUGX(ID),BUGY(ID),PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,BUG(ID,1))

 

2820 SUB LOOK(BUGX,BUGY,PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,V)

 

The values of BUGX,BUGY and V in the subroutine remain 0 regardless of the values passed to them in the arrays of the calling statement.

Link to comment
Share on other sites

9 hours ago, Vorticon said:

It seems that passing arrays to SUB routines is not working. With:

 

1150 CALL LOOK(BUGX(ID),BUGY(ID),PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,BUG(ID,1))

 

2820 SUB LOOK(BUGX,BUGY,PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,V)

 

The values of BUGX,BUGY and V in the subroutine remain 0 regardless of the values passed to them in the arrays of the calling statement.

I wouldn't even expect XB to cope. ?
 

Link to comment
Share on other sites

24 minutes ago, sometimes99er said:

I wouldn't even expect XB to cope. ?

Sure it does :) The SUB functionality in XB is exceptionally robust and sadly an under-appreciated facility. The code snippets are actually from a real XB program of mine (Musings in Artificial Intelligence https://tigameshelf.net/edu.htm) simulating colonies of predators and prey. It is excruciatingly slow, and I am trying to compile it... 

  • Like 1
Link to comment
Share on other sites

10 hours ago, Vorticon said:

It seems that passing arrays to SUB routines is not working. With:

 

1150 CALL LOOK(BUGX(ID),BUGY(ID),PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,BUG(ID,1))

 

2820 SUB LOOK(BUGX,BUGY,PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,V)

 

The values of BUGX,BUGY and V in the subroutine remain 0 regardless of the values passed to them in the arrays of the calling statement.

 

If you are not attempting to change the calling program’s array values in the subprogram, try enclosing the passed array elements in “( )” to force passing by value:

1150 CALL LOOK((BUGX(ID)),(BUGY(ID)),PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,(BUG(ID,1)))

2820 SUB LOOK(BUGX,BUGY,PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,V)

...lee

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

17 minutes ago, Lee Stewart said:

 

If you are not attempting to change the calling program’s array values in the subprogram, try enclosing the passed array elements in “( )” to force passing by value:


1150 CALL LOOK((BUGX(ID)),(BUGY(ID)),PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,(BUG(ID,1)))

2820 SUB LOOK(BUGX,BUGY,PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,V)

...lee

Wow. I never new about that.

Thanks Lee

  • Like 1
Link to comment
Share on other sites

2 hours ago, Lee Stewart said:

 

If you are not attempting to change the calling program’s array values in the subprogram, try enclosing the passed array elements in “( )” to force passing by value:


1150 CALL LOOK((BUGX(ID)),(BUGY(ID)),PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,(BUG(ID,1)))

2820 SUB LOOK(BUGX,BUGY,PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,V)

...lee

I did try that earlier and it did not work...

Link to comment
Share on other sites

2 hours ago, TheBF said:

Wow. I never new about that.

Thanks Lee

Yup, the SUB facility is very versatile as you can pass parameters either by reference or by value. You can even pass entire arrays by omitting the array subscripts (for example BUG(,) ).That and the fact that all variables within the SUB section are local to the sub and not global (an advanced concept for the Basics' of the time) make it far more powerful than regular subroutines and help modularize the program.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

17 hours ago, Vorticon said:

It seems that passing arrays to SUB routines is not working. With:

 

1150 CALL LOOK(BUGX(ID),BUGY(ID),PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,BUG(ID,1))

 

2820 SUB LOOK(BUGX,BUGY,PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,V)

 

The values of BUGX,BUGY and V in the subroutine remain 0 regardless of the values passed to them in the arrays of the calling statement.

The program below is adapted from your example and prints the expected 7 three times in both XB and when compiled.


100 FOR I=0 TO 10 :: BUGX(I)=I :: BUGY(I)=I :: BUG(I,1)=I :: NEXT I
1000 ID=7 
1150 CALL LOOK(BUGX(ID),BUGY(ID),PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,BUG(ID,1))
1200 PRINT "BACK FROM SUB" :: END 
2820 SUB LOOK(BUGX,BUGY,PREDATOR,FOOD,FRIEND,PX,PY,FX,FY,FRX,FRY,V)
2830 PRINT BUGX:BUGY:V
2850 SUBEND 

i should add that the numbers passed here are treated as simple values. I don't think you can pass an entire array to a subprogram when compiled. (But I could be wrong)

I just tested and found that you can indeed pass an entire array to a subprogram in a compiled program.

Edited by senior_falcon
  • Like 1
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...