Requesting a small explanation on game screens, edges, and wrapping (or lack of)

[Kitsune Mifune]

Hi all. I'm not looking for any hard code per se, more some wisdom and an explanation.

I was wondering if someone could do me a small explanation of the Amstrad screen as I'm having bother getting my head around it.

Specifically: in games, a player can partially disappear off the left or right edge of a screen without it wrapping, and enemies can completely move off the edge of a screen. However, any size that I make the screen, it wraps as soon as anything goes off the edge.

I assume that the screen in games is actually wider than what is visible and the edges are some sort of windows which is smaller than the actual screen size. Or is it two memory locations, and going off the edge goes into another non-visible screen address? Regardless, could someone please explain what is happening and/or how to do it?

I realise it's a bit of a nooby question, but I'm not finding any decent explanations from searches and it's more just to get a good visualisation of what's happening.

Thank you in advance.

[Sykobee (Briggsy)]

I would imagine that the sprite renderer, if it allows the character to go off the edge of the screen (many games will have renderers will not allow parts of a sprite to go off the edge at all because that's far simpler to not allow the character to move there at all than check when rendering), will actually simply not render the parts of the sprite beyond the edge.


Otherwise, as you note, the graphics will wrap around, one character line lower, because that's how screen memory is arranged.

[andycadley]

Yes, the usual approach is to clip the sprites at the edges so you just don't draw the whole sprite, giving the appearance it has gone off the edge. You could use an overscan technique to make the screen wider than the monitor can display, which would also work but means you have to have a very wide display. In theory you could possibly also use rupture like techniques (or the Plus screen splitting) to accomplish similar things without needing to make the screen so wide, but I'm not sure that wouldn't end up complicating things more than just a simple rectangular clip.


Also if you're drawing to an off screen buffer first, you can of course just make that wider and then clip it when you actually copy to the screen.

[Kitsune Mifune]

Thank you both very much, it's just what I was after.

I never even thought that the sprites would just be clipped and simply not drawn when they go off the edge. It's almost fiendishly simple (in theory).

Are there any examples of how to clip a sprite at the edges so that it doesn't wrap? I'll obviously have a search but just in case there are some that are well known/better than others.

Thank you again. Just knowing how things are meant to happen is a huge help.

[Sykobee (Briggsy)]

Clipping does add a lot of calculation to a sprite renderer - as you're forever checking 'is this byte i'm drawing over the edge of the screen'.


You may find it faster to have a non-clipping routine, and routines for each edge that you want overlap, assuming most sprites won't be oclipped and thus shouldn't be slowed down by the clipping routines.


CPCTelera has a drawSprite without clipping, but interestingly doesn't provide clipped sprite rendering methods, only various masked and blending modes.

[andycadley]

You shouldn't really have to check on every byte, since you can calculate in advance the width and height of the clipped region reasonably easily (unless you are doing some very fancy non-rectangular clips). If you're dealing with variable width sprites already it doesn't really amount to much more than being able to skip a few bytes each line. Although it certainly might be faster to have an entirely unclipped routine, particularly if you have fixed width sprites.


Another possibility is to just avoid it all together and have sprites just appear fully on screen and disappear at the edges. It looks less realistic, but in many types of games you don't really notice and it works well enough without all the complexity of messing around clipping images.

[Kitsune Mifune]

Very interesting. It's good to know what targets are available to aim for as I didn't really have a clue what was going on before to achieve the effect.

At the moment I have screen boundaries set so that the edge of the sprite(s) stops dead before it goes off the edge of the screen, but it's more if I want enemies to come in off the left or right edges of the screen without them just suddenly appearing.

I've been focusing so much on just player/enemy sprites of late and how they move, plus setting up collisions etc. and so I've not done much research on the screen itself and how stuff like this works. This information is very useful, so thank you all once again.

[roudoudou]

in Dragon Ninja game the screen is 64 bytes width but the visible screen is 60 bytes width
i guess the engine assumes sprites are never more than 5 bytes width before doing a real clipping
then you can render any 5 bytes or less sprite as usual, it will warp to the other side of the screen
then before the buffer flipping, the game is drawing two vertical black lines

[Kitsune Mifune]

in Dragon Ninja game the screen is 64 bytes width but the visible screen is 60 bytes width
i guess the engine assumes sprites are never more than 5 bytes width before doing a real clipping
then you can render any 5 bytes or less sprite as usual, it will warp to the other side of the screen
then before the buffer flipping, the game is drawing two vertical black lines

That's interesting becasue I assumed that's how it worked with most beat 'em up type games of that ilk, in that the actual screen was wider than what the "window" on the screen was. I tended to think that the space to the left or right of the screen was the margins where the maps were being "built" for scrolling, but I was never sure how it worked.

I've had a mess around with the CRTC settings as it has some registers which deal with "actual" screen width and "visible" screen width, but I've not had much luck unfortunately as I don't really know what I'm doing. Still, it's good to know that sort of thing is possible.

[roudoudou]

That's interesting becasue I assumed that's how it worked with most beat 'em up type games of that ilk

Saboteur 2 (ported from spectrum) deals only with very small tiles => ninja girl is composed of many small tiles
then it's easy to know if you have to draw the tile with X/Y coordinates => the game is slow because it's a speccy adaptation but this method can perform well
Here is a native usage of this method https://www.cpc-power.com/index.php?page=detail&num=3556

[Kitsune Mifune]

Saboteur 2 (ported from spectrum) deals only with very small tiles => ninja girl is composed of many small tiles
then it's easy to know if you have to draw the tile with X/Y coordinates => the game is slow because it's a speccy adaptation but this method can perform well
Here is a native usage of this method https://www.cpc-power.com/index.php?page=detail&num=3556

Interesting site. My sprites go through a piece of code to get the X/Y origin's offset to the bottom center instead of the top left (with some versions shifting the sprite left or right by half the width for animations that require the X/Y to be bottom left). This is another reason I'm asking about the screen edges as there's always just a moment before the calculation where the actual pre-calculated offset is half a sprite's width more left or right. Sometimes this can go over the edge of the screen if I'm beside it and turn round, which isn't visible on the sprite as it's done before the actual draw routine, but I think the screen itself still see and recognises it as there's some funny position shifting that happens now and then.

A little bit of a margin beyond the left and right of the visible screen before wrapping starts would be ideal, but as I say I'm unsure how it works in the case of games.

[IndyUK]

Hi,
I have been experimenting with wrapping sprites and do have a working example. It's not the best in the world but it seems to work. At the moment I have it working vertically and now am working on the horizontal direction. The latter is a bit more tricky (at least for me) because when it wraps the screen address drops 8 scanlines. It is working but need to figure out how to deduct the 8 scanlines. I will try and get a video together so you can see it. I need to reduce the captured video file size to under 4MB (currently at 150MB).

Thanks

[IndyUK]

Hi,
I've shrunk the video file down. Hope the MP4 format works.
Thanks

[Sykobee (Briggsy)]

I guess you'd have to subtract a scanline's worth of bytes from the address when rendering the wrapped portions.


On a 40 char wide CPC screen, that means subtracting 80 from the target address. On a 32 char wide configuration, that's subtracting 64.


Obviously that will add some time to the rendering routine.


Another method is to render the two portions separately, as if they are two clipped sprites.