| |
Raistlin
Registered: Mar 2007
Posts: 680 |
C64GFX - Image Formats
I'm starting to think about "better" ways to categorise images on C64... and whether images just need multiple toggles/options for different things. Eg.:-
Image: Picture, Logo, Font
Type: Bitmap, CharSet, PETSCII, other?
Colour Mode (Main Screen): HiRes, MultiColor, FLI, Mixed?, Other
Interlace: 1 frame, 2 frames, more?
On-Screen Sprites: no/yes
Top/Bottom Border Sprites: no/yes
Side Border Sprites: no/yes
Rasters: no/yes
Multi-Screen: Horizontal, Vertical, Diagonal 1x1 scroll, Diagonal 2x1 scroll, Large, etc..?
Animated: no/yes
Other: .. option to write notes here
^^ there's probably even more than that.
That feels like a lot.. is it overkill? Is it useful? Is it even possible to determine all these things for (currently) ~16,000 images. For regular MC and HiRes, I can add code to my toolset to find these, along with marking which images extend outside of the regular screen area (which can be a sign of rasters, sprites, or just a bad screenshot).
Is any of this even useful..? Maybe I should only be caring about the mass-market formats and just calling the others "extended"? |
|
| |
Mr SQL
Registered: Feb 2023
Posts: 137 |
Quoting RaistlinI'm starting to think about "better" ways to categorise images on C64... and whether images just need multiple toggles/options for different things. Eg.:-
Image: Picture, Logo, Font
Type: Bitmap, CharSet, PETSCII, other?
Colour Mode (Main Screen): HiRes, MultiColor, FLI, Mixed?, Other
Interlace: 1 frame, 2 frames, more?
On-Screen Sprites: no/yes
Top/Bottom Border Sprites: no/yes
Side Border Sprites: no/yes
Rasters: no/yes
Multi-Screen: Horizontal, Vertical, Diagonal 1x1 scroll, Diagonal 2x1 scroll, Large, etc..?
Animated: no/yes
Other: .. option to write notes here
^^ there's probably even more than that.
That feels like a lot.. is it overkill? Is it useful? Is it even possible to determine all these things for (currently) ~16,000 images. For regular MC and HiRes, I can add code to my toolset to find these, along with marking which images extend outside of the regular screen area (which can be a sign of rasters, sprites, or just a bad screenshot).
Is any of this even useful..? Maybe I should only be caring about the mass-market formats and just calling the others "extended"?
Very cool to see the whole list, I think some of the more esoteric formats are even more interesting for being unusual.
I'll be releasing two formats in demos and games presently you may want to add to the list. Double resolution retina only format that only works on CRT and MBR Motion Blur Reduction format.
There's also an NTSC only format that bears mentioning:
http://RelationalFramework.com/Paper.jpg
That's a black and white image with about 10 colors from a computer art contest I competed in in the 80's, it's possible to do this mode on my early breadbox model but not with later versions of the VIC-II.
A more controversial maximum phosphor image format is/was seen in my deleted screen shot for Gate Crasher Jazz Improv. It is possible to trick out the phosphor by scrolling the colors perpendicular to the direction of screen scroll. |
| |
ccr
Registered: May 2002
Posts: 26 |
Quote: I'm starting to think about "better" ways to categorise images on C64... and whether images just need multiple toggles/options for different things. Eg.:-
Image: Picture, Logo, Font
Type: Bitmap, CharSet, PETSCII, other?
Colour Mode (Main Screen): HiRes, MultiColor, FLI, Mixed?, Other
Interlace: 1 frame, 2 frames, more?
On-Screen Sprites: no/yes
Top/Bottom Border Sprites: no/yes
Side Border Sprites: no/yes
Rasters: no/yes
Multi-Screen: Horizontal, Vertical, Diagonal 1x1 scroll, Diagonal 2x1 scroll, Large, etc..?
Animated: no/yes
Other: .. option to write notes here
^^ there's probably even more than that.
That feels like a lot.. is it overkill? Is it useful? Is it even possible to determine all these things for (currently) ~16,000 images. For regular MC and HiRes, I can add code to my toolset to find these, along with marking which images extend outside of the regular screen area (which can be a sign of rasters, sprites, or just a bad screenshot).
Is any of this even useful..? Maybe I should only be caring about the mass-market formats and just calling the others "extended"?
I'd probably separate FLI from "colour mode", because there are both hires and MC FLI, and FLI on every 1/2/4 lines etc.
Also I think DrazLace (e.g. 1 frame multicolor 1-pixel x-scroll wiggle) style interlace versus some others that do not do the x-scroll wiggle are different sub-categories.
On the implementation side, it'd probably be best to make all these attributes "tags". And perhaps create a list of common formats that contain specific set of tags, e.g. typical paint programs that produce certain format. Of course nowadays many use some custom code etc so .. dunno.
Personally I find this kind of metadata interesting, although I can certainly understand that it can be a lot of effort to input and/or maintain. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
I'd probably only make a difference between "native" formats (Koala/Hires/Charset) and tag everything else as "non standard" (or whatever). Because i really don't care about fancy formats anymore, and find regular Koalas much more impressive. YMMV :) |
| |
Deev
Registered: Feb 2002
Posts: 206 |
I quite like the idea of such detailed info if you can write tools to work it out.
Instead of colour mode, I think it would be good to have "pixel type" for hires or multicolour. Then I like what Groepaz is saying about native versus non-standard. I feel like non-standard is perhaps enough as opposed to trying to name every brand of FLI. |
| |
Joe
Registered: Apr 2002
Posts: 229 |
Agree. Non-standard should be better than explaining all this and that. One can only listen to it to recall a novel by Thomas Bernhard. ;D
After his many pages however, maybe there will be questions on this and that, of course... |
| |
Joe
Registered: Apr 2002
Posts: 229 |
No, seriously, of course it would be dead serious (listening to Thomas Bernhards repetitions), to actually have all those very dedicated differences of split modes named. That was half of the c64-scenes criteria Afterall from late 1980: ies onwards anyway with dimitives.
Just imagine how they sound:
“rasterlinedbitmapwithoverlayedhiresspriteschangedeverysecondrasterfortheghost byteoverlay”. :D |
| |
Raistlin
Registered: Mar 2007
Posts: 680 |
"rasterlinedbitmapwithoverlayedhiresspriteschangedeverysecondrasterfortheghost byteoverlay"
OK, i've added that one. But shortened to RLBWOHSCESRFTGBO to make it easy to remember.
What are people's thoughts on IFLI nowadays I wonder..? Did it ever really look good on C64 CRT? It seemed to be everywhere in the early 90s, all the top party graphics seemed to use it ... and nowadays there just seem to be a small handful of people using it. Those 90s GFX -really- looked like bad converts in many cases, too.. what were people thinking? Were all the proper pixel artists sleeping..? |
| |
Joe
Registered: Apr 2002
Posts: 229 |
The interlace modes actually looked quite nice on a real setup back then. Horrible on the emulator! |
| |
rexbeng
Registered: Aug 2012
Posts: 37 |
Edit: Ah, I might have posted this in the (slightly) wrong thread. Mods, feel free to delete. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:The interlace modes actually looked quite nice on a real setup back then. Horrible on the emulator!
I don't agree with that - at all. Not as a generic statement anyway. There have been LOTS of interlace pictures that were a terrible flickering mess, and the only reason for why they rated high in compos were the slow and crappy projectors of that time, which hide that fact.
And of course - a ton were just (bad) converts. Everyone did it. |
| |
Deev
Registered: Feb 2002
Posts: 206 |
Quote: Quote:The interlace modes actually looked quite nice on a real setup back then. Horrible on the emulator!
I don't agree with that - at all. Not as a generic statement anyway. There have been LOTS of interlace pictures that were a terrible flickering mess, and the only reason for why they rated high in compos were the slow and crappy projectors of that time, which hide that fact.
And of course - a ton were just (bad) converts. Everyone did it.
But bad execution and converts can exist with any graphics mode. I agree with Joe that on a CRT a well-made interlace image looks nice. |
| |
spider-j
Registered: Oct 2004
Posts: 498 |
Quoting JoeThe interlace modes actually looked quite nice on a real setup back then.
Probably even back then it was a matter of screen and taste. With my first Commodore 1802 I always found the flicker graphics annoying.
@topic: "non standard" is also future proof :-) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:I agree with Joe that on a CRT a well-made interlace image looks nice.
"well made" is the key there. That's the exception though, not the norm. Very often they are just drawn (if not straight converted) as if there is a 320x200 mode, and the result is a flickering mess. |
| |
Deev
Registered: Feb 2002
Posts: 206 |
Quote: Quote:I agree with Joe that on a CRT a well-made interlace image looks nice.
"well made" is the key there. That's the exception though, not the norm. Very often they are just drawn (if not straight converted) as if there is a 320x200 mode, and the result is a flickering mess.
If converted graphics exhibit problems that the best hand-pixelled graphics don't then blame the converter.
Images were often drawn at 320x200 on a PC, but it's easy to do this whilst also considering how the final release might look. I'd heavily anti-alias high contrast edges and most importantly test the final file and fix any trouble spots.
And even the flickering messes look better on a CRT. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
And those high contrast edges will most likely still be headache inducing. No thanks :) |
| |
Deev
Registered: Feb 2002
Posts: 206 |
Quote: And those high contrast edges will most likely still be headache inducing. No thanks :)
I'd have eliminated those :) |
| |
Raistlin
Registered: Mar 2007
Posts: 680 |
I do find screenshots on interlace images “interesting”…
So if I flicker between a full screen of white, and a full screen of white, which will “probably” be a little bit flickery… I can just upload a pic that is full screen mid-grey (0x808080). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Why not use anigif? :) |
| |
Raistlin
Registered: Mar 2007
Posts: 680 |
Hah. I of course meant black and white alternating not white and white.
AniGIF would be the way, yeah - but someone mentioned that animated GIFs are a problem on website (which is news to me)? |
| |
Jetboy
Registered: Jul 2006
Posts: 337 |
Quote: Hah. I of course meant black and white alternating not white and white.
AniGIF would be the way, yeah - but someone mentioned that animated GIFs are a problem on website (which is news to me)?
For normal animated gifs there are not much problems with them.
For using them to display interlace images, there is a problem that you cannot expect stable* framerate from them.
*it is more of a problem that they are not synchronized with your display refresh rate, and flickering will be even worse. |
