"clipka" <nomail@nomail> wrote in message 
news:web.49ca4fd59fb46029c1f399840@news.povray.org...
>
> Oh, those pesky OOP-spoilt greenhorns! ;)
>
> When I was still young and handsome, such information would be stored in a
> separate array, like this:
>
<SNIP>

o_O'

Eew...BASIC...I'd rather learn just get it over with and Assembly (its on 
the TODO list)..

> (Yeah, those were the days! You just flipped the power switch, and your
> programming IDE would be up and running in 5 seconds... ah, modern
> technological advancement has deprived us of all that joy...)

Ubuntu will boot on a very old machine I have from the liveCD in just over 6 
times that...not that bad considering that includes GNOME.

> .... then someone invented structs (oh, well, "records" for me back then, 
> because
> I went for Turbo Pascal)...

Structs rock.

> But I'm getting a bit off topic... so back to your problem:
>
> First thing to know: No, POV SDL unfortunately doesn't have something like
> structs. Nor does it have dynamic lists. Be happy and content that you 
> don't
> have to mess around with line numbers ;)

Dynamic lists also rock.
I did mess around with BASIC back in elementary school (early/mid 80's). 
That is when I decided that I didn't like it much, and chose to avoid any 
language with Basic in the name.

Damn...maybe it would be seriously worth the effort of tracking down 
whatever code handles structs and dynamic lists and etc.. in the language 
that pov was written, and integrating that into povray with some nice SDL 
implementation. I'm more than sick of needing and not having those kinds of 
things.

http://www.haskell.org/haskellwiki/POV-Ray_SDL_project

Someone has the right idea.
They said this too: "Endless flamewars have raged over the subject of 
whether the SDL should become object-oriented."
When did THAT happen?! O_o'

This newsgroup seems rife with thoughtful discourse and quite a high SNR, 
not "endless flamewars"...

>>   #declare Array[i][0][0] = <RRand(RsA, Min, Max),RRand(RsA, Min,
>> Max),RRand(RsA, Min, Max)>;
>>   #declare Array[i][1][0] = <0,0,0>;
>>   #declare Array[i][1][1] = <0,RRand(RsA, rMin, rMax),0>;
>
> Why use a 3-dimensional array when a 2-dimensional one will do the job?

Beyond being just something that I threw together to do something like what 
I wanted, I decided that I might want to add an absurd amount of 
functionality later and that this would be the most logical way to leave my 
options open. For example I might add other related things to each of the 
dimensions, and it might be best to keep each category of data seperate.

> #declare Array[i][0] = <...>;
> #declare Array[i][1] = <0,0,0>;
> #declare Array[i][2] = <0,RRand(RsA, rMin, rMax),0>;
>
> Then, to get rid of an entry of such an array, you could use:
>
> #undef Array[i][0]
> #undef Array[i][1]
> #undef Array[i][2]

I might be able to adapt such a thing to do what I wanted in the first 
place. I guess if the following (untested) macro works, I could just call it 
once the established number of "uses" has been reached to purge the elements 
I need to.

#macro 
undefElement(Array,dim1Element,dim2Element,dim3Element,dim4Element,dim5Element)
 #local numDimensions = dimensions(Array);
 #if (numDimensions = 1)
  #undef Array[dim1Element]
 #end
 #if (numDimensions = 2)
  #undef Array[dim1Element][dim2Element]
 #end
 #if (numDimensions = 3)
  #undef Array[dim1Element][dim2Element][dim3Element]
 #end
 #if (numDimensions = 4)
  #undef Array[dim1Element][dim2Element][dim3Element]][dim4Element]
 #end
 #if (numDimensions = 5)
  #undef 
Array[dim1Element]][dim2Element][dim3Element]][dim4Element][dim5Element]
 #end
#end

> and check for #ifdef(Array[i][0]) when you loop through the array.
>
> I guess that's as close as you can get to what you want.

So I wasn't too far off from what I was looking for. That is a good sign. 
:-)
I suppose I could just redefine the wiped element with interpolated 
vectors...or something...should I need to, by using the above macros 
functionally mirror image.

As a side note, why in the nine hells aren't there Round and VRound macros 
in pov to start with??
They seem kind of useful to just have been left out...then again...so do 
structs, enums, custom types, multi-datatype arrays, type casting, type 
conversion and list<T>'s...

More of a side note....it would be cool to create a set of macros which 
emulated basic circuit components, so that one could produce such an act of 
irony as a properly functioning raytraced circuit...
Hmm....to make a macro which can produce accurate semiconductor curves.... 
Gah! I need to finish this damn macro suite...no new projects! :-p

ian

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> > (GOSUB, eww. PROC was the only way forwards :-) )
>
> Not on the Amstrad CPC 6128 I was toying around with ;)
>
> Locomotive Basic 1.1 ((C) 1985 if I remember correctly...)

I suspected it probably wasn't Acorn BASIC. The interpreter didn't worry about
LETs, and didn't say Ready at every prompt. Definitely a contemporary though!

> I ended up writing a parser for the old Sinix Basic code that would
> auto-generate a VBA module, and a library of subroutines that would simulate
> the Sinix Basic's formatted input, output and file access functions with all
> their peculiarities...

Good job.

Whoops, this is veering a little off-topic now... :)

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> Damn...maybe it would be seriously worth the effort of tracking down
> whatever code handles structs and dynamic lists and etc.. in the language
> that pov was written, and integrating that into povray with some nice SDL
> implementation. I'm more than sick of needing and not having those kinds of
> things.

If I wasn't working on various other pieces of POV code, that's what I'd
probably be doing right now...

(Note however that "in the language that pov was written" would mean C until
only very recently, so nowhere close to dynamic lists whatsoever; and structs,
although C does have them, would have to be represented internally using
"arrays of members" as it were, because C can't create new structs at runtime.)

> http://www.haskell.org/haskellwiki/POV-Ray_SDL_project

Yargh! Vade! >_<

> Beyond being just something that I threw together to do something like what
> I wanted, I decided that I might want to add an absurd amount of
> functionality later and that this would be the most logical way to leave my
> options open. For example I might add other related things to each of the
> dimensions, and it might be best to keep each category of data seperate.

Again, too much OO thinking for POV SDL. You can't store separate things in the
multiple dimensions of such an array anyway; and if one of your "subsections"
would need more elements, you'd need to add more elements to the other
"subsections" as well... not too bright.

But what you might want to do is:

#declare POINT  = 0;
#declare COUNT  = 1;
#declare RANDOM = 2;

#declare Array[i][POINT]  = <...>;
#declare Array[i][COUNT]  = <0,0,0>;
#declare Array[i][RANDOM] = <0,RRand(RsA, rMin, rMax),0>;

(That's basically how struct support would have to be implemented in POV
internally - except that we'd need to be able to store different things in the
array elements)

or maybe

#macro GET_POINT(a,i)
  Array[i][0]
#end

#macro GET_COUNT(a,i)
  Array[i][1].x
#end

#macro GET_RANDOM(a,i)
  Array[i][2].y
#end

> As a side note, why in the nine hells aren't there Round and VRound macros
> in pov to start with??

You can round using "int(x+0.5)", so no problem writing your own macros...

Yes, maybe the standard include files could use an overhaul, too.

> They seem kind of useful to just have been left out...then again...so do
> structs, enums, custom types, multi-datatype arrays, type casting, type
> conversion and list<T>'s...

.... and a new SDL grammar, as we're on it.

For the job we're doing, octrees would come in handy, too.

I think one of the greatest current limitations is the inability of arrays to
store elements of different types. Otherwise, structs could easily be simulated
by using identifiers holding constants, e.g.

#declare FIELD_FOO = 0
#declare FIELD_BAR = 1

#declare MyArray[FIELD_FOO] = <0,0,0>;
#declare MyArray[FIELD_BAR] = pigment { ... };

which still wouldn't be ideal, but still quite an improvement.

Post a reply to this message

"clipka" <nomail@nomail> wrote in message 
news:web.49ca88269fb46029c1f399840@news.povray.org...
> If I wasn't working on various other pieces of POV code, that's what I'd
> probably be doing right now...
>
> (Note however that "in the language that pov was written" would mean C 
> until
> only very recently, so nowhere close to dynamic lists whatsoever; and 
> structs,
> although C does have them, would have to be represented internally using
> "arrays of members" as it were, because C can't create new structs at 
> runtime.)

I had a feeling it was C still; long ago I looked at the source when 
considering adding new media scattering methods...then quickly abandoned 
that idea when I discovered how much work would actually be involved with 
the implementation of a new (to pov) algo.. :-|

>> http://www.haskell.org/haskellwiki/POV-Ray_SDL_project
>
> Yargh! Vade! >_<

Hmm? Sounds like something a norseman might shout just after boarding your 
vessel and just before doing something awful with a large blade. ;-)

> Again, too much OO thinking for POV SDL.

OO is the crack of programming. :-)

> You can't store separate things in the multiple dimensions of such an 
> array anyway; and if one of your "subsections"
> would need more elements, you'd need to add more elements to the other
> "subsections" as well... not too bright.

All of the dim1 elements will have the same attributes, so in this case it 
isn't really an issue, as they are just flags really. I do wish I could 
store multiple datatypes though, as using vectors when all you want is a 
flag is somewhat like the programming equivalent of a nasty hacked up 
hairball; ugly, gross and not something you like having to deal with.

> But what you might want to do is:
>
> #declare POINT  = 0;
> #declare COUNT  = 1;
> #declare RANDOM = 2;
>
> #declare Array[i][POINT]  = <...>;
> #declare Array[i][COUNT]  = <0,0,0>;
> #declare Array[i][RANDOM] = <0,RRand(RsA, rMin, rMax),0>;

So using different placed in dim2 would be better than having related vector 
flags grouped in their own dimension?
It seems to me that it could become confusing and require code rewrites (for 
grouping of like flags/misc) if one uses only 2d when thy might have a set 
of flags in d2 for say, branching, child nodes, etc.. and more for 
interpolated vectors or the like. It also seems that using those additional 
attributes could become messy if they are just all over the place.

> (That's basically how struct support would have to be implemented in POV
> internally - except that we'd need to be able to store different things in 
> the
> array elements)

I'd say step one would be to implement vector and integer/double/long 
support in the same array, see what that took to do, and then fan out from 
there.

> or maybe
>
> #macro GET_POINT(a,i)
>  Array[i][0]
> #end
>
> #macro GET_COUNT(a,i)
>  Array[i][1].x
> #end
>
> #macro GET_RANDOM(a,i)
>  Array[i][2].y
> #end

I like that better, seems easier to use and keep track of. I still like the 
idea of using multiple dimensions for related flags for my specific purpose, 
as I won't have many categories. It isn't so much that it really matters, so 
long as whatever method used works and does so quickly. Even so, for general 
extensibility, get/set macros for the win. I'll need to try both using 
stupid amounts of elements, and then compare the stats.

> You can round using "int(x+0.5)", so no problem writing your own macros...

True, but sometimes you just want to use a thing, without having to go find 
math.h to write your own.
There are a lot of little things like that in pov.

> Yes, maybe the standard include files could use an overhaul, too.

Agreed. Especially the textures, a lot of them kinda suck...like the 
metals...and glasses...
I'd like to see a nice influx of textures created by the community. Waters, 
glasses, metals, stones....there are so very many great ones I've seen used 
here.
A lot of the more esoteric macros in povray need example files too.

Maybe once I get my macro suite to a good place, I could get the snowball 
rolling on this..assuming they would actually use any files I created.
Probably if they would, I'd not be alone in wanting to do this.

> .... and a new SDL grammar, as we're on it.

Yes. My vote is cast with using more common C-ish things, as those who 
program will quickly adapt, and those who don't will spend the same amount 
of time learning as before, but will also be familiar with java/c#/c++ ish 
languages without even knowing it. Good for everyone.

>
> For the job we're doing, octrees would come in handy, too.

And hash tables(with a good many hashing methods), and heaps(with a lot of 
heap types), and a proof of the riemann hypothesis, and and and ;-D

> I think one of the greatest current limitations is the inability of arrays 
> to
> store elements of different types. Otherwise, structs could easily be 
> simulated
> by using identifiers holding constants, e.g.
>
> #declare FIELD_FOO = 0
> #declare FIELD_BAR = 1
>
> #declare MyArray[FIELD_FOO] = <0,0,0>;
> #declare MyArray[FIELD_BAR] = pigment { ... };
>
> which still wouldn't be ideal, but still quite an improvement.
>

Indeed. I'd take any improvement at this point.
Any idea why they never did that?

*sigh* I might just have to track down the file(s) where they coded those 
things and have a look...maybe it won't be the massive PITA that I get the 
feeling it is...

ian

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Darren New wrote:
> Bill Pragnell wrote:
>> Hmm, looks very much like Acorn BASIC. Although, 5 seconds? If that
>> were a beeb
>> you'd be ready to go before your finger had even left the power button...
> 
> That included the time for the TV tube to warm up. ;-)
> 
	Guess what? Somebody did a benchmark of an old 1986 Mac against a
dual core AMD64. And the winner is..... the 1986 Mac! By 9 tests to
8 (including a whopping six times faster boot sequence):
http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

		Jerome
- --
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknKozQACgkQd0kWM4JG3k8TCQCfQHSlH7oHl0sxvs/mLynEImeQ
dXUAnjCt3GBfJpePz2ACWYQUoTTHNuQJ
=79sN
-----END PGP SIGNATURE-----

Post a reply to this message

"[GDS|Entropy]" <gds### [at] hotmailcom> wrote:
> I had a feeling it was C still; long ago I looked at the source when
> considering adding new media scattering methods...then quickly abandoned
> that idea when I discovered how much work would actually be involved with
> the implementation of a new (to pov) algo.. :-|

There are still some areas where the code is quite C-ish, and a few C-ish data
types are still waiting to be "classified", but the coding style has changed
quite dramatically. It now resembles software, not a hack ;P

(Speaking of it - ever seen the NetHack source code? *That* is something to
drive every OO-enthusiast mad... >_<)

> >> http://www.haskell.org/haskellwiki/POV-Ray_SDL_project
> >
> > Yargh! Vade! >_<
>
> Hmm? Sounds like something a norseman might shout just after boarding your
> vessel and just before doing something awful with a large blade. ;-)

Well, I was thinking more of the latin "Vade Satanis!" :P

> > But what you might want to do is:
> >
> > #declare POINT  = 0;
> > #declare COUNT  = 1;
> > #declare RANDOM = 2;
> >
> > #declare Array[i][POINT]  = <...>;
> > #declare Array[i][COUNT]  = <0,0,0>;
> > #declare Array[i][RANDOM] = <0,RRand(RsA, rMin, rMax),0>;
>
> So using different placed in dim2 would be better than having related vector
> flags grouped in their own dimension?

Yeah, because it doesn't waste so much space. See, your approach used N*2*2
array entries - so far! This one only uses N*3 entries. Saves you N entries in
this case. Depending on how many groups you have, and how much they differ in
size, this can quickly get a lot more. E.g., if one group only had a single
entry while another had 8, you'd waste N*7 entries.

> It seems to me that it could become confusing and require code rewrites (for
> grouping of like flags/misc) if one uses only 2d when thy might have a set
> of flags in d2 for say, branching, child nodes, etc.. and more for
> interpolated vectors or the like. It also seems that using those additional
> attributes could become messy if they are just all over the place.

You cannot avoid *some* kind of mess with POV's SDL.

> > Yes, maybe the standard include files could use an overhaul, too.
>
> Agreed. Especially the textures, a lot of them kinda suck...like the
> metals...and glasses...

Most of them date back to the pre-Radiosity era; that's why they have ambient in
them, and that's why they do suck indeed.

> I'd like to see a nice influx of textures created by the community. Waters,
> glasses, metals, stones....there are so very many great ones I've seen used
> here.

I guess the POV team would agree. The major problem is that although the POV
community is obviously alive and kicking, nobody seems to see that here's where
they could help the dev team quite a lot.

People possibly don't get involved because they think developing POV 3.7 is all
about C++ programming. Well, it is not: POV 3.7 will need various updates to
the documentation. POV 3.7 would greatly benefit from a major overhaul of the
include files. And so on. Someone just needs to take the lead, team up with
others here to get those things done, and in the end lay the results in front
of the dev team to get it all approved. All the while the dev team can
concentrate on C++ coding.

I took the step from a normal POV user to a code contributor because I wanted
both symmetric multiprocessing *and* radiosity, which wasn't available end of
last year.

If you want better textures, why not take a step forward, too, and become a
contributor of texture include files? You don't even need to do all on your
own. Beg, steal or borrow whatever you think should be part of a "POV starter
pack". Or hack up some macros you think every POV user should have at their
disposal - you seem to be darn good at it, except for some lack of experience
(but really making up for it by a strong will to experiment, and actually
benefiting from that lack by looking at things from a different and fresh
perspective).

You know, becoming a contributor to the POV package is not difficult: Just pick
a thing you *want* improved and think you *could* improve if given the chance -
then step forward here in the newsgroups, making clear that you would like to
have a go at it, and I'm quite sure you will *get* that chance.

> Maybe once I get my macro suite to a good place, I could get the snowball
> rolling on this..assuming they would actually use any files I created.

Do so. And expect them to do appreciate your contributions.

> > .... and a new SDL grammar, as we're on it.
>
> Yes. My vote is cast with using more common C-ish things, as those who
> program will quickly adapt, and those who don't will spend the same amount
> of time learning as before, but will also be familiar with java/c#/c++ ish
> languages without even knowing it. Good for everyone.

Yeah, that would (roughly) be the direction I'd suggest, too. I guess there's no
"syntax family" as big as the "C-alikes", ranging from C over C++, Java, C# to
JavaScript (so web designers should be familiar with it as well) or even some
unix shells.

However, for some statements I would take a radically different approach. For
instance, although I'm perfectly accustomed to it, I never got to really like
the C-style 'for' loops. For my taste, "for" loops should always iterate
linearly (99% of all C 'for' loops do anyway); and there should be a "foreach"
loop to iterate over data containers.

> > For the job we're doing, octrees would come in handy, too.
>
> And hash tables(with a good many hashing methods), and heaps(with a lot of
> heap types), and a proof of the riemann hypothesis, and and and ;-D

I don't care about the riemann hypothesis, and I don't think we need dedicated
heaps, but hash tables might be useful at times ;)

But I really wasn't kidding: As we're dealing with objects in 3D space, I think
really the most "natural" data structures for a lot of problems would indeed be
spatial subdivision trees, and octrees would probably the most widely applicable
of those.

> Indeed. I'd take any improvement at this point.
> Any idea why they never did that?

Yes: C.

You don't think about such stuff as long as you're coding straightforward
classic C. In that language, you don't mix data types. Real C programmers just
don't think OO. It's almost a break of style that there is a generic object{}
statement.

Fortunately, the dev team doesn't have any real C programmers among their ranks
anymore (as far as I know); the internals are getting migrated to C++; and it's
probably about time for the SDL to head for OO, too.

Post a reply to this message

"clipka" <nomail@nomail> wrote in message 
news:web.49cab78d9fb46029c1f399840@news.povray.org...
>
> There are still some areas where the code is quite C-ish, and a few C-ish 
> data
> types are still waiting to be "classified", but the coding style has 
> changed
> quite dramatically. It now resembles software, not a hack ;P
>
> (Speaking of it - ever seen the NetHack source code? *That* is something 
> to
> drive every OO-enthusiast mad... >_<)

I'll have to check NetHack out. Yup last time I looked at the POV source I 
think it was looking back; kinda like when you leave something in the fridge 
too long and it grows a 'fro, and you aren't so sure who is about to throw 
who away. ;-p

> Well, I was thinking more of the latin "Vade Satanis!" :P

Gotcha! ;-D
Yeah some code looks more like Inno A Satana than much else. ;-p

>
> Yeah, because it doesn't waste so much space. See, your approach used 
> N*2*2
> array entries - so far! This one only uses N*3 entries. Saves you N 
> entries in
> this case. Depending on how many groups you have, and how much they differ 
> in
> size, this can quickly get a lot more. E.g., if one group only had a 
> single
> entry while another had 8, you'd waste N*7 entries.

They would all have the same number of entries; but you do make a valid 
point. The way I was doing it isn't very efficient.

> You cannot avoid *some* kind of mess with POV's SDL.

:-(

> Most of them date back to the pre-Radiosity era; that's why they have 
> ambient in
> them, and that's why they do suck indeed.

I think the metals include file will be my first project. I have some of my 
own that I'll start out with, as well as improving the old ones. I think 
I'll put a section on my website for this, showing previews (rad/norad) and 
code. I may create some facility to allow users to upload code, or I may 
just do a call to arms in the newsgroup. I have a VAST archive of povray 
files, and some have some killer metals in them. I guess I'll need to track 
people down and get permission for things..


> I guess the POV team would agree. The major problem is that although the 
> POV
> community is obviously alive and kicking, nobody seems to see that here's 
> where
> they could help the dev team quite a lot.

Almost nobody. ;-)

> People possibly don't get involved because they think developing POV 3.7 
> is all
> about C++ programming. Well, it is not: POV 3.7 will need various updates 
> to
> the documentation. POV 3.7 would greatly benefit from a major overhaul of 
> the
> include files. And so on. Someone just needs to take the lead, team up 
> with
> others here to get those things done, and in the end lay the results in 
> front
> of the dev team to get it all approved. All the while the dev team can
> concentrate on C++ coding.

Yup, there are spelling errors that I have seen in the docs. I think my main 
focus will be textures and later demo files for esoteric 
functions/macros.I'll probably include a standard set of macros that people 
seem to use a lot, but aren't included. Perhaps I'll write an insert menu 
addon for them.

My concern is future changes in 3.7; it would be a shame to get this all 
polished and then have it break in RC1 or some such.

> I took the step from a normal POV user to a code contributor because I 
> wanted
> both symmetric multiprocessing *and* radiosity, which wasn't available end 
> of
> last year.
>
> If you want better textures, why not take a step forward, too, and become 
> a
> contributor of texture include files? You don't even need to do all on 
> your
> own. Beg, steal or borrow whatever you think should be part of a "POV 
> starter
> pack". Or hack up some macros you think every POV user should have at 
> their
> disposal - you seem to be darn good at it, except for some lack of 
> experience
> (but really making up for it by a strong will to experiment, and actually
> benefiting from that lack by looking at things from a different and fresh
> perspective).

While I doubt stealing would be appreciated by the community, I can always 
make my own versions of anything that I can't get permission for. ;-D

I think that I will host some of this stuff on my site, so that people can 
view and give feedback/improve/debug. Setting that up will take a bit, I 
will probably not have usernames/logins just yet, but if I choose to allow 
others to upload content, I'm sure as hell going to screen applicants. I 
don't need any security issues...or jagoffs uploading pr0n...

> You know, becoming a contributor to the POV package is not difficult: Just 
> pick
> a thing you *want* improved and think you *could* improve if given the 
> chance -
> then step forward here in the newsgroups, making clear that you would like 
> to
> have a go at it, and I'm quite sure you will *get* that chance.

Sounds like a capital idea, and a reasonable task which can be completed in 
a reasonable time given the scope I wish to attack.

> Do so. And expect them to do appreciate your contributions.

I've been using this program for more years than I'd like to admit to, given 
my current skill level...but it's time for me to give something back. ;-D

> Yeah, that would (roughly) be the direction I'd suggest, too. I guess 
> there's no
> "syntax family" as big as the "C-alikes", ranging from C over C++, Java, 
> C# to
> JavaScript (so web designers should be familiar with it as well) or even 
> some
> unix shells.

Exactly, I can't see any possible disadvantage to this as of yet.

>
> However, for some statements I would take a radically different approach. 
> For
> instance, although I'm perfectly accustomed to it, I never got to really 
> like
> the C-style 'for' loops. For my taste, "for" loops should always iterate
> linearly (99% of all C 'for' loops do anyway); and there should be a 
> "foreach"
> loop to iterate over data containers.

I do like my foreach. Actually, I like all the loop types available. There 
is always that one time when you need the weird one.

> I don't care about the riemann hypothesis, and I don't think we need 
> dedicated
> heaps, but hash tables might be useful at times ;)

hehe...yeah all pov needs after all that is a windowing framework and we can 
start cranking out apps in SDL. ;-p

> But I really wasn't kidding: As we're dealing with objects in 3D space, I 
> think
> really the most "natural" data structures for a lot of problems would 
> indeed be
> spatial subdivision trees, and octrees would probably the most widely 
> applicable
> of those.

I think you are right, as many of the other types are only good in very 
specific circumstances, and can be weird to implement.

>> Indeed. I'd take any improvement at this point.
>> Any idea why they never did that?
>
> Yes: C.

D'oh!

> You don't think about such stuff as long as you're coding straightforward
> classic C. In that language, you don't mix data types. Real C programmers 
> just
> don't think OO. It's almost a break of style that there is a generic 
> object{}
> statement.
>
> Fortunately, the dev team doesn't have any real C programmers among their 
> ranks
> anymore (as far as I know); the internals are getting migrated to C++; and 
> it's
> probably about time for the SDL to head for OO, too.
>

*does a little dance*
w00t! :-D

ian

Post a reply to this message

>         Guess what? Somebody did a benchmark of an old 1986 Mac against a
> dual core AMD64. And the winner is..... the 1986 Mac! By 9 tests to
> 8 (including a whopping six times faster boot sequence):

  How is that comparing a Macintosh with an AMD64? That's comparing the old
MacOS with Windows.

  It is possible to set up a PC so that it uses coreboot and a architecture-
customized lightweight linux distro. You can get from power-on to the end of
the boot sequence in something like 2 or 3 seconds.

-- 
                                                          - Warp

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Warp wrote:
> "J�r�me M. Berger" <jeb### [at] freefr> wrote:
>>         Guess what? Somebody did a benchmark of an old 1986 Mac against a
>> dual core AMD64. And the winner is..... the 1986 Mac! By 9 tests to
>> 8 (including a whopping six times faster boot sequence):
> 
>   How is that comparing a Macintosh with an AMD64? That's comparing the old
> MacOS with Windows.
> 
	It's comparing a "standard" computer of 1986 and a "standard"
computer of today for "standard" tasks (i.e Word and Excel which is
what most users actually do when they work on their computers).

>   It is possible to set up a PC so that it uses coreboot and a architecture-
> customized lightweight linux distro. You can get from power-on to the end of
> the boot sequence in something like 2 or 3 seconds.
> 
	Of course, and it is also possible to set up this same computer
with an optimized embedded OS that will be even faster and similar
things were already possible back in '86. But then you're comparing
apples and oranges. The point was to compare typical office use of
computers in '86 and today. And the result is that the '86 computer
was at least as fast as today's.

		Jerome
- --
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAknLyBQACgkQd0kWM4JG3k9v8QCfSJ5/QDkgXD/XfEa1iCT0um/5
KsgAoIrpcD1AAWOAGchj891v3xwILHa0
=mjzx
-----END PGP SIGNATURE-----

Post a reply to this message

> The point was to compare typical office use of
> computers in '86 and today. And the result is that the '86 computer
> was at least as fast as today's.

  Does "typical office use" include things like opening and editing
a 1600x1200 full color image for a powerpoint presentation?

  I'd like to see you doing that with the old Mac. ;)

-- 
                                                          - Warp

Post a reply to this message