> Amstrad CPC: 160x200, 16 colours from a palette of 27 FTW!
> (alternatively 320x200, 4 colours from the same palette)

   I still have here my CPC 464 (it was my very first computer), but just
as decoration... I doubt it will still function properly.

--
jaime

Post a reply to this message

> Am 02.12.2016 um 02:03 schrieb Alain:

>>> =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
>>>> This is how POV-Ray should look on the Commodore 64! Block graphic font
>>>> in 40 by 25 characters! No image bigger than 1000 bytes!
>>>>
>>>> Retrocomputing rules! There should be a POV-Ray version for each of the
>>>> 1980s' 8-bit classic machines!
>>>
>>> Apple II: 280 x 192 (effective color resolution 140 x 192), 6 colors
>>>
>>
>> It have two graphic modes, low res and high res.
>> You describe the hires mode.
>> Low res is 40 x 48 in 16 colours.
>
> Sounds like an abused text mode to me (40x24 characters, using 2-block
> graphic characters and per-character foreground/background colours).
>

some text into the graphic area and actually change the graphic, or plot 
some dots into your text to get some weird changes in the displayed 
text. Bits 0-3 stood for the bottom part and bits 4-7 for the top part.
As the text was strictly black and white, upper case only, there was no 
foreground/background play. Text could be writen in normal (white on 
black), inverse and flash, or blink mode. Inverse was triggered by 
turning bit 7 on, and flash, IIRC, with bit 7 off and bit 6 on, but not 
for punctuation and special characters.

I still have my Apple ][+ 48K, with all it's documentation.


Alain

Post a reply to this message

On 2016/12/01 09:28 PM, Cousin Ricky wrote:
> =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
>> This is how POV-Ray should look on the Commodore 64! Block graphic font
>> in 40 by 25 characters! No image bigger than 1000 bytes!
>>
>> Retrocomputing rules! There should be a POV-Ray version for each of the
>> 1980s' 8-bit classic machines!
>
> Apple II: 280 x 192 (effective color resolution 140 x 192), 6 colors
>
> TRaSh 80: 80 x 24 (IIRC), black and white
>
> IBM PC-XT with CGA: 320 x 200, 4 colors unevenly distributed on the color wheel
>
> P.S.  Examining the IBM CGA color selections, it was clear that it was designed
> for engineering shortcuts rather than for the end user.  This would not be the
> first time IBM chose an engineering shortcut over utility: their RANDU
> pseudorandom number generator was a clever hack that saved many CPU cycles, and
> churned out a stream that was horrifyingly non-random, even by LCG standards.
> (Imagine running a simulation on that system, getting it published in a
> peer-reviewed scientific journal, and then discovering that your entire study is
> utterly worthless because some engineer over at IBM cleverly solved the wrong
> problem.)
>
>


palette of 8 (black, blue, red, magenta, green, cyan, yellow and white). 
Additionally, the entire attribute block may be designated as 'bright', 
resulting in a total of 15 possible colours (because both bright and 
dark black is the same color #000000).

-- 
________________________________________

-Nekar Xenos-

Post a reply to this message

On 12/01/2016 12:27 PM, clipka wrote:
> Am 01.12.2016 um 20:28 schrieb Cousin Ricky:
>> =?UTF-8?Q?J=c3=b6rg_=22Yadgar=22_Bleimann?= <yaz### [at] gmxde> wrote:
>>> This is how POV-Ray should look on the Commodore 64! Block graphic font
>>> in 40 by 25 characters! No image bigger than 1000 bytes!
>>>
>>> Retrocomputing rules! There should be a POV-Ray version for each of the
>>> 1980s' 8-bit classic machines!
>>
>> Apple II: 280 x 192 (effective color resolution 140 x 192), 6 colors
>>
>> TRaSh 80: 80 x 24 (IIRC), black and white
> (According to Wikipedia it was 128x48. Alternatively, 64x16 "greyscale"
> using characters.)
>
> Amstrad CPC: 160x200, 16 colours from a palette of 27 FTW!
> (alternatively 320x200, 4 colours from the same palette)
>
> I still have one of those buggers at home, including some RAM expansion
> and an EPROM board, for a whopping 512+48 kB of usable physical RAM and
> about 128 kB of hard-wired software, so it might actually have the
> capacity to run a (arguably fairly limited) port of our famous
> raytracing software. Don't expect any renders to finish before the
> zombie apocalypse hits though ;)
>
> (Also, burning the software into a set of EPROMS might actually be the
> only reasonable way to get it into the computer; it doesn't have
> anything in terms of standardized external interfaces.)
>
>> IBM PC-XT with CGA: 320 x 200, 4 colors unevenly distributed on the color wheel
>
> PC-XT doesn't cout; it's a 16 bit system, and therefore far too advanced
> to run interesting software.
>

Then there was the Zenith Z-100 (or H-100 for the Heathkit version) — 640 x 225, 8
colors, IIRC.

I wrote a graphics library for it in C for my own use.  An interesting challenge —
the way the 
graphics were implemented was WEIRD!  The three R, B, B planes were separate 64K 8080
segments, 
and it used this memory in a non-contiguous manner.  Lots of fun to work out with the
very 
limited documentation provided.  But I did end up with a usable C library.   :-)

-- 
      -=- Larry -=-

Post a reply to this message

On 12/02/2016 08:15 PM, Larry Hudson wrote:
>  The three R, B, B planes were separate 64K 8080 segments,
Oops:                                        8086

-- 
      -=- Larry -=-

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> (many things)

I agree with he principle wholeheartedly; I nearly always prototype complex
things in an atomic fashion once I hash out the models mentally, in order
to sanity check my work.

I do the same when extricating legacy software algorithms from the
festering bulk from whence they originate.

Once you separate the routines which are responsible for doing the work
from whatever horrific matrix of septic horrors and sad excuses for OO
design patterns within which they were entombed, you are then free to
implement a plugin based architecture.

At my current place of employment I wrote a sort of meta framework.

Typically I use interface driven design with a pair of interfaces which
describe the module in question:
Lazy<IFooPlugin, IFooPluginMetadata>

Then I use MEF and a number of design patterns that allow me to represent
arbitrarily complex hierarchical relationships and access any given subset
in O(1) time, due to the interface pairs existing in a concurrent
collection and the hierarchy relationships enforced by interface.

Long story short you end up with a strongly typed system that supports
backwards compatibility, dynamic plugin loading and hosting, the ability to
compose functionality, versioning, business logic tracking and execution
tree reproduction for rerunning records, on the fly extensibility without
recompilation, etc..

With the WCF plugins that run on the same framework, you have dynamic
content type handling with no work required by the dev to support it, you
just decorate your service method, all the capabilities of the above,
dynamic REST/SOAP support, spooling of services based on load, across
servers....no hardcoded URIs but instead you request one and if an instance
exists that meets your spooling criteria you get the URI otherwise it
spools it...new servers can be stood up in under 20m and they immediately
become part of the global pool for load balancing on their own.

And more.

I wrote an extension to my framework that finds all plugins of the same I/O
type and loads them in a UI like Visio but node based, so you can compose
new programs from deployed plugins as easily as building a flow chart. It
makes an XML file that goes to the server, the UI host reads it and creates
a UI for input, and voila, business users can compose new apps from extant
plugins with no coding knowledge, letting them use the plugins written by
any BU and thus save time and testing and each new plugin benefits all
BUs...it uses dynamic generation of Func<> behind the scenes and chains a
call stack together with them using lambdas and TPL.

It is actually incredibly stable and fast as heck. :)

But I digress...my point was I guess to illustrate my love of well designed
code and systems architecture. :)

Like you have mentioned, some sort of truly modular architecture can be
implemented for Pov, where all parts can be replaced and new modules can be
dynamically inserted into the call stack of all parts without recompilation
so we basically have full composition capabilities via polymorphism, using
CoR, strategy, decorator, (and others).

Throw a nice node editor in there and we'll be in business. :-D

Folks will be able to add new algos for rendering pipeline, effects, domain
scripting languages and essentially any and everything.

Obviously the easier it is to do stuff like that the more likely it is
folks will in fact do it, which would be awesome.

Ian

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> BTW, here's a demonstration of why I think general-purpose programming
> languages are ill-suited for scene description:
> 

You could be really malevolent and make people use Brainfuck as an SDL.

<evil grin>

Ian

Post a reply to this message

Am 03.12.2016 um 16:11 schrieb [GDS|Entropy]:
> clipka <ano### [at] anonymousorg> wrote:
>> (many things)
> 
> (many other things)
> 
> But I digress...

You don't say! ;D

> (yet some more things)
> 
> Folks will be able to add new algos for rendering pipeline, effects, domain
> scripting languages and essentially any and everything.

Indeed. Though I would be happy enough if for starters this could be
done at compile-time.

If some day folks studying computer graphics at Cornell would be
introduced to the various raytracing approaches by letting them toy
around with POV-Ray, and a typical homework assignment would be to
shuffle the basic building blocks of POV-Ray (which uses so-called
backward ray tracing) to turn it into a forward ray tracer just for
giggles (while still retaining its capability to render arbitrary
POV-Ray scenes of course), that would be enough to make my day.

Post a reply to this message

Nekar Xenos <nek### [at] gmailcom> wrote:
>

> palette of 8 (black, blue, red, magenta, green, cyan, yellow and white).
> Additionally, the entire attribute block may be designated as 'bright',
> resulting in a total of 15 possible colours (because both bright and
> dark black is the same color #000000).

You know, I can imagine how good that must have been, because you reminded me of
the Timex Sinclair 1000, my first computer. Only B&W.
Seen a story about Spectrum Next, retro revival thing. Don't know if I could get
back into that stuff, although I do still have that TS1000 proudly displayed on
a bookshelf.

Bob

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Because let's face it: All we really need is a bare-bones render engine.
> We'll hack in the scene description in C++, and re-compile the binary
> every time we make a change. And who needs fancy image output when we
> can have a text mode preview?
>
> And guess what: It works! YAY! :D
>

You know, that's basically what happens with GPU-based renderers. Speaking of
which, would this make porting to OpenCL easier?

Post a reply to this message