Enhanced graphics modes with PMG

[+Spaced Cowboy]

I've been following some of the threads showing N colours per scan line using various tricks with DLIs and VBIs. My question is: are any of these generally useful with PMGs superimposed, i.e: such that moving the PMG around the play field doesn't have consequences for the colour of the PMG ?

 

Basically, can you have "better" graphics in the background, and still have PMGs in the foreground, without the PMGs changing colour when they move around the screen ?

[peteym5]

If the enhanced graphics mode does not combine with player/missile tricks to get the extra colors. Some tricks like setting PRIOR to 0 that "OR"s player/missile graphics with screen graphics will be an issue. Super IRG is the simplest because that just toggles between two character sets in alternating frames. APAC or CIN can work, but gobble up CPU time per frame to get more colors.

[emkay]

Back in the 90s I had an idea of a rather low CPU using mode that I named MCS , to make eventually games on it.

 

http://a8.fandal.cz/detail.php?files_id=3624

 

 

For a quick overview

 

 

Edited January 28, 2018 by emkay

[+Spaced Cowboy]

I've been looking around, but I can't quite find the spec for MCS - I found John Harris' GED, but that seems too cpu-intensive to be practical in a game environment.

 

Can you point me at (preferably) source code. Or at least a spec for how memory is laid out and what is required in terms of DLI and/or VBI ?

 

Then I could think about writing a PNG to MCS converter

 

Cheers

Simon

[_The Doctor__]

the link works now so go ahead and click it.

Edited January 29, 2018 by _The Doctor__

[+Spaced Cowboy]

fix your fandal link mkay, its truncated and will produce an error

 

I don't think that's him, actually - the entire http://a8.fandal.cz site appears to be down. I did successfully look at the link before...

[emkay]

The mode was kept very simple. To have clean logics around it.

Gr. 12 and charset change every 3 mode lines.

PMg has fixed positions.

 

The pictures have to be set to 4 colors, allowing to change the color value to a close color and same brightness, to have some optical "dither" . The important part is to still use only 4 different brightness values. That's why the pictures show just gray at the start.

 

There have been two negative aspects to people who had seen the images.

 

The always colored border . Which is imho an acceptable issue, if the color is always the 2nd darkest, or a big part of the image.

 

Then people misunderstood the "gray" at the start of a picture. They thought the colorization was taking that long.

But it was done to show how the pictures have to be prepared, and colors had been easy changed in Basic.

Funny , how things can get misunderstood.

Edited January 29, 2018 by emkay

[popmilo]

Nice images Emkay !

PMg has fixed positions.

 

Fixed for all images alike or is every image different ? And are PMg expanded or not ?

[emkay]

Nice images Emkay !

 

Thanks!

 

Some of them were ripped from single screen scrollers, some were self painted.

 

I wrote all tools to convert bitmap to charset/row and the bit setting for the PMG myself...

 

 

 

Fixed for all images alike or is every image different ? And are PMg expanded or not ?

They were expanded to fill the playfield. Always the same position there.

 

It's just only 7 DLIS for charset change that slows down the CPU for that.

Edited January 29, 2018 by emkay

[+Spaced Cowboy]

Okay, so let me see if I have this right

 

• It's a 5-colour playfield with no restrictions
• The PMGs are used as "background" and stretched out (to 4 colour-clocks wide, for a total of 5 * ( 4 * 8 ) or 160 pixels, neatly covering the entire screen)
• but that means that your 6th through 9th colours are "zoned", each into 5 equal vertical sections spaced across the screen. If you want a solid background, it's really a 6-colour mode.
• unless you can put up with very wide pixels and use one of the playfield colours as background
• The charset changes every 3 modelines because you're using 40 chars per line, and you get 128 per charset, that gives you the resolution if you change every 3 lines.
• DMA overhead will be relatively low.

So it's a low-CPU overhead for relatively high resolution at the colour depth. That's pretty cool.

 

It does mean you don't get to use PMGs without giving up a colour-zone though, so you're using software sprites (which you probably have the CPU time for, to be fair)

 

If you want more than 9(6) colours per screen, we could use DLIs to change them, but then you're back to STA WSYNC and reducing the CPU time.

 

Is that a fair summary ?

Edited January 29, 2018 by Spaced Cowboy

[emkay]

If you want more than 9(6) colours per screen, we could use DLIs to change them, but then you're back to STA WSYNC and reducing the CPU time.

 

Is that a fair summary ?

Right at all.

[Wrathchild]

Is PM DMA enabled or disabled and if enabled, single or double height?

[emkay]

Is PM DMA enabled or disabled and if enabled, single or double height?

Ofcourse DMA enabled . If I remind correctly, it is double height to save memory. It's also faster to handle .

[tebe]

https://atariwiki.org/wiki/Wiki.jsp?page=Ironman%20Atari#section-Ironman+Atari-MCS