Hi folks,

another variant of POV-Ray has seen the light of day. Please welcome...
(Ta-da!)

    MiniPOV
    =======

A truly minimalistic version of POV-Ray that works without all the stuff
nobody really needs: The Virtual Front-End module, the front-end module,
the message-massing layer, the user-defined functions virtual machine,
the back-end thread control module -- heck, even the parser had to go.

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


There's a serious background to this though: That sorry little excuse of
a renderer will serve as a testbed to find out how successful I've been
in separating POV-Ray's modules. With the project set up entirely from
scratch, all it uses from the official projects is the source code of
the base module and core render engine module.

Turns out the core module is already better than I had feared. Still, it
has highlighted various issues that still need sorting out -- mostly
expected (such as failure to set various default values upon object
construction), but a few I did not expect, like some compile-time config
settings that don't come with defaults.

Post a reply to this message

Attachments:
Download 'minipov.png' (9 KB)

Preview of image 'minipov.png'

> Turns out the core module is already better than I had feared. Still, it
> has highlighted various issues that still need sorting out -- mostly
> expected (such as failure to set various default values upon object
> construction), but a few I did not expect, like some compile-time config
> settings that don't come with defaults.

I guess you noticed already, but your checkered plane didn't seem to 
work properly either ;-)

Post a reply to this message

Hi(gh)!

On 01.12.2016 16:07, clipka wrote:
> Hi folks,
>
> another variant of POV-Ray has seen the light of day. Please welcome...
> (Ta-da!)
>
>     MiniPOV
>     =======
>
> A truly minimalistic version of POV-Ray that works without all the stuff
> nobody really needs: The Virtual Front-End module, the front-end module,
> the message-massing layer, the user-defined functions virtual machine,
> the back-end thread control module -- heck, even the parser had to go.
>
> 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

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!

See you in Khyberspace!

Yadgar

Post a reply to this message

Am 01.12.2016 um 18:16 schrieb scott:
>> Turns out the core module is already better than I had feared. Still, it
>> has highlighted various issues that still need sorting out -- mostly
>> expected (such as failure to set various default values upon object
>> construction), but a few I did not expect, like some compile-time config
>> settings that don't come with defaults.
> 
> I guess you noticed already, but your checkered plane didn't seem to
> work properly either ;-)

Bah - checkered planes are for wussies. I'm much more worried about the
gamma handling... ;)

Post a reply to this message

Attachments:
Download 'minipov.png' (17 KB)

Preview of image 'minipov.png'

=?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.)

Post a reply to this message

Am 01.12.2016 um 20:26 schrieb clipka:
> Am 01.12.2016 um 18:16 schrieb scott:
>>> Turns out the core module is already better than I had feared. Still, it
>>> has highlighted various issues that still need sorting out -- mostly
>>> expected (such as failure to set various default values upon object
>>> construction), but a few I did not expect, like some compile-time config
>>> settings that don't come with defaults.
>>
>> I guess you noticed already, but your checkered plane didn't seem to
>> work properly either ;-)
> 
> Bah - checkered planes are for wussies. I'm much more worried about the
> gamma handling... ;)

BTW, here's a demonstration of why I think general-purpose programming
languages are ill-suited for scene description:

	pov::Sphere* pSphere(new pov::Sphere);
	pSphere->Center = pov::Vector3d(0,0,0);
	pSphere->Radius = 1;
	pSphere->Texture = new pov::TEXTURE();
	pSphere->Texture->Type = pov::PLAIN_PATTERN; // TODO shouldn't need this
	pSphere->Texture->Pigment = new pov::PIGMENT();
	pSphere->Texture->Pigment->Type = pov::PLAIN_PATTERN; // TODO shouldn't
need this
	pSphere->Texture->Pigment->colour =
pov_base::TransColour(pov_base::MathColour(1));
	pSphere->Texture->Finish = new pov::FINISH();
	pSphere->Texture->Finish->Ambient = pov_base::MathColour(0.05);
	pSphere->Texture->Finish->Diffuse = 0.1;
	pSphere->Texture->Finish->Brilliance = 1.0;
	pSphere->Texture->Finish->BrillianceAdjust = 1.0;
	pSphere->Texture->Finish->Specular = 2.0;
	pSphere->Texture->Finish->Roughness = 100;
	pSphere->Texture->Finish->Reflection_Min = pov::MathColour(0.0);
	pSphere->Texture->Finish->Reflection_Max = pov::MathColour(1.0);
	pSphere->Texture->Finish->Reflect_Exp = 1.0;
	pSphere->Texture->Finish->Reflect_Metallic = true;
	pSphere->Texture->Finish->Reflection_Fresnel = false;
	pScene->objects.push_back(pSphere);

	pov::Plane* pPlane(new pov::Plane);
	pPlane->Normal_Vector = pov::Vector3d(0, 1, 0).normalized();
	pPlane->Distance = 1;
	pPlane->Texture = new pov::TEXTURE();
	pPlane->Texture->Type = pov::PLAIN_PATTERN;
	pPlane->Texture->Pigment = new pov::PIGMENT();
	pPlane->Texture->Pigment->Type = pov::GENERIC_PATTERN;
	pPlane->Texture->Pigment->pattern = pov::PatternPtr(new
pov::CheckerPattern);
	pov::ColourBlendMap* pCheckerMap(new pov::ColourBlendMap);
	pov::ColourBlendMapEntry CheckerMapEntry;
	CheckerMapEntry.value = 0;
	CheckerMapEntry.Vals = pov::ToTransColour(pov_base::RGBFTColour(0, 0,
0, 0, 0));
	pCheckerMap->Blend_Map_Entries.push_back(CheckerMapEntry);
	CheckerMapEntry.value = 1;
	CheckerMapEntry.Vals = pov::ToTransColour(pov_base::RGBFTColour(1, 1,
1, 0, 0));
	pCheckerMap->Blend_Map_Entries.push_back(CheckerMapEntry);
	pPlane->Texture->Pigment->Blend_Map =
pov::GenericPigmentBlendMapPtr(pCheckerMap);
	pPlane->Texture->Finish = new pov::FINISH();
	pPlane->Texture->Finish->Ambient = pov_base::MathColour(0.1);
	pPlane->Texture->Finish->Diffuse = 0.7;
	pPlane->Texture->Finish->Brilliance = 1.0;
	pPlane->Texture->Finish->BrillianceAdjust = 1.0;
	pPlane->Texture->Finish->Specular = 0.0;
	pPlane->Texture->Finish->Roughness = 100;
	pScene->objects.push_back(pPlane);

	pov::LightSource* pLight(new pov::LightSource);
	pLight->Center = pov::Vector3d(-1, 1, 1).normalized() * 100;
	pLight->colour = pov_base::MathColour(0.7);
	pLight->index = 0; // TODO shouldn't need this
	pScene->lightSources.push_back(pLight);

Yup, that's just a plain simple RSOCP scene.

Post a reply to this message

On 12/1/2016 2:37 PM, clipka wrote:
> Am 01.12.2016 um 20:26 schrieb clipka:
>> Am 01.12.2016 um 18:16 schrieb scott:
>>>> Turns out the core module is already better than I had feared. Still, it
>>>> has highlighted various issues that still need sorting out -- mostly
>>>> expected (such as failure to set various default values upon object
>>>> construction), but a few I did not expect, like some compile-time config
>>>> settings that don't come with defaults.
>>>
>>> I guess you noticed already, but your checkered plane didn't seem to
>>> work properly either ;-)
>>
>> Bah - checkered planes are for wussies. I'm much more worried about the
>> gamma handling... ;)
>
> BTW, here's a demonstration of why I think general-purpose programming
> languages are ill-suited for scene description:
>
> 	pov::Sphere* pSphere(new pov::Sphere);
> 	pSphere->Center = pov::Vector3d(0,0,0);
> 	pSphere->Radius = 1;
> 	pSphere->Texture = new pov::TEXTURE();
> 	pSphere->Texture->Type = pov::PLAIN_PATTERN; // TODO shouldn't need this
> 	pSphere->Texture->Pigment = new pov::PIGMENT();
> 	pSphere->Texture->Pigment->Type = pov::PLAIN_PATTERN; // TODO shouldn't
> need this
> 	pSphere->Texture->Pigment->colour =
> pov_base::TransColour(pov_base::MathColour(1));
> 	pSphere->Texture->Finish = new pov::FINISH();
> 	pSphere->Texture->Finish->Ambient = pov_base::MathColour(0.05);
> 	pSphere->Texture->Finish->Diffuse = 0.1;
> 	pSphere->Texture->Finish->Brilliance = 1.0;
> 	pSphere->Texture->Finish->BrillianceAdjust = 1.0;
> 	pSphere->Texture->Finish->Specular = 2.0;
> 	pSphere->Texture->Finish->Roughness = 100;
> 	pSphere->Texture->Finish->Reflection_Min = pov::MathColour(0.0);
> 	pSphere->Texture->Finish->Reflection_Max = pov::MathColour(1.0);
> 	pSphere->Texture->Finish->Reflect_Exp = 1.0;
> 	pSphere->Texture->Finish->Reflect_Metallic = true;
> 	pSphere->Texture->Finish->Reflection_Fresnel = false;
> 	pScene->objects.push_back(pSphere);
>
> 	pov::Plane* pPlane(new pov::Plane);
> 	pPlane->Normal_Vector = pov::Vector3d(0, 1, 0).normalized();
> 	pPlane->Distance = 1;
> 	pPlane->Texture = new pov::TEXTURE();
> 	pPlane->Texture->Type = pov::PLAIN_PATTERN;
> 	pPlane->Texture->Pigment = new pov::PIGMENT();
> 	pPlane->Texture->Pigment->Type = pov::GENERIC_PATTERN;
> 	pPlane->Texture->Pigment->pattern = pov::PatternPtr(new
> pov::CheckerPattern);
> 	pov::ColourBlendMap* pCheckerMap(new pov::ColourBlendMap);
> 	pov::ColourBlendMapEntry CheckerMapEntry;
> 	CheckerMapEntry.value = 0;
> 	CheckerMapEntry.Vals = pov::ToTransColour(pov_base::RGBFTColour(0, 0,
> 0, 0, 0));
> 	pCheckerMap->Blend_Map_Entries.push_back(CheckerMapEntry);
> 	CheckerMapEntry.value = 1;
> 	CheckerMapEntry.Vals = pov::ToTransColour(pov_base::RGBFTColour(1, 1,
> 1, 0, 0));
> 	pCheckerMap->Blend_Map_Entries.push_back(CheckerMapEntry);
> 	pPlane->Texture->Pigment->Blend_Map =
> pov::GenericPigmentBlendMapPtr(pCheckerMap);
> 	pPlane->Texture->Finish = new pov::FINISH();
> 	pPlane->Texture->Finish->Ambient = pov_base::MathColour(0.1);
> 	pPlane->Texture->Finish->Diffuse = 0.7;
> 	pPlane->Texture->Finish->Brilliance = 1.0;
> 	pPlane->Texture->Finish->BrillianceAdjust = 1.0;
> 	pPlane->Texture->Finish->Specular = 0.0;
> 	pPlane->Texture->Finish->Roughness = 100;
> 	pScene->objects.push_back(pPlane);
>
> 	pov::LightSource* pLight(new pov::LightSource);
> 	pLight->Center = pov::Vector3d(-1, 1, 1).normalized() * 100;
> 	pLight->colour = pov_base::MathColour(0.7);
> 	pLight->index = 0; // TODO shouldn't need this
> 	pScene->lightSources.push_back(pLight);
>
> Yup, that's just a plain simple RSOCP scene.
>


Can't you use shorthand object notation?

pPlane =
{
	Texture =
	{
		Finish =
		{
			Ambient = pov_base::MathColour(0.1),
			Diffuse = 0.7,
			Brilliance = 1.0,
		}
	}
}

And so on...

Mike

Post a reply to this message

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.

Post a reply to this message

Am 01.12.2016 um 21:24 schrieb Mike Horvath:
> On 12/1/2016 2:37 PM, clipka wrote:
>> Am 01.12.2016 um 20:26 schrieb clipka:
>>> Am 01.12.2016 um 18:16 schrieb scott:
>>>>> Turns out the core module is already better than I had feared.
>>>>> Still, it
>>>>> has highlighted various issues that still need sorting out -- mostly
>>>>> expected (such as failure to set various default values upon object
>>>>> construction), but a few I did not expect, like some compile-time
>>>>> config
>>>>> settings that don't come with defaults.
>>>>
>>>> I guess you noticed already, but your checkered plane didn't seem to
>>>> work properly either ;-)
>>>
>>> Bah - checkered planes are for wussies. I'm much more worried about the
>>> gamma handling... ;)
>>
>> BTW, here's a demonstration of why I think general-purpose programming
>> languages are ill-suited for scene description:
>>
>>     pov::Sphere* pSphere(new pov::Sphere);
>>     pSphere->Center = pov::Vector3d(0,0,0);
>>     pSphere->Radius = 1;
>>     pSphere->Texture = new pov::TEXTURE();
>>     pSphere->Texture->Type = pov::PLAIN_PATTERN; // TODO shouldn't
>> need this
>>     pSphere->Texture->Pigment = new pov::PIGMENT();
>>     pSphere->Texture->Pigment->Type = pov::PLAIN_PATTERN; // TODO
>> shouldn't
>> need this
>>     pSphere->Texture->Pigment->colour =
>> pov_base::TransColour(pov_base::MathColour(1));
>>     pSphere->Texture->Finish = new pov::FINISH();
>>     pSphere->Texture->Finish->Ambient = pov_base::MathColour(0.05);
>>     pSphere->Texture->Finish->Diffuse = 0.1;
>>     pSphere->Texture->Finish->Brilliance = 1.0;
>>     pSphere->Texture->Finish->BrillianceAdjust = 1.0;
>>     pSphere->Texture->Finish->Specular = 2.0;
>>     pSphere->Texture->Finish->Roughness = 100;
>>     pSphere->Texture->Finish->Reflection_Min = pov::MathColour(0.0);
>>     pSphere->Texture->Finish->Reflection_Max = pov::MathColour(1.0);
>>     pSphere->Texture->Finish->Reflect_Exp = 1.0;
>>     pSphere->Texture->Finish->Reflect_Metallic = true;
>>     pSphere->Texture->Finish->Reflection_Fresnel = false;
>>     pScene->objects.push_back(pSphere);
>>
>>     pov::Plane* pPlane(new pov::Plane);
>>     pPlane->Normal_Vector = pov::Vector3d(0, 1, 0).normalized();
>>     pPlane->Distance = 1;
>>     pPlane->Texture = new pov::TEXTURE();
>>     pPlane->Texture->Type = pov::PLAIN_PATTERN;
>>     pPlane->Texture->Pigment = new pov::PIGMENT();
>>     pPlane->Texture->Pigment->Type = pov::GENERIC_PATTERN;
>>     pPlane->Texture->Pigment->pattern = pov::PatternPtr(new
>> pov::CheckerPattern);
>>     pov::ColourBlendMap* pCheckerMap(new pov::ColourBlendMap);
>>     pov::ColourBlendMapEntry CheckerMapEntry;
>>     CheckerMapEntry.value = 0;
>>     CheckerMapEntry.Vals = pov::ToTransColour(pov_base::RGBFTColour(0, 0,
>> 0, 0, 0));
>>     pCheckerMap->Blend_Map_Entries.push_back(CheckerMapEntry);
>>     CheckerMapEntry.value = 1;
>>     CheckerMapEntry.Vals = pov::ToTransColour(pov_base::RGBFTColour(1, 1,
>> 1, 0, 0));
>>     pCheckerMap->Blend_Map_Entries.push_back(CheckerMapEntry);
>>     pPlane->Texture->Pigment->Blend_Map =
>> pov::GenericPigmentBlendMapPtr(pCheckerMap);
>>     pPlane->Texture->Finish = new pov::FINISH();
>>     pPlane->Texture->Finish->Ambient = pov_base::MathColour(0.1);
>>     pPlane->Texture->Finish->Diffuse = 0.7;
>>     pPlane->Texture->Finish->Brilliance = 1.0;
>>     pPlane->Texture->Finish->BrillianceAdjust = 1.0;
>>     pPlane->Texture->Finish->Specular = 0.0;
>>     pPlane->Texture->Finish->Roughness = 100;
>>     pScene->objects.push_back(pPlane);
>>
>>     pov::LightSource* pLight(new pov::LightSource);
>>     pLight->Center = pov::Vector3d(-1, 1, 1).normalized() * 100;
>>     pLight->colour = pov_base::MathColour(0.7);
>>     pLight->index = 0; // TODO shouldn't need this
>>     pScene->lightSources.push_back(pLight);
>>
>> Yup, that's just a plain simple RSOCP scene.
>>
> 
> 
> Can't you use shorthand object notation?
> 
> pPlane =
> {
>     Texture =
>     {
>         Finish =
>         {
>             Ambient = pov_base::MathColour(0.1),
>             Diffuse = 0.7,
>             Brilliance = 1.0,
>         }
>     }
> }
> 
> And so on...

/If/ the language in question supports such a notation, it typically
gets you as far as the point where you want to apply a series of
transformations.

Also, "pov_base::MathColour(0.1)" is a very cumbersome way of writing
"rgb 0.1", and "pov::Vector3d(-1,1,1)" is a very cumbersome way of
writing "<-1,1,1>".

I agree that C++ is probably one of the more ill-suited languages for an
SDL, but other general-purpose languages all suffer from similar
problems to some extent.

Post a reply to this message

On 12/1/2016 8:27 PM, clipka wrote:
> (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.)

How about using a lump hammer and two 12" shifting spanners?
That usually solves most problems. ;)


-- 

Regards
     Stephen

Post a reply to this message

Am 01.12.2016 um 22:09 schrieb Stephen:
> On 12/1/2016 8:27 PM, clipka wrote:
>> (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.)
> 
> How about using a lump hammer and two 12" shifting spanners?
> That usually solves most problems. ;)

That certainly /gets rid/ of most problems. Doesn't necessarily produce
a /solution/ though ;)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 01.12.2016 um 20:28 schrieb Cousin Ricky:
> > 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.

Oh, yeah.  Cramming those 16 bits through an 8 bit bus must have confused me.

Their color selection sucked anyway; it had me pining for the Apple II.

Post a reply to this message

in news:58403cc6@news.povray.org clipka wrote:

>     MiniPOV
>     =======
Years of modeling with exquisite exlusive tools:

      |~
     (oo)
   _/ \/ \_______
  ( \    / ) ) ) )
  '\')  ('/'/'/'/'
_____\/\/______
_____{}{}___s7.
   /||  |\\  

      |~     ~|  
     (..)   (..)
     -\/-   _\/_
    ()  () ()  ()
_____\/\/___\/\/_____
_____{}{}___{}{}__s7.

Ingo

Post a reply to this message

Am 01.12.2016 um 20:26 schrieb clipka:
> Am 01.12.2016 um 18:16 schrieb scott:
>>> Turns out the core module is already better than I had feared. Still, it
>>> has highlighted various issues that still need sorting out -- mostly
>>> expected (such as failure to set various default values upon object
>>> construction), but a few I did not expect, like some compile-time config
>>> settings that don't come with defaults.
>>
>> I guess you noticed already, but your checkered plane didn't seem to
>> work properly either ;-)
> 
> Bah - checkered planes are for wussies. I'm much more worried about the
> gamma handling... ;)
> 

Obviously I couldn't rest until the gamma handling was fixed.

Post a reply to this message

Attachments:
Download 'minipov.png' (27 KB)

Preview of image 'minipov.png'

On 12/01/2016 08:28 PM, Cousin Ricky wrote:

> 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

    My first computer have only 8 red leds as display,
    really nice setup for some k2000 effects...

Post a reply to this message

On 12/1/2016 9:24 PM, clipka wrote:
> Am 01.12.2016 um 22:09 schrieb Stephen:
>> On 12/1/2016 8:27 PM, clipka wrote:
>>> (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.)
>>
>> How about using a lump hammer and two 12" shifting spanners?
>> That usually solves most problems. ;)
>
> That certainly /gets rid/ of most problems. Doesn't necessarily produce
> a /solution/ though ;)
>

Maybe not but who is going to around to complain? ;)

-- 

Regards
     Stephen

Post a reply to this message

On 12/1/2016 11:51 PM, Stephen wrote:
> Maybe not but who is going to *Be* around to complain? ;)


-- 

Regards
     Stephen

Post a reply to this message

Le 16-12-01 à 14:28, Cousin Ricky a écrit :
> =?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.

Post a reply to this message

Am 02.12.2016 um 02:03 schrieb Alain:
> Le 16-12-01 à 14:28, Cousin Ricky a écrit :
>> =?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).

Post a reply to this message

On 2016-12-01 10:57 PM (-4), clipka wrote:
> Am 02.12.2016 um 02:03 schrieb Alain:
>> Le 16-12-01 à 14:28, Cousin Ricky a écrit :
>>> 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).

That's effectively what it was, although I can't remember if that was 
literally the case.  Either way, it was handled transparently by the 
graphics commands.

The original Apple II used a 6 bit ASCII subset, so there was plenty of 
room to play around with the extra bits.  The Apple IIe used the full 7 
bit ASCII set, but I'm less familiar with that model.

Post a reply to this message

Am 02.12.2016 um 04:29 schrieb Cousin Ricky:
> On 2016-12-01 10:57 PM (-4), clipka wrote:
>> Am 02.12.2016 um 02:03 schrieb Alain:
>>> Le 16-12-01 à 14:28, Cousin Ricky a écrit :
>>>> 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).
> 
> That's effectively what it was, although I can't remember if that was
> literally the case.  Either way, it was handled transparently by the
> graphics commands.
> 
> The original Apple II used a 6 bit ASCII subset, so there was plenty of
> room to play around with the extra bits.  The Apple IIe used the full 7
> bit ASCII set, but I'm less familiar with that model.

Ah, that brings memories to life!

Such as flipping a hardware switch to change the character set from
German to ASCII when writing program code, and later flipping back to
German when running the program.

Post a reply to this message

On 2-12-2016 0:00, clipka wrote:
> Am 01.12.2016 um 20:26 schrieb clipka:
>> Am 01.12.2016 um 18:16 schrieb scott:
>>>> Turns out the core module is already better than I had feared. Still, it
>>>> has highlighted various issues that still need sorting out -- mostly
>>>> expected (such as failure to set various default values upon object
>>>> construction), but a few I did not expect, like some compile-time config
>>>> settings that don't come with defaults.
>>>
>>> I guess you noticed already, but your checkered plane didn't seem to
>>> work properly either ;-)
>>
>> Bah - checkered planes are for wussies. I'm much more worried about the
>> gamma handling... ;)
>>
>
> Obviously I couldn't rest until the gamma handling was fixed.
>

Yes, much better indeed! How is aa coming along?

-- 
Thomas

Post a reply to this message

El 01/12/16 a las 21:27, clipka escribió:
> 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

Le 16-12-01 à 21:57, clipka a écrit :
> Am 02.12.2016 um 02:03 schrieb Alain:
>> Le 16-12-01 à 14:28, Cousin Ricky a écrit :
>>> =?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).
>
As it was using exactly the same memory space, yes. You could «print» 
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.)
>
>

ZX Spectrum: 256×192. 15 colours, only two colours may be used out of a 
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:
>
> ZX Spectrum: 256×192. 15 colours, only two colours may be used out of a
> 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