Storing a graphics file then calling it when required in BASIC

[zeropolis79]

Is it possible to store a graphics file in memory then call it when required? Maybe BANKMAN could be used..
Thanks

[mr_lou]

Absolutely. You can create a very simple RSX command to do that. I'm sure someone will paste the code soon.

What you do, basically, is to load the image into an address (that isn't screen address). Then the RSX command basically just copies everything to the screen address when called.

[zeropolis79]

Thanks  this is for my mod of The Wild Bunch - I'm going to do the street for the gunfight as a graphic file but want to only load it once.

[AMSDOS]

I'm not quite sure what's been proposed here, are you talking about 17K Screens or Small Data files with Sprites in them? A screen landscape image maybe worthwhile using a Screen Compressor. The program I have is called SQ23, I think it's on CPC-Power, though maybe under a different name, I used that program once to make a Menu loading program which compressed 3 Screens into the Menu program.

[zeropolis79]

I'm not quite sure what's been proposed here, are you talking about 17K Screens or Small Data files with Sprites in them? A screen landscape image maybe worthwhile using a Screen Compressor. The program I have is called SQ23, I think it's on CPC-Power, though maybe under a different name, I used that program once to make a Menu loading program which compressed 3 Screens into the Menu program.

The original plan was to load in two normal 17k screen images and store them in memory and then call either up when required, replacing the 16 lines of BASIC for the street scene.. (the lines in question which cover DRAW and MOVE commands take up 3k in total) while still using the BASIC sprite of the cowboy. The screen image would also replace a map, also done in BASIC.

Compressing the screens would be a good idea. Would have to investigate how it would work.

Thanks

[AMSDOS]

The original plan was to load in two normal 17k screen images and store them in memory and then call either up when required, replacing the 16 lines of BASIC for the street scene.. (the lines in question which cover DRAW and MOVE commands take up 3k in total) while still using the BASIC sprite of the cowboy. The screen image would also replace a map, also done in BASIC.

Compressing the screens would be a good idea. Would have to investigate how it would work.

Thanks

If the drawing is continuous (for example one line follows another and so on), then all that information can go into DATA. AA had an example of this in Issue 102 with Clur Hodgson drawing a Space Rocket and Star, then FILLing it all in. Apart from the FILLing, that routine inspired me to create one in Assembly, which reduces the size of the code again as well as run quite fast, the only trouble is the DATA has to get stored in memory.


EDIT: Following up on that example I mentioned, I converted their program to assembly. Not all of it was using Loops either such as the Top of the Tail Fin, but was able to easily add code to draw that in in-between the drawing of the Rocket and Big Star. Code size 196 bytes.

Code Select Expand



;; Draw loop in Assembly


org &4000 ;; This routine can go almost anywhere

ld hl,rocketx
ld (adrxpos),hl ;; point xpos data of rocket to address pointer


ld hl,rockety
ld (adrypos),hl ;; point ypos data of rocket to address pointer


ld a,1
call &bbde ;; graphics pen 1


ld hl,150
ex hl,de
ld hl,60
call &bbc0 ;; move 150,60 - position of rocket


ld b,6 ;; number of times to loop - FOR m=1 TO 6
call draw_loop ;; draw rocket body


ld hl,100
ex hl,de
ld hl,150
call &bbc0 ;; move 100,150 - position of top fin


ld hl,70
ex hl,de
ld hl,190
call &bbf6 ;; draw 70,190


ld hl,170
ex hl,de
ld hl,190
call &bbf6 ;; draw 170,190


ld hl,500
ex hl,de
ld hl,360
call &bbc0 ;; move 500,360 - position of big star


ld hl,bigstarx
ld (adrxpos),hl ;; point xpos data of big star to address pointer


ld hl,bigstary
ld (adrypos),hl ;; point ypos data of big star to address pointer


ld b,10 ;; for m=1 TO 10
call draw_loop ;; draw big star


ret ;; return to BASIC


.draw_loop ;; The main loop


ld hl,(adrypos) ;; Address contents which points to image data for ypos goes into HL


ld e,(hl) ;; \
inc hl ;; - Contents of HL which is ypos data (16bit number) goes into DE
ld d,(hl) ;; /


ex de,hl ;; That information (ypos data) needs to go into HL register


push hl ;; But I need to protect that information so I can use HL.


ld hl,(adrxpos) ;; Address contents which points to image data for xpos goes into HL


ld e,(hl) ;; \
inc hl ;; - The same process now happens for xpos data (16bit number) going into DE
ld d,(hl) ;; /


pop hl ;; I can now restore that ypos data back into HL...


push bc ;; ...though I need to protect the loop counter.


call &bbf6 ;; GRA LINE ABSOLUTE, Entry: HL = y-coordinate, DE = x-coordinate
;; Exit: AF, BC, DE & HL corrupt.


pop bc ;; Restore loop counter.


ld hl,(adrxpos) ;; \
inc hl ;; - This moves address pointer for xpos to the following address & stores it.
inc hl ;; - Because 16bit data is being used, HL is incremented twice.
ld (adrxpos),hl ;; /


ld hl,(adrypos) ;; \
inc hl ;; - And the same thing applies for the address pointer for ypos data.
inc hl ;; - And again 16bit data is used.
ld (adrypos),hl ;; /


djnz draw_loop ;; If loop counter hasn't being reached,
;; loop counter is decreased by 1 until B = 0.
;; The following address pointer will then be used.


ret ;; Returns to BASIC (if called from there).


.adrxpos


defw 0


.adrypos


defw 0


.rocketx


defw 300,340,250,100,170,230


.rockety


defw 160,240,240,150,20,110


.bigstarx


defw 530,570,540,540,500,450,460,420,470,500


.bigstary


defw 320,310,280,230,250,230,280,310,320,360


[zeropolis79]

It's not so easy as the 16 lines doesn't draw the whole landscape as there is some code that randomises the time.. if it's night time or day time...

[SkulleateR]

Picking up this old thread since I got almost the same problem...


I have two graphics on disc, both 70x70 Pixels,is there a way to load them to mem and display them when needed?


Preferrably in basic, if that's not possible I would also accept a usable rsx extension 

[AMSDOS]

It's possible to do in BASIC, though it's really a matter of if it will be a satisfactory result, as opposed to a Sprite Driver written in Assembly that does it faster.
Last Month, I was writing a small Double Buffer routine (which I think was what @zeropolis79 wanted), which used a small amount of Machine Code to switch between screens and using BASIC for everything else, though I was also moving the object (down the screen) and using the switch when the new graphic was drawn, though it was only 4x8 to produce a 8x8 image in MODE 0 and while the animation was flicker free, it did have a noticable lag between the screen switches, so I don't know how well a 70x70 would go if you need to move it.

[SkulleateR]

There will be no movement, I will use this as kind of illustration for some text, in the moment I use a 17KB full screen with the rest of the picture having background colour, but that is definitely a waste of memory ....

[AMSDOS]

There will be no movement, I will use this as kind of illustration for some text, in the moment I use a 17KB full screen with the rest of the picture having background colour, but that is definitely a waste of memory ....

Below is an example I made with a BASIC Sprite Driver, the Driver being the routine Lines 1000 to 1090, for a Graphic 70x70, it would have to be adjusted to 70x72 with the last 2 lines blank as this operates in 8 Lines, Line 1000 would need to be adjusted to WHILE blk<10 and 1020 adjusted to FOR x=w+0 TO w+70 I guess unless you mean it's 70 pixels across, in that case it depends on the MODE you're in, so MODE 0 it would read w+35 or if it's MODE 1 it would be w+18 with the image widen to 72 (making it 72x72). The routine would need changing to reflect where the image is in memory too, with my example it prepares an Sprite 8x16 from an array and draws it. A Loaded Sprite could be loaded somewhere in memory e.g. &8000, then 1030 altered to read POKE s+x+y,&7FFF+p

Code Select Expand

100 MODE 0:INK 0,0:INK 1,1:INK 2,2:INK 3,11
110 GOSUB 1100
120 p=1:w=0:z=0:blk=1:s=&C000:GOSUB 1000
130 LOCATE 1,10:END
1000 WHILE blk<3
1010 FOR y=z+0 TO z+&3800 STEP &800
1020 FOR x=w+0 TO w+3
1030 POKE s+x+y,b(p)
1040 p=p+1
1050 NEXT x
1060 NEXT y
1070 s=s+&50:blk=blk+1
1080 WEND
1090 RETURN
1100 DIM b(64):RESTORE 1150
1110 FOR p=1 TO 64
1120 READ b(p)
1130 NEXT p
1140 RETURN
1150 DATA 0,64,128,0
1160 DATA 0,132,72,0
1170 DATA 0,132,200,0
1180 DATA 0,132,72,0
1190 DATA 0,132,72,0
1200 DATA 0,132,72,0
1210 DATA 0,132,72,0
1220 DATA 0,64,128,0
1230 DATA 0,64,128,0
1240 DATA 0,132,72,0
1250 DATA 0,132,200,0
1260 DATA 0,132,72,0
1270 DATA 0,132,72,0
1280 DATA 0,132,72,0
1290 DATA 0,132,72,0
1300 DATA 0,64,128,0


[SkulleateR]

looks promising 


will try out as soon as I got some spare time for it