Re: 8 bit values in mode 13h?

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 10/27/03

  • Next message: Beth: "Re: What is this code doing?" 
    Date: Mon, 27 Oct 2003 01:14:49 -0000

    laura fairhead wrote:
    > Anyway another idea I had was what you could do if you redraw the
    frame
    > each time, sometimes displaying some pixels as red/green/blue or
    even
    > cycling through a sub-spectrum to give the overall impression of
    more
    > colour information... sortof like error-diffusion when you are
    trying
    > to represent gray-scale on a black & white display but using the
    time
    > dimension too, might be interesting there are a lot of possibilities
    <g>

    Actually, with my "modified" version of the flame program, I
    accidentally typed in a wrong "source" location for the whole "copy it
    one pixel higher and 'average' it out" blur thing and it resulted in a
    "dithered" look somehow...not quite sure what exactly I did there,
    mind you, it was actually a bug...but, yeah, the "dithered" look
    wasn't actually at all bad...so, yeah, if you sort of used "error
    diffusion", it could be made to look really groovy...

    Mind you, another thing about the program is that it's only really
    using about 80 colours...the rest are all set to white...so, another
    possibility to attempt first might be to simply work out an algorithm
    that distributes the colours better so that all 256 are properly used
    and the palette is "maximised" (the issue here, though, is that the
    "blurring" effect tends to rapidly drop from the higher colours to the
    lower colours but then slows down...it's not quite a linear drop in
    colour and that's why the palette gets "biased" like that, I
    presume...so that it looks "linear-ish" on the screen, even though the
    "blur" effect doesn't actually move through them like that itself
    :)...

    I do like the idea of changing the palette completely to get 24-bit
    images, though...this is actually _exactly_ the sort of graphical
    trickery that used to be used on older 8-bit machines like the C64 for
    displaying tons of "sprites" and more than 4 colours on the screen (16
    colours on screen? Wow! Well, it was "Wow" in those days, anyway
    ;)...the C64's graphics chip actually had a brilliant little function
    in it that made this sort of thing easy as well as totally
    smooth...the "VIC" chip, as it was called, could be programmed to
    signal an interrupt on any scanline you specified and with clever
    re-programming of this interrupt on the fly, you could divide the
    screen up vertically in all different ways...re-using the 8 hardware
    sprites to display many more...or changing the colours to display more
    complex graphics...or even - something that'll likely be a nightmare
    on PC machines - to have the top half of the screen in a completely
    different screen mode to the bottom half (a trick often employed by
    games to have the top half in graphics for the game and then the
    "score panel" at the bottom is back into a simple text mode :)...

    I've said it before but it deserves to be said again...the vertical
    blank interrupt on PC graphics systems should never have been
    "depreciated" (IRQ 2 was the "VGA interrupt" at one point but, due to
    not being implemented on many machines, it got "pushed out", as you
    couldn't depend on it being present :)...video is something that
    really should actually be worked off interrupts rather than the
    typical PC thing of sitting in a "polling loop" waiting for the
    vertical blank to happen to smooth out the video...the old "polling
    versus interrupt-driven" arguments apply...polling wastes time that
    could be used elsewhere and seeing as we're dealing with something
    that doesn't "wait" at all (the monitor will keep refreshing whatever
    the CPU is doing :) then trying to make the "polling" more useful by
    including code for it to complete while it's waiting for a vertical
    blank is limited...it can't really be doing too much or the vertical
    blank could happen half-way through and by the time it checks, we're
    half-way down the screen...oops! ;)

    While, if interrupt-driven, then the game or demo or whatever it is
    can actually carry on doing useful work (moving the characters about
    with AI, checking the input, etc. :) and, when the vertical blank
    hits, it can jump straight into the video code...

    In fact, if you play some of the older C64 games, where the graphics
    chip _did_ have this capability then you might even be able to "feel"
    the difference...because, with interrupt-driven games, it's possible
    to, for instance, run the entire game continuously and move the
    characters when the joystick is pressed and that sort of thing and
    then only bother to update the screen with the current state of play
    when the vertical blank appears, telling you it's time to draw the
    next frame...rather than what's the more common structure - thanks to
    the lack of a reliable "vertical blank" IRQ on the PC hardware - where
    the entire game works in distinct discrete "frames" throughout...

    This is a little fussy, yes, but the human senses are able to discern
    a difference...it improves the "feel" of a game...also, with modern PC
    graphics capabilities, you could even use this to have "motion blur"
    and mad ideas like that (i.e. draw the "sprite" in between the current
    position and where it was last time the screen was drawn...but as the
    game variables update in their own time, not "video time" then that
    effect would actually work really nicely, I reckon :)...

    Plus, of course, you _could_ up the number of colours in mode 13h
    using this technique but just not as high as 24-bit colour, so that it
    works on slower machines well too...even with 30 scanlines, that's
    about 1700 colours on a mode 13h screen, which isn't bad...you could,
    for example, follow the example of some of those C64 games and the top
    three quarters of the screen uses the full 256 colours while the
    bottom quarter can also use the full 256 colours for a "score panel"
    thingy...

    Because, with that "flame" effect, there's clearly "bands",
    anyway...you know, blues and dark reds at the top, oranges and reds
    and yellows in the middle with yellows and whites at the bottom...if
    you divide it three ways like this and then give the full 256 colours
    (with some overlap as the flame doesn't divide totally cleanly :) then
    that's 768 potential colours for this particular effect...

    Which is actually a point...that's more colours than we actually have
    scanlines...we wouldn't be able to use all of those colours, in
    fact...for the flame effect specifically in mode 13h, 256 colours
    should actually be more than enough, _were_ the colours better
    distributed (as noted, only about 80 colours are actually different,
    with the rest all set to white...if we could alter the algorithm to
    space out the colour use better across the full 256 colours that
    shouldn't be greatly difficult - well, compared to "dithering",
    anyway - and should get an effect that couldn't be much improved,
    anyway :)...

    Beth :)

  • Next message: Beth: "Re: What is this code doing?"
    • Quantcast