Beamrider scanlines

[Bones-69]

Hey guys,

 

Been fooling with the idea of shaping the Beamrider concept into something with a similar theme for the TI. Intent would be to write in XB and compile.

 

 

Initially I thought this would be pretty simple to throw together until I invested some time and realised the horizontal scrolling scanline/s were a lot more difficult to replicate than I first thought. 

 

 

 

If the scanline was to start just below the red sprite and move downward, every time it comes in contact with a Blue Lined character and passes on through - this would require an additional 8 characters definitions to produce the illusion. I've worked out a way to do it which basically involves a temporary row being overlaid and then every character in that row is redefined to produce the effect of a solid scanline passing through (actually pretty efficient as there are only ever between 9 and 3 characters that need to be defined at any one time in any given row). However it turns out I need 120 character definitions to do this (15 individual characters that each themselves have 8 variations), and a bunch of strings to make it all work. Seems I am going to be out 3-4K just for the price of this effect although the code will only be like 6 lines or something and should run pretty darn quick.

 

Has anyone got any thoughts on how this might be streamlined? I considered using a sprite overlay on each line intersection to negate all the above, but I would need anywhere between 6 and 2 sprites in a row which apart from the 4 sprites in a row "ïssue",  I feel this is an unwholesome solution anyway. The only other option is I don't cross the lines, which makes the whole problem go away but I feel it looses something in the process. Below shows this super easy solution that could all be achieved with one character that SIMPLY goes FF, 00FF, 0000FF, 000000FF and then jumps to the next row after 00000000000000FF.

 

 

The only other thing I can think of is to manipulate the existing character strings by inserting a "FF" and controlling the string/char value as the FF moves its way down each Charcode. This would save a stack of memory, but I think performance would take a massive hit as instead of pulling the predefined characters definitions from memory and defining them in a single statement, I would have to perform several hundred (I calculated just under 600) string manipulations to complete one full screen pass. 

 

Must be an easier way? 

 

 

 

[Asmusr]

It looks like the animation consists of 8 frames only. Using assembly you could perhaps fit all of them into VDP RAM so you could flip between them by setting a few registers. It sounds like a difficult task to make if move fast enough in XB - even if compiled.

[Bones-69]

5 hours ago, Asmusr said:

It looks like the animation consists of 8 frames only. Using assembly you could perhaps fit all of them into VDP RAM so you could flip between them by setting a few registers. It sounds like a difficult task to make if move fast enough in XB - even if compiled.

I think I have all but decided to stick with the last idea which contains the "dashes", but I will follow this experiment through to completion. I was counting on being able to define 8 characters using a single XB256 command. Figured doing this once every loop and then incrementing the row after the 8th definition wouldn't be too demanding. I had even theorised I may have needed to slow it down! I am super interested to find out which is true and will post results. Cheers.

[oddemann]

What if you cheat and use changing colours ("rainbow'ing") to simulate the movement. BUT, then the abrupt colour changes are big. The TI should have a Gray scale of colours mode.

Would that be possible to cheat and make that mode in C99?

[Asmusr]

16 hours ago, Bones-69 said:

 I am super interested to find out which is true and will post results.

Me too.

And maybe I will try to make an assembly version, if you don't mind. Not of the whole game, just of the grid.

[Asmusr]

4 hours ago, oddemann said:

What if you cheat and use changing colours ("rainbow'ing") to simulate the movement.

I don't understand how that would work. Please explain.

[senior_falcon]

47 minutes ago, Asmusr said:

Me too.

And maybe I will try to make an assembly version, if you don't mind. Not of the whole game, just of the grid.

Juwel lets you use assembly support routines with compiled code. An assembly routine that runs from the interrupt hook might be perfect for this. Then the compiled code would only have to deal with game play. Moving the lines is a little tricky because perspective makes them speed up as they approach.

[tmop69]

47 minutes ago, Asmusr said:

Me too.

And maybe I will try to make an assembly version, if you don't mind. Not of the whole game, just of the grid.

Well, it could be interesting to have the full game in compiled XB256, Assembler and C (maybe sharing the same assets) an compare the final result and the effort (in terms of hours of coding). Beamrider is a really nice game. I like the Atari 2600 version, probably better than Colecovision version, although a less powerful hw.

[oddemann]

3 hours ago, Asmusr said:

I don't understand how that would work. Please explain.

Spoiler

10 CALL CLEAR
20 FOR I=128 TO 152 STEP 8
30 CALL CHAR(I,"FFFFFFFFFFFFFFFF")
40 NEXT I
60 CALL SCREEN(8)
70 FOR A=13 TO 10 STEP -1
80 CALL COLOR(13,A,A)
90 CALL COLOR(14,A+1,A+1)
100 CALL COLOR(15,A+2,A+2)
110 CALL COLOR(16,A+3,A+3)
120 CALL HCHAR(8,1,128,128)
130 CALL HCHAR(12,1,136,128)
140 CALL HCHAR(16,1,144,128)
150 CALL HCHAR(20,1,152,128)
160 NEXT A
170 GOTO 70

 

I am sure that the code can be made smaller, but that is the idea.
And then do this inside all the "segments" and have the colour rolling towards you.
Maybe put the lines on top of this.

But this is the idea!

[Bones-69]

8 hours ago, senior_falcon said:

Juwel lets you use assembly support routines with compiled code. An assembly routine that runs from the interrupt hook might be perfect for this. Then the compiled code would only have to deal with game play. Moving the lines is a little tricky because perspective makes them speed up as they approach.

I had thought about this and believe the illusion could be created with just three speeds. 1 being the lowest, 9 being the highest..... I imagine 1111 5555 5555 5559 99, where each number represents sequential screen rows(my mock-up has 18 rows in play), and where the value represents the frequency of the character definition update (effectively the scroll speed).

 

Updating the character definition frequency speed using something algorithmic would look a lot better - but I'm not that smart.

  

[PeteE]

From the video, it looks like each horizontal line is 2 pixels thick, and moves by increments of 2 pixels, so the number of character groups would be 5 (one for each of the 4 horizontal line positions, plus one for no line.)  My mock-up in Magellan uses about 24 characters per group, so roughly 120 total.  So this could run without changing the character patterns, only changing the horizontal rows of characters on screen.  And it seems like the number of rows updated on each frame is low, so the animation would be pretty efficient.

beamrider2.mag

Edited December 19, 2021 by PeteE
Attached Magellan file. The animation is on screens 5 to 41.

[Asmusr]

Here's an implementation of my idea of using 8 VDP RAM buffers for drawing the background. Once the data are uploaded to the VDP, it takes only a couple of machine code instructions to switch between the images, leaving almost all the CPU for the actual game. It can run at any speed, but I have slowed it down to 30 FPS in the demo, waiting for VSYNC before switching the buffer, which prevents any screen tearing you could get from updating the screen while it's being drawn.

 

The demo is using 218 characters for all 8 images, but depending on how you draw the images it could probably be done with fewer. Note that the lines have to speed up as they reach the bottom of the screen to make it look like a proper 3D animation, so in some cases there will be more than two lines in one character. The 8 buffers take 8 x 768 bytes of VDP RAM in addition to the patterns, so I don't know if my idea could by used with compiled XB, but if I was to implement the game using assembly, that's what I would do.

beamrider-gfx-8.bin

Edited December 27, 2021 by Asmusr

[Bones-69]

2 hours ago, Asmusr said:

Here's an implementation of my idea of using 8 VDP RAM buffers for drawing the background. Once the data are uploaded to the VDP, it takes only a couple of machine code instructions to switch between the images, leaving almost all the CPU for the actual game. It can run at any speed, but I have slowed it down to 30 FPS in the demo, waiting for VSYNC before switching the buffer, which prevents any screen tearing you could get from updating the screen while it's being drawn.

 

The demo is using 218 characters for all 8 images, but depending on how you draw the images it could probably be done with fewer. Note that the lines have to speed up as they reach the bottom of the screen to make it look like a proper 3D animation, so in some cases there will be more two lines in one character. The 8 buffers take 8 x 768 bytes of VDP RAM in addition to the patterns, so I don't know if my idea could by used with compiled XB, but if I was to implement the game using assembly, that's what I would do.

beamrider-gfx-8.bin 32 kB · 4 downloads

I don't know what to do with a .bin file. Gimmie some time to research. :)

 

I was fooling around more with the idea trying to understand the scroll rate. All the idea's I had would produce something that would resemble this type of scroll effect (which I find rather undesirable personally).

https://www.youtube.com/watch?v=Ou4v1GJe0ko

[Asmusr]

8 hours ago, Bones-69 said:

I don't know what to do with a .bin file. Gimmie some time to research.

It's a cartridge image that requires 32K. You can open it in Classic99 as a user cartridge, or use it in the FinalGROM.

[+mizapf]

An RPK file for MAME users. I suppose it's the usual 378-based banking.

beamrider.rpk

[+TheBF]

17 hours ago, Asmusr said:

Here's an implementation of my idea of using 8 VDP RAM buffers for drawing the background. Once the data are uploaded to the VDP, it takes only a couple of machine code instructions to switch between the images, leaving almost all the CPU for the actual game. It can run at any speed, but I have slowed it down to 30 FPS in the demo, waiting for VSYNC before switching the buffer, which prevents any screen tearing you could get from updating the screen while it's being drawn.

 

The demo is using 218 characters for all 8 images, but depending on how you draw the images it could probably be done with fewer. Note that the lines have to speed up as they reach the bottom of the screen to make it look like a proper 3D animation, so in some cases there will be more than two lines in one character. The 8 buffers take 8 x 768 bytes of VDP RAM in addition to the patterns, so I don't know if my idea could by used with compiled XB, but if I was to implement the game using assembly, that's what I would do.

beamrider-gfx-8.bin 32 kB · 13 downloads

I have a minimal understanding of this concept and would love to learn more.

Is there any chance we could see the source code...  

[Asmusr]

1 hour ago, TheBF said:

I have a minimal understanding of this concept and would love to learn more.

Is there any chance we could see the source code...  

Sure, but it just a matter of changing VDP register 2 to use another address for the name table (or screen image table as it was called in the E/A documentation). I created the images using a Java program (not attached) and imported them into Magellan (file attached). From Magellan I exported the data to 'graphics.a99', which is part of the source code.  

src.zip beamrider.mag

Edited December 27, 2021 by Asmusr

[+OLD CS1]

Quick-and-dirty in compiled XB.  It is not exact and lacks perspective of the moving lines, also has a ~100ms delay between line moves (deliberate to manage speed.)  This was done using 20 characters.  Perspective on the horizontal lines will add more characters, as will more vertical lines.  The lines currently line up to a for row section, as the least steep angle lines up to four characters.  Could be less, could be more.  But, this is just a simple PoC.

 

BEAMS-X.zip

[+TheBF]

12 hours ago, OLD CS1 said:

Quick-and-dirty in compiled XB.  It is not exact and lacks perspective of the moving lines, also has a ~100ms delay between line moves (deliberate to manage speed.)  This was done using 20 characters.  Perspective on the horizontal lines will add more characters, as will more vertical lines.  The lines currently line up to a for row section, as the least steep angle lines up to four characters.  Could be less, could be more.  But, this is just a simple PoC.

Are just putting CALL CHAR() in a loop for the demo?

[+OLD CS1]

On 12/28/2021 at 9:16 AM, TheBF said:

Are just putting CALL CHAR() in a loop for the demo?

Yes. Seemed an easy way to do it in XB.  I was thinking about how to do perspective but my brain is addled right now by meds.

 

5 CALL CLEAR 6 READ L$(0),L$(1),L$(2),L$(3) 8 FOR I=0 TO 1 :: READ H$(I,0),H$(I,1),H$(I,2),H$(I,3),H$(I,4):: NEXT I 10 FOR I=1 TO 14 :: READ A$ :: PRINT A$;:: NEXT I 11 CALL CHAR(90,L$(3)):: CALL HCHAR(10,3,90,28) 20 FOR I=0 TO 3 :: FOR J=0 TO 3 :: CALL CHAR(81+I,L$(J),65+I*4,H$((I AND 1),J)) 21 CALL SOUND(100,220,30):: CALL SOUND(1,220,30):: NEXT J 22 CALL CHAR(81+I,"",65+I*4,H$((I AND 1),4)):: NEXT I 30 GOTO 20 500 DATA FFFF,0000FFFF,00000000FFFF,000000000000FFFF 501 REM | | | | 502 DATA FFFF040810204080FFFF020204040808FFFF404020201010FFFF201008040201 503 DATA 0102FFFF102040800101FFFF040408088080FFFF202010108040FFFF08040201 504 DATA 01020408FFFF408001010202FFFF080880804040FFFF101080402010FFFF0201 505 DATA 010204081020FFFF010102020404FFFF808040402020FFFF804020100804FFFF 506 DATA 0102040810204080010102020404080880804040202010108040201008040201 511 REM | | | | 512 DATA FFFF040810204080FFFF202040408080FFFF040402020101FFFF201008040201 513 DATA 0102FFFF102040801010FFFF404080800808FFFF020201018040FFFF08040201 514 DATA 01020408FFFF408010102020FFFF808008080404FFFF010180402010FFFF0201 515 DATA 010204081020FFFF101020204040FFFF080804040202FFFF804020100804FFFF 516 DATA 0102040810204080101020204040808008080404020201018040201008040201 600 DATA QQQQQQQQAQQQBQQQCQQQDQQQQQQQ 601 DATA RRRRRRRERRRRFRRRGRRRRHRRRRRR 602 DATA SSSSSSISSSSJSSSSSKSSSSLSSSSS 603 DATA TTTTTMTTTTTNTTTTTOTTTTTPTTTT 604 DATA QQQQAQQQQQBQQQQQQQCQQQQQDQQQ 605 DATA RRRERRRRRRFRRRRRRRGRRRRRRHRR 606 DATA SSISSSSSSJSSSSSSSSSKSSSSSSLS 607 DATA TMTTTTTTTNTTTTTTTTTOTTTTTTTP 608 DATA AQQQQQQQBQQQQQQQQQQQCQQQQQQQ 609 DATA RRRRRRRRFRRRRRRRRRRRGRRRRRRR 610 DATA SSSSSSSJSSSSSSSSSSSSSKSSSSSS 611 DATA TTTTTTTNTTTTTTTTTTTTTOTTTTTT 612 DATA QQQQQQBQQQQQQQQQQQQQQQCQQQQQ 613 DATA RRRRRRFRRRRRRRRRRRRRRRGRRRRR

[Willsy]

Might be worth seeing how Buck Rogers does it. IIRC it is using character mode and just re-defining some characters. Classic99 debugger will tell you. I remember having a conversation with @sometimes99er about it many, many moons ago!