TrueEU updated
I've posted an incremental update/bugfix to the
library. It's a correct fix of a 'hack' implemented
to fix a smearing problem with the mouse, if the mouse
was confined to a 'window', around the border of said
'window'.
Also, in the near future, since sooner would be better than
later, as per a suggestion by jiri, I will be changing
(practically) the entire library so that all of the calling
parameters will be as close as possible to EU.
Along with that change will (probably) be a redefinition of
common EU graphic commands so that for most cases of
graphics programs, you will be using the same syntax
with only the color values changing from atoms to
BGR sequences...
Programs that use pixel and line will be able to use
this mechanism as soon as TrueEU 2.0 is available.
Programs that use polygon or ellipse will be able to
operate in this way shortly after that (like TrueEU 2.1)
Additionally, polygon and ellipse (and box? and circle?)
will be able to fill with tiles/textures (on screen and
virtually, both) :)
These above additions/changes will break all prior code
developed with TrueEU versions before 2.0. This is
felt to be a necessary evil and growing pain. The future,
after doing this, promises far far easier coding and
conversion into TrueEU modes...
Virtual screen work will also be updated to include
autosensing of graphic mode, and the rearranging of
parameters to be consistent with/mimic EU graphics.
The question you may wish to ask:
"what to do with colors?"
shall be handled by the library internally.
To Wit: you make a call to pixel() with:
pixel({7,4,3},{200,350})
How does the library know if that is a set of 3 pixels
or one TrueEU pixel?
The library will examine if it is in a TrueEU mode and
act accordingly, by calling either true_pixel or the
'real' pixel for you. If you are in a TrueEU mode,
calls to pixel will be expecting BGR sequences...
"well i want this program written in 16 color mode to
be displayed in TrueEU so i can do other stuff from TrueEU
at the same time, like laser_puts, or read_targa..."
You will have a function called Trans16ToBGR (or some such
moniker) that will go thru and if a color is GREEN, it
will become TrueGreen, if it's WHITE then it will become
TrueWhite... etc... Bright isn't a problem, but Blink
could be a large big meany problem...
You would then use it like:
pixel(Trans16ToBGR({7,4,3}),{200,350})
and also, naturally, for that to work, you would need to be
in a TrueEU mode...
Programs that use palette/256 color may never be able to be
converted to TrueEU modes as ... well, palettes just don't
apply to those modes... the idea of palette can be simulated
with brute force, albeit slowly... by just capturing the
entire "actual display", and adjusting each pixel according
to some formulation, and slapping the new 'image' back
on the actual display... slow...
Another method I have been thinking over is the fact that in
256 color mode, you are accessing 256 out of a possible,
what? 128000 colors? 256000 colors?
I was thinking of a way to remap that entire spectrum
to an index list of appropriate TrueEU BGR values,
and setting a pixel based upon some formulae like:
PixelColorBGR = TrueEU_LookupTable[PixelColor][CurrentPaletteNumber]
or some such equally wild transmution/transmutation...
and you would then have something like Trans256ToBGR...
Even this won't solve palette shifting/rotating for those
cool flame and fade effects only implementable via palette
work, because of palette's *instant* transformation
of a color/pixel upon the screen...
It's already giving me a headache thinking about it :)
tis all fer now...
enjoy!--Hawke'
|
Not Categorized, Please Help
|
|
