Jump to content
senior_falcon

XB Game Developers Package

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

 

Share this post


Link to post
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

Share this post


Link to post
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 1

Share this post


Link to post
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! :)

 

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
Posted (edited)
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

Share this post


Link to post
Share on other sites
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. 

Share this post


Link to post
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

Share this post


Link to post
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...