Bones-69

Quick update for my new game. Some changes to the original idea. Map has been changed to 45 x 120 (previously 63 x 112) as this allowed for more even scrolling and also gained another 1500 bytes memory which although I don't *think* I will need - it adds a nice buffer for the unforeseen and some extra bells and whistles. After much consideration in regards to how I was going to trigger events for each new screen that scrolls into place, I came up with a pretty simple yet obvious idea. Although I can't define graphics ASCII characters over 143, I can put these characters into strings and display them and on the black screen background of the game - and they remain invisible to the player. In each new screen there will be the opportunity to use GCHAR to fetch the value of the character which controls the game events (this character will always appear in the same X/Y location in each screen). I can then use the value of this character within the program using ON GOTO or ON GOSUB to trigger events. Potentially this gives me 112 opportunities (characters 144 to 255) - even though I won't require this many, or for that matter have the programming space for this many events.... But using perhaps 50 doesn't seem unreasonable. This works out really well as it now completely disolves the requirement of the massive disc files I thought I would have to originally use which were quite wasteful in the big scheme of things. I am now in the process of building the level/s. Initially I hope to release the game with a single level (45 x 120 locations) and get some community feedback however the big plan is to build perhaps a game that consists of 5 levels each with a total grid of 45 X 120 locations. New levels will simply be read from disk so there is virtually no memory limitations in doing this. At this stage I am experimenting with level design and attempting to learn what makes an interesting and fun level without the frustration of navigating these large maps. I am finding it is a fine line between making things too hard and frustrating, and making things to easy...

Thanks for trying it guys. The difference between systems is nice to know. I have been playing around with some maps and I think one thing is now clear... Having a game screen height of just 9 characters makes it difficult for the little character to jump. Having the little dude jump was part of the original plan but I think I am going to have to ditch this, it just takes away from the game having to allocate jump clearance in the levels. I think now I am heading in a direction where the maze plays a bigger part of the game rather than "arcade action". Enemies will still exist but these must be destroyed to pass, rather than simply being able to jump over them.

As another thought, if you have lots of variables in arrays you can also put them into a single (or couple) of strings, then save the string/s to disk. For example (where A(n) is your array); FOR I=1 TO 50::A$=A$&STR$(A(I))&"#"::NEXT I::PRINT #1:A$ When you want to retrieve or save the data you only have to read one or 2 records. Then you can use LEN$, SEG$, POS and VAL to put the data back into the array where it belongs. The "#" is used to flag the end of one variable and the start of the next (so the value or length of A(I) is of no concern). I haven't done the test for speed but I am quite sure it is much quicker to read a single string and then process the string from within the program rather than (in this example), read/write 50 different records and allocate each one as it is encountered. Not sure how many variables you will be dealing with but on the assumption it is quite a few, this might help speed things up quite a bit during the SAVE/LOAD routine.

That sounds very useful. I have also wanted to be able to GOTO A, or GOSUB A(n), or anything that makes a good work-around for the whole ON GOTO or ON GOSUB alternatives.

Is getting RXB into Classic 99 an option? As much as I love the old hardware, I don't have the desk real estate to ever contemplate going back to a real TI system....

Before going too far into designing maps and more sprites etc, I wanted to nail the way the game screen moved and see if the idea had any real limitations. I think I came have some fairly tidy code that moves the screen around probably about the best I had hoped for. In the actual game I don't expect this scroll speed to change much as there will only be a few additional enemy sprites being relocated as they scroll on or off the viewable area. The current test map has some vertical and horizontal data on the top and left side. This was only to help me debug. The test map has 7056 locations (112 x 63) which is still currently my plan for the game resolution. http://www.youtube.com/watch?v=cezf689xfnk Would appreciate feedback on how it runs on different machines under full throttling (use arrow keys to move around). I can only test on a 4 year old Quad core and I do expect it to get a bit lazy on slower machines. Scroll "engine" is lines 500 to 650. 100 DIM M$(63):: X=41 :: Y=41 :: T=1 :: N=1 :: C$="********" 110 CALL CLEAR :: CALL SCREEN(2):: FOR I=3 TO 13 :: CALL HCHAR(I,2,120,30):: NEXT I 120 CALL CHAR(97,"55803DBC3DBC01AA",104,"558019A4259801AA",120,RPT$("F",16)) 130 CALL CHAR(128,"00000F080B0B0B0B0B0B0B0B0B0B080F0000FC04F4F4F4F4F4F4F4F4F4F404FC") 140 FOR I=1 TO 8 :: CALL COLOR(I,16,2):: NEXT I :: CALL COLOR(2,11,2,9,10,7,10,4,13,12,5,2) 150 A$=RPT$(RPT$("a",28)&RPT$("h",28),2):: B$=RPT$(RPT$("h",28)&RPT$("a",28),2) 160 FOR D=0 TO 63 STEP 18 :: FOR I=1 TO 9 170 M$(I+D)=A$ :: M$(I+9),M$(27+I),M$(45+I)=B$ :: NEXT I :: NEXT D 180 FOR D=9 TO 63 STEP 9 :: FOR I=1 TO 4 :: A=A+1 :: IF A<10 THEN A$="*MAP 0"&STR$(A)&"*" ELSE A$="*MAP "&STR$(A)&"*" 190 B$=SEG$(M$(D-4),1,I*28-18)&A$ :: M$(D-4)=B$&SEG$(M$(D-4),I*28-9,104) 200 B$=SEG$(M$(D-5),1,I*28-18)&C$ :: M$(D-5)=B$&SEG$(M$(D-5),I*28-9,104) 210 B$=SEG$(M$(D-3),1,I*28-18)&C$ :: M$(D-3)=B$&SEG$(M$(D-3),I*28-9,104):: NEXT I :: NEXT D 220 FOR I=1 TO 63 :: IF I<10 THEN M$(I)="0"&STR$(I)&M$(I)ELSE M$(I)=STR$(I)&M$(I) 230 NEXT I 235 A=65 :: M$(1)="01" :: FOR I=1 TO 112 :: :: M$(1)=M$(1)&CHR$(A):: A=A+1 :: IF A=91 THEN A=65 236 NEXT I ! M$(1) TEXT IS FOR TESTING. DEL 235 & 236 240 A$="" :: FOR I=0 TO 8 :: A$=A$&SEG$(M$(I+T),N,28):: NEXT I :: DISPLAY AT(4,1)BEEP:A$ 250 CALL MAGNIFY(3):: CALL SPRITE(#1,128,16,Y,X) 260 GOSUB 1000 :: GOSUB 1010 269 ! USE CODE ONWARDS IN GAME 270 B=0 :: CALL KEY(0,K,A):: IF K=-1 THEN 270 ELSE IF K=13 THEN 270 ! USE ENTER TO TEST REMOVING MAP CHARACTER 280 IF K<8 OR K>11 THEN 270 290 IF K<10 THEN 340 !JUMP TO HORIZ MOVEMENT ELSE PROCESS VERT MOVEMENT 300 IF K=11 AND Y<32 THEN B=1 ELSE IF K=11 THEN Y=Y-1 ! IN GAME CHECK FOR GCHAR 310 IF K=10 AND Y>72 THEN B=1 ELSE IF K=10 THEN Y=Y+1 ! IN GAME CHECK FOR GCHAR 320 IF B<>0 THEN 400 !SPRITE HAS REACHED END OF SCREEN 330 CALL LOCATE(#1,Y,X):: GOSUB 1000 :: GOTO 270 340 IF K=8 AND X<30 THEN B=1 ELSE IF K=8 THEN X=X-1 ! IN GAME CHECK FOR GCHAR 350 IF K=9 AND X>210 THEN B=1 ELSE IF K=9 THEN X=X+1 ! IN GAME CHECK FOR GCHAR 360 GOTO 320 399 ! CHECK IF EDGES OF FULL MAP (63X112) HAVE BEEN REACHED 400 IF K=11 AND T=1 THEN 270 ELSE IF K=10 AND T=55 THEN 270 410 IF K=8 AND N<4 THEN 270 ELSE IF K=9 AND N>83 THEN 270 420 IF K<10 THEN 600 499 ! PROCESS VERTICLE 500 IF K=11 THEN T=T-2 :: A=MAX(T-4,1):: IF ABS(A-T)<>4 THEN A=A-1 510 IF K=10 THEN A=MIN(T+4,54) 520 IF A<T THEN B=-1 ELSE B=1 530 FOR D=T TO A STEP B :: A$="" :: FOR I=1 TO 9 :: A$=A$&SEG$(M$(D+I),N,28):: NEXT I :: Y=Y+-B*8 540 DISPLAY AT(4,1):A$ :: CALL LOCATE(#1,Y,X):: NEXT D :: T=D 545 IF K=11 THEN T=T+2 550 GOSUB 1000 :: GOSUB 1010 :: GOTO 270 600 C=-1 :: IF K=8 THEN A=MAX(N-22,1) 610 IF K=9 THEN A=MIN(N+22,86):: C=1 620 IF A<N THEN B=-1 ELSE B=1 630 FOR D=N TO A STEP B :: IF D+C=0 THEN 640 635 A$="" :: FOR I=0 TO 8 :: A$=A$&SEG$(M$(T+I),D+C,28):: NEXT I :: X=X+-B*8 640 DISPLAY AT(4,1):A$ :: CALL LOCATE(#1,Y,X):: NEXT D :: N=MAX(D,1) 650 GOSUB 1000 :: GOSUB 1010 :: GOTO 270 1000 DISPLAY AT(18,1):"SPRITE POS Y=";STR$(Y);" X=";STR$(X):: RETURN 1010 DISPLAY AT(20,1):"STRING ROW=";STR$(T):"STRING POS=";STR$(N):: RETURN

I have reserved character 33,34 & 35 which are all staying as blank characters ("0000000000000000"). I intended to put these into the strings and when encountered they could flag the specific action required. If I stick to keeping these on the common coloured back ground they remain invisible to the player, but I can still search for them using the POS command. I am still deciding on how exactly I will use them to flag the action. My best choice is to simply look up the location from a disk record (this I like but it makes for large records which are 95% composed of nothing that will ever be used), or use the program to recognise the flag from the location and then jump somewhere else where it can load the variables. I am thinking of testing for both and seeing how the speed works out....

One thing I have noticed is how using CHAR can be minimised depending on what characters are changed. For example; AC BD Say this is a character running right. If the character is designed in a way where characters A&C don't change (maybe they are the head and shoulders), but B or D (maybe both) change to represent the legs running, then the re-draw effect using CHAR is highly reduced. If sprites can be designed so only 1 or 2 characters need to be changed for animation then you can sometimes get away with using CHAR at no great disadvantage. For complicated sprites this doesn't help much but I thought it worth the mention. 100 CALL CLEAR :: CALL MAGNIFY(4):: CALL SCREEN(2) 110 A$="0000003F0007073F408098988080807F0000F09090F0F0FC022121F9212101FE" 120 B$="0000003F0007073F408098988080807F0000F09090F0F0FC0211A171294101FE" 130 C$="0000003F0007073F408098988080807F0000F09090F0F0FC0211D121594101FE" 140 D$="0000003F0007073F408098988080807F0000F09090F0F0FC02895121518901FE" 150 CALL SPRITE(#1,128,14,100,100,0,-6) 160 CALL CHAR(128,A$,128,B$,128,C$,128,D$):: GOTO 160

Using CHAR will likely have a noticable effect on the sprite. CHAR really does seem to draw at a speed the eye can notice. For best results you probably should have a buffer set of 8 characters where you can redefine the next possible change of player direction and pre-define it before it needs to be displayed, then use PATTERN when the sprite needs to be changed. But, I do appreciate the limited characters we have at our BASIC fingertips and know that doing this often comes at a graphical disadvantage somewhere. Would have been great if TI gave us another 16 colour sets to play with! In regards to using CHAR for the character change if you have no choice but to go this way, I would load each new character into a string which is 64 characters in length and then call this value from an array which is linked to the program variables. So say you have CALL KEY(0,A,B) and press the left arrow key, which would set A value at 8, perahps in this instance you could then CALL CHAR(128,A$(A)).... Or something similar that suits your circumstance.

Rather than finish the last three programs I started, thought I might start something new after realising how well DISPLAY AT can be used in XB to get a reasonable large screen scroll. Below was my original test to see just how well it would work. http://www.youtube.com/watch?v=Mlp516HJQ8w Youtube has reduced overall quality and made it quite jumpy, however - when emulated it does run reasonably well with CPU Overdrive in Classic 99. To use this technique I need to build an image with strings where each horizontal line is exactly 28 characters. The most characters that a single string can hold is 255. So by default the largest display area that I can potentially scroll in a single command is 9 rows x 28 columns (a total of 252 characters), which was the case in the above demo. My new project named "Grotto Escape" will have a total resolution of 7056. Put another way, the game map will have 112 columns x 63 rows, OR (4 horizontal maps x 7 vertical maps). 112 was chosen because it is evenly divisible by 28 and also 8. I want to horizontally scroll each screen with a buffer of 2 positions in either direction. 63 was chosen for similar reasons but in this instance it needed to be evenly divisible by the height (9 characters). Vertical scroll will have only a single character overlap on either side so it needed to be also divisible by 7, hence the magic number 63. The array for the map will have 63 locations each filled with 112 characters which build the total map. This requirement alone will leave me with around 6400 remaining STACK which should be heaps of room for handful of other variables variables. This string will hold everything the player sees with the exception of sprites. It will also keep track of game events and all objects. For example, the players sprite might walk over a stick of dynamite and pick it up, when this happens the relevant line string and position is cut, a space inserted where the graphic for the dynamite was, and the balance of the string will be sown back together. There will be no need to manually keep track of of any item variables or their locations. My idea for sprites in each location is a little different but still similar in principal. In the strings themselves there will be the occasional character that is invisible to the player. When each 28 character string is fetched during the scroll process (triggered when the player moves towards the edge of the game field), a POS command will search each new 28 character string for the invisible character. If it finds the invisible character (lets call it the # character), it will calculate the row column position the # was found (by multiplying the row and column of the total map, and this number will refer to a single record on a disk file that contains a total of 7056 individual records. This record will be in the form of a positive or negative number such as -.1280700025 and from this number the program will identify which sprite character to display, the colour, the score for killing it, and other values that will set rules for the way the sprite behaves. If for example this sprite was an enemy and the player kills it, the original invisible character that was used to triggered the sprite event will be removed from the string location in the same way as described earlier, the next time this string is read the sprite trigger will not exist and no file will be looked-up. Seems simple enough.. Excluding the player, there will never exceed more than two enemy sprites on the screen at the same time, so game play should be quick and also the scroll process shouldn't be slowed because it will never fetch anymore than two disk files each time the screen is scrolled or re-drawn. Now the game... I am shooting for some real nice sprite movement however CALL PATTERN will not be used - rather each character will have it's next animated step just redefined. Classic 99 with CPU throttling seems to do this without the flicker that usual TI speed produces. http://www.youtube.com/watch?v=LNt-ZTR_oOg Needless to say, this program is written with Classic Throttling in mind. It will never run on original hardware due to the graphics but more importantly due to the disc file size. SAVE GAME will be a feature of this game. I have designed the player interface screens and am working on the initial two loaders. The first loader is to check the integrity of the big files and prepares the second loader to be run. The second loader defines the graphics and draws the screens. Almost all initialisation data from the game will be read from disc to save program space. Here's hoping I get this one finished. Looking very forward to designing the maps. Magellan will be used extensively and the output converted to the strings which will then be saved to disc. Here are some sample game screens. Each screen won't be this "busy", but I have been trying to finalising the graphics and colours etc. I have been looking at these too long and lost my judgement - any feedback on the preferred colour scheme would be welcomed.

These are the individual frames. Please excuse the Excel copy/paste from my game spreadsheet.

Greenwalker! http://www.youtube.com/watch?v=TmeViPYgi5g

To be honest, and the answer is nothing to be proud about, but I have probably only read like 10% of the docs and I cringe to think how many cool little tricks like LIST "CLIP" I might not have discovered. It's one of those things, you discover the program and start to play around and get stuff working and then never have a good reason to go back and read the docs - unless you actually find yourself with a major problem somewhere down the track. I suspect my honesty is gunna get me a kick in the butt with a giant shoe!

This is also new to me. I think stuff like this could almost warrant a Classic 99 tips & tricks sticky....

Cheers mate. If anybody could run this little program on original hardware I would be interested in the results....

Thanks Owen. Any thoughts on the different figures reported by Classic and Win994/a?

I have an idea for a new program/game and I am doing the intial homework to work out memory in advance. As part of my homework I have run the following simple program; 10 DIM A$(27),A(2268) 20 FOR I=1 TO 27 :: A$(I)=RPT$("F",84) :: NEXT I I run this in Classic 99 and SIZE reports; 11466 BYTES OF STACK FREE 6265 BYTES OF PROGRAM SPACE FREE I run this in Win994a and SIZE reports; 9378 BYTES OF STACK FREE 6265 BYTES OF PROGRAM SPACE FREE Any idea what is going on here? I need to nail the memory (limitations) in advance before I go any further. Also... As a general learning curve observation, I always thought PROGRAM SPACE was effectively the space only used by typing in the program and was separate from allocation of variables. This obviously isn't the case?

Not compiled, just straight XB. Refer post 20 in this thread for the code.(Youtube vid was mostly run in overdrive.)

VIEWSCROLL.AVI uploaded. No music or flashyness because I am not as fancy as Owen. http://www.youtube.com/watch?v=Mlp516HJQ8w

That's very odd. I tested it after I posted the message and it worked perfect, but now when I do it from a different computer I agree there are problems. I tried pasting my original code from here to a document, changed it to landscape mode and then posted back to Classic99, and it worked again! Could this be a browser issue? Anyway... Have attached the disk image instead. VIEWSCROLL.zip

This really is so cool - those are some great images Owen. I wish this was around in 1984, I would have been sticking it so hard to my C64 mates.

I threw something silly together, it really needs to be run with CPU throttling - but I think the concept has some potential. 90 ! REM VIEWSCROLL 100 CALL CLEAR :: FOR I=1 TO 14 :: READ A,B,C :: CALL COLOR(A,B,C) :: NEXT I :: CALL SCREEN(11) 110 FOR I=1 TO 89 :: READ A,B$ :: CALL CHAR(A,B$) :: NEXT I 120 FOR I=1 TO 9 :: READ M$(I) :: NEXT I 130 FOR I=1 TO 100 :: FOR D=1 TO 9 :: D$=D$&SEG$(M$(D),I,28) :: NEXT D :: DISPLAY AT(10,1)$ :: D$="" :: NEXT I 140 GOSUB 200 150 FOR I=100 TO 1 STEP-1 :: FOR D=1 TO 9 :: D$=D$&SEG$(M$(D),I,28) :: NEXT D :: DISPLAY AT(10,1)$ :: D$="" :: NEXT I 160 GOSUB 200 :: GOTO 130 200 FOR D=1 TO 3000 :: NEXT D :: RETURN 1000 DATA 1,16,11,2,4,8,3,2,8,4,5,4,5,9,8,6,16,8,7,6,8,8,14,8 1010 DATA 9,7,8,10,7,15,11,2,8,12,2,1,13,2,1,14,2,1 1020 DATA 33,"0010101010100010",34,"0028282800000000",35,"0028287C287C2828",36,"0038545038145438" 1030 DATA 38,"0020505020544834",39,"0008081000000000",40,"000000000F1F7FFF",41,"0000011FFFFFFFFF" 1040 DATA 42,"0000F8FFFFFFFFFF",43,"000000C0E0F8FCFF",45,"FFFFFFFFFFFFFFFF",46,"0F7F7FFFFFFFFFFF" 1050 DATA 47,"0080E0F0FCFEFFFF",48,"070F1F3F7FFF0300",49,"0707060606060707",50,"C0E0F0F8FCFE8000" 1060 DATA 51,"C0C0C0C0C0C0C0C0",52,"0000000101010303",53,"0000000000008080",54,"0018204078444438" 1070 DATA 56,"FFFFFFFF00000000",58,"0000303000303000",59,"0000303000301020",60,"0008102040201008" 1080 DATA 61,"0000007C007C0000",62,"0020100804081020",63,"0038440408100010",65,"000000FF7F3F1F0F" 1090 DATA 66,"FFFFE7DBDBE7FFFF",67,"FFFFFFFFFFFFFFFF",68,"FFFEFCF8F0E0C080",69,"000000FFFFFFFFFF" 1100 DATA 70,"0103070F1F3F7FFF",71,"80C0E0F0F8FCFEFF",72,"1C14171C14141C14",73,"001C387070783E1C" 1110 DATA 74,"0002400000080000",75,"0000081408000000",76,"00003E46FA8A8CF8",77,"FFFFFFFFFFFFFFFF" 1120 DATA 78,"00446464544C4C44",79,"007C44444444447C",80,"C3FFFFFFFFFFFFFF",81,"0038444444544834" 1130 DATA 82,"0078444478504844",83,"0038444038044438",84,"007C101010101010",85,"0044444444444438" 1140 DATA 86,"0044444428281010",87,"0044444454545428",88,"3838127C10382828",89,"0000000E1E078EFE" 1150 DATA 90,"0000000000008040",91,"1C1C483E08081422",93,"0038080808080838",94,"0000102844000000" 1160 DATA 95,"000000000000007C",96,"00000049FF494949",97,"00000038447C4444",98,"0000007824382478" 1170 DATA 99,"0000003C4040403C",100,"0000007824242478",101,"0000007C4078407C",102,"0000007C40784040" 1180 DATA 103,"0000003C405C4438",104,"101010FF424242FF",105,"FFFFFFFFFFFFFFFF",106,"C3C3C3FFFFC3C3C3" 1190 DATA 107,"FFFFC3C3C3C3FFFF",108,"000000404040407C",109,"000000446C544444",110,"0000004464544C44" 1200 DATA 111,"0000007C4444447C",112,"80E0F0F8F8FCFEFF",113,"00000000F0F8FCFF",114,"FFFFFFFFFFFFFFFF" 1210 DATA 115,"C0E0F0FCFEFFFFFF",116,"030FFFFFFFFFFFFF",117,"0000FFFFFFFFFFFF",118,"0000000000007EFF" 1220 DATA 119,"0000004444545428",120,"0000004428102844",121,"0000004428101010",122,"0000007C0810207C" 1230 DATA 123,"0018202040202018",124,"0010101000101010",125,"0030080804080830",126,"0000205408000000",44,"0" 1300 DATA "v,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,," 1310 DATA "rtsq,,,,,X,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,I,,,,,J,,,,,,,,,,,,,,,,,,,," 1320 DATA "rrrrrrrrrrp,v,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,H45,,,,,,,,,,,,,,,,,,,,,," 1330 DATA "rrrrrrrrrrrtrrp,,,,,,,,,,,,,,,FCCCCCCCCG,,,FCCCCCG,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,KH13,,,,,,,,,,,,,,,,,,,,,," 1340 DATA "rrrrrrrrrrrrrrrp,,,,,,,,,,,,,,hhhhhhhhh3,,,hkhkhkh,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,H13,,,,,,,,,,,,,X,YZ[X,,," 1350 DATA "rrrrrrrrrrrrrrrrp,,,,,,,,,,,,,hkhkhkhkh3,,,hjhjhjh,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,H02,,,,,,,,,,,,,---------" 1360 DATA "rrrrrrrrrrrrrrrrrp,,,,,,,,,,,,hihihihih3,,,hihihih,,,,,,,,,,,,,,,,,,,,,,,,CLLE,,,,,,,,,,,,,,,,,,,,,(.-----+,,,,,,,,,,,.---------" 1370 DATA "rrrrrrrrrrrrrrrrrrsq[,````````hhhhhhhhh3```hhhhhhhX``````,,,,,,,,,,,,,,,ABCCBCD,,,,,,,,,,,,,,,,,,()--------*+,,,,,,(*.----------" 1380 DATA "------------------------------------------------------PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP-------------888888-------------"

Bit of a brainwave.... Would be real interesting to use a 9x28 display (like the above number example) to create a little animated movie. Probably wouldn't even be as time consuming as I initially thought with great tools like Magellan now around. Oooohhhh, this does sound like a lot of fun! I think there could be some real magic in changing 252 characters in a single pass from basic.

Basically just used DISPLAY AT with a string length of 112 characters so it evenly displayed 4 full rows each pass. The basic is too slow to use DISPLAY AT on 4 different statements to get any sort of smooth or even flow, it starts to look like a checkerboard and becomes... overlapped. In fact, I found it too slow to even display 2 different statements. I just worked out a little mountain image 4 X 8 chars and put each row into it's own string using the RPT$ function (each row string is 32 characters long). Then when it came to to display I borrowed 28 characters from each string then joined them together to get 4 full rows of data (or 112 chars). I *think* the same process could be used to scroll up to 9 rows without it looking any jumpier (but I have never tried to know for sure). This little test below suggests it should work OK though.... The last line seems to draw at the same time as the first line unlike a HCHAR or VCHAR where you can see the iamge actually getting laid down. 100 CALL CLEAR :: FOR I=1 TO 9 :: A$(I)=RPT$(STR$(I),252) :: NEXT I 110 FOR I=1 TO 9 :: DISPLAY AT(1,1):A$(I) :: NEXT I 120 GOTO 110

Heh... You don't mess around do you?