| |
Oswald
Registered: Apr 2002
Posts: 5074 |
koala otpimizing
Hi Everyone,
I know there's a c64 tool out there that helps with optimizing koala pictures for packing, but no idea what it is called. Anyone knows?:) Timanthes would do the job for me aswell with its nibble swapper tool, but is there a way to load/save a native c64 koala format picture with it ? *.prg doesnt works, what format does it expect to be .prg anyway ?:) |
|
... 80 posts hidden. Click here to view all posts....
|
| |
Fungus
Registered: Sep 2002
Posts: 668 |
Hey Sparta can you change .scr to .scn because it's a reserved filename in windows.
Burg can you add a split output mode for bitmaps, both MCM and HIRES.
Thank you both, saving me countless hours of manual optimization. |
| |
Burglar
Registered: Dec 2004
Posts: 1066 |
Quoting FungusBurg can you add a split output mode for bitmaps, both MCM and HIRES. I'm not sure I want to support alternate outputs. especially when its a oneliner in a normal shell:
dd skip=2 count=8000 if=foo.prg of=foo.bin bs=1
dd skip=8002 count=1000 if=foo.prg of=foo.scn bs=1
dd skip=9002 count=1000 if=foo.prg of=foo.col bs=1 |
| |
Burglar
Registered: Dec 2004
Posts: 1066 |
Quoting SpartaSPOT 1.4 WIP with the same 19 pics and dali: 112867 bytes damn, but dont worry, I still have some tricks up my sleeve :)
looking forward to running a new benchmark myself :) |
| |
Fungus
Registered: Sep 2002
Posts: 668 |
I dealt with it in 64tass, still koala format is not very useful :) |
| |
Jetboy
Registered: Jul 2006
Posts: 265 |
Quote: I dealt with it in 64tass, still koala format is not very useful :)
I find it useful enough :) But seriously, how is koala format not useful for you? |
| |
Fungus
Registered: Sep 2002
Posts: 668 |
Waste of memory to have to move things around into usable locations. |
| |
Raistlin
Registered: Mar 2007
Posts: 622 |
Quote: Waste of memory to have to move things around into usable locations.
When the Koala data is linked, it should be done in 2 or more chunks so that this moving/copying data isn’t needed. |
| |
Fungus
Registered: Sep 2002
Posts: 668 |
Yeah I tend to put the color map at $0800, the color memory at $0c00, the bitmap at $2000 and the code at $1000 so all I have to copy is the color memory and the maximum space is available for linking after it. |
| |
ChristopherJam
Registered: Aug 2004
Posts: 1402 |
Again, that's a thing you do with your assembler or linker, and it's pretty independent of the container format that editors or converters spit the image out in.
Much less directory clutter to have a single file than two or three, and it's no more work in your assembly source to have three lines that grab chunks of one file than three lines that grab three separate files.
Easier to ensure the color and screen attribs are from the same version as the bitmap, too - can't accidentally update one or two of those without the rest. |
| |
Monte Carlos
Registered: Jun 2004
Posts: 355 |
Removing unnecessary information from c64 images is one thing, the memory layout for placing bitmap, screen and colorram the other thing. This thread is mixing up both and it is difficult to follow who talks about what. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 - Next |
