Merging Screens Together to Create Bigger Maps

[Jonathan Cauldwell]

I've created Spectrum and CPC user routines that will merge another screen on top of the existing one to help create a wider variety of unique and more complex screens without using lots of extra memory. Essentially the idea is to call USER S where S is the screen number to merge on top of the one the player is in. Zero blocks will be ignored, any other blocks on the merged screen will be drawn.

To use it, you need to use a variable to indicate when the screen has been redrawn, then check if it has been set in the Main loop 1 event. For example, you could use M to indicate a merged screen. In the Restart screen event you'd need this line adding:

LET M = 1

Then in Main loop 1 you could have something like this:

IF M = 1
   RESTORE
   READ M                ; read first base screen.
   WHILE M < SCREEN
       READ M            ; skip merged screen.
       READ M            ; get next base screen.
   ENDWHILE
   IF M = SCREEN         ; does this screen need a merged screen?
       READ M            ; get screen to merge in.
       USER M            ; merge in new screen.
   ENDIF
   LET M = 0             ; don't do this again until screen is redrawn.
ENDIF

; Table of rooms (in ascending order) followed by merged screens.  
DATA 0,6,2,6,255          ; merge screen 6 into screens 0 and 2.


Files are here, I'll also include them in the next release:
MergeRoom.asm (1.72 KB)MergeRoomCPC.asm (1.64 KB)

[jltursan]

Cool!, saving memory tricks are always welcome!

Btw, do you know about metablocks?, some of the engines have this feature implemented and using 16x16 blocks you can save quite some RAM. As an example, ROBOT - The Impossible Mission uses it...

[amaweks]

Dec 4, 2020 18:24:26 GMT Jonathan Cauldwell said:

I've created Spectrum and CPC user routines that will merge another screen on top of the existing one to help create a wider variety of unique and more complex screens without using lots of extra memory. Essentially the idea is to call USER S where S is the screen number to merge on top of the one the player is in. Zero blocks will be ignored, any other blocks on the merged screen will be drawn.

To use it, you need to use a variable to indicate when the screen has been redrawn, then check if it has been set in the Main loop 1 event. For example, you could use M to indicate a merged screen. In the Restart screen event you'd need this line adding:

LET M = 1

Then in Main loop 1 you could have something like this:

IF M = 1
   RESTORE
   READ M                ; read first base screen.
   WHILE M < SCREEN
       READ M            ; skip merged screen.
       READ M            ; get next base screen.
   ENDWHILE
   IF M = SCREEN         ; does this screen need a merged screen?
       READ M            ; get screen to merge in.
       USER M            ; merge in new screen.
   ENDIF
   LET M = 0             ; don't do this again until screen is redrawn.
ENDIF

; Table of rooms (in ascending order) followed by merged screens.  
DATA 0,6,2,6,255          ; merge screen 6 into screens 0 and 2.


Files are here, I'll also include them in the next release:
View AttachmentView Attachment

Awesome, I just tested here and worked fine.

Just for the record, I've first have pasted the "main loop" routine on the top of the mainloop event. It worked for the screen merge, but it messed with my other time based rotines on the mainloop (i'm using some variables for these, but not the M variable). Them I've placed the Merge on the end of the mainloop, after my other codes, them it worked fine without messing anything.

[amaweks]

Dec 4, 2020 18:24:26 GMT Jonathan Cauldwell said:

I've created Spectrum and CPC user routines that will merge another screen on top of the existing one to help create a wider variety of unique and more complex screens without using lots of extra memory. Essentially the idea is to call USER S where S is the screen number to merge on top of the one the player is in. Zero blocks will be ignored, any other blocks on the merged screen will be drawn.

To use it, you need to use a variable to indicate when the screen has been redrawn, then check if it has been set in the Main loop 1 event. For example, you could use M to indicate a merged screen. In the Restart screen event you'd need this line adding:

LET M = 1

Then in Main loop 1 you could have something like this:

IF M = 1
   RESTORE
   READ M                ; read first base screen.
   WHILE M < SCREEN
       READ M            ; skip merged screen.
       READ M            ; get next base screen.
   ENDWHILE
   IF M = SCREEN         ; does this screen need a merged screen?
       READ M            ; get screen to merge in.
       USER M            ; merge in new screen.
   ENDIF
   LET M = 0             ; don't do this again until screen is redrawn.
ENDIF

; Table of rooms (in ascending order) followed by merged screens.  
DATA 0,6,2,6,255          ; merge screen 6 into screens 0 and 2.


Files are here, I'll also include them in the next release:
View AttachmentView Attachment

I'm now struggling with some details to get where I want on this routine...

My goal is have a background screen that I can reuse "behind" other screens with ust the collision tiles...
Lets say I have my screen 0 filed with a landscape, that's my background for the screens.

Them I have my screen 1 with some wall tiles, and screen 2 with wall tiles on a diferent patern.

I want to put screen 1 and 2 on the map, and make these 2 screens call the "M = 1", to make screen 1 and 2 draw on top of screen 0.

But I'm geting the oposite: scrren 0 draws on top of screen 1 and 2, erasing platforms and wall collisions

So, is it possible to make it so? To edit the ASm routine, or the main loop routine, to make the inverse, and make the screen 1 and 2 draw on top of the screen 0?

I do not know if I'm getting clearer.

__________________

Edit:

I think I'll get myself clear redoing de question:

I'll make a exemple of my DATA for the screens to merge

DATA 1,3,2,3,250

In this case the routine will overlay the screen 3 over screen 1 and 2.

What I want to do is the oposite, I want that the routine overlay the screen 1 over 3, and screen 2 over 3.

[amaweks]

I've managed to "brute force" the routine and make what I need. Not the best way to do it, and the screen have an aditional lag to load, but it worked.

Instead the normal code routine co call the user routine, I did something like this:

On RESTART SCREEN:

IF SCREEN 7
LET M 6
ENDIF

IF SCREEN 8
LET M 6
ENDIF

and on MAIN LOOP:

IF M 6
LET M SCREEN
LET SCREEN 6
REDRAW
USER M
LET M 0
ENDIF


So I'll do this for every "background" screen on the game.

Edit:

Testing the Merge Screen feature.



The routine did not worked as I planed, but in a inverse way (puting the screen I want behing on front of the others), So I did some adaptarions on the code to have it as planned.



The downside is a little bit more time when loading a screen. It first load the screen base (the one I whant on foregorund), them loads the screen to merge (the one I whant to be the background) on top of it, and them i make it loads the base screen again so it can draw on top of the background screen.

Its just take a little longer to load, but I think it worth to have a really good byte saving method to have as much screens and content as possible.

[amaweks]

Dec 4, 2020 18:24:26 GMT Jonathan Cauldwell said:

I've created Spectrum and CPC user routines that will merge another screen on top of the existing one to help create a wider variety of unique and more complex screens without using lots of extra memory. Essentially the idea is to call USER S where S is the screen number to merge on top of the one the player is in. Zero blocks will be ignored, any other blocks on the merged screen will be drawn.

To use it, you need to use a variable to indicate when the screen has been redrawn, then check if it has been set in the Main loop 1 event. For example, you could use M to indicate a merged screen. In the Restart screen event you'd need this line adding:

LET M = 1

Then in Main loop 1 you could have something like this:

IF M = 1
   RESTORE
   READ M                ; read first base screen.
   WHILE M < SCREEN
       READ M            ; skip merged screen.
       READ M            ; get next base screen.
   ENDWHILE
   IF M = SCREEN         ; does this screen need a merged screen?
       READ M            ; get screen to merge in.
       USER M            ; merge in new screen.
   ENDIF
   LET M = 0             ; don't do this again until screen is redrawn.
ENDIF

; Table of rooms (in ascending order) followed by merged screens.  
DATA 0,6,2,6,255          ; merge screen 6 into screens 0 and 2.


Files are here, I'll also include them in the next release:
<button disabled="" class="c-attachment-insert--linked o-btn--sm">Attachment Deleted</button><button disabled="" class="c-attachment-insert--linked o-btn--sm">Attachment Deleted</button>

Is it possible to adapt the routine for MSX?

[jltursan]

Sorry for the late response...

Sure, it can be adapted; but keep in mind that in MSX, drawing twice the screen would be probably noticeably slow, even with the tricks already implemented to speed up the drawing process.

If Jonathan makes this part of his next release, it'll be converted.

[Minilop]

I've been trying the merge screens routine and it works ok for normal mode games, however I don't think it is compatible with Adventure mode.

[amaweks]

Mar 16, 2022 18:43:04 GMT jltursan said:

Sorry for the late response...

Sure, it can be adapted; but keep in mind that in MSX, drawing twice the screen would be probably noticeably slow, even with the tricks already implemented to speed up the drawing process.

If Jonathan makes this part of his next release, it'll be converted.

Hi, thanks for response. I was away from my MPAGD projects for a wile too, sorry for the late response.



The merge could be usefull because I have all screens done and merged on the ZX code, so just use the same on MSX could avoid me to redo the work on all screens, and change all the code related to it. Can you make a MSX version of the merge user routine?

[amaweks]

Mar 16, 2022 18:43:04 GMT jltursan said:

Sorry for the late response...

Sure, it can be adapted; but keep in mind that in MSX, drawing twice the screen would be probably noticeably slow, even with the tricks already implemented to speed up the drawing process.

If Jonathan makes this part of his next release, it'll be converted.

You are right, no use to do the merge trick on MSX, I was able to reconstruct all screens without the merge, add details to them, and all fits on a 48kb cart. Thanks, no need (at least for my project) to use merge on MSX.

Soon I'll post updates of the MSX version around here