Players, PRIOR, Backgrounds brain dump...

[andym00]

Just a bit of a brain dump that I need to get out before I forget it all..

 

Players & PRIOR modes, and how to achieve colourful playfields has been bugging me for a few days now.. Hell I even dreamt about P0/P1 and P2/P3 playfield combinations last night

 

Okay, thinking about graphics options for rendering a game with lots of sprite, and trying to keep things as colourful as possible..

For the kind of scenario I'm thinking I'm imagining some horizontal based game, using soft sprites with players on top (either simple overlays or OR'd contraptions), and also using players on top of static (actually animated) background imagery..

 

The idea is that a general purpose multiplexer manages players and colours, and horizontal sizes, so that normal sized players can be used for overlaying software sprites..

 

• Using PRIOR OR'd 'voodoo'..
  Means we really have to use the 5 colour background character mode, so limits us to character modes, and no bitmap modes, otherwise with only 4 colour P2/P3 will only have access to one colour, though this would be manageable I imagine, so include bitmap modes back in..
  It doesn't feel so useable since it means we have to ensure a certain player is allocated into either P0/P1 or P2/P3 which although manageable easily from the multiplexers point of, and doing so would mean that variable height sprites would naturally fall out of the system, I'm not entirely convinced that it's practical due to the constraints it brings with it..
   
  It just feels far too limiting in terms of being able to easily manage a screen without things falling to pieces should a sprite fail to allocate the the P0/P1 or P2/P3 slots they absolutely need..
   
  For example we've got 2 sprites on a line that need to be in P0/P1 and a 3rd joins the club, we're a bit screwed.. P2/P3 might be free, but they're no help in this mode..
   
  From a fairly general point of view I don't see this being so practical in a game with a fair amount of freedom for objects to move..
   
  Plus the Missiles don't seem to be fantastically useful in this mode if using 5 colour mode..
   
   
  
• Using 4 colour background and limit used bitpatterns and palette..
  Use 4 colour background mode and only use bitpatterns 00,01,10 with 11 being set to the same colour as 01, and 10 not being combinable with players.. This means don't have to worry about which Player a sprite gets allocated.. It can go into P0/P1 or P2/P3 and it makes no graphical difference..
   
  It means we have 3 colour backgrounds, but each player can add 2 additional colours to the underlaid graphics (be that software sprite or static background imagery)..
   
  Missiles do become useful here in this mode, but only in the context of single colour objects..
   
  
• No OR'd mode..
  And just 4 or 5 colour backgrounds with overlays and then use use a Player as a simple overlay, adding only 1 colour.. If combined with 5 colour character mode, this isn't far off what the 64 is typically managing, in that PF3 would be like SPRMC0, and we'd just be one common multicolour short on each sprite..
   
  Missiles are useful here in 4 colour modes since that's essentially a fifth player for the system..
  

 

The other downside to the OR'd mode is that is makes using colours splits down the screen for the screen harder to work with.. I like the OR'd mode a lot, just it feels very difficult to use well in a general purpose scenario especially given the different P0/P1 P2/P3 combinations, I mean P0/P1 with PF0/PF1 and P2/P3 with PF2/3.. But maybe I'm missing some magical point of clarity ?

 

Unless I'm mistaken, the 5 colour modes makes software sprites a wee bit hellish to do ? (edit: It just occured to me, that it wouldn't be any harder than managing the OR'd mode sprites anyway when it comes to restricting how stuff overlaps, so maybe scratch the comment)..

 

My brain is exploding thinking about the various possibilities, and I'm curious if anyone has any thoughts on the subject, and if there's other real-world possiblities that haven't entered my mind yet ?? Or maybe I've completely misunderstood the above graphics possibilities ??

 

But keeping it real please, not heading off into G2F land

 

Anyway, off to collect my 130XE and possibly an unopened/sealed 800XL as well

Edited September 13, 2009 by andym00

[PeteD]

Alternatively Players and Missiles as underlays as I'm using for Exploding Fist (for the background at least) using the 5 colour char mode. That way you can expand the PMGs to get more coverage and still use the foreground to mask them off to pixel sizes. Of course then "foreground" means using a PF colour as background instead and working your graphics so the actual background colour is mostly used where no massive PMGs go over else they show through (stop sprites from overlapping the background, even if they do sometimes it's ok).

 

You can use this for backgrounds to add more colour and for software sprites. I've gone through a few C64 games and worked out where you can use this and produce the same number of colours as the 64 game, if you're, careful because it's surprising how many of them use colours from the background in the sprites as well, so allowing your softsprite routine to use them

 

 

As far as the 5 colour thing goes for Fist I'm doing it this way. Where the guys overlap and are pretty much static I have all the PMGs free (lower screen area with solid colour background) so I can use them as an extra "covering" layer in the "attiribute clash" areas. When the same happens over the background, "usually" the guys will be moving quite fast so I either ignore it OR I have a 2nd copy of the graphics which has the clashing colour changed to a different one or removed all together. As my 2 "clashing" colours are white and red it's too obvious to let one change to the other in the background so removing them instead (they're mostly smaller stuff anyway) seemed a better choice.

 

 

Pete

Edited September 13, 2009 by PeteD

[analmux]

Another possibility is using the following priority scheme:

 

(highest) PM0,1 - PF0,1,2,3 - PM2,3 - BG (lowest)

 

LDA #$02

STA GPRIOR

 

Then PM 0&1 can be used at normal width for PM overlays, to add f.e. some colours to sw sprites.

PM 2&3 can then be used as PM UNDERLAYS at quad width, to spice up some larger parts of the background scene.

 

Other things are possible when using 5th player mode. Then the 4 missiles (forming the 5th P) are always on top:

 

(highest) 5th P - PF0,1,2,3 - PM0,1,2,3 - BG (lowest)

 

LDA #$14

STA GPRIOR

Edited September 13, 2009 by analmux

[analmux]

Just an example:

http://www.phys.uu.nl/~bpos/IR1/DemoSMB3/

You can run the .atr file on emulator or real machine.

The prog shows possibility of using PM purely as quad width underlays for adding more colours to the background.

Of course after that, you're restricted to SW sprites.

 

The source code is included in the .zip file.

However, I failed the first coding lesson: Don't forget to use comments in the source code.

[andym00]

That's pretty damn cool actually Hmmm, time to play around with this stuff then

[andym00]

Another possibility is using the following priority scheme:

 

(highest) PM0,1 - PF0,1,2,3 - PM2,3 - BG (lowest)

 

LDA #$02

STA GPRIOR

 

Then PM 0&1 can be used at normal width for PM overlays, to add f.e. some colours to sw sprites.

PM 2&3 can then be used as PM UNDERLAYS at quad width, to spice up some larger parts of the background scene.

 

Other things are possible when using 5th player mode. Then the 4 missiles (forming the 5th P) are always on top:

 

(highest) 5th P - PF0,1,2,3 - PM0,1,2,3 - BG (lowest)

 

LDA #$14

STA GPRIOR

 

That's interesting.. I didn't realise that was the case from the reading I did, that P4 will stay above the playfield in that case..

I think I should start thinking more about underlaying the playfield then since now it's been pointed out it does make a lot more sense, and it'll work much better with a mutliplexer taking care of the horizontal expansions as well It's just a concept I found unusual at first, but now can really start to see the benefits of it..

[analmux]

That's pretty damn cool actually Hmmm, time to play around with this stuff then

 

Oh, one extra comment I forgot:

 

(press Help key for explanation screen, Help key another time to go back to demo)

 

This screen explains functions of pressing key 1, 2 or 3.

These can be used to toggle features, f.e. turn on/off sideborder clipping, or changing GPRIOR settings, or turn off all gfx, PM only etc.

 

Please use it, and you'll see what's all behind the theory of PM underlays.

[PeteD]

@Analmux

 

Is that the demo where you use the GRAFP and turn off the DMA fetch to save cycles?

 

 

Pete

[analmux]

@Analmux Is that the demo where you use the GRAFP and turn off the DMA fetch to save cycles?

Yes, that's him!

 

It's really the most convenient solution for this type of problem. When we need vertically scrolling AND PM underlays, it's better to chop the screen up in blocks / horizontal bands, and do GRAFPn processing instead. Otherwise we'd need too much cpu processing to move everything around, at least when we need a scrolling step of more than 1 rasterline between 2 frames.

 

This one's just a demo, and it still has some 'bugs'. Sometimes we see that parts of objects are not 'coloured' after scrolling a bit. This is just because more than 4 (or 5) PMs are needed there. But, this is a bad example of course. When using this technique, we can 'design' the level around the possibilities.

 

Another bug is caused by too little CPU time, just after a bad line. The prog uses Antic 4 display, thus we have badline problems. The down side is that exactly at the char boundary we also want the PM underlay to change.

[PeteD]

No real reason for stuff to be on char boundaries if you're designing the game yourself, tops of platforms etc can be 1 or 2 pixels down or 4 and just spread the graphic over 2 lines for narrow (short) platforms. More chars used but I don't think that's too much of a problem. The taller/bigger blocks just skipping a couple of lines off the tops would work. Alternatively use a timer. This is one of the times that the DLIs being synced to the drawing rather than the raster count becomes a pain, but like I say, plenty of solutions.

 

 

 

Pete

[snicklin]

Just an example:

http://www.phys.uu.nl/~bpos/IR1/DemoSMB3/

You can run the .atr file on emulator or real machine.

The prog shows possibility of using PM purely as quad width underlays for adding more colours to the background.

Of course after that, you're restricted to SW sprites.

 

The source code is included in the .zip file.

However, I failed the first coding lesson: Don't forget to use comments in the source code.

 

Thank you, this demo has given me a lot of ideas.