Hi
I'm converting a PC screen of the game "Titanic" to make a menu for the cpc version and "upgrade" a little the disc loader...
The problem is that the converted screen is not centered, and i tried 1000 times to center it...
I like the results that ConvimgCPC brings to my screen but is not centered!!
(http://i68.tinypic.com/2emiwm0.png)
anyone knows what can be happening???
and why Convimgcpc save the scr screens with a header of #50 bytes??
Thankyou!!
Quote from: Joseman on 00:04, 05 February 16
Hi
I'm converting a PC screen of the game "Titanic" to make a menu for the cpc version and "upgrade" a little the disc loader...
The problem is that the converted screen is not centered, and i tried 1000 times to center it...
I like the results that ConvimgCPC brings to my screen but is not centered!!
(http://i68.tinypic.com/2emiwm0.png)
anyone knows what can be happening???
and why Convimgcpc save the scr screens with a header of #50 bytes??
Thankyou!!
ConvimgCPC adds an amsdos header to a cpc file it saves. The header consists of 128 bytes, added at the beginning of the file. The issue with centering is caused by these additional 128 bytes. If you want to read raw image to display it correctly, you need to remove this header.
Quote from: Docent on 01:57, 05 February 16
ConvimgCPC adds an amsdos header to a cpc file it saves. The header consists of 128 bytes, added at the beginning of the file. The issue with centering is caused by these additional 128 bytes. If you want to read raw image to display it correctly, you need to remove this header.
Hi, thanks for the reply
Yes, the first thing that i thought that it was an amsdos header (#80 bytes) but, if you substract #80 bytes of the converted file the size of the file is: 16336 bytes (not 16384 bytes like a normal cpc screen), that is why I thought that it wasn't an amsdos header, but a special header of convimgcpc, then i substracted #50 bytes that leave the file on the normal 16384 bytes cpc screen.
I just tried now to substract #80 bytes and the 16336bytes file work correctly!!
But this brings me another question! why the 16336bytes file and not the 16384byte? i know that there is screen ram that is not displayed, perhaps this is the explanation? anyone knows why convimgcpc do it this way?
Thankyou again!
Quote from: Joseman on 14:51, 05 February 16
Hi, thanks for the reply
Yes, the first thing that i thought that it was an amsdos header (#80 bytes) but, if you substract #80 bytes of the converted file the size of the file is: 16336 bytes (not 16384 bytes like a normal cpc screen), that is why I thought that it wasn't an amsdos header, but a special header of convimgcpc, then i substracted #50 bytes that leave the file on the normal 16384 bytes cpc screen.
I just tried now to substract #80 bytes and the 16336bytes file work correctly!!
But this brings me another question! why the 16336bytes file and not the 16384byte? i know that there is screen ram that is not displayed, perhaps this is the explanation? anyone knows why convimgcpc do it this way?
Thankyou again!
The reason why the size of a screen saved by ConvImgcpc bar the header is not equal to 16384 is pretty simple. Screen memory layout of Amstrad is a bit weird and in default settings is built from 200 lines of 80 bytes. Each byte represents 8, 4 or 2 pixels depending on video mode. When you do the math you'll find that the visible screen actually takes only 16000 bytes. Due to the interleaved division of the screen memory into 8 blocks of 2048 bytes, the remaining 48 bytes of each block are not visible. Unfortunately due to interleave you cannot remove them all to have screen of exactly 16000 bytes, only the remaining 48 bytes of the last block can be cut. So it gives you 16384-48=16336 - the size of the screen saved by convimgcpc without amsdos header.
To summarize - don't bother about missing 48 bytes :)
Did you try another conversion program? Maybe the one of JavaCPC? But there is more out there. Suggesting that just to see if the problem is the source screen or the converter.
Quote from: Joseman on 14:51, 05 February 16
Hi, thanks for the reply
Yes, the first thing that i thought that it was an amsdos header (#80 bytes) but, if you substract #80 bytes of the converted file the size of the file is: 16336 bytes (not 16384 bytes like a normal cpc screen), that is why I thought that it wasn't an amsdos header, but a special header of convimgcpc, then i substracted #50 bytes that leave the file on the normal 16384 bytes cpc screen.
I just tried now to substract #80 bytes and the 16336bytes file work correctly!!
But this brings me another question! why the 16336bytes file and not the 16384byte? i know that there is screen ram that is not displayed, perhaps this is the explanation? anyone knows why convimgcpc do it this way?
Thankyou again!
Yes, ConvImgCPC saves only 16336 bytes for a normal screen (no overscan) because the 48 left bytes are unused in the screen
Quote from: demoniak on 18:56, 05 February 16
Yes, ConvImgCPC saves only 16336 bytes for a normal screen (no overscan) because the 48 left bytes are unused in the screen
Btw, any chances for a new version of ConvImgCpc? I have 0.17 from 2011...
Quote from: Docent on 20:22, 05 February 16
Btw, any chances for a new version of ConvImgCpc? I have 0.17 from 2011...
0.17??
The last i have is 0.16!!
Where can i download this version (or another new)
btw what is the purpose of an amsdos header on a scr file?
Quote from: Joseman on 20:56, 05 February 16
btw what is the purpose of an amsdos header on a scr file?
It allows the CPC to load the picture. Without an Header it would be considered a text file.
Joseman - You should put here scr file instead picture. Let us check it what the problem is. I converted hundreds pictures by ConvImgCPC and I never had problem with header. Binary files on CPC shoud have it, and this is information about file for OS, not part of file, end of story.
Anyway on your picture first line look black so it no header. For me it looks rather as wrong offset in register 13 in CRTC. There should be 0, what is normal after command MODE. :)
I found ConvImgCPC 0.17 here:
CPC-POWER, CPCArchives (http://www.cpc-power.com/cpcarchives/index.php?page=articles&num=126)
Quote from: ZbyniuR on 23:45, 05 February 16
Joseman - You should put here scr file instead picture. Let us check it what the problem is. I converted hundreds pictures by ConvImgCPC and I never had problem with header. Binary files on CPC shoud have it, and this is information about file for OS, not part of file, end of story.
As far as AMSDOS is concerned, that is information for that Disk Operating System, though Joseman hasn't stated what Operating System their using.
I've read and displayed Screens using Turbo Pascal under CP/M (I've got such a program on my website), so when loading screens with AMSDOS Headers, space has to be allocated because the Header gets read too.
The problem was the amsdos header, problem resolved!!
i'm loading the file with a simple load"menu.scr",&c000
just substracted the #80 amsdos header and all works correctly!
Thanks again to all!!
Biggest problem with all Demoniak's wonderful tools is total lack of documentation -at least in English... >:(
anyone can help perhaps??
Quote from: fgbrain on 13:36, 06 February 16
Biggest problem with all Demoniak's wonderful tools is total lack of documentation -at least in English... >:(
anyone can help perhaps??
True, its very useful tool with very sparse documentation.
I'd add only one functionality though - the possibility to mark a rectangle from loaded picture and convert and save just only the selected rectangle.
Or perhaps there is such option in the program I did not know of? :)