Silly Programming Ideas - Turning Text into Graphics

[TFM]

LDI (16 clock cycles) = 80 * 16 = 1280 clock cycles
LDIR (21 clock cycles) = 80 * 21 = 1680 clock cycles

Ok, don't kick my butt, but I gotta correct this... for the circumstances on the CPC...
LDI (20 clock cycles) = 5 ys
LDIR (24 clock cycles) = 6 ys[nb]as Long as BC is not 1[/nb]

[redbox]

Ok, don't kick my butt, but I gotta correct this... for the circumstances on the CPC...
LDI (20 clock cycles) = 5 ys
LDIR (24 clock cycles) = 6 ys[nb]as Long as BC is not 1[/nb]

Thanks TFM.

I knew there was overhead on the CPC, but didn't know how much it was 

[AMSDOS]

Does that mean LDIR is faster or slower if BC is not equal to 1?

It's unusual when people say LDIR is 21 or 24, but then it repeats itself, so for every repeat that's 21 or 24 due to the nature of the instruction - if it was say 24 for the entire 4000h it had to transfer, I guess our machine would be whipping all the others. 

[redbox]

It's unusual when people say LDIR is 21 or 24, but then it repeats itself, so for every repeat that's 21 or 24 due to the nature of the instruction - if it was say 24 for the entire 4000h it had to transfer, I guess our machine would be whipping all the others. 

Well, that would be DMA 

LDIR is a powerful instruction and the block moving of memory with the Z80 is good, it's just that the CPC has a lot of screen RAM (16kb) so it feels slow.  If you only had 8kb (or 4kb even) then it would come into it's own a lot more.

[TFM]

Well, yes, it may feel slow. But for Scrolling one should make a Screen split and use Hardware Scrolling, then everything is quick.

[AMSDOS]

I had another silly idea for a scroll routine, though I'll have to play around with the idea first to see if it's going to work. 

[TFM]

So you are going to use RLD, are you?

[AMSDOS]

So you are going to use RLD, are you?

I don't know anything about RLD and my assembly book only gives a little bit of information about it, nothing about what it uses or if it only takes in a number from the Accumulator. There is a website on this instruction, though I don't know if it's worthwhile making a scroller out of it.

In BASIC though a simple VT to move the Cursor Up one line works well if the fastest Speed Key setting is applied and can be just another way to speed up your program if cursor control is being applied.

Code: [Select]

10 MODE 0:INK 0,0:INK 1,26:INK 2,13
20 SPEED KEY 1,1
30 WHILE INKEY$<>" "
40  PLOT (RND*638),398,(RND*2)
50  LOCATE 1,1:PRINT CHR$(11)
60  CALL &BD19:CALL &BD19
70 WEND
80 MODE 2:CALL &BC02
90 SPEED KEY 30,2
Line 60 is totally optional as it is waiting for the Frame Flyback, though if that is removed, the program flies off it's head.

Personally I think it's so fast that your brain hasn't got time to process if it's pixel perfect scrolling and it kind of looks smooth. 

[TFM]

RLD (and RRD) moves nibbles through (HL) and uses A to store them. It can be used for 1-pixel precise scrolling in MODE 0 f.e.[nb]However, I personally use other ways, because RLD is not really quick.[/nb]

[AMSDOS]

I put together a program (or two) from this thread to come up with a way to draw an image to screen and then convert it into the bytes you get which can be used for a sprite.

Code: [Select]

10 ' MODE 0 8x8 Plot Image -> Sprite Generator
20 ' Use Lines 1050 to 1120 to Setup your image, the INK numbers reflect
30 ' the image to display, when the program starts enter the palette numbers for
40 ' those INKs to display the image.
50 ' Once the Image has been drawn, press any key and this program will generate
60 ' byte values which can be used for Sprite Driver.
70 '
80 DIM c%(15),col%(64),sp%(32):INK 0,0:BORDER 0:GOSUB 1200:MODE 0
90 GOSUB 1000:a%=1:y%=398:x%=0
100 c1%=0:c2%=0
110 WHILE (c1%<>8):WHILE (c2%<>8)
120 PLOT x%,y%,col%(a%)
130 x%=x%+4
140 a%=a%+1
150 c2%=c2%+1
160 WEND
170 c2%=0
180 y%=y%-2
190 x%=0
200 c1%=c1%+1
210 WEND
220 GOSUB 1300:CALL &BB18
230 MODE 2
240 r%=0:WHILE r%<>32
250 FOR p%=1 TO 4
260  PRINT sp%(p%+r%);
270 NEXT p%
280 PRINT:r%=r%+4
290 WEND
300 END
1000 ' Sprite Array
1010 FOR a%=1 TO 64
1020 READ c%
1030 col%(a%)=c%
1040 NEXT a%:RETURN
1050 DATA 0,0,0,0,0,0,0,0
1060 DATA 0,0,4,4,4,4,0,0
1070 DATA 0,4,1,0,1,4,4,0
1080 DATA 0,4,1,0,0,4,4,0
1090 DATA 0,4,1,1,1,4,4,0
1100 DATA 0,4,4,4,4,4,4,0
1110 DATA 0,0,4,4,4,4,0,0
1120 DATA 0,0,0,0,0,0,0,0
1200 ' Set up Colours
1210 MODE 2
1220 FOR i%=1 TO 15
1230  PRINT"Enter Colour for INK ";i%;:INPUT c%(i%)
1240  INK i%,c%(i%):NEXT i%
1250 RETURN
1300 ' 8x8 Sprite Details
1310 RESTORE 1350:FOR p%=1 TO 32
1320  READ a$
1330  sp%(p%)=PEEK(VAL("&"+a$))
1340 NEXT p%:RETURN
1350 DATA c000,c001,c002,c003
1360 DATA c800,c801,c801,c803
1370 DATA d000,d001,d002,d003
1380 DATA d800,d801,d802,d803
1390 DATA e000,e001,e002,e003
1400 DATA e800,e801,e802,e803
1410 DATA f000,f001,f002,f003
1420 DATA f800,f801,f802,f803

So the program is limited to Mode 0, and 8x8 (64 byte characters), but you can arrange your own colours at the start and multicoloured images are possible, so you can design your own designs by editing lines 1050 to 1120, I use paint to generate the image I'm after, followed by editing those lines, once the program has drawn the image, any key will return the bytes for that, however the dimensions are not returned though which some sprite drivers like to have, for a 8x8 sprite, the height is 8 and width will be 4 (cause it's dealing in bytes).

[HAL 6128]

With some basic thread ideas (creating sprite within BASIC) I tried to program a game (try attached disc, use Cursor and Copy keys). Hmm, unfinished, no sound, only one level and buggy. Just a try.
A port of CandyCrash. I named it ColorFlash and it's pure BASIC. For some reason it is possible to create sprites and play around with them. But the game has to be somekind of "static". And BASIC is very limited in memory for such things, ...or better: I don't know how to do it better.

Honestly, I got stuck because I've lost overview of the variables during programming. Than a bug appears. I couldn't solve it. I got frustrated and stopped it.

I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?

[AMSDOS]

With some basic thread ideas (creating sprite within BASIC) I tried to program a game (try attached disc, use Cursor and Copy keys). Hmm, unfinished, no sound, only one level and buggy. Just a try.
A port of CandyCrash. I named it ColorFlash and it's pure BASIC. For some reason it is possible to create sprites and play around with them. But the game has to be somekind of "static". And BASIC is very limited in memory for such things, ...or better: I don't know how to do it better.

Honestly, I got stuck because I've lost overview of the variables during programming. Than a bug appears. I couldn't solve it. I got frustrated and stopped it.

I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?

I could only get the game to do some row clear once and an extra square appeared on the left hand side where that row was cleared, after that it did nothing except remain visible. I haven't work with games that size before, though you've done the right thing my commenting which should help explain what's happening.

[pelrun]

I don't know how you  guys develop a game / application.

Debugging is a skill, and even when you're good at it it can be incredibly frustrating. BASIC is pretty terrible for non-trivial programs too (especially when you don't have named procedures like BBC BASIC) which just multiplies the difficulties.


Also, there's an element of stubbornness involved, because getting everything finished takes about 50x longer than you expect. So don't be too hard on yourself; software is hard.

[AMSDOS]

With some basic thread ideas (creating sprite within BASIC) I tried to program a game (try attached disc, use Cursor and Copy keys). Hmm, unfinished, no sound, only one level and buggy. Just a try.
A port of CandyCrash. I named it ColorFlash and it's pure BASIC. For some reason it is possible to create sprites and play around with them. But the game has to be somekind of "static". And BASIC is very limited in memory for such things, ...or better: I don't know how to do it better.

Honestly, I got stuck because I've lost overview of the variables during programming. Than a bug appears. I couldn't solve it. I got frustrated and stopped it.

I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?

I had another look at your ColorFlash program, personally I'd go through and change all the PRINT statements so they have a semi-column ";" at the end of them. Though I'm unsure if the issue your referring to would be resolved. I'm pretty hopeless at your game I'm lucky to get to 250 let alone 400 in your game, so I'm probably not unveiling these so called "bug", though semi-column at the end of all print statements maybe a start because that prevents BASIC from any Returns/Enters from occurring.

[SyX]

I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?

Everything you can put in paper before to start, it helps a lot.

Locomotive Basic is good enough for a lot of projects, but a more structured language or one that force you to follow an structure (declare variables, use functions/procedures, ...) is better in the long term and for learning, because helps to reduce the complexity and force you to follow those rules.

And if you are using  a language as c (z88dk or sdcc) or pascal in CPC, you can compile the code in the PC too and that is perfect for debugging/testing complex algorithms.

[arnoldemu]

I don't know how you  guys develop a game / application. Maybe more in a structured and well-prepare way?

If you program it in C:

* Use comments to describe exactly what is happening
* Use comments to seperate functions e.g. /*-------------------------------------------*/
* Use useful variable names
* Split your program into multiple files (e.g. sprites.c)

If you program in asm:

Very similar to how I would do C. I may comment the code more.

I often write part of the code, make a test program for it. e.g. sprite drawing code.
I position sprites in different places, move them about, check the clipping works.
Make tests for all parts.
Then I join all together.

If you program in BASIC:

You can use rem statements, gosub and split up your code. You can use sensible variable names.
Then use a tool such as Beebug's toolkit to reduce the size after - this removes REMs and shortens variable names I think - at least there is one that did this on BBC.

When program becomes big, it is more of a problem to keep track of what is happening. Here you need to be able to trace it, either with prints, or to step through it using a debugger (ok if you are using asm and an emulator - you can step through and look at all registers and memory etc) - not for basic - don't know how you can do that.

If you make it in modules, you can debug each seperately and remove as many bugs as you can before you join all parts together.

There is a lot of work debugging and fixing bugs at the end so you need lots of patience.

[SyX]

 @HAL 6128, all the tips of arnoldemu are very sensible and those days you have the luck of being abl to use the old magazines lists and tutorials for learning how structure better your code, magazines as Computing with the Amstrad has a LOT of good quality basic programs and a lot of them are already in CPC-Power for you don't need to type them (load"" and list #9 to redirect to the printer, usually a text file in your favourite emulator).

[AMSDOS]

Then use a tool such as Beebug's toolkit to reduce the size after - this removes REMs and shortens variable names I think - at least there is one that did this on BBC.

Funnily enough I think the scans I did from my copy of Australian Personal Computer (Dec. 86) has a program (called CPC Progdoc)which is set out to just do that.


APC Dec 1986 - CPCWiki


Unfortunately I haven't typed it in, but I think the scan I've provided should be more than adequate for typing it in.

[HAL 6128]

When program becomes big, it is more of a problem to keep track of what is happening. Here you need to be able to trace it, either with prints, or to step through it using a debugger (ok if you are using asm and an emulator - you can step through and look at all registers and memory etc) - not for basic - don't know how you can do that.

If you make it in modules, you can debug each seperately and remove as many bugs as you can before you join all parts together.

There is a lot of work debugging and fixing bugs at the end so you need lots of patience.

Debugging is exactly the problem I have. Tracing back to the root cause. Which value of variable creates a problem. Damn!!
But thank you all for your hints. Programing in modules might be a good and better start next time.
Maybe I start learning another more structured programing language like C. I'm a little bit familiar with machine code but far away from being good enough, and MC it's soooo flexible, you're not so forced to keep a structure e.g. like declaring variable before using it.

@SyX: Good idea printing out the source code and transfer it via Emulator to a PC. I made an attempt with the help of the application NOTEPAD.  There it is possible to highlight the source code syntax!
@AMSDOS: I don't know why I put all that semicolons after the "Print" statements. I will check it. Normally I use it only if I print a character at the border. Thanks for checking!!

[AMSDOS]

@AMSDOS: I don't know why I put all that semicolons after the "Print" statements. I will check it. Normally I use it only if I print a character at the border. Thanks for checking!!

I didn't notice if you were using any Windows in your game, I have a couple in my game (including one for the playing area), and I had to put some Semicolons cause some funny stuff some occurring along the edge of the window. If you're not using Windows there maybe something else going on, though PRINT statements without semicolons forces a Carriage Return, you can see the devastation it makes if you're in TAG more and using PRINT because it will literally print those characters alongside whatever your printing.

[AMSDOS]

Earlier in this topic (on page 2), I was playing with the idea of Drawing a large Bub Character onscreen in BASIC and then writing a similar routine in Assembly using SCR FILL BOX. A while ago I was pondering in how to make the character appear from the bottom of the screen and wasn't able to generate the effect correctly until now.


I've gone back to the BASIC and changed how the drawing takes place and using a physical cursor down to move the line up. The idea here was to simply draw each line at the same position until it gets to the end, the trouble I was having earlier was trying to overcomplicate things and was using 2 FOR Loops for the original program when it was better to using a WHILE loop for the "y%" variable to control when I can increment the Loop, which comes after doing a physical cursor down.

Code: [Select]


10 MODE 0: INK 0,0:INK 1,26:INK 4,3:INK 6,1:INK 7,2:INK 8,4:INK 9,16
20 DIM col%(242):GOSUB 100:a%=1
30 WHILE (y%<>22)
40 FOR x%=1 TO 11
50 LOCATE x%,25:PEN col%(a%):PRINT CHR$(143);
60 a%=a%+1
70 NEXT x%:LOCATE 1,25:PRINT CHR$(10):y%=y%+1:WEND
80 CALL &BB18:PEN 1:MODE 2:END
100 ' Set up Colours
110 FOR a%=1 TO 241
120 READ c%
130 col%(a%)=c%
140 NEXT a%:RETURN
150 DATA 0,4,4,4,4,4,4,0,0,0,0
160 DATA 0,4,4,4,4,4,4,4,4,4,0
170 DATA 0,4,4,4,4,4,4,9,4,4,0
180 DATA 4,4,4,4,4,4,4,9,4,4,0
190 DATA 4,4,4,4,4,4,9,9,9,4,4
200 DATA 4,4,4,4,1,0,9,0,1,4,4
210 DATA 4,9,4,9,1,0,9,0,1,4,4
220 DATA 0,9,4,9,1,0,9,0,1,4,4
230 DATA 0,9,9,9,1,0,9,0,1,4,0
240 DATA 0,4,9,9,1,1,9,1,9,9,0
250 DATA 0,4,9,9,9,1,9,1,9,9,0
260 DATA 0,4,9,9,9,9,9,9,9,9,0
270 DATA 0,7,4,9,9,9,0,9,9,9,0
280 DATA 7,7,7,9,9,9,9,9,9,8,0
290 DATA 7,7,7,8,7,7,7,8,7,8,0
300 DATA 7,7,9,8,7,7,7,8,9,9,0
310 DATA 7,9,9,9,8,8,8,8,9,9,0
320 DATA 0,9,9,8,6,1,6,1,8,9,0
330 DATA 0,8,8,8,8,6,6,6,6,8,0
340 DATA 0,8,8,8,8,8,8,8,8,8,8
350 DATA 0,4,6,6,6,0,6,6,6,6,4
360 DATA 0,4,4,4,4,0,4,4,4,4,4


The Assembly program I made earlier is a little bit easier to modify, none of the loops needed changing. row variable becomes a constant pointing to the line 25 (or 24 in this case being 0 based), and using SCR HW ROLL (&BC4D) to roll the screen up.
The effect from the Assembly is interesting as the character emerges very quickly from the bottom of the screen using Block Imagery to cover the screen.

Code: [Select]


   org &4000


   ;; Main Routine


   ld a,0
   call &bc0e      ;; Set Screen Mode 0


   call setupcols      ;; CALL to Setup Screen Inks
   call drawimg      ;; Main Routine to Draw using SCR FILL BOX
   call resval      ;; Reset values so program can execute again once Exit.
   call &bb18      ;; KM WAIT KEY, Waits for any key to be pressed
   ld a,2
   call &bc0e      ;; Set Screen Mode 2
   ret         ;; Program exits here


.setupcols
   ld hl,cols      ;; Adress of Cols (Colours) points to HL Register
   ld a,0         ;; Accumulator contains PEN Colour
.inkloop
   ld c,(hl)      ;; Place INK value into C
   ld b,c         ;; And B
   push af         ;; Preserve Accumulator by PUSHing onto the Stack
   push hl         ;; Preserve HL Reigister by PUSHing onto the Stack
   call &bc32      ;; SCR SET INK, Entry: A = Ink no, B = First Colour,
            ;; C = Second Colour. Exit: AF & HL are corrupt.
   pop hl         ;; Restore previous HL Register by POPing off the stack
   pop af         ;; Restore previous Accumulator value by POPing off the stack
   inc hl         ;; hl = hl + 1
   inc a         ;; a = a + 1
   cp 10         ;; Does A = 10?
   jr c,inkloop      ;; Loop back to inkloop if A <> 10
   ret         ;; Return to Main routine


.drawimg
   ld hl,(bubptr)      ;; Address of INK values goes into HL
   ld a,(hl)      ;; Accumulator contains the contents that address points at,
            ;; in this case the encoded INK value.


   push af         ;; Those values are then PUSHed onto Stack to protect


   ld a,(column)      ;; Contents of Column is loaded into Accumulator
   ld h,a         ;; and then put into H register
   ld d,a         ;; and D register


   ld a,(row)      ;; Contents of Row is loaded into Accumulator
   ld l,a         ;; and then put into L register
   ld e,a         ;; and E register


   pop af         ;; Accumulator can now be restored to hold encoded INK value


   call &bc44      ;; SCR FILL BOX Routine, Entry = all the above registers are
            ;; used, H, D, L & E work using Text Based Co-ordinates &
            ;; accumulator uses Encoded INK to draw an 8 x 8 pixel shape.
 
   ld hl,(bubptr)      ;;
   inc hl         ;; Increase Address of pointer to INK values
   ld (bubptr),hl      ;;
   
   ld a,(column)      ;;
   inc a         ;; Increase Address of Column
   ld (column),a      ;;


   ld a,(fcount)      ;;
   inc a         ;; Increment First Counter for X Co-ordinate Position
   ld (fcount),a      ;;


   ld b,a         ;; If the First Counter hasn't reached the value
   ld a,(xval)      ;; in the X Co-ordinate Position (xval), then
   cp b         ;; Return to the start (drawimg), otherwise continue
   jr nz,drawimg      ;; to the second part adjust the Y Co-ordinate position.


   ld a,(fcount)      ;;
   xor a         ;; First Counter Position (fcount) must return to 0
   ld (fcount),a      ;;
   ld (column),a      ;; Column can also return to 0

   ld b,1
   ld a,0
   call &bc4d


   ld a,(scount)      ;;
   inc a         ;; Increment Second Counter for Y Co-ordinate Position
   ld (scount),a      ;;


   ld b,a         ;; If the Second Counter hasn't reached the value
   ld a,(yval)      ;; in the Y Co-ordinate Position (yval), then
   cp b         ;; Return to the start (drawimg), otherwise proceed
   jr nz,drawimg      ;; to the end of this cycle.
   
   ret         ;; Return to Main Routine


.resval
   xor a         ;; Fancy way of Returning Accumulator to 0.
   ld (fcount),a      ;;
   ld (scount),a      ;;
   ld (column),a      ;; Return all these Variables back to 0
   ld hl,bub      ;; Restore original address to the inks
   ld (bubptr),hl      ;; by returning the address of the inks to the Pointer
   ret         ;; Return to Main Routine


.cols   defb 0,26,0,0,3,0,1,2,4,16   ;; Setup INKs using these colours


.fcount   defb 0         ;; Value of First Counter (used during the X Co-ordinate Position)
.scount defb 0         ;; Value of Second Counter (used during the Y Co-ordinate Position)


.column defb 0         ;; Position of Column


.row defb 24         ;; Position of Row




.yval   defb 22         ;; Image to be draw is 22 columns in height
.xval   defb 11         ;; By 11 Rows Across as defined in 'bub'


.bubptr defw bub


.bub            ;; Dimension 11 x 22 in size
   defb &00,&30,&30,&30,&30,&30,&30,&00,&00,&00,&00
   defb &00,&30,&30,&30,&30,&30,&30,&30,&30,&30,&00
   defb &00,&30,&30,&30,&30,&30,&30,&c3,&30,&30,&00
   defb &00,&30,&30,&30,&30,&30,&30,&c3,&30,&30,&00
   defb &30,&30,&30,&30,&30,&30,&c3,&c3,&c3,&30,&30
   defb &30,&30,&30,&30,&c0,&00,&c3,&00,&c0,&30,&30
   defb &30,&c3,&30,&c3,&c0,&00,&c3,&00,&c0,&30,&30
   defb &00,&c3,&30,&c3,&c0,&00,&c3,&00,&c0,&30,&30
   defb &00,&c3,&c3,&c3,&c0,&00,&c3,&00,&c0,&30,&00
   defb &00,&30,&c3,&c3,&c0,&c0,&c3,&c0,&c3,&c3,&00
   defb &00,&30,&c3,&c3,&c3,&c0,&c3,&c0,&c3,&c3,&00
   defb &00,&30,&c3,&c3,&c3,&c3,&c3,&c3,&c3,&c3,&00
   defb &00,&fc,&30,&c3,&c3,&c3,&00,&c3,&c3,&c3,&00
   defb &fc,&fc,&fc,&c3,&c3,&c3,&c3,&c3,&c3,&03,&00
   defb &fc,&fc,&fc,&03,&fc,&fc,&fc,&03,&fc,&03,&00   
   defb &fc,&fc,&c3,&03,&fc,&fc,&fc,&03,&c3,&c3,&00
   defb &fc,&c3,&c3,&c3,&03,&03,&03,&03,&c3,&c3,&00
   defb &00,&c3,&c3,&03,&3c,&c0,&3c,&c0,&03,&c3,&00
   defb &00,&03,&03,&03,&03,&3c,&3c,&3c,&3c,&03,&00
   defb &00,&03,&03,&03,&03,&03,&03,&03,&03,&03,&03
   defb &00,&30,&3c,&3c,&3c,&00,&3c,&3c,&3c,&3c,&30
   defb &00,&30,&30,&30,&30,&00,&30,&30,&30,&30,&30


;; Masks to be used in PENs


;; pen 0 = &00
;; pen 1 = &c0
;; pen 4 = &30
;; pen 6 = &3c
;; pen 7 = &FC
;; pen 8 = &03
;; pen 9 = &c3


[ervin]

Nice work!
 

It's quite shocking to see how much faster something is in machine code, innit?

[AMSDOS]

Nice work!
  

Thanks

It's quite shocking to see how much faster something is in machine code, innit?

After some thought I thought I'm actually being really unfair to the BASIC program in this case, because in the BASIC program I'm using LOCATE, PEN & PRINT to print the appropriate box. In assembly that's &BB75 (TXT SET CURSOR), &BB90 (TXT SET PEN) and &BB5A (TXT OUTPUT), which I've replaced with &BC44 (SCR FILL BOX), which so conveniently places where you want the patten on screen, along with the INK mask & displaying the image. The sad news is there is no SCR FILL BOX in BASIC, so I guess the Sean McManus approach would be to write an small Assembly routine. I think the simplest approach would be to take the PEN number and encode it using SCR INK ENCODE (&BC2C) followed by SCR FILL BOX, and modify the assembly. The result should be a little bit fairer.


EDIT: I've attached a copy of the patched BASIC with the appropriate M/C bits being used for SCR INK ENCODE & SCR FILL BOX as well as a SCR HW ROLL (&BC4D), though was surprised to see how much faster it was when compared to my earlier BASIC. From this perspective the Assembly appears much quicker, it might take a little longer when I transform the Encoded INK into it's INK number. SCR INK ENCODE would have to called each time the routine loops through. From my short M/C routine here I made for BASIC, preserving the Accumulator is enough to quickly get the Encoded INK for use with SCR FILL BOX.

Code: [Select]

10 IF PEEK(&4000)<>221 THEN GOSUB 1000
20 MODE 0: INK 0,0:INK 1,26:INK 4,3:INK 6,1:INK 7,2:INK 8,4:INK 9,16
30 DIM col%(242):GOSUB 100:a%=1:y%=0
40 WHILE (y%<>22)
50 FOR x%=1 TO 11
60 CALL &4000,col%(a%),x%,24
70 a%=a%+1
80 NEXT x%:CALL &4016:y%=y%+1:WEND
90 CALL &BB18:PEN 1:MODE 2:END
100 ' Set up Colours
110 RESTORE 150:FOR a%=1 TO 241
120 READ c%
130 col%(a%)=c%
140 NEXT a%:RETURN
150 DATA 0,4,4,4,4,4,4,0,0,0,0
160 DATA 0,4,4,4,4,4,4,4,4,4,0
170 DATA 0,4,4,4,4,4,4,9,4,4,0
180 DATA 4,4,4,4,4,4,4,9,4,4,0
190 DATA 4,4,4,4,4,4,9,9,9,4,4
200 DATA 4,4,4,4,1,0,9,0,1,4,4
210 DATA 4,9,4,9,1,0,9,0,1,4,4
220 DATA 0,9,4,9,1,0,9,0,1,4,4
230 DATA 0,9,9,9,1,0,9,0,1,4,0
240 DATA 0,4,9,9,1,1,9,1,9,9,0
250 DATA 0,4,9,9,9,1,9,1,9,9,0
260 DATA 0,4,9,9,9,9,9,9,9,9,0
270 DATA 0,7,4,9,9,9,0,9,9,9,0
280 DATA 7,7,7,9,9,9,9,9,9,8,0
290 DATA 7,7,7,8,7,7,7,8,7,8,0
300 DATA 7,7,9,8,7,7,7,8,9,9,0
310 DATA 7,9,9,9,8,8,8,8,9,9,0
320 DATA 0,9,9,8,6,1,6,1,8,9,0
330 DATA 0,8,8,8,8,6,6,6,6,8,0
340 DATA 0,8,8,8,8,8,8,8,8,8,8
350 DATA 0,4,6,6,6,0,6,6,6,6,4
360 DATA 0,4,4,4,4,0,4,4,4,4,4
1000 RESTORE 1040:FOR addr%=&4000 TO &401D
1010 READ a$
1020 POKE addr%,VAL("&"+a$)
1030 NEXT addr%:RETURN
1040 DATA DD,7E,04,CD,2C,BC
1050 DATA F5,DD,7E,02,67,57
1060 DATA DD,7E,00,6F,5F,F1
1070 DATA CD,44,BC,C9,06,01
1080 DATA 3E,00,CD,4D,BC,C9

[AMSDOS]

For Decades I'd been toying with the idea of making a Block Editor, with the influence from the Rock Hopper Board Designer (ACU June 1985), and back in the early days made a crude editor, without having much understanding of Array's & the Transparent Command ("PRINT CHR$(22)+CHR$(1);"). 


So a while ago I went back to scratch, on the Understanding I needed an Array & better Transparency management that I would see from the Board Designer, but had problems because my Block Editor operates a little bit differently to the Rock Hopper Board Designer, which relies on Game Board Symbols 1 = Rock 2 = Grass 3 = Treasure, and so on, compared to my one Block Shape (143). Fortunately my new ideas of using the Array as a series of PEN numbers has got the result I'm happy with:

Code: [Select]

10 ' Block Editor
20 '
30 GOSUB 110
40 WHILE ch$<>"E"
50 GOSUB 210
60 GOSUB 310
70 GOSUB 510
80 WEND:MODE 2:PEN 1:CALL &BC02:END
100 ' Initialise Variables
110 MODE 0
120 DIM grid%(25,20)
130 x%=10:y%=10
140 oldx%=x%:oldy%=y%
150 c%=1
160 INK 0,0 : ' <- Use this line to add INK Values.
170 RETURN
200 ' Print Cursor
210 PRINT CHR$(22)+CHR$(1);
220 LOCATE x%,y%
230 PEN 15
240 PRINT"X";
250 PRINT CHR$(22)+CHR$(0);
260 oldx%=x%:oldy%=y%
270 RETURN
300 ' Check for Keypress
310 ch$=UPPER$(INKEY$):IF ch$="" THEN 310
320 IF ch$=" " THEN GOSUB 610
330 IF ch$="Q" THEN y%=y%-1
340 IF ch$="A" THEN y%=y%+1
350 IF ch$="O" THEN x%=x%-1
360 IF ch$="P" THEN x%=x%+1
370 IF ch$="C" THEN c%=c%+1
380 IF y%>25 THEN y%=25
390 IF y%<1 THEN y%=1
400 IF x%<1 THEN x%=1
410 IF x%>19 THEN x%=19
420 IF c%=14 THEN c%=0
430 RETURN
500 ' Preserve Block
510 LOCATE oldx%,oldy%
520 PEN grid%(oldy%,oldx%)
530 PRINT CHR$(22)+CHR$(0);CHR$(143);CHR$(22)+CHR$(1);
540 RETURN
600 ' Print Block
610 LOCATE x%,y%
620 grid%(y%,x%)=c%
630 PEN grid%(y%,x%)
640 PRINT CHR$(143);
650 RETURN

At the moment it's only a simple MODE 0 Block Editor move the Cursor around with Q,A,O,P, Pressing C will change the PEN colour (starts at Pen 1 after Pen 13 Moves back to Pen 0), using Standard PEN set (except for PEN 0), edit Line 160 for appropriate INKS. 


Program isn't going to Save 17k Screens (but program can easily be added if desired), I was going to work out how to Load/Save information from the Array to produce smaller files.


The only odd thing I had happen when I got the program to this point was if I used Row Column 20 for my X-Coordinate, the cursor wasn't being erased when I was moving the cursor along the Y-Coordinate and the Screen Rolls when I get to the Bottom.    For this reason I left it so the Cursor won't progress back Row Column 19, unsure if it's the positioning of where oldx & oldy reside in line 260.

[AMSDOS]

So the little problem I was having with the Block Editor above was when I change Line 410 to read:

Code: [Select]

410 IF x%>20 THEN x%=20

If I take my 'X' to Column 20 and run it up and down the screen it's not being deleted and the Cursor is Rolls the screen down when I take it to the Bottom of the screen.


It seems my placement of the LOCATE in the Preserve Block is the Culprit in this case, I've changed the code to read:

Code: [Select]

500 ' Preserve Block
510 PEN grid%(oldy%,oldx%)
520 PRINT CHR$(22)+CHR$(0);
530 LOCATE oldx%,oldy%
540 PRINT CHR$(143);
550 PRINT CHR$(22)+CHR$(1);
560 RETURN
So now it will work as a 20x25 Block Editor