Jump to content
IGNORED

Quantizator


ilmenit

Recommended Posts

New Feature Request:

I'm not sure how technically possible this is with the way that the code is structured, but I'll ask anyway. Would it be possible to have a command line switch to specify which colours / PMGs can be used?

 

The reason that I ask this is because it would nice to be able to make the pictures more usable in games. Rather than just having a static screen, it would be nice if you could have a mouse pointer over it, to be able to point at things. This could then be somehow linked into 'Adventure Studio' or other tools. In such a case, I would determine which PMGs the mouse uses and then switch them off for RastaConverter.

  • Like 1
Link to comment
Share on other sites

<p>

New Feature Request:

I'm not sure how technically possible this is with the way that the code is structured, but I'll ask anyway. Would it be possible to have a command line switch to specify which colours / PMGs can be used?

 

The reason that I ask this is because it would nice to be able to make the pictures more usable in games. Rather than just having a static screen, it would be nice if you could have a mouse pointer over it, to be able to point at things. This could then be somehow linked into 'Adventure Studio' or other tools. In such a case, I would determine which PMGs the mouse uses and then switch them off for RastaConverter.

This would be nice...Let's say you would like to have PMGs free to move a joystick/cursor over a static picture in a Graphic Adventure screen...
Link to comment
Share on other sites

Today I had fun ;)

 

I was preparing this picture to test with RastaConverter and found something interesting.

 

The title isn't finished.

 

post-2756-0-66055300-1340039249_thumb.jpg

 

The most obvious is the face, and could be a special style of drawing.

But , have a look at the rocket launcher. It has no body, as you only have a black line over Rambo's abdomen.

 

And, the hand looks like one of his parents must have been a fish ;)

 

 

Edited by emkay
Link to comment
Share on other sites

Check out the Rambo Revisited - GFX Compo on csdb. Some of the best ones.

 

Can I take part there ;)

 

post-2756-0-09673100-1340086310_thumb.png

 

rambi.xex

 

Some changes in the picture and still the try to use Rastaconverter as a simple import tool. Hope, Ilmenit will do the needed stuff, handling the low colour pictures...

 

 

Btw: I'll have a look at that source ;)

Some of that pics need to be on the A8 :D

 

 

Link to comment
Share on other sites

Some changes in the picture and still the try to use Rastaconverter as a simple import tool. Hope, Ilmenit will do the needed stuff, handling the low colour pictures...

 

Looking at the Leaderboard Golf picture http://www.atariage.com/forums/topic/156160-quantizator/page__st__525?do=findComment&comment=2540048 I see that limiting colours to only used in the picture will not solve the problem. This is what Wrathchild tried.

 

"Even so, sometimes the 'seemingly' most simple things aren't picked up by the application, for example with this World Class Leaderboard screen, the vertical grey/white bars take an age to resolve... this is after 160M evaluations."

 

Are you 100% sure that it is even possible to perfectly convert this "most simple" picture?

In unresolved lines there up to 9 different colours in line. Big areas of the picture are covered with playfield colours (4 available on Atari). Smaller details are covered with 4 sprites. The other colour has to be covered by sprite multiplication and inline colour modification, which can happen on determined screen places. Random nature of RastaConverter can't guarantee that it will ever find the perfect solution. Even heuristics of /init=smart or /init=less do not help, because sprite position or colour reg change of missing colour would have to be accurately calculated. With each missing colour the problem gets much more complicated. For that a totally new tool or algorithm is needed. RastaConverter base on heuristic random hill-climbing optimization to find suboptimal solution for complex cases. I don't know how to do some better and universal algorithm that will work for more than one particular picture.

Link to comment
Share on other sites

Are you 100% sure that it is even possible to perfectly convert this "most simple" picture?

 

This wasn't intended as a criticism, for the main part of the image the tool has does a very job job, but it was more the top part of just the "leaderboard golf" and tees section that should have been simple as there are only the black, colours for the letters, 2 greys and white and the blue sky.

 

The kind of element of the solution I felt was missing here is being able to recognise a consistent pattern vertically and locking, for example a player or missle, to it.

Link to comment
Share on other sites

for the main part of the image the tool has does a very job job, but it was more the top part of just the "leaderboard golf" and tees section that should have been simple as there are only the black, colours for the letters, 2 greys and white and the blue sky.

The kind of element of the solution I felt was missing here is being able to recognise a consistent pattern vertically and locking, for example a player or missle, to it.

 

To preserve the vertical pattern there are two mutations: swap raster program line with previous line and copy raster program to the next line. They do a good work usually and they do a good work in case of this picture, but only in lines, where colours are really the same. I can try to add or modify mutation to copy the raster program to some other random line, but every redundant or unnecessary mutation just slows down the optimization process.

 

However even with "simple as there are only the black, colours for the letters, 2 greys and white and the blue sky" we have 7 colours to cover (sample line rescaled):

post-22831-0-87037200-1340105524_thumb.png

 

The black, orange and brown because of size have to be covered with the playfield colours. Then we have 1 PF colour for the sky, white and 2 greys. Lets say that we use it for the sky.

To cover remaining 3 colours (white and two greys) we have 4 players. Those colors are on the sides of the screen so we have to multiply the sprites in a line. It is possible to reposition them only because those 3 colours are used on the side of the screen and you won't have time to reposition them back if you do some more colour changes - you won't have cycles free. If those 3 colours were be placed somewhere else it is not be possible to cover them by sprite multiplication (the case of vertical bars below).

 

Take a look at the line where "by Bruce and Roger Carver" text is (the line is rescaled to be more visible):

post-22831-0-91639600-1340107825_thumb.png

It is not possible to cover 100% corectly it's all 10 colors with Atari gfx capabilities.

Edited by ilmenit
Link to comment
Share on other sites

 

Are you 100% sure that it is even possible to perfectly convert this "most simple" picture?

 

7 colours...

post-2756-0-80607200-1340118657_thumb.jpg

 

 

The line is from the lower part of the picture. The Ocean logo uses bright blue, and the trousers get the blue colour, because the colour has the same brightness.

Drop a different brightness there and the trouser get it's own colour.

 

Seems the colours get some sorting priority rule, which is a good thing for "true colour" adjustment. But for indexed colour pictures, every colour should have the same priority.

Link to comment
Share on other sites

 

Are you 100% sure that it is even possible to perfectly convert this "most simple" picture?

 

7 colours...

post-2756-0-80607200-1340118657_thumb.jpg

 

 

The line is from the lower part of the picture. The Ocean logo uses bright blue, and the trousers get the blue colour, because the colour has the same brightness.

Drop a different brightness there and the trouser get it's own colour.

 

Seems the colours get some sorting priority rule, which is a good thing for "true colour" adjustment. But for indexed colour pictures, every colour should have the same priority.

Link to comment
Share on other sites

Here some example of some problems with the converter.

They use the same amount of colours...

Compare the EXE...

 

post-2756-0-85338400-1340452362_thumb.pngpost-2756-0-67824200-1340452323_thumb.pngpost-2756-0-61838600-1340452360_thumb.png

 

It's a nice feature of the palette there... imagine a game using this full palette animations... just like Dune ;)

 

 

The difference is in the colour usage, not in the colour count.

 

This one has the least errors and evaluations

blue.xex

 

This one shows some problems with the correct pixels

green.xex

 

This one has a visual bug. And I'm just let rendering it again.

error.xex

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

The bug still appears in that picture.

 

But, have a look here:

 

You see a square, where it doesn't belong to.

10000s of solutions and billions of evaluations may not handle it.

 

post-2756-0-87607600-1340518159_thumb.png

 

red.xex

 

It seems, blue gets handled correctly, and the more red turns in, the converter gets a problem.

Edited by emkay
Link to comment
Share on other sites

Seems the colours get some sorting priority rule, which is a good thing for "true colour" adjustment. But for indexed colour pictures, every colour should have the same priority.

 

There is nothing like colour sorting priority. The process is random.

 

You see a square, where it doesn't belong to.

 

The square is a part of a sprite (quadruple width) over COLBAK. Due to random nature of RastaConverter on one picture some color can be choosen as sprite, on the other as playfield color.

 

It seems, blue gets handled correctly, and the more red turns in, the converter gets a problem.

 

Nope. The result is random. Rerun the converter a few times to get different resutl.

Remember also that the colour spread over Atari palette is not linear.

 

If this logical bug is removed, the converter will probably get 10x faster (or even more)

 

There is no logical bug AFAIK - the process is random.

Link to comment
Share on other sites

 

There is no logical bug AFAIK - the process is random.

 

There is a logical bug. Probably it has to do with the vaules of the colours themselves and there is no intention.

 

 

Look at the picture....

 

They both were based on the same amount of 17 indexed colours.

 

post-2756-0-51357500-1340615435_thumb.jpg

 

The lower one has 587 million evaluations and dist. of 6.45

 

The upper one hae only 66M evaluations and a better distance of 5.72

 

Only the values of the colours have changed.

 

 

Link to comment
Share on other sites

 

There is no logical bug AFAIK - the process is random.

 

There is a logical bug. Probably it has to do with the vaules of the colours themselves and there is no intention.

 

 

Look at the picture....

 

They both were based on the same amount of 17 indexed colours.

 

post-2756-0-51357500-1340615435_thumb.jpg

 

The lower one has 587 million evaluations and dist. of 6.45

 

The upper one hae only 66M evaluations and a better distance of 5.72

 

Only the values of the colours have changed.

 

 

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...