Jump to content
IGNORED

For fun - multi-colouring Players


Recommended Posts

Hi,

 

Here is the beginnings of an attempt to animate a colourful h/w sprite.

 

Using the Game Gear sprite-sheet you can see I've taken a manual approach to initially coding the data - hence only 10 lines in the example! These images are nicely 16 pixels wide.

 

Effectively I tried using Blue and Brown colour with OR'd to produce a 3rd colour, toggled each frame with either a White or Black to produce a extra range of colours.

 

So by altering the image data and Player colour registers every Vblank this is the result you can get.

 

The tricky part about the Sonic images are that they actually use 7 colours and so to obtain the Black I have had to leave those areas as background (all zero) in the Player data but then make 'holes' in the green scenery to make the background visible in the right pixels. Though not done in the example, this is setup in the data as an AND mask to help.

 

Having seen it looks OK, next up would be to make a data-2-src encoder for the images. Once a few frames of animation are ready then animating them should be possible.

 

Therefore back-drop wise, all 3 colours are available and independent from the Player image. I'm using mode 7 (Antic D) with 4 colours @ 160 * 96 because I've used double-line Players and this matches the pixel size.

 

One reason for positing though was to gauge any other approaches programmers may have had.

Having re-read most of the PRIOR discussions we can agree that the statement that overlapping players = Black if multi-colour isn't enabled wasn't accurate.

So would there possible be a way to get a seventh colour without sacrificing the background too much?

Or is the not possible because the distribution of these effects across the P0/1 and P2/3 combined with PFs?

 

EDIT: this only really appears to work correctly if Frame Blending is enabled in the emulator

 

Regards,

Mark

PmColorTest.asm

PmColorTest.xex

post-1822-0-03316100-1434781500_thumb.jpg

post-1822-0-68967400-1434783281.png

Edited by Wrathchild
  • Like 1
Link to comment
Share on other sites

> Can you please post picture of Sonic frames in that 7colours GR.7?

 

I can't because I haven't got that far :)
Also it not 7 colours of the Gr.7, the Player is giving 6 colours and black supplied by the background. Other modes would suffice.

Edited by Wrathchild
Link to comment
Share on other sites

I am thinking is Sonic beeing 16pixels wide then it will be two Players one colour more two other gives a 3rd colour in multicolour mode.

The other 3colours would came from PF0, 1 and 2.

MISSILES in 5th Player mode as PF3 Gives the 7th one and all around him I would do it as BAK register.

Link to comment
Share on other sites

Humm, maybe this work. On your picture, the A8 colours one/just face you have:

-> Darkest Brown - use as PF0 [E6];

-> Lilac/Middle Blue - use [7A] as PF1;

-> Black - I would use a [02] instead and not a 100% Black, as PF2;

 

Then PMGs (in multicolour and 5th Player modes):

-> Your that seems colour 9 as P0&P2 in luminance 8;

-> Your that seems Dark Blue as colour 8 as P1&P3 in luminance 4 or 6;

-> This gives the Oring when overlaping light [9C] or [9E] for that lightest white part;

 

Then PF3 on your light brown as [FE] and then because Missiles are in 5th Player mode. Maybe it's possible and it seems these pixels are less used/width and inside Sonic shape(s) possible with some small pixels re-arrangement...

Link to comment
Share on other sites

I am thinking is Sonic beeing 16pixels wide then it will be two Players one colour more two other gives a 3rd colour in multicolour mode.

The other 3colours would came from PF0, 1 and 2.

MISSILES in 5th Player mode as PF3 Gives the 7th one and all around him I would do it as BAK register.

I am already using the 2 combined P0/1 and P2/3 to provide the 16 pixels.

I want to avoid mixing colours of Playfields (PRIOR 0?) as I would imagine that would be very complicated when it comes to drawing the background.

The method described above is simply to multiplex the colours of the Players to provide more.

Link to comment
Share on other sites

Not anything to do with Prior0, what I said is 3colours are the PFs, other 3 are the Players in multicolour and 7th is PF3 if you have possibility to have the Missiles in 5th Player mode (background is BAK colour register).

You can set Prior1 and there's no oring between PFs and PMGs.

Is there any possibility to use the Missiles this way? Just watching that frame probably, like I proposed, the light brown?

Edited by José Pereira
Link to comment
Share on other sites

Good luck with this! It reminds me of a technique we used on the TI-99/4A back in the day. It didn't have a graphics mode (or at least not one you could access through EXTENDED BASIC), but you could redefine the printable characters to make some pretty good two-color graphics. Then there were a huge number (32 maybe?) of 16x16 sprites but the hardware would only let you display 4 on any horizontal line. That made about 6 colors and you could change 4 of them every 16 scan lines. I remember typing in a program from a book that made a clown head that smiled at you.

  • Like 1
Link to comment
Share on other sites

Solution: interleaving

 

#1

 

bmp_frame0   line0
bmp_frame1   line1
bmp_frame0   line2
bmp_frame1   line3
...
...

 

#2

 

bmp_frame0   line1
bmp_frame1   line0
bmp_frame0   line3
bmp_frame1   line2
...
...
Edited by tebe
Link to comment
Share on other sites

CSharp source for the data converter included (needs the file pointed to in the first post).

 

pm_data.asm is what this produces and is now included by the PmColorTest2.asm main file.

(that's a lot of data so I may move that into a banked switched cart next)

 

Thanks Tebe, would this require the Player colour changes made each line within the kernel?

e.g. it could be possible to switch off player DMA and draw the data direct to their data registers.

 

Would you be able to demonstrate by mod'ing the sources?

PmColorTest2.zip

Edited by Wrathchild
Link to comment
Share on other sites

Any anti-flicker strategies welcome :)

(1) I don't like flickering ;)

 

(2) In some cases you can get interesting effects when using the GPRIOR=$30 setting, thus also the 5th player. Mixing COLPM2 & COLPM3 & COLPF3, then you already have 7 colours. F.e. use player 2&3 and all missiles to get 7 colour grid of 8 bit width. Now you can turn SIZEP0 & SIZEP1 to $00, turn SIZEP2 & SIZEP3 to $01 and turn SIZEM to $55.

  • Like 1
Link to comment
Share on other sites

I think Popmilo can add something to this discussion.

Think you're right, as soon as I get some free time later today, I'll bang something up without flicker ;)

 

ps. For some reason that link to original sprite sheet opens only if I go through that website links (choose sprites, game gear, sonic etc.). Here is png file for experiments:

post-14652-0-10554200-1435128680_thumb.png

  • Like 1
Link to comment
Share on other sites

Have added some background graphics but still using Antic D rather than swapping to a charmap'd mode. This makes applying the 'background hole' masks easier and you'll see I'm cheating when it comes to restoring the background before the next sprite redraw ;)


Some things to consider...

How the animation sequences work, e.g do they align on 4 pixel boundaries or move a few pixels and hence would the 'black' masks need shifting/pre-shifting.

Examine efficient ways of restoring the background before the next 'black' masks are drawn.

PmColorTest3.xex

post-1822-0-56441000-1435209086_thumb.png

PmColorTest3.zip

Edited by Wrathchild
  • Like 4
Link to comment
Share on other sites

Took me little more time that I thought but here it is - v0.1 of PalBlending converter :)

 

Sonic sprites in 7 colors. I've joined two similar blue shades to get max three shades of each color because of Pal blending limitations.

Here is result with simple 1:1 color change to atari palette:

post-14652-0-83789200-1435510043_thumb.png

 

And here is quick render of how it would look like in Pal blending mode. Unfortunately saturation is lower than on real thing so you'll have to wait till I convert it to binary and make atari executable to see how it looks:

post-14652-0-69200600-1435510061_thumb.png

 

  • Like 6
Link to comment
Share on other sites

Whoa!

Take a look at this :)

 

post-14652-0-49184700-1435518561.png

 

And here is executable for testing in emulator or even better on a real thing (think you'll be surprised how good it looks on TV):

sonic.xex

 

Reminder on Pal blending mode specs:

- 4 greys, 4 colors mixed to produce 4 colors in 4 shades.

In this case, 4 greys (including black and white), 4 greens, 4 blues and 4 reds.

- Lots of cpu time spent on changing colors in visible parts of screen, but lots remains so should be possible to make nice game (maybe not super sonic, but something slower and nicer :) ).

post-14652-0-49184700-1435518561_thumb.png

  • Like 7
Link to comment
Share on other sites

Nice, stable without frame blending enabled.

One thing I noticed on Altirra was that colours were very washed with Filter Mode=Point and so Bilinear produced the greens in your screenshot.

:thumbsup:

I use Filter Mode=Point too.

What is the difference with Filter Mode=Bilinear?

 

Which is the more faithful with real hardware and CRT?

Edited by Philsan
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...