Search the Community
Showing results for tags 'Image'.
Found 2 results
I am looking to have an option to have a game cartridge be able to detect VBXE and load the image into VBXE memory. I see a few samples use the DAP file format but I am trying to figure out how to convert to the format from a Windows BMP file. I am using GIMP to edit the sprites at the moment and will be divided up for each sprite.
Hi, as some may know, I played quite a while with the A8 graphics modes to achieve unexpected output (like http://atariage.com/forums/topic/124933-new-true-color-mode/#entry1510330 or http://atariage.com/forums/topic/134852-atari-v-commodore/page-220#entry1737525). I never liked interlace or the scan line grille of APAC, so since several years I tried to cope with the restrictions and tried various things. Finally I have a result which I find convincing. The format is nothing really new, just works like HIP without interlace and can be coloured (the profile image of member 'pirx' seems to use this principle already), but I created a converter which is very easy to use, and at least I'm not aware of a similar one. Since I haven't found any description of this format in conjunction with a name, I named it 'JAG' (Just Another Graphics-(format)). The creation process is half automatic and a conversion takes about two dozens of clicks (colour assignments), which can be performed in a minute. (I had a fully automatic process, but results are less convincing.) When compared to RastaConverter (BIG LIKE!), the only disadvantages are the lower resolution and on NTSC systems the images are not that colourful, but the advantages are: * CO2 friendly: conversion is question of minutes * no affinity to banding (but depending on mode/selection slightly scan line grille) * no use of PMGs (less memory and DMA load) (and usable in game scenarios (even with limited colour possibilities) * simple to save & load * simple code for depiction * ATM moderate DLI load: converter supports a single palette for the complete image (this is subject to change, which can improve output quality a lot - depending on the input image) * easier to use in animation scenarios (generation is more 'stable', since available colours can be distributed more freely) * more shades (currently only the obvious theoretical 144 (9*16) per image, in the future all 256) There are still bugs in the converter I need to fix (some are detectable in the images below), output has to be beautified (e.g. top colour border) and I have to write some instructions too, but hopefully next week I can release V1 (if there is demand?). Have fun and stay tuned...