Is it a good "trick" for 32x32 sprites?

By andrear1979

Expert (97)

24-05-2014, 01:48

Hi guys, I had this naive idea and wanted to share it. Not too hardware-specific, just plain MSX1 sprites are involved.

16x16 zoomed sprites ("SCREEN 2,3") look rather blocky, because every sprite pixel is a square of 2x2 screen pixel. What if you take two (carefully crafted) blocky sprites and stack them with 1-pixel diagonal offset? For certain special cases the sprite looks "at 1-pixel resolution" and you used only two 16x16 sprites (in general you may need four).

You may play with a visual, easier-to-understand example here below (arrow keys = add more offset, space bar = change color of lower-priority sprite, ESC= exit).

Is this drawing technique a well-known one? does it have a name? is it just crap, or do you think it may be useful for MSX? I don't remember having ever read about it . Any comment and directions are welcome, thanks!

10 REM -- Draw two 16x16 ZOOMED sprites (32x32 pixels)
20 REM -- Every sprite pixel is 2x2 pixels on screen
30 REM -- Stack them with (+1,+1) pixel offset
40 REM -- Looks like a 32x32 pixels sprite at full resolution!
50 SCREEN 2,3: COLOR 15,4,1
60 DEFINT A-Z
70 C=1: REM -- sprite colour
80  A0$="": A1$="": REM --- 1st sprite
90  A$="0000011111000000": GOSUB 530 
100 A$="0001100000110000": GOSUB 530 
110 A$="0010000000001000": GOSUB 530 
120 A$="0100000000000100": GOSUB 530 
130 A$="0100011011000100": GOSUB 530 
140 A$="1000100100100010": GOSUB 530 
150 A$="1001010101010010": GOSUB 530 
160 A$="1001010101010010": GOSUB 530 
170 A$="1000100100100010": GOSUB 530 
180 A$="1000011011000010": GOSUB 530 
190 A$="0100000000000100": GOSUB 530 
200 A$="0100000000000100": GOSUB 530 
210 A$="0010000000001000": GOSUB 530 
220 A$="0001100000110000": GOSUB 530 
230 A$="0000011111000000": GOSUB 530 
240 A$="0000000000000000": GOSUB 530 
250 SPRITE$(0)=A0$+A1$
260 A0$="": A1$="": REM --- 2nd sprite
270 A$="0001110011100000": GOSUB 530 
280 A$="0010000000010000": GOSUB 530 
290 A$="0100000000001000": GOSUB 530 
300 A$="1000000000000100": GOSUB 530 
310 A$="1000101101000100": GOSUB 530 
320 A$="1001010010100100": GOSUB 530 
330 A$="0000110011000000": GOSUB 530 
340 A$="0001010010100000": GOSUB 530 
350 A$="1000101101000100": GOSUB 530 
360 A$="1000000000000100": GOSUB 530 
370 A$="1000000000000100": GOSUB 530 
380 A$="0100000000001000": GOSUB 530 
390 A$="0010000000010000": GOSUB 530 
400 A$="0001110011100000": GOSUB 530 
410 A$="0000000000000000": GOSUB 530 
420 A$="0000000000000000": GOSUB 530 
430 SPRITE$(1)=A0$+A1$
440 PUT SPRITE 0, (90, 80), 1
450 PUT SPRITE 1, (91+X, 81+Y), C
460 IF STICK(0)=1 AND Y>0 THEN Y=Y-1
470 IF STICK(0)=5         THEN Y=Y+1
480 IF STICK(0)=7 AND X>0 THEN X=X-1
490 IF STICK(0)=3         THEN X=X+1
500 IF STRIG(0)<>0 THEN C=((C+1) MOD 4) + 1
510 IF INKEY$<>CHR$(27) GOTO 440
520 END
530 REM -- convert
540 A0$=A0$+CHR$(VAL("&b"+MID$(A$,1,8)))
550 A1$=A1$+CHR$(VAL("&b"+MID$(A$,9,8)))
560 RETURN

By flyguille

Prophet (3031)

24-05-2014, 03:14

very very interesting.... and more if they are sprite2, to get more colours

By hit9918

Prophet (2932)

24-05-2014, 03:44

In monochrome it is no win in per-scanline budget, 2 sprites used for 32 pixel wide.
It gives more when using two different colors.
Make the first sprite color 8 and the second one color 6.
But not every shape can be modeled, it must be special shapes.
The circle went not so good while the other shape is perfect.

By Sandy Brand

Champion (301)

24-05-2014, 13:37

Maybe not a win per scanline budget but certainly a win considering that these sprites literally cover a 32 by 32 area (actually, 33 by 33). You'd be amazed how much bigger sprites change the look and feel of a game, making it much more 'arcady' easily.

Very interesting idea! Though probably a bit too limiting to be of practical value in a real game unless you give it a bit of an abstract theme. I guess something cool could be done with this in a demo maybe?

By hit9918

Prophet (2932)

24-05-2014, 15:26

@SandyBrand, yes, in normal mode one would need more than 32 sprites to get similar masses.

Look at the modded program below, I tried to make a space ship.
"abstract theme" is the right keyword.
it is like "everything must be made of diagonal lines of 2 pixels".

10 REM -- Draw two 16x16 ZOOMED sprites (32x32 pixels)
20 REM -- Every sprite pixel is 2x2 pixels on screen
30 REM -- Stack them with (+1,+1) pixel offset
40 REM -- Looks like a 32x32 pixels sprite at full resolution!
50  COLOR 15,1,1 : SCREEN 2,3 
60 DEFINT A-Z
70 C=1: REM -- sprite colour
80  A0$="": A1$="": REM --- 1st sprite
90  A$="0000000000000000": GOSUB 530 
100 A$="0000000000000000": GOSUB 530 
110 A$="0000000000000000": GOSUB 530 
120 A$="1100000000000000": GOSUB 530 
130 A$="1110000000000000": GOSUB 530 
140 A$="1111000000000000": GOSUB 530 
150 A$="1111111111100000": GOSUB 530 
160 A$="1111111111111111": GOSUB 530 
170 A$="0111111111111111": GOSUB 530 
180 A$="0000000000000000": GOSUB 530 
190 A$="0000000000000000": GOSUB 530 
200 A$="0000000000000000": GOSUB 530 
210 A$="0000000000000000": GOSUB 530 
220 A$="0000000000000000": GOSUB 530 
230 A$="0000000000000000": GOSUB 530 
240 A$="0000000000000000": GOSUB 530 
250 SPRITE$(0)=A0$+A1$
260 A0$="": A1$="": REM --- 2nd sprite
270 A$="0000000000000000": GOSUB 530 
280 A$="0000000000000000": GOSUB 530 
290 A$="1000000000000000": GOSUB 530 
300 A$="1100000000000000": GOSUB 530 
310 A$="1110000000000000": GOSUB 530 
320 A$="1111111111000000": GOSUB 530 
330 A$="1111111111111110": GOSUB 530 
340 A$="1111111111111111": GOSUB 530 
350 A$="0111111111111110": GOSUB 530 
360 A$="0000000000000000": GOSUB 530 
370 A$="0000000000000000": GOSUB 530 
380 A$="0000000000000000": GOSUB 530 
390 A$="0000000000000000": GOSUB 530 
400 A$="0000000000000000": GOSUB 530 
410 A$="0000000000000000": GOSUB 530 
420 A$="0000000000000000": GOSUB 530 
430 SPRITE$(1)=A0$+A1$
440 PUT SPRITE 0, (90, 80), 8
450 PUT SPRITE 1, (91+X, 81+Y), 6
460 IF STICK(0)=1 AND Y>0 THEN Y=Y-1
470 IF STICK(0)=5         THEN Y=Y+1
480 IF STICK(0)=7 AND X>0 THEN X=X-1
490 IF STICK(0)=3         THEN X=X+1
500 IF STRIG(0)<>0 THEN C=((C+1) MOD 4) + 1
510 IF INKEY$<>CHR$(27) GOTO 440
520 END
530 REM -- convert
540 A0$=A0$+CHR$(VAL("&b"+MID$(A$,1,8)))
550 A1$=A1$+CHR$(VAL("&b"+MID$(A$,9,8)))
560 RETURN

By Sandy Brand

Champion (301)

24-05-2014, 15:54

Yeah exactly.

I guess it can mostly be used as a sort of 'anti-aliasing' trick.

By hit9918

Prophet (2932)

24-05-2014, 16:31

The purely monochrome version is like perfect antialiasing, with 2x2 pixels as basis you get shapes in 1x1 pixel.
But using different colors, the 2x2 pixel blocks actualy pop up again!

Except when using colorpairs that are close in brightness, like 8,6 / 2,12 / 5,4 / 11,10 / 15,14.
And that is where I see the application of the method.
Because the monochrome version gives no increase in scanline budget.
And without increased scanline budget, the increased total masses is a weak argument.

Especialy as the tpical fighter in normal mode could be made 2 sprites wide and only 1 sprite high.
And a tank bullet needs one sprite, while the 2x2 version needs two sprites to remove blockiness!
Except using a single pixel, getting a 2x2 block.

It has advantage in a niche like
"space shooter with two twocolor objects per scanline that are 32 pixel wide".

And then backgrounds that match the sprite style.
They need not be drawn in the same limitation, but the overall style should match.
Smoothscrollable screen 2 gfx would be happy to do that.

By hit9918

Prophet (2932)

24-05-2014, 16:51

Another idea:
The 2x2 mode only on the endmonster.
This needs the player and shootings done as software sprite.

The endmonster 64 pixels wide and 256 pixels high
Squeezing it to 64 pixels high with variable height sprites, you can have loads colorchanges in vertical direction.

But then again, this has to compete vs 32 sprites used on the endmonster in 1x1 mode.
That can have more mono parts because dont always need double the sprites to remove the 2x2 blocks.
And again plenty vertical colorchanges.

Generaly I often thought: if you manage to get the player into a software sprite,
you got a nice practical increase in scanline budget for enemies on the entire screen.
Because the player is the most unknown in the equation about where he is on the screen.

In a charmode (which screen 2 is) it is possible that the pixels in the player chars update 50fps even when scroll is not 50fps.

By andrear1979

Expert (97)

24-05-2014, 18:19

(thanks for all these feedbacks and opinions guys; I agree with you all, there are strong limitations due to this "area vs resolution trade" concept)

Additional observation: I noticed that some transparent parts (special case again) can actually contain 1-pixel thin lines, you can see that there is a thin blue circle in the black "eyes" of the example sprite.

By Sandy Brand

Champion (301)

24-05-2014, 18:27

Hmm mixing sprite scaling modes using a screen-split is an interesting idea, although still quite limiting.

I guess if you made the lower part of the screen in 1x1 sprite mode and upper part in 2x2 scaled mode, you could do something like Space Invaders whereby the actual game-play design makes sure sprites do not cross the screen-split line. Projectiles and lasers and such could be done in screen 4, or like you suggested as software sprites in screen 5, so that these can actually transition from bottom to top and vice versa.

Or maybe something like Beam Rider where the player's movement is limited to the bottom half of the screen in a fairly 'natural' way?

By hit9918

Prophet (2932)

24-05-2014, 19:34

by the way, have you heard of the variable height sprite?
I wanted to mention it again, normaly empty lines of sprites too cost scanline budget, but no more when sorting them by Y.

a minus of the idea with the 2x2 big sprites actualy would be
that they cover so much Y space and this way ditch scanline budget.
for example a little tank bullet would still make load in 32 lines.
but with variable height sprites, this problem is gone.

also more color can be stacked in vertical direction.