Silly Programming Ideas - Turning Text into Graphics

[AMSDOS]

I've modified the last program so now it's running on WHILE..WEND loops instead of FOR..NEXT. It was a pain in the butt trying to get it to work (I'm bad when it comes to WHILE..WEND loops!  ), and the program is obviously larger than the last one, using more variables (I've added comments to explain it as well). The advantage with this program now though, is you simply tell where the image can go - x & y positions and the program will do the rest, unlike the last example which requires the start and end positions! I've also altered the y coordinate in this as well (instead of stepping 8 pixels which should have been 4) which produces a more natural look of the image, instead of a stretched one! 
 

Code: [Select]

10 MODE 0:BORDER 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 1000:a=1:y=398:x=0
30 c1=0:c2=0
40 WHILE (c1<>22):WHILE (c2<>11)
50 PLOT x,y,col(a)
60 x=x+8 ' increment x position by 8 pixels, generates dotted effect. Change to 4 for undotted effect.
70 a=a+1 ' increment for colour array, with image colour in it
80 c2=c2+1 ' increment loop (x coordinate) position by 1
90 WEND ' c2 trigger - works on x coordinate
100 c2=0 ' reset loop position to the start (for x coordinate)
110 y=y-4 ' position y position down 4 pixels, generates dotted effect. Change to 2 for undotted effect or 8 for more dotted effect.
120 x=0 ' return x position to begining, can be anywhere depending on position of image
130 c1=c1+1 ' increment loop (y coordinate) position by 1
140 WEND ' c1 triggers back to first loop if total has not been reached, otherwise exits
150 CALL &BB18
160 MODE 2:CALL &BC02:END
1000 ' Set up Colours
1010 FOR a=1 TO 241
1020 READ c
1030 col(a)=c
1040 NEXT a:RETURN
1050 DATA 0,4,4,4,4,4,4,0,0,0,0
1060 DATA 0,4,4,4,4,4,4,4,4,4,0
1070 DATA 0,4,4,4,4,4,4,9,4,4,0
1080 DATA 4,4,4,4,4,4,4,9,4,4,0
1090 DATA 4,4,4,4,4,4,9,9,9,4,4
1100 DATA 4,4,4,4,1,0,9,0,1,4,4
1110 DATA 4,9,4,9,1,0,9,0,1,4,4
1120 DATA 0,9,4,9,1,0,9,0,1,4,4
1130 DATA 0,9,9,9,1,0,9,0,1,4,0
1140 DATA 0,4,9,9,1,1,9,1,9,9,0
1150 DATA 0,4,9,9,9,1,9,1,9,9,0
1160 DATA 0,4,9,9,9,9,9,9,9,9,0
1170 DATA 0,7,4,9,9,9,0,9,9,9,0
1180 DATA 7,7,7,9,9,9,9,9,9,8,0
1190 DATA 7,7,7,8,7,7,7,8,7,8,0
1200 DATA 7,7,9,8,7,7,7,8,9,9,0
1210 DATA 7,9,9,9,8,8,8,8,9,9,0
1220 DATA 0,9,9,8,6,1,6,1,8,9,0
1230 DATA 0,8,8,8,8,6,6,6,6,8,0
1240 DATA 0,8,8,8,8,8,8,8,8,8,8
1250 DATA 0,4,6,6,6,0,6,6,6,6,4
1260 DATA 0,4,4,4,4,0,4,4,4,4,4
 


[SuTeKH/Epyteor]

@ CPM/User
If you're going to be using ONLY integer values for your variables, may I suggest using either a DEFINT a-z at the beginning of your programs or add a % symbol to the end of all your INTEGER variables, especially now as your programs are growing more and more complex. This will seriously speed up the BASIC programming, as it only needs to process INTEGERs rather than FLOATING POINT numbers.
 
For example;

Code: [Select]


10 t=TIME
20 FOR l=1 TO 5000
30 NEXT l
40 PRINT (TIME-t)/300
50 '
60 t=TIME
70 FOR l%=1 TO 5000
80 NEXT l%
90 PRINT (TIME-t)/3000

The first LOOP takes 5.5 seconds to run as the CPU is processing FLOATING POINT numbers and the second LOOP only takes 2.4 seconds as the CPU only needs to process INTEGERs.
 
 
I hope this may help you in the future,
- JTMS...

[AMSDOS]

@ CPM/User
If you're going to be using ONLY integer values for your variables, may I suggest using either a DEFINT a-z at the beginning of your programs or add a % symbol to the end of all your INTEGER variables, especially now as your programs are growing more and more complex. This will seriously speed up the BASIC programming, as it only needs to process INTEGERs rather than FLOATING POINT numbers.

Yeah sloppy BASIC programming on my behalf!    I'm only writing them so they exist and then perhaps code them to Assembly using the Firmware, which is unfair I guess in a sense because it makes the Assembly look even faster and the BASIC even slower!    I'm somewhat hesitant using DEFINT a-z, which obviously works, though is defining everything as Integer, if I can at least DEFINT x,y,a,c,c1,c2 would that work as an alternative?
I like the idea of having "%" as a way of recognising the type of variable that's being used, though coding it throughout the program is time consuming! 

[SuTeKH/Epyteor]

I'm somewhat hesitant using DEFINT a-z, which obviously works, though is defining everything as Integer, if I can at least DEFINT x,y,a,c,c1,c2 would that work as an alternative?

Yes, you can set DEFINT to define as many letters as you want and exclude the ones you don't want. (For more details; User Guide, page 174)
For example; If variables 'money_earned', 'money_spent' & 'tax_owed' are FLOATING POINT but all others are INTEGER, then use DEFINT a-l,n-s,u-z at the beginning of the program. As long, of course, as none of your INTEGER variables start with m or t, but see below for a solution to that problem!
 
(NOTE: All memory addresses, despite being INTEGER numbers, still need to be defined as REAL numbers, so make sure their variable 'letter' is not included in the DEFINT)
 

I like the idea of having "%" as a way of recognising the type of variable that's being used, though coding it throughout the program is time consuming! 

It all depends on your variable-name convention. If you like to use single-character variable names, then yes you're doubling your programming effort whenever you use the "%" extension. However, if (like me) you like to use longer, descriptive variable names, then adding the "%" enhances that description. And if you use it regularly, it's like always adding a "$" for STRINGs; it simply becomes common practice.
 
There's more about variable extensions in the User Guide (page 115), but here are the three extensions for variables;
 
% - Integer
! - Floating Point (Real)
$ - Strings
 
So, if you use DEFINT a-z, and then define a variable called 'mem_loc', you can always add the "!" to override the DEFINT command and define the variable as a REAL number (or in this case, a memory location), so your variable will, obviously, be 'mem_loc!'.
 
Now, you can take that a step further if you REALLY want and use the DEFSTR command so you don't even have to include the "$" to all STRING variables! Or DEFREAL to define your FLOATING POINT variables (kinda redundant as the system defines all variables, without extensions, as REAL by default). This all becomes VERY confusing, so I would recommend adding the extensions to existing variables instead.
 
Doing this can create ANOTHER problem; if you forget to add your "%" to 'x_position' variable, the system will create a new REAL variable called 'x_position', give it its default value of '0' and continue to use this instead of 'x_position%'! Debugging problems like this can be a real nightmare, even when EDITing in MODE 2 (the best MODE for BASIC editing!).
 
So, you're left with a simple question; do you want to speed up your BASIC programs/games for the user or do you want to make your programs easy to program for yourself? There's no right or wrong answer to that, it's all down to personal choice.
 
 
There's a lot more to LocoBASIC than most people know, or even care about. There are some really useful commands (BASIC 1.0) that are rarely used, but can substantially enhance programs! Yes, it will never be as fast as Z80, but I like the challenge of creating programs/games in BASIC to run as fast as possible. I believe my POCORO LEGENDS game is in a pretty playable state and it's 100% BASIC.
(Ok, also, I don't know enough Z80 to program properly in assembler!)
 
- JTMS... (redefining tl;dr)
 

[AMSDOS]

Okay so what your saying is you cannot DEFINT <first letter here> or DEFINT <variable name>, which will take the first letter of that "name", and make everything which begins with that letter an Integer regardless, unless I use the symbols to define what they are, which is BASICs real way of defining what's what! A bit of a nuisance cause as you say, your going through the entire program to make it like that. Declaring variables in Pascal for example is necessarily, otherwise the programs won't compile or run without them, though they work more effectively as names - apple can be defined as an Integer for instance and army can be defined as a real (decimal numbers), using alternative names which aren't declared and it won't work!     I could see how that would also help make those programs easier to read. 

[SuTeKH/Epyteor]

Okay so what your saying is you cannot DEFINT <first letter here> or DEFINT <variable name>, which will take the first letter of that "name", and make everything which begins with that letter an Integer regardless, unless I use the symbols to define what they are, which is BASICs real way of defining what's what! A bit of a nuisance cause as you say, your going through the entire program to make it like that. Declaring variables in Pascal for example is necessarily, otherwise the programs won't compile or run without them, though they work more effectively as names - apple can be defined as an Integer for instance and army can be defined as a real (decimal numbers), using alternative names which aren't declared and it won't work!     I could see how that would also help make those programs easier to read. 

I'm saying that DEFINT is a good idea if all your variables are INTEGERS, but the "%" extension is easier to manage, even in larger programs. I see it as no different to the "$" extension for STRINGs these days.
Either way, it will speed up larger BASIC programs/games. Use it only if you feel the need.

In your example, LocoBASIC variables would read 'apple' and 'army!' with DEFINT a or 'apple%' and 'army' without DEFINT a.

I don't know if it only applies to REAL variables, but using a new variable in the middle of a program (ie one that hasn't been pre-declared; eg a 'tempX' variable to store the player's old x position) will cause the system to pause while it creates the variable in system memory, which is not good in the middle of a game! I found this out during my POCORO programming. So, having a 'set-up' section where variables are pre-declared is also a good idea.
 

[AMSDOS]

I'm saying that DEFINT is a good idea if all your variables are INTEGERS, but the "%" extension is easier to manage, even in larger programs. I see it as no different to the "$" extension for STRINGs these days.
Either way, it will speed up larger BASIC programs/games. Use it only if you feel the need.

In your example, LocoBASIC variables would read 'apple' and 'army!' with DEFINT a or 'apple%' and 'army' without DEFINT a.

I don't know if it only applies to REAL variables, but using a new variable in the middle of a program (ie one that hasn't been pre-declared; eg a 'tempX' variable to store the player's old x position) will cause the system to pause while it creates the variable in system memory, which is not good in the middle of a game! I found this out during my POCORO programming. So, having a 'set-up' section where variables are pre-declared is also a good idea.

In that case I would have liked to have gone though all the BASIC attachments I've posted (on here) and corrected them, though given I cannot do that, the only way I can simplify it is to correct all of them and post that into a Disk Image! 
 
UPDATED: All the BASIC stupid mistakes i&#39;ve made solved
All the BASIC stupid mistakes i've made solved.
 
Featuring: 17Kb of Absolute Madness, you've been warned! 
 
Early Comments: "Hmm,some examples appear faster, others are harder to pick up speed wise when compared to the original programs."

[AMSDOS]

This is perhaps the easiest way I can think of with regard to producing an scrolling effect and indeed it seems to work.
At the moment it's simply a bunch of screen addresses followed by LDIR - 15 of them which moves the line 15 lines down. Just to test the whole effect I'm plotting a series of dots near the top of the screen (not at the top cause the scroll routine will smear those pixels down), when this is appllied I can call the Scrolling routine which will move those dots down the screen, making it appear as if your moving through a starfield.
After having a few thoughts about this over the last couple of days, I'm wondering how effective that scrolling method would go in a loop with a couple of pointers pointing to the addresses of where the screen is and where it has to go. The third paramater (BC) which is the length across is basically a constant.

EDIT:Refined code:

Code: [Select]

;; LDIR Scroll - This shifts the screen down a row at a time, kind of giving a smooth scroll.
;; CP/M User.


org &4000

ld b,15 ;; This is how many lines to scroll down.
.loop
push bc ;; This protects the Loop Counter (not required at this stage)

ld hl,(adr_hl) ;; This holds the address pointer and is place into HL
ld e,(hl) ;; Though the Contents from that address goes into DE
inc hl ;; Cause it's 16bit data this is the only way I know
ld d,(hl) ;; How to do it, there maybe other ways. I dunno.

ex de,hl ;; The data above needs to go into HL and not DE


push hl ;; I need to protect my data in HL


ld hl,(adr_de) ;; This holds the address pointer and is place into HL
ld e,(hl) ;; Though the Contents from that address goes into DE
inc hl ;; Cause it's 16bit data this is the only way I know
ld d,(hl) ;; How to do it, there maybe other ways. I dunno.


pop hl ;; But restore it again for this routine


ld bc,&1f ;; BC is used here to address the length of the data on screen upto &4f.
ldir ;; This wonderful instruction can make things move around very quickly.
pop bc ;; Restores Loop Counter value so loop can address it.


ld hl,(adr_hl) ;; Increment Start Position to the next spot
inc hl
inc hl
ld (adr_hl),hl ;; And store it in that pointer variable.


ld hl,(adr_de) ;; Increment Destination to the next position
inc hl
inc hl
ld (adr_de),hl ;; And store it in that pointer variable


djnz loop ;; returns to loop if any remaining lines, otherwise proceed to exit


ld hl,begin ;; Restores pointer to the beginning
ld (adr_hl),hl ;; should the user want to continue calling routine


ld hl,dest ;; Restores pointer to the Destination
ld (adr_de),hl ;; should the user want to continue calling routine


ret ;; exit routine


.adr_hl defw begin ;; pointer position to where the start position is for HL register
.adr_de defw dest ;; pointer position to where the start position is for DE register


.dest defw &f850 ;; These are Screen co-ordinate positions for DE, move from bottom to top of the screen
.begin defw &f050
defw &e850
defw &e050
defw &d850
defw &d050
defw &c850
defw &c050
defw &f800
defw &f000
defw &e800
defw &e000
defw &d800
defw &d000
defw &c800
defw &c000

Demonstration:

Code: [Select]

10 MODE 1:INK 1,26:INK 2,13
20 WHILE INKEY$<>" "
30 PLOT (RND*240),396,INT(RND*2)+1
40 CALL &BD19:CALL &4000:CALL &BD19
50 WEND

[AMSDOS]

Using the scroll routine above, along with a setup routine for it and a routine for plotting an image on & off screen, this is what I've come up with.


 [ Invalid Attachment ]


This was a bit of a test to see how the Plot Image Routine would cope plotting and unplotting an image off the screen as well. In this situation I've made a bypass effect if it encounters a zero cause the object is 16x8 pixels in size and takes up a few zeros. To unclear the image (cause this is done in mode 1), I've used Pen 4 which acts as pen 0 except won't bypass and unplot the area. The effect is a quickish blinking ship moving left & right smoothly moving through space.

[AMSDOS]

This is the CP/M 2.2 version of the previous attachment including the Turbo Pascal source.

[AMSDOS]

I made this following program which is a BASIC variation of an Assembly  Sprite Routine:

Code: [Select]

10 MODE 1:BORDER 0

20 GOSUB 1000
30 DIM scr%(8):scr%(1)=&C000:scr%(2)=&C800:scr%(3)=&D000:scr%(4)=&D800:scr%(5)=&E000:scr%(6)=&E800:scr%(7)=&F000:scr%(8)=&F800
40 GOSUB 100
50 FOR p%=0 TO &4E:addr%=&4000:CALL &BD19:CALL &BD19:GOSUB 110
60 addr%=&4010:CALL &BD19:CALL &BD19:GOSUB 110:NEXT p%
70 CALL &BB18:END
100 ' Poke Sprite to Screen
110 FOR y%=1 TO 8
120 a%=scr%(y%)+p%:POKE a%,PEEK(addr%):addr%=addr%+1
130 b%=scr%(y%)+1+p%:POKE b%,PEEK(addr%):addr%=addr%+1
140 NEXT y%
150 RETURN
1000 ' Poke Sprite Data to Memory
1010 FOR addr%=&4000 TO &401F:READ a$
1020 POKE addr%,VAL("&"+a$)
1030 NEXT addr%:RETURN
1040 DATA D0,60,77,CC,03,08,03,08
1050 DATA 03,08,03,08,03,08,10,00
1060 DATA 00,00,00,00,00,00,00,00
1070 DATA 00,00,00,00,00,00,00,00

Certainly by no means was I writing this compare it with an Assembly Sprite Routine, I always knew this was going to be slower, though I'm sort of surprised at the pace this program runs, though it's only being told to do 2 things, draw the image & wipe it off and it just makes it look like an image is moving across the top of the screen (which is what it is). 


I wrote this though to see how my encoded sprite moves across the screen and given I can see now how that information gets passed to the screen I can understand a little better how an Assembly Sprite Routine draws this information to screen.

[AMSDOS]

This is what I came up with using SCR PIXELS, though it's not as clear cut as what I thought it would be because it wants Encoded INK information as well as Mask Data.    I've attached a Disk Image (with Demonstration program) and Source file as well.

Code: [Select]

;; 8x8 Sprite using SCR PIXELS.


;; Entry from BASIC:
;; CALL &4000,<address of sprite>,<colour data for image>,<x-coordinate>,<y-coordinate>

;; E.g. CALL &4000,&40AD,&40BF,80,100

org &4000


ld hl,addrimgdata ;; Address of the Colour Data comes in here and stored
ld e,(ix+04)
ld d,(ix+05)
ld (hl),e
inc hl
ld (hl),d


ld hl,addofimage ;; Address of the Sprite Data comes in here and stored
ld e,(ix+06)
ld d,(ix+07)
ld (hl),e
inc hl
ld (hl),d


ld hl,ypos ;; Value of YPOS comes in here and is stored,
ld e,(ix+00)
ld d,(ix+01)
ld (hl),e
inc hl
ld (hl),d


ld hl,xpos ;; And the same for XPOS as well.
ld e,(ix+02)
ld d,(ix+03)
ld (hl),e
inc hl
ld (hl),d


ld hl,(xpos)
ex hl,de ;; haha.
ld hl,(ypos)


call &bc1d ;; SCR DOT Position coverts this into a Screen Address


ld (scraddr),hl ;; Screen Address of Location
ld (storscraddr),hl ;; This is used because Scradr has to be Incremented


.loop ld hl,(addrimgdata) ;; Colour Information about the object needs to be
ld a,(hl) ;; Gathered here and encoded when using SCR PIXELS.
call &bc2c ;; SCR INK ENCODE

ld b,a ;; Information goes into B register.


ld hl,(addrimgdata) ;; This points to that information of the Colour Data.
inc hl ;; It's Incremented and stored for the next Bit Mask
ld (addrimgdata),hl ;; which is used for SCR PIXELS.


ld hl,(addofimage) ;; This points to the Bit Mask Data (the patten which
ld c,(hl) ;; gets drawn), and gets stored into the C register.


ld hl,(scraddr) ;; Address of the screen address.


call &bc5c ;; SCR PIXELS. Entry: B = Encoded INK Colour
;; C = Bit Mask Pattern
;; HL = Address to draw the Image.


ld hl,(scraddr) ;; I then have to increment the value of screen
inc hl ;; address to the next position to draw the next spot
ld (scraddr),hl ;; along. It gets stored so I can reuse my registers.


ld hl,(addofimage) ;; The address for the Bit Mask Pattern is also
inc hl ;; increment to point to the next value and is also
ld (addofimage),hl ;; stored as well.


;; An advance understanding of assembly might be able to pull off some PUSHing..POPing
;; to generate the right effect, though in this situation I found SCR PIXELS to be very
;; tricky to apply in a looping situation due to the extra information required from it.


ld a,(count1) ;; This is my loop sequence and again I needed to store
inc a ;; values into memory. I wanted to use my old friend
ld (count1),a ;; DJNZ, though was proving to be a nightmare.
ld b,a ;; This one checks if count1 equals loop1 and if it


ld a,(loop1) ;; doesn't it will jump back to loop to do another pass.


cp b
jr nz,loop ;; The Jump is applied here back to the loop label.


ld a,(count1) ;; If it has reacted this point then count1 equals loop1
xor a ;; it must be set back to zero so it can work when it
ld (count1),a ;; returns back to the main loop.

ld hl,(storscraddr) ;; This is used to calculate the previous line.
call &bc29 ;; SCR PREVIOUS LINE
ld (scraddr),hl ;; I store the value into scraddr for the main loop
ld (storscraddr),hl ;; and I also store the screen address for this routine.

ld a,(count2) ;; Once all that is done I have to do the same thing
inc a ;; here and check to see if count2 equals loop2. And
ld (count2),a ;; again the values need to be stored in memory and
ld b,a ;; recalled again for when I need to check.


ld a,(loop2) ;; As long as count2 is not equal to loop 2, it will


cp b ;; return back to the main loop, otherwise it will
jr nz,loop ;; proceed to exit, back to BASIC if called from there.



ld a,(count2) ;; though upon exit count2 needs to return to 0
xor a ;; Just so this routine can be recalled again.
ld (count2),a ;; values are returned into it's rightful place.


ret


.loop1 defb 2
.loop2 defb 8
.xpos defw 0
.ypos defw 0
.count1 defb 0
.count2 defb 0
.scraddr defw 0
.storscraddr defw 0
.bitmask defb 0
.addofimage defw 0
.rocket defb &d0,&60
defb &77,&cc
defb &03,&08
defb &03,&08
defb &03,&08
defb &03,&08
defb &03,&08
defb &10,&00
.addrimgdata defw 0
.imgdata defb 1,1,3,3,2,2,2,2,2,2,2,2,2,2,1,0
.blankimgdata defb 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0


[AMSDOS]

I've built together a little collection of routines, demos and examples from bits of code I've put together, I've put it all together on my Profile Page (in CPCWiki) as a way of informing people what I've created.    And I've slipped in a Link in my Signature in case anyone can do something with it. 

[Gryzor]

I've built together a little collection of routines, demos and examples from bits of code I've put together, I've put it all together on my Profile Page (in CPCWiki) as a way of informing people what I've created.    And I've slipped in a Link in my Signature in case anyone can do something with it. 

Ooh nice work mate!

[AMSDOS]

Until Yesterday I didn't know what the story was with SCR FLOOD BOX (&BC47) thinking it was a Firmware Equivalent to the BASIC 1.1 'FILL' command, though I tested it to discovered it works in 1.0 Firmware, though I also discovered it can simply be a 1x1 Pixel.


In order to draw a Sprite using SCR FLOOD BOX I've just made some adjustments to SCR PIXELS routine (posted above), which had produce a more compacted piece of code because unlike SCR PIXELS, SCR FLOOD BOX doesn't need to know the Mask of the PEN to draw with. C = Encoded PEN to be used, D & E give the width and height, which will always be 1 for this routine & HL holds the Screen Address, Using SCR DOT POSITION (&BC1D) sorts that out and I'm using SCR PREVIOUS LINE (&BC29) to Calculate the Next Line, so in some ways it's similar to SCR PIXELS (&BC5C), though it's compacted cause doesn't need as much information to draw the image to screen.

Code: [Select]


;; 8x9 Sprite using SCR FLOOD BOX.


;; Until Yesterday I didn't even know if SCR FLOOD BOX did 1x1 Encoded INK Pixels
;; and just thought it was based on BASIC 1.1 FILL command. :(


;; Entry from BASIC:
;; CALL &4000,<address of sprite>,<x-coordinate>,<y-coordinate>

;; E.g. CALL &4000,&4094,80,100

org &4000


ld hl,addofimage ;; Address of the Sprite Data comes in here and stored
ld e,(ix+04)
ld d,(ix+05)
ld (hl),e
inc hl
ld (hl),d


ld hl,ypos ;; Value of YPOS comes in here and is stored,
ld e,(ix+00)
ld d,(ix+01)
ld (hl),e
inc hl
ld (hl),d


ld hl,xpos ;; And the same for XPOS as well.
ld e,(ix+02)
ld d,(ix+03)
ld (hl),e
inc hl
ld (hl),d


ld hl,(xpos)
ex hl,de ;; haha.
ld hl,(ypos)


call &bc1d ;; SCR DOT POSITION coverts this into a Screen Address


ld (scraddr),hl ;; Screen Address of Location
ld (storscraddr),hl ;; This is used because Scradr has to be Incremented


.loop ld d,1 ;; Width of the Image
ld e,d ;; Height of the Image


ld hl,(addofimage) ;; This points to the Bit Mask Data (the patten which
ld c,(hl) ;; gets drawn), and gets stored into the C register.


ld hl,(scraddr) ;; Address of the screen address.


call &bc47 ;; SCR FLOOD BOX.
;; Entry: C = Encoded INK
;; D = Width of the Image
;; E = Height of the Image
;; HL = Address to draw the Image.


ld hl,(scraddr) ;; I then have to increment the value of screen
inc hl ;; address to the next position to draw the next spot
ld (scraddr),hl ;; along. It gets stored so I can reuse my registers.


ld hl,(addofimage) ;; The address for the Bit Mask Pattern is also
inc hl ;; increment to point to the next value and is also
ld (addofimage),hl ;; stored as well.


ld a,(count1) ;; This is my loop sequence and again I needed to store
inc a ;; values into memory. I wanted to use my old friend
ld (count1),a ;; DJNZ, though was proving to be a nightmare.
ld b,a ;; This one checks if count1 equals loop1 and if it


ld a,(loop1) ;; doesn't it will jump back to loop to do another pass.


cp b
jr nz,loop ;; The Jump is applied here back to the loop label.


ld a,(count1) ;; If it has reacted this point then count1 equals loop1
xor a ;; it must be set back to zero so it can work when it
ld (count1),a ;; returns back to the main loop.

ld hl,(storscraddr) ;; This is used to calculate the previous line.
call &bc29 ;; SCR PREVIOUS LINE
ld (scraddr),hl ;; I store the value into scraddr for the main loop
ld (storscraddr),hl ;; and I also store the screen address for this routine.

ld a,(count2) ;; Once all that is done I have to do the same thing
inc a ;; here and check to see if count2 equals loop2. And
ld (count2),a ;; again the values need to be stored in memory and
ld b,a ;; recalled again for when I need to check.


ld a,(loop2) ;; As long as count2 is not equal to loop 2, it will


cp b ;; return back to the main loop, otherwise it will
jr nz,loop ;; proceed to exit, back to BASIC if called from there.



ld a,(count2) ;; though upon exit count2 needs to return to 0
xor a ;; Just so this routine can be recalled again.
ld (count2),a ;; values are returned into it's rightful place.


ret


.loop1 defb 2 ;; Width of the Image
.loop2 defb 9 ;; Height of the Image
.xpos defw 0 ;; Store XPOS here for use with SCR DOT POSITION
.ypos defw 0 ;; Store YPOS here for use with SCR DOT POSITION
.count1 defb 0 ;; Checks for when the Width of the Image is Reached
.count2 defb 0 ;; Checks for when the Height of the Image is Reached
.scraddr defw 0 ;; Holds the screen address in relation to the Width.
.storscraddr defw 0 ;; Retains original screen address to calculate next line.
.addofimage defw 0 ;; Points to the address of the image to Display
.rocket defb &00,&00 ;; What I'm using as my Display image.
defb &d0,&60
defb &77,&cc
defb &03,&08
defb &03,&08
defb &03,&08
defb &03,&08
defb &03,&08
defb &10,&00


I've made this image 8x9 in size, the 9th line is a blank so once it's been Compiled the Rocket can blast off without the flame:

Code: [Select]

10 MODE 1:FOR y%=0 TO 190:CALL &BD19:CALL &4000,&4094,100,y%:NEXT y%

[AMSDOS]

I've just updated my "Silly" programs disc, some of the improved programs I'd thought I had done weren't enhanced to run faster in BASIC to my shock horror. Some of the more recent programs I've done since my original disk image have been added (e.g. BASSPR.BAS), and I've modified one of my earlier BASIC programs which is now using a 2D Array to display the image.

[AMSDOS]

Just found this other program I made 4 years ago which I sort of forgot about. It's a simple Command Driven program which lets you plot and draw lines to the screen. I think I only made it so I wasn't typing:

Code: [Select]

plot 100,100
draw 100,200
draw 150,100
draw 100,100


all over the screen. I haven't even given it provision for Colours, though it's kind of nifty if you're drawing shapes. You would have to remember (or write down) where you've been though cause it's not saving the data.

Code: [Select]

10 ' BASIC Graphics
20 ' CP/M User - 2008
30 INK 0,0:INK 1,26:BORDER 1:MODE 1: WINDOW#1,1,14,25,25: WINDOW#2,20,40,25,25
40 WHILE 1
50 LOCATE 1,25:INPUT#1,"Command:-";c$:CLS#1
60 IF c$="d" THEN LOCATE 1,1:PRINT#1,"Draw Selected":LOCATE 1,1:INPUT#2,"xco-ordinate";x%: CLS#2:LOCATE 1,1:INPUT#2,"yco-ordinate";y%: DRAW x%,y%: CLS#2
70 IF c$="e" THEN MODE 2:END
80 IF c$="p" THEN LOCATE 1,1:PRINT#1,"Plot Selected":INPUT#2,"xco-ordinate";x%: CLS#2:LOCATE 15,25:INPUT#2,"y co-ordinate";y%: PLOT x%,y%: CLS#2:CLS#1
90 WEND


It's Command Driven so when it asks for "Command" you can select:


"p" - for plot. Important to begin with this cause this acts as a move as well.
"d" - for draw. the X & Y co-ordinates work in relation to where to draw to and move to that point. To Draw from that spot to another spot simply "d" for draw again, otherwise "p" can be used to move to another spot on screen to draw another shape.

[AMSDOS]

More silly routines for this thread, this one is graphically moving a smiley face left and right on the screen changing colour every so often, though the colour changing process is being done due to EVERY which is outside the loop. It kind of has me thinking in another dimension because it's not clear cut BASIC and if you don't know what EVERY does, it could be confusing.

Code: [Select]


10 EVERY 5,2 GOSUB 1000
20 x%=1:y%=100:dir%=1:num%=1:MODE 0
30 WHILE INKEY$=""
40 TAG:MOVE x%,y%:PEN num%:CALL &BD19:PRINT " ";CHR$(224);" ";:TAGOFF
50 x%=x%+dir%
60 IF x%=320 THEN dir%=-1
70 IF x%=1 THEN dir%=1
80 WEND
90 CALL &BC02:MODE 2:PEN 1:END
1000 num%=num%+1:i%=(RND*26)
1010 IF num%=15 THEN num%=1
1020 INK num%,i%
1030 RETURN


[Gryzor]

Man, it really tripped my girl out, I can tell you that

[AMSDOS]

Man, it really tripped my girl out, I can tell you that

Hmm, trippy cause?


1) It's a Smiley Face
2) Moving Left/Right onscreen
3) It's Changing Colour
4) All the Above


I guess it's got some hipp-ish influence about it (if I can say that).

[AMSDOS]

I'm doing this rotating square the hard way from BASIC and this is what I came up with:

Code: [Select]

5 MODE 1:p=0:GOSUB 2000
10 EVERY 10,1 GOSUB 1000
15 WHILE INKEY$="":WEND:END
20 MOVE 100,100
30 DRAW 200,100,c
40 DRAW 200,200,c
50 DRAW 100,200,c
60 DRAW 100,100,c
65 RETURN
70 MOVE 75,125
80 DRAW 125,225,c
90 DRAW 225,175,c
100 DRAW 175,75,c
110 DRAW 75,125,c
115 RETURN
120 MOVE 75,150
130 DRAW 150,225,c
140 DRAW 225,150,c
150 DRAW 150,75,c
160 DRAW 75,150,c
165 RETURN
170 MOVE 75,175
180 DRAW 175,225,c
190 DRAW 225,125,c
200 DRAW 125,75,c
210 DRAW 75,175,c
220 RETURN
1000 oldp=oldp+1:p=p+1
1020 c=1:IF p=1 THEN CALL &BD19:GOSUB 20
1021 c=0:IF oldp=1 THEN CALL &BD19:GOSUB 20
1030 c=1:IF p=2 THEN CALL &BD19:GOSUB 70
1031 c=0:IF oldp=2 THEN CALL &BD19:GOSUB 70
1040 c=1:IF p=3 THEN CALL &BD19:GOSUB 120
1041 c=0:IF oldp=3 THEN CALL &BD19:GOSUB 120
1050 c=1:IF p=4 THEN CALL &BD19:GOSUB 170
1051 c=0:IF oldp=4 THEN CALL &BD19:GOSUB 170
1060 IF p=5 THEN p=0
1065 IF oldp=5 THEN oldp=0
1070 RETURN
2000 MOVE 50,50
2010 DRAW 250,50,2
2020 DRAW 250,250,2
2030 DRAW 50,250,2
2040 DRAW 50,50,2
2050 RETURN

though I was wondering if there's a better way of doing it - e.g. using some maths or applying some "DRAWR" instead?
It has some funny rotational look to it when it reaches the complete cycle and I'm trying to delete the first square when the second is being drawn up, so I'm thinking I need to create a dummy position for 1 and start the cycle at 2.


INK swapping would have been more ideal for this, though I'm working in MODE 1, and I need every Colour I can get from it.


EDIT: I'll attach the source code.

[HAL 6128]

I would prefer drawing with a transformation matrix and XOR modus. (A precalculated table could also increase speed). Flickering is still a problem under BASIC. Best is use two small screens in BASIC.

Code: [Select]


10 GOSUB 130:' initialize
20 :
30 MOVE -100,-100:DRAWR 200,0:DRAWR 0,200:DRAWR -200,0:DRAWR 0,-200
40 :
50 ' ****** Main Loop
55 GOSUB 290
60 FOR rot=1 TO 5
65 GOSUB 290
70 GOSUB 360
80 GOSUB 290
100 NEXT rot
110 GOTO 60
120 :
130 '****** Initializing
140 MODE 1
150 DEFINT a-z:DEG:ORIGIN 100,100
160 theta=30:sinus!=SIN(theta):cosinus!=COS(theta)
170 DIM x(4),y(4),a(4),b(4),tmp(4)
180 FOR i=1 TO 4
190 READ x(i),y(i)
200 NEXT i
210 FOR i=1 TO 4
220 READ a(i),b(i)
230 NEXT i
240 RETURN
250 :
260 DATA -50,-50,50,-50,50,50,-50,50
270 DATA 1,2,2,3,3,4,4,1
280 :
290 ' ****** Draw & Delete
300 FOR i=1 TO 4
310 MOVE x(a(i)),y(a(i))
320 DRAW x(b(i)),y(b(i)),1,1
330 NEXT i
340 RETURN
350 :
360 ' ****** Transformation
370 FOR i=1 TO 4
380 tmp(i)=x(i)*cosinus!-y(i)*sinus!
390 y(i)=y(i)*cosinus!+x(i)*sinus!
400 x(i)=tmp(i)
410 NEXT i
420 RETURN


[AMSDOS]

I would prefer drawing with a transformation matrix and XOR modus. (A precalculated table could also increase speed). Flickering is still a problem under BASIC. Best is use two small screens in BASIC.

Code: [Select]


10 GOSUB 130:' initialize
20 :
30 MOVE -100,-100:DRAWR 200,0:DRAWR 0,200:DRAWR -200,0:DRAWR 0,-200
40 :
50 ' ****** Main Loop
55 GOSUB 290
60 FOR rot=1 TO 5
65 GOSUB 290
70 GOSUB 360
80 GOSUB 290
100 NEXT rot
110 GOTO 60
120 :
130 '****** Initializing
140 MODE 1
150 DEFINT a-z:DEG:ORIGIN 100,100
160 theta=30:sinus!=SIN(theta):cosinus!=COS(theta)
170 DIM x(4),y(4),a(4),b(4),tmp(4)
180 FOR i=1 TO 4
190 READ x(i),y(i)
200 NEXT i
210 FOR i=1 TO 4
220 READ a(i),b(i)
230 NEXT i
240 RETURN
250 :
260 DATA -50,-50,50,-50,50,50,-50,50
270 DATA 1,2,2,3,3,4,4,1
280 :
290 ' ****** Draw & Delete
300 FOR i=1 TO 4
310 MOVE x(a(i)),y(a(i))
320 DRAW x(b(i)),y(b(i)),1,1
330 NEXT i
340 RETURN
350 :
360 ' ****** Transformation
370 FOR i=1 TO 4
380 tmp(i)=x(i)*cosinus!-y(i)*sinus!
390 y(i)=y(i)*cosinus!+x(i)*sinus!
400 x(i)=tmp(i)
410 NEXT i
420 RETURN


Thanks for that. Unfortunately this is becoming more complicated than what I thought, though this routine may help me get my head around rotation. I tried a few other things using DRAWR, the main issue seems to be keeping the shape relatively same size throughout it's rotation cycle.


The routines I was doing in BASIC wasn't relying on XOR mode and was more of a clear the old position when about to draw the new. In that situation I was delaying after the image was drawn (with a FOR loop) and then clearing the image as quick as possible which seems to help with the Flicker problem.

[AMSDOS]

I made some adjustments to your program so it displays the contents of the X,Y Array, put some KM WAIT KEYs in there (&BB18) so it shows the initial position for the X, Y Array on the Left and the modified positions in the right column. I was also playing around with the "theta" variable. 

[Devilmarkus]

Indeed, DRAW and PLOT is very slow...

My example:

Code: [Select]

10 MODE 1
20 DEG
30 g=1
40 WINDOW #1,14,27,7,16:PAPER #1,0:INK 0,0:BORDER 0:INK 1,13
50 A%=100:B%=50
60 FOR p%=0 TO 88 STEP 2
70 MOVE 320+SIN(p%)*A%,200+COS(p%)*B%,g:DRAW 320,300
80 MOVE 320+SIN(p%+90)*A%,200+COS(p%+90)*B%:DRAW 320,300
90 MOVE 320+SIN(p%+180)*A%,200+COS(p%+180)*B%:DRAW 320,300
100 MOVE 320+SIN(p%+270)*A%,200+COS(p%+270)*B%:DRAW 320,300
110 MOVE 320+SIN(p%)*A%,200+COS(p%)*B%:DRAW 320+SIN(p%+90)*A%,200+COS(p%+90)*B%
120 DRAW 320+SIN(p%+180)*A%,200+COS(p%+180)*B%:DRAW 320+SIN(p%+270)*A%,200+COS(p%+270)*B%
130 DRAW 320+SIN(p%)*A%,200+COS(p%)*B%
150 CALL &BD19:CLS #1
160 NEXT
170 GOTO 60


Perhaps anybody can improve this?