Images generated by RastaConverter

[Gunstar]

That turned out well, what does the original look like?

 

Is your av pic also an RC conversion?

To answer the second question you only need look above in this thread.

 

First question:

[Gunstar]

Asia Aura. 35 colors.

 

 

Asia_Aura.xex

[Gunstar]

Vermont Winter. 54 colors. This one definitely looks better on real hardware for the colors. What looks pinkish in the .png image are proper oranges and yellows on a PAL Atari, more closely matching the original image.

VermontWinter.xex

Edited July 27, 2017 by Gunstar

[ivop]

Scariest thing to appear on my A8 since the Rescue on Fractalus incident

Here's some more Eddie

32 colours:

42 colours:

ivop-book_of_souls.xex

ivop-eddie.xex

[ivop]

A bit more mellow images.

 

33 colours:

 

 

 

41 colours:

 

ivop-windmill.xex

ivop-kinderdijk.xex

[Gunstar]

Geosynchronous Orbit. 76 colors.

 

Molly Hatchet: Beating the Odds. 74 colors.

 

 

geosynchronousorbit.xex

MHOdds.xex

[ZylonBane]

I wonder if Chris Foss's stuff would look great because it's so colorful, or terrible because it has so many regions of solid color.

[a8isa1]

Geosynchronous Orbit. 76 colors.

 

Molly Hatchet: Beating the Odds. 74 colors.

 

 

That Geosynchronous Orbit is outstanding! Looks as if a pixel artist drew it specifically for A8.

 

It also looks quite good on my NTSC machine, a fortunate selection of colors in the original no doubt.

[Gunstar]

That Geosynchronous Orbit is outstanding! Looks as if a pixel artist drew it specifically for A8.

 

It also looks quite good on my NTSC machine, a fortunate selection of colors in the original no doubt.

I guess it was a fluke all around then, because this was one of the rare ones that turned out great the first attempt on default settings. Out of all the pictures I've done there were probably half a dozen that turned out good on the very first attempt default settings.

 

Of course when I say default settings I'm not talking about number of solutions or number of threads I'm just talking about pre conversion settings but choosing a palette.

Edited July 29, 2017 by Gunstar

[Gunstar]

Star Wars: The Old Republic scout. 51 colors.

 

SWtorScout.xex

[ivop]

It's the Amsterdam Gay Pride Week. The canal parade is this Saturday. Here's 8-bit pride!

 

PAL, 51 colours:

 

NTSC, 57 colours:

 

 

Both images do NOT use any player/missiles! As mentioned in the "Rastaconverter bug"-thread, this image triggers the bug within a couple of million evaluations. They did look better with PMs though

 

Anyway, I thought these turned out pretty good with only four colour registers

 

ivop-rainbow_flag.xex

ivop-rainbow_flag_ntsc.xex

[Gunstar]

 

 

Anyway, I thought these turned out pretty good with only four colour registers

 

How many colour registers are there with player/missiles on? IIRC, off hand, there are two players and two missiles? So is that a maximum of eight registers (or however many P/M's if I'm wrong)? Or is there some other Jiggery-pokery going on beyond DLI's & VBI's with sprite multiplexing? Can hardware sprites (P/M's) on the Atari be multiplexed or is that only possible with soft-sprites? Anyone?

Edited August 1, 2017 by Gunstar

[ivop]

How many colour registers are there with player/missiles on?

 

Eight, but the extra four have a lot more restrictions.

 

The four playfields cover 160 pixels, the four players 8 consecutive pixels each. Repositioning a player on the same scan line could potentially add 8 more, but the content is not dynamic, so these pixels have to be the same. Don't think that happens often, unless all 8 are on (one/1) and the player is used to fill large patches of the same colour.

The missiles are not used at all. Adding those would add 2 pixels each of the same colour as the corresponding player or all four missiles can share a colour if you enable fifth player. But, IIRC you still need four HPOS registers for the missiles, so that's probably why Ilmenit did not use them.

[ivop]

Answering everything after "IIRC" which was not there when I first answered

 

There are four players, 8 pixels wide each, and four missiles, 2 pixels wide each.

Players and missiles share a colour register, i.e. player two has the same colour as missile two, unless a certain bit is set and the missiles are treated as a fifth player. In that case, player five (the four missiles) have the same colour as playfield 3, which is not available in graphics 15, the 160x239 four colour mode, which has a background colour and three playfields (0, 1, 2).

But, as said in the previous post, the missiles are not used by rastaconverter.

 

About multiplexing, it is possible to change the horizontal position of a hardware sprite after it has been displayed to some point further on the same scanline and it will be displayed again.

 

Players and missiles either get their pixel data through DMA (the contents remain the same if you reposition) or you can write the pixel data directly to the GTIA chip through five GRAFx registers (4 players, 1 register for 4 missiles).

Edited August 1, 2017 by ivop

[Gunstar]

Wicked pleasures. 28 colors.

Red fox pup. 61 colors.

Ugly ducklings. 26 colors.

 

Additional: I attached an inferior .xex image of Ugly ducklings at first, the right one has been posted now.

WickedPleasures.xex

redfoxpup3.xex

UglyDucklings.xex

Edited August 2, 2017 by Gunstar

[José Pereira]

Where's the red fox? I only see a yellowish one.

[Gunstar]

So, are you someone that likes to "chase the Dragon?" What do you do if you actually catch it?

 

Green Dragon. 46 colors.

GreenDragon.xex

[adam242]

Red fox pup looks very nice

[Gunstar]

Blue Dragon. 60 colors.

BlueDragon.xex

[Gunstar]

Dragon's Fire. 41 colors.

 

DragonsFire.xex

[gorgh]

howdy,
Is there an option to save RC files as asm sources? If not what are the methods for adding one's own code like rmt player?

[Rybags]

Not sure there is actually. What you get in an executable file is about 8K worth of bitmap data and 16K or so worth of code which is the kernal that does all the register changes.

Embedding in your own program would be simple enough though not sure what provision there is for relocation.

Though that said, relocating the picture would be easy enough, probably need to replicate the display list to the point where the DMA load is the same (LMS would offset that scanline 2 cycles through DMA loss).

 

The kernal itself consists of mostly inline code with some subs, branches and a jump near the start of each screen. Relocation would be fairly easy.

What I have noticed though is that the generated code has a lot of NOPs. Some size optimization could be possible by replacing large enough blocks of them with sub calls to create the same delay (e.g. 6 NOPS = 12 cycles which = a JSR/RTS combination which would save 3 bytes a time). Though that said, as a manual process might take 30 minutes per pic for the sake of saving maybe several bytes per scanline at best.

 

Here's one I did a while back. It's an amuzing pic but seems to lack contrast in the final product, probably some pre-processing needed to get a better result on the Atari side:

 

Rybags_Desert1.xex

[José Pereira]

Australian cactus are big !...

[Rybags]

I think it's an American pic actually... pretty sure no native cactus here and not really any big ones common in the wild.

[Gunstar]

Outland Dragon. 49 colors.

 

Dragon Spell. 76 colors.

 

Blue Dragon. Dithered, 60 colors.

OutlandDragon.xex

DragonSpell.xex

BlueDragonD.xex

Edited August 7, 2017 by Gunstar