This answer is targeted towards a previous revision of the question which asked about generic assets and sprites.
In chunky linear modes like VGA Mode 13h, the problem for copying a rectangular region onto another is simple as the following variables can be calculated:
- The number of visible horizontal pixels and rows of the sprite remaining after taking a union with the destination clipping rectangle.
- The offset into the sprite's data to begin reading if the sprite is clipped on its left or top sides.
- The destination pixel on the destination to begin drawing.
With these you calculate the following two constants which allow the source and data points to jump to their respective next lines after drawing a line of the sprite.
- The offset between successive lines of the sprite data.
- The offset between successive lines of the destination surface.
Then your drawing loop sets up the source and destination pointers, then for for
effective_height rows: draws
effective_width pixels, then skips
In bitplaned video (CGA/EGA), horizontal clipping is difficult because it requires manipulating bits rather than bytes - masking out some number of individual bits from the left or right sides of the drawn sprite when they exceed the destination rectangle. In tweaked video modes (Mode X) your clipping algorithm has to consider a model where VGA RAM addresses manipulate groups of four pixels at a time - you'll have to change the currently enabled planes at certain times depending on whether you're drawing columns or rows.
In both cases, if it's at all possible to simply not do clipping and blindly copy full bytes in bitplaned video, or full quads in unchained mode, then that's best. Clipping requires calculation and results in non-constant values (the values calculated up above). Instead, if it's possible to write a hard-coded 'draw a 16x16 thing at x,y' routine with no clipping, then all the constants get folded into the instructions and loops can be unrolled. Drawing some variable number of rows is much simpler because that's simply the number of repetitions of the loop that draws rows as in the chunky case.
This answer expands on my comment in Justme's answer.
I recall some games that used tweaked modes and larger virtual canvas that they did not care to draw only visible area of sprites, they were copied fully so when the sprites extended beyond visible viewport it did not show as it was in a non-visible part of frame buffer.
These gifs are from my previous answer about Commander Keen: What is 'Adaptive Tile Refresh' in the context of Commander Keen?
This is an animation of the first stage of the game - I believe you want to know how clipping for the alien sprites is done.
The graphics card registers allow you to specify the stride (or offset) between adjacent rows of graphics data in graphics card RAM. By default this is exactly the minimum number of bytes needed to display a row on screen - the byte after the one containing the furthest right's pixel data immediately precedes the byte for the leftmost pixel of the next line. If the stride value is bigger than this, then this reserves additional horizontal space on the right side of the row in graphics card RAM which is not displayed on screen, and the effect is to create a logical virtual screen which is wider than the display region (whose size remains unchanged).
The start address and pixel panning registers together specify what position in the graphics card RAM, and therefore in the virtual screen, the display should begin from. Because the virtual screen is wider than the displayed region, anything that is in the border isn't displayed. This is how Keen does scrolling, which is linked to when and where clipping is necessary.
This is a visualisation of the contents of graphics RAM during Keen. Watch the left side of the screen where the green aliens are drawn into the black. If these sprites were clipped then the reserved region there would not be drawn into. Unfortunately this only shows a 320x wide region whereas the real stride is much wider to allow for the extra tiles, so here's a single frame as example (sorry it's less than 100% accurate but it's illustrative).
The fuschia region here is the displayed window, which moves from left to right within the green rectangle. When the fuschia region hits the right side, it's jolted back by 16 pixels and anything that needs to be redrawn is redrawn. Notice that the black border is never shown because the fuschia region can't move that far, it's locked in the green zone. The Keen engine erases sprites every frame by redrawing the tiles on top of the sprites every time they're overdrawn by a moving object or the camera moves. Drawing a 16x16 tile aligned to display memory is fast because it's a fixed size and no panning is involved. The sprites aren't clipped in Keen horizontally at all; they're drawn fully but appear to be clipped because the excess pixels land in a safe location offscreen rather than wrap to the opposite side.
For a text mode screen, the graphics card parameters are the same: you can set the start address of the screen and have various finer-grained panning parameters for horizontal and vertical panning, allowing the programmer to manipulate the display of the text mode tile plane very much like it was a games console tile plane.
Like in Keen, you can specify a data stride to produce a logical screen of characters that is wider than the displayed region. Only a single extra character cell is necessary in this case to allow full free scrolling horizontally. With the extra character cell, you can pan within a character to smoothly slide the position of the text mode tile plane across the screen horizontally. When a full character size has been reached, the contents of the tile map can be updated to reflect what should be displayed at the camera's new position. You'd have to copy the contents of the text mode screen 'left' one row (or in whatever direction you wanted) each time.
Alternatively, the graphics card RAM can be used to store a large region of text or ASCII art characters in its entirety, and the start address and horizontal and vertical panning parameters can be used to freely fly around this prepared region without the contents or attributes of the displayed cells needing to be altered at all.
In these cases, the ability to direct the graphics card's text mode display to pan across partial tiles horizontally or vertically allows for things to 'fall off' the visible screen and it's the programmers responsibility to ensure the resulting content of the screen is acceptable with all the parameters in their new positions reflecting the scrolling to the new tile.