[CSDb] - User Forums - Sprite multiplexing *with* priorities

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Sprite multiplexing *with* priorities

2009-01-24 14:40

Bregalad
Account closed

Registered: Jul 2008
Posts: 42

Sprite multiplexing *with* priorities

I'm willing to port a game on the C64 but for sure I'll need more than 8 sprites per screen. The game uses a top-down perspective so sprites that are southern on the screen must show above the sprites that are nothern, else it will look weird.
Unfortunately, most sprite multiplexing tehniques I've seen arround the net seems to kill any priorities, and that's not good.

I guess I can come up with a solution, but I'm not sure how good it is :
- The screen is sepearated into 10 areas of 20 pixel tall
- There is a raster interrupt each 20 pixels that will handle the multiplexing, and the interrupt at line 250 will also be used for the other usual stuff (screen updates, sound code, etc...)
- Each sprite always crosses 2 areas no matter where they are positionned (this assumes Y expanding is never used)

Now during the frame :
In the first area (lines 0-20), the sprites are mapped to hardware sprites with regards to their sorted priorities. If there is more than 8 then the lowest pirority is discarded.

In the second area, the sprites that were already used in the first area cannot be used, so I map the sprites that are still unused to the sprites starting in the second area, regarding to their priorities.

In the third area, all sprites that were used in the first are done being displayed and I can re-map them to sprites of the third area according to their priorities, etc....

Now the priorities are not matched between areas, but at least they are inside each area. Also the number of interrupts is constant, and everything can be pre-calculed during the non-display time, so that interrupts just do a few writes each 20 scanlines which is not too bothersome and allow it to be mixed with other raster split without too much trouble.

I know Cadavers said it was a bad idea to split the screen with areas, but I can't come with anything else. I could use the generic method in a way so that top sprites are lowest priorities than bottom sprites, and hoping it won't look too weird.

... 61 posts hidden. Click here to view all posts....

2009-02-09 11:40

Bregalad
Account closed

Registered: Jul 2008
Posts: 42

I'm pretty sure it will change it on all sprites globally, so any sprite that would be draw before the hero's would change it's color in the middle of the sprite, and that's not what you'd want to happen.

2009-02-09 11:57

MagerValp

Registered: Dec 2001
Posts: 1078

Why don't you post some of the NES sprites here, so some of our experienced C64 graphicians can give you some suggestions?

2009-02-09 12:23

Bregalad
Account closed

Registered: Jul 2008
Posts: 42

I guess I have a good idea that should work in my case to get more deatail& 4 colors. Have the skin, hair and black outines with 2 vertically arranged multicolor sprites, and have the clothes color on another layer from a third hires sprite, so that I can get more detail on the shape the clothes takes, and the face part does not need that color so only 1 sprite will do. The main drawback is that there is no way to guarantee the priorities of the sprites, and that I can't have much detail on the face.

You can see some graphics from the NES version on my website here.

2009-02-09 13:14

Jetboy

Registered: Jul 2006
Posts: 337

You have 1 color that can be set per sprite, and 2 that are common for all sprites and used in multicolor mode.

So good practice is to set common colors to dark gray and light gray/white so you can add higligts shadows. Then you use color that is changable per sprite, to give color to your multicolor sprites, then you use overlaid hires sprite that is black to give outlines.

Characters fitting in 1 sprite should be perfectly fine for such kind of game. So you could use 2 sprites per enemy in the same mode, or just have 6 independent sprites.

You could then multiplex those 2 sprites for hero and make her 2x as high

That could complicate it a bit but you could try to make enemies try to avoid being in the same lines (can be a little bit costly depending on implementation), but would make avoiding graphics glitches more easily.

2009-02-09 20:42

Bregalad
Account closed

Registered: Jul 2008
Posts: 42

I didn't understand everything.
I'm planning to use light yellow ($7) for highlight as it goes well with pretty much all colors in existance (with red it makes fire-like things, with blue metal-like things, and with green or brown normal highlight, etc...), and can be used for skin color for human characters (that makes them look Chineese, but well, the C64 does not really have any accurate skin color, the only second closer is $a, but too greyish and too dark under some settings.

Small monsters can definitely fit only one sprite, but larger ones and the hero will be 2, because 21 pixels isn't really high. Hires outlines could be good, but having them on the player and every enemy could be too much ? If I do like you say I'd end up with 4 colors per sprites, but for the NES I designed them with 3 and I don't know how to use the last.

Also since my multiplexing engine has no way to guarantee the priorities between sprites (it can only make them very likely to get some priority), hires outlines would randomly be pasted below the colors, and that would make some ugly effects. Again, there will be some ugly effects when too much sprites show up anyway, so I don't know how acceptable this would be. If this ends up not acceptable, I could just stuck with 3 color sprites. No hires for characters, but this may not look that much worse : Since all pixels are wider than tall, the eye won't really notice it. If I make some places very detailed with hires and some places very clunky with multi-color, the multi-color places will look less detailed. If everything is multi-color then it won't be as noticeable.

2009-02-10 05:28

Oswald

Registered: Apr 2002
Posts: 5094

if you're going to use 2 sprite high objects, overlay is a big no no imho, as 2 of such objects will use up all 8 sprites already, and I guess you'll want to display more than that.

2009-02-10 07:01

MagerValp

Registered: Dec 2001
Posts: 1078

I don't see why those sprites couldn't be redrawn to fit in 24x21. With a bit of skill you should even be able to add details, especially when animated.

2009-02-10 08:41

Bregalad
Account closed

Registered: Jul 2008
Posts: 42

Yeah I probably won't be using hires outlines for that game, or, as you say, only for small sprites.

Some monsters will be able to be redrawn for 24x21, but not all, some will be too large. Human or humanoïd characters are supposed to be taller than larger, in some video games it may be okay if they look square, but if will definitely be horrible if they are larger than taller. So the small ones fit 24x21 (not using all the 24 width), but the larger ones will be something like 24x42 (not using all the 42 height).

Not using the whole height for the protagonist will be benefical as it implies less stuff to rewritre when the animation frame is changed. And I don't care to use more than 8 sprites cause I have a general multiplexing engine ready to use. Altough it would be nice if not many glitches shows up on screen.

2009-02-10 21:46

Hein

Registered: Apr 2004
Posts: 954

Hires overlay without priority sorting isn't possible, is it?

If you read Dokk's interview at www.c64.com, some wise advice was given to him, long long ago, when the protagonists were still square blobs: interpret the graphics, don't try to do exact converts. C64 is a different medium, so it requires a 'fresh' approach to what you have allready for NES. I wouldn't spend painfull energy on hires graphics, rather spend it on expressive animations and cool gameplay.

2 cents in the basket, soon enough you'll be rich.

2009-02-11 10:29

MagerValp

Registered: Dec 2001
Posts: 1078

Well a quick fix would be to reserve sprite 0 for the main character hires overlay, and only multiplex sprites 1-7.

Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next

Refresh

Subscribe to this thread: