|
| |
Credits :
Download :
Look for downloads on external sites:
Pokefinder.org
Production Info
Submitted by algorithm on 22 August 2010
Conversion is very straightforward.
Each sprite color column is initially chosen
Then all fli 8x1 ink/paper combo's are mapped onto either sprite cols 1,2 or 3 (with 1 and 2 being fixed for the entire image and the third color being different for each 6 char column
Each sprite/ink pixel is 4 pixels wide and its the responsibility of the hires ink color to 'hide' the blockiness
The crazy part was to convert the data to c64 format. Sprite definitions are scattered all across the memory.
It took some time to reverse engineer the vic code and to figure out where all the sprite definitions were stored.
If you have a look at the c64 code for the image displayer, the core of the display code is by crossbow.
The display code was used in the demo 'demus interruptus' which featured moving sprite logo over an FLI picture.
As it features a true overlay, I knew this could have been utilised for a new gfx mode with some amendments
As the vic display routine was optimized with no cycles left, i did not change the core displayer at all. apart from the skeleton code and modifying sprite priorities, position, colors, mcols etc. I could have redone the main core of the displaycode, but would end up looking the same. (heavy usage of the illegal opcode SAX) just one lda/ldx, and a write to $d018 &$d011 utilising the above opcode.
The converter code is not optimum in particular the sprite color column choser and the color matching (rgb). This was initially for testing purposes and for major speedup (mmx/sse opcodes |
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Support CSDb | |
|
 |  |
|
