I entered ludum dare last weekend, which is a 48 hour from scratch game development compo, and I decided I was going to make an Apple II "battleship" clone (since the theme was discovery) currently its 4 days past deadline and I am still fighting with it lol
anyway a half hour before the competition started, I decided I needed a way to draw highres graphics and export them to the II, so I whipped up this little ghetto system to do just that
Requirements: PC running The Gimp PC with lua 5.1 installed (older versions of the lua interpreter will not work) The Gimp palette file I made for the Apple II HGR colors The Lua conversion script I made
Basic Rundown: you make a 280x192 or 280x160 graphic using the gimp and the pallet, save it as a ppm file, edit the convert.lua file to change what image file your working on, that spits out a ginormous list of HPLOT and HCOLOR commands that you copy n paste (hopefully in a emulator running as fast as it will go, otherwise prepare to be bored ... for a long while)
Gimp pallet: Apple-II.gpl (save as) open The Gimp, right click in the main window, choose Windows > Dockable Dialogs > Palettes, this will open a pallets window, right click on that window, and choose Import Palette, choose Palette file and select the Apple-II.gpl file to install
Graphics: Make an image or convert an image using the supplied palette at 280x192 or 280x160 and save as a *.ppm file
Script: convert.lua (save as) edit the convert.lua file to point to the *.ppm file you are currently wanting to convert, and save
The convert.lua script as posted needs to be in the same directory as your ppm files !! If your using windows, AND unzipped to the suggested location above there is a "click n go" cmd file for you, everyone else will need to run lua convert.lua OR lua5.1 convert.lua from the command line. This reads the ppm file and produces a *.ppm_out file, which is just a bucket-ton of basic statements
You can then copy and paste them into an Apple II system, BSAVE them and recall them
BE WARNED!! this produces tens of thousands of HPLOT and HCOLOR statements, I strongly recommend you paste them into an emulator running at full tilt warp speed, Apple II win can do it in a matter of seconds, but needles in eyes speed at 1MHz, ALSO this does not account for any of the funnier aspects of the Apple II video system, what you see in the gimp is NOT what you get on the apple, but its close
This is such a ghetto fabulous brute-force solution. I love it!
Recently I've been trying to take my ridiculously huge 12 megapixel DSLR photos and scaling them down to Apple IIGS (and given the scalability of the image, standard Apple II DHR / HGR) resolutions. Convert 3200 seens to have the best all-round SHR mode conversion chops, though the images I get from a program called JpeGS are the most supernaturally amazing 16-color graphics I've ever seen on my Apple monitor.
Unfortunately JpeGS is lacking a "save" function and timed CDA screen savers don't work :(
Wondering if anyone else has done any nutty graphics conversions or has any tips for a modern+retro process.
This reminded me of something I did a long time ago and, rather than dig through old archives, I decided to start rewriting it, so here's the first release:
Ok I took a look at the Atkinson dither. It is interesting that it does seem to get subjectively better results on some images because algorithmically, it looks like Atkinson's main concern was performance: his dither doesn't require any multiplications. I'll include it as an option in the next release.
To anyone reading - is there a preferred file format for DHGR images? I'm leaning towards a straight memory image, like HGR, but even then, should the file contain the aux memory image followed by main memory? The other way around? Interleaved in display order? If there's no "standard" then I'll probably go with the first of the options I just mentioned.
On Jan 7, 4:50 pm, Sheldon Simms <wsspa...@gmail.com> wrote:
> To anyone reading - is there a preferred file format for DHGR images? I'm leaning towards a straight memory image, like HGR, but even then, should the file contain the aux memory image followed by main memory? The other way around? Interleaved in display order? If there's no "standard" then I'll probably go with the first of the options I just mentioned.
I think of Dazzle Draw as the "standard", but might be wrong. IIRC their format is [Aux][Main], whereas another app (Blazing Paddles?) used [Main][Aux].
> Ok I took a look at the Atkinson dither. It is interesting that it does seem to get subjectively better results on some images because algorithmically, it looks like Atkinson's main concern was performance: his dither doesn't require any multiplications. I'll include it as an option in the next release.
> To anyone reading - is there a preferred file format for DHGR images? I'm leaning towards a straight memory image, like HGR, but even then, should the file contain the aux memory image followed by main memory? The other way around? Interleaved in display order? If there's no "standard" then I'll probably go with the first of the options I just mentioned.
This probably won't be much of a help... I was working on a utility/program subroutine which stored the data of a DHGR page as a linear buffer of 4bit pixels and made the conversion to DHGR whenever requested by the programmer. I got kind of busy when I was near the end so I was only able to get it partly working. Maybe reversing the process would let you perform different forms of compression on the data...
> For the DHGR format, the aux part always come first in a file. > antoine
That baffles me as it requires 2 moves. From Main $2000 to Aux $2000 then Main $4000 to Main $2000, whereas the the other way is just one move, Main $4000 to Aux $2000 as the first part is already in the right place. Can anyone see a good reason for this?
> To anyone reading - is there a preferred file format for DHGR images? I'm leaning towards a straight memory image, > like HGR, but even then, should the file contain the aux memory image followed by main memory? The other way > around? Interleaved in display order? If there's no "standard" then I'll probably go with the first of the options I just > mentioned.
Yes, it is preferred my way. :)
You might want to check out my Dbl hi-res screen compressor. It has one of the highest compression algorythms as well as it can compress any part of the screen. This allows for compressed animation that can be animated in one spot on the screen. Loading a smaller file and uncompressing the file is faster than loading the complete file uncompressed plus it save a lot of disk space.
My compressor saves anywhere from 1 to 5 blocks over Beagles Double Scrunch routine.
I am slowing bringing my software to the light of day. A couple of more off the top of my head is: for users of the extended keyboard on their IIGS, a way to turn the caps lock, scroll lock and num lock lights on and off for Prodos 8 users. and short and simple font routines for the Dbl Hires screen.
On 7 jan, 19:55, "ict@ccess" <gids...@sasktel.net> wrote:
> > For the DHGR format, the aux part always come first in a file. > > antoine
> That baffles me as it requires 2 moves. From Main $2000 to Aux $2000 > then Main $4000 to Main $2000, whereas the the other way is just one > move, Main $4000 to Aux $2000 as the first part is already in the > right place. Can anyone see a good reason for this?
Because Apple said it is the way it should be. If you want your images to be loaded by existing software, it is the best solution to choose (not the most efficient for sure) but I doubt somebody will write a new/update an existing software to handle your format.
That is what was done on the IIgs with the Apple Preferred Format (handles all kinds of image files) vs proprietary formats like the Dreamgraphix one (better LZxx (c) (tm) compression), that one being compatible with... Dreamgraphix only.
In French, we say "le mieux est l'ennemi du bien", is "let well alone" correct?
> In French, we say "le mieux est l'ennemi du bien", is "let well alone" > correct?
> antoine
we English have many sayings too, "Let by-gones be by-gones" but I am the type of guy that looks under every cloud for a silver lining and sometimes even killing 2 birds with one stone comes in handy.
Good info. Thanks. I'm not so sure about those crazy packbytes image formats, but the algorithm seems to be really simple, so I'll go ahead and include it as an option.
Probably just because the aux memory byte leads every scan line. It seems like it would be possible to load the image directly into auxiliary memory at $2000 and then copy the second half to main.
Sheldon Simms <wsspa...@gmail.com> writes: > Probably just because the aux memory byte leads every scan line. It > seems like it would be possible to load the image directly into > auxiliary memory at $2000 and then copy the second half to main.
Even from BASIC and ProDOS it's not so bad:
load the aux half: BLOAD DHR.PIC,A8192,L8192,B0
move it to aux with the $C311 routine (using a short asm routine to set up $3C-3F,$42-43)
BLOAD DHR.PIC,A8192,B8192
In assembly it would be even simpler since you don't have to open the file twice.
OPEN READ 8192 bytes => $2000 ... jsr AuxMove READ 8192 bytes => $2000 set DHGR display mode
I have completed the double hires output option so there is a newer version of 'tohgr' for anyone who is interested. If anyone has actually downloaded the program, you will want to get this update because I fixed a bug in the scaling algorithm that negatively impacted image quality.
I'm actually pretty impressed at some of the double hires images produced. The extra colors available really improve the results considerably.
I also added Atkinson dithering as an option in this release. It works best on greyscale images. I prefer Floyd-Steinberg for most color pictures.
The next thing I will probably do is add the option to produce the crazy packbits-enabled HGR and DHGR image formats. After that I'll probably work on IIgs graphics modes. After that I'll see about some other input options (better than XPM).
This utility will allow you to convert to Apple II Double Hi-Res 140 x 192 x 16 color images from IBM-PC graphics files in the following formats:
CGA 320 x 200 x 4 color BASIC BSAVED IMAGE (.BAS) Files CGA 320 x 200 x 4 color ZSOFT .PCX Files EGA 320 x 200 x 16 color Windows .BMP Files
Double Hi-Res Graphics
The double high-resolution display mode that is available for the Apple IIe displays 140 columns of color, for which all 16 of the low-resolution colors are available. Because the double high-resolution graphics mode provides twice the horizontal dot density as standard hi-res graphics does, double hi-res requires twice as much memory as does standard hi-res.
The double hi-res display interleaves bytes from the two different memory pages (auxiliary and motherboard). Seven bits from a byte in the auxiliary memory bank are displayed first, followed by seven bits from the corresponding byte on the motherboard. The bits are shifted out the same way as in standard hi-res (least-significant bit first).
> Sheldon Simms <wsspa...@gmail.com> writes: > > Probably just because the aux memory byte leads every scan line. It > > seems like it would be possible to load the image directly into > > auxiliary memory at $2000 and then copy the second half to main.
> Even from BASIC and ProDOS it's not so bad:
> load the aux half: > BLOAD DHR.PIC,A8192,L8192,B0
> move it to aux with the $C311 routine (using a short asm routine to set > up $3C-3F,$42-43)
> BLOAD DHR.PIC,A8192,B8192
> In assembly it would be even simpler since you don't have to open the > file twice.
"ict@ccess" <gids...@sasktel.net> writes: > On Jan 7, 10:22 pm, Jerry <awande...@yahoo.ca> wrote: >> Sheldon Simms <wsspa...@gmail.com> writes: >> > Probably just because the aux memory byte leads every scan line. It >> > seems like it would be possible to load the image directly into >> > auxiliary memory at $2000 and then copy the second half to main.
>> Even from BASIC and ProDOS it's not so bad:
>> load the aux half: >> BLOAD DHR.PIC,A8192,L8192,B0
>> move it to aux with the $C311 routine (using a short asm routine to set >> up $3C-3F,$42-43)
>> BLOAD DHR.PIC,A8192,B8192
>> In assembly it would be even simpler since you don't have to open the >> file twice.
"Sheldon Simms" <wsspa...@gmail.com> wrote: >Source code like that is why I can't release my source code yet. I've been >shamed!
Don't worry about stuff like that...
Release early and release often... There aren't that many people left in the world interested in Apple II's so play with them while you have the chance:)
And if people can easily convert from a common image format to an apple II graphic they won't worry about your source code.
"Sheldon Simms" <wsspa...@gmail.com> wrote: >It seems like it would be possible to load the image directly into >auxiliary memory at $2000 and then copy the second half to main.
Here's what I do...
/* dlode.c by bill buckels 2009 */ /* a picture viewer for the apple II */ /* written in Manx Aztec C65 Version 3.2b */ /* runs under DOS 3.3 */ /* displays BSaved double hi-res Images */
In article <igerh7$5o...@speranza.aioe.org>, "Bill Buckels" <bbuck...@mts.net> wrote:
> "Sheldon Simms" <wsspa...@gmail.com> wrote: > >Source code like that is why I can't release my source code yet. > >I've been shamed!
> Don't worry about stuff like that...
> Release early and release often... There aren't that many people left > in the world interested in Apple II's so play with them while you > have the chance:)
Bill's points are well taken; and, like so many others here, his code is exemplary, as well as instructive. One of my favorite examples of constructive analysis is Neil Parker's examination of this old demo:
The new features are conversion to 3200 color super hires "Apple Preferred" images and the ability to select packed output (filetypes $08/$4000 & $08/$4001) for hires and double hires images.
This is a feature-incomplete release, but it's been a while and I wanted to get something out there. The Mac (Snow Leopard) executable is up and I'll get a Mac PPC executable and a Windows EXE up sometime later today. I've also put up a disk image of 3200 color pictures.
