XB256 revised

[Opry99er]

So, if I understand this correctly, we could have two completely different screens drawn up and stored in memory... Then to switch between the two (instantaneously) all that would need to be done is a CALL LINK("SCRN1") and the two screens will "toggle" on command, correct?

 

If that is the case, are character and color set redefinitions handled in assembly or in XB?

 

Sorry if I'm asking a ton of questions here, I'm just a bit amazed by what all this thing does. =)

 

 

Owen

[senior_falcon]

Character definitions and color definitions for Screen1 and Screen2 are independent of each other. Screen1 is the standard XB screen that we've used for the past 30 years and CALL CHAR, CALL COLOR, CALL CHARPAT, CHARSET, etc. work as usual. Screen2 uses different areas of the VDP memory for the colors and character patterns. So for screen2 you access these with CALL LINK("CHAR2",hexadecimal string), CALL LINK("COLOR2",FG,BK,CHSET), CALL LINK("CHPAT2",X,A$), CALL LINK("CHSET2")

 

You toggle between them with CALL LINK("SCRN1") or CALL LINK("SCRN2"). XB256 defaults to Screen1. After choosing a screen, DISPLAY AT, PRINT, HCHAR, VCHAR, GCHAR, SPRITE, etc. all work normally.

 

A quick demo of toggling between screens:

 

 

100 CALL LINK("CHSETL") ! set large character set for scrn2

110 CALL LINK("SCRN1"):: PRINT "Now in Screen One"

120 GOSUB 150

130 CALL LINK("SCRN2"):: PRINT "NOW IN SCREEN TWO": :

140 GOSUB 150 :: GOTO 110

150 CALL KEY(0,K,S):: IF S<1 THEN 150 :: RETURN

[sometimes99er]

Would it be possible to have a Screen3 with character and color definitions as for Screen1, but screen definition as for Screen2 ? Is that effectively what we would just call a screen buffer or double buffering ? I think I'd find that rather useful, economic and efficient with quite some game, demo and effect ideas.

 

Edited April 19, 2013 by sometimes99er

[senior_falcon]

I would have to think about how practical that would be. I am assuming that what you want is to be able to prepare the new screen where it cannot be seen, then with one CALL LINK have it replace the old screen as fast as possible. That way you wouldn't see the screen as it is being updated but just a series of completed screens replacing each other. You could prepare the screen in the usual place, VDP ram >0000 to >02FF. In theory you could write this screen to two separate buffers in VDP memory and toggle between them by changing VDP registers. The problem is actually doing anything with the screen that is active. INPUT and ACCEPT AT wouldn't work because they expect the screen to be in the usual area. Tell me what you have in mind with this and I would be in a better position to know how feasable this is.

[sometimes99er]

Ah yeah, it has its implications when active screen is not the one on display.

 

I guess your arsenal as is, is fine for setting up splash scenes of "eaten", "the end", interludes (Pac-Man) or commercials (mighty Coca-Cola logo). All of these came to mind from things I did in the eighties. I think I forgot how fast the compiled code is, and it's easy to simply keep all 16 color-sets all one color while setting up the screen with this and that, if one wants a real "splash".

 

"Double buffering" using VWRITE and VREAD, and then the ability to switch would be all fine. Can VWRITE be used for doing the switch ? I think I used to be able to use Mini Memory and its POKEV to do just that - not sure though. Again, I was momentarily forgetting the speed of compiled code, and maybe wrapped a little in a First Person Shooter mode.

 

Anyway, no imminent needs to be covered.

 

[Opry99er]

100 CALL LINK("CHSETL") ! set large character set for scrn2

110 CALL LINK("SCRN1"):: PRINT "Now in Screen One"

120 GOSUB 150

130 CALL LINK("SCRN2"):: PRINT "NOW IN SCREEN TWO": :

140 GOSUB 150 :: GOTO 110

150 CALL KEY(0,K,S):: IF S<1 THEN 150 :: RETURN

 

That's pretty awesome.... For games that use multiple screens, this could be an excellent feature. In Riding For the Brand, I specifically stayed away from the "stat" screen between villains because I didn't want to have to redraw and take all that time.

What I had originally wanted to do was, after each villain, show a statistic screen which showed how many bullets were expended during the course of the shootout (and place a limit to the amount of TOTAL bullets for the game), what the gunslinger's accuracy percentage was (hits/total) and have a "dead villain" graphic on the screen... I didn't do any of that because of the screen-draw limitations in XB.

 

Once "Baseball99-BBS" is done, I will certainly need to think about what's possible using this tool for the full-game development. I think you suggested before having the "gameplay" screen, and then a "stat" screen of sorts... similarly to what I had intended for RFTB.

 

Exciting times for XB programmers. =) Assembly speed screen draws via built-in XB calls.

[Opry99er]

Here's been my path to "workable" screen draws...

 

10260 FOR I=1 TO 14 :: CALL COLOR(I,2,1):: NEXT I :: GOTO 210

 

All this does is change EVERYTHING black until I can re-draw... Then I have been re-setting the colors... A little trick that makes the display more pleasant, but definitely not fast. I think little stuff like this is what separates great XB games from great Assembly games... Play Honeycomb Rapture and then play Neverlander. Both quality concepts, both well implemented, but in a "shootout," the A/L game wins every time. =)

 

Plus Marc is a better programmer than I am. =) hehehe

Edited April 20, 2013 by Opry99er

[senior_falcon]

"Double buffering" using VWRITE and VREAD, and then the ability to switch would be all fine. Can VWRITE be used for doing the switch ?

After CALL LINK("SCRN1"), Screen1 is displayed on the screen (VDP memory 0 to 767) Screen2 is kept in a buffer from 11264 to 12031. After CALL LINK("SCRN2") Screen2 which was kept in the buffer from 11264 to 12031 is transferred to the screen (0 to 767) and Screen1 which is currently displayed is transferred to the buffer. Here's the tricky part - the first 256 bytes go to VDP from12032 to 12287 and the last 512 bytes go to 11264 to 11775. If you keep this in mind, it is possible to use VREAD and VWRITE to modify the screen that is not being displayed and then use CALL LINK("SCRN1") or CALL LINK("SCRN2") to switch screens.

 

Also remember that the COMPRESS utility can be used to save characters from the screen or character definitions into DATA statements that can be merged into your XB program. Then these can be loaded with a simple one line program. (Pages 15 - 18 in the manual.)

[sometimes99er]

Okay. Thanks.