| |
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....
|
| |
Bregalad
Account closed
Registered: Jul 2008
Posts: 42 |
Quote:
As for sprite graphics - i think the best way would be to repaint them for c64 with c64 restrictions in mind. Any other method would make them look bad.
Yes you are entierely right. I'll do that, it would look bad to have a lot of sprites that aren't entierely filled. Altough in some way I'd still have to "port" the graphics at some point. Too bad so many graphics editor are for the 64 and not for a modern PC, and that many PC graphic editor does not allow 64 multicolor format (or use full-screen bitmapped-FLI stuff). Hires 1BP format is no match, but not very practical for in-game use.
Quote:
If there is 8 sprites and a hero using 2 sprites, and it happens that you need to flip them all at once, it would take 9*10 = 90 raster lines, that not counting code to modyfy flipping routine. You need a few interupts going, doing sorting, sprite multiplexing, playing music and running game logic. Are you sure there will be enough cycles left to do that all?
Well, I said only the hero's sprite would be rewritten in real time, so that's only 2 or 3 sprite, that wouldn't even be rewritten every frame. Enemy's sprite should be pre-loaded and flipped by software before the level begin (not in real time). That way I don't store the graphics twice, but this doesn't slow anything down.
I guess there would be about 4-6 different enemies per level, altough I haven't put a definite number on that.
Some palette swapping to get more different enemies is planned too. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
Quoting BregaladAlmost all characters have black outlines, it would be an idea to make the black outline hires and the colored stuff multi-color, and if the pixels of the colored stuff are slighly off it really shouldn't matter. Also since the borders are almost alway black outlines I could cheat a little with that. I guess I have to try different things and see how well it works.
Hires outlines work quite well. A lot of games do that:
Stormlord
Target Renegade
The Untouchables
Nebulus
Platoon
Batman - The Movie
Firefly
Microprose Soccer
etc...
|
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Quote:Too bad so many graphics editor are for the 64 and not for a modern PC, and that many PC graphic editor does not allow 64 multicolor format (or use full-screen bitmapped-FLI stuff). Hires 1BP format is no match, but not very practical for in-game use.
full-screen bitmapped-FLI stuff is not really usefull for games, except maybe title screen, but you can edit that format on PC easily with Timanthes Timanthes
There were some sprite editors released too but i don't remember them, as i never used them.
64 multicolor is no use on c64 as it only has 16 predefined colors.
There are a few good bitmap editors on pc, that are particularly good for making sprites and game graphics, Pro Motion is one of them, the other one is especially good if you do games for nintendo and nintendo ds, but i don't remember the name - it has $1000++ price tag so it wouldn't be of much use anyway.
-
If only hero sprite is going to be manipulated in realtime it might work. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
For designing levels, you can also take a look at Charpad (it's in the csdb database) and Spritepad. |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
Remembers me the time I programmed "Grand Monster Slam" ...
-Multiplexer with priorities ...
-Hires outlined sprites ...
-top-down perspective ...
-shortage of the 16K VIC because of sprites (I copied the dwarf animation every time)
Ahh, good old days ...
|
| |
Bregalad
Account closed
Registered: Jul 2008
Posts: 42 |
Haha, the good old days.
The xxx-pad programms looks quite great. Thanks for pointing me to them.
Hires outlines seems a good technique but as long as some sprites use black and you do not want to use hires outline for them, you'll have to set a multi-color constant to black, so then it's kind of a "waste" to have one black hires outines. I'll think about that another day tough. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
You can also set one of the sprite colors to black.
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
Quote: You can also set one of the sprite colors to black.
Yes, but then the two other multicolor colors (d025 and d026) are the same for every sprite => all enemies same colors.. (assuming you dont want to change the black color).
It's best to set d025 to black or something, but this means that your main sprite will have one less color.. (black in d025, and again black in the hires sprite) |
| |
Bregalad
Account closed
Registered: Jul 2008
Posts: 42 |
That's what I were saying. Probably the best color candidates for multicolor constants are $d025 = $0 (black) and $d026 = $7 (yellow), to handle outlines and highlights respectively.
Altough you could use dark-brown ($2) outlines for enemies and have black only for the protagonist, using the dark brown to another escient, but it would make it looks much darker and that may look weird. |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Or you could change sprite color when you change sprite pointer. That is only one more lda/sta pair. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 - Next |
