"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > "Jesus was a capricorn"
> >
> > (Identified from memory... man, it's been ages since I've last heard that song.)
> >
> >
> Me too. I have it somewhere on a reel to reel tape. I wonder how long it
> would take
> me to find it.:)

I gotta ask my dad to copy that vinyl record to mp3... I didn't really like
"Jesus was a Capricorn", but I guess one or two other songs from the album were
ok, though the only other one I recall was "Jesse Younger" (which I quite
liked).

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> I ought to apologize for my typos and irregular lines. The keyboard on
> this Timex Sinclair
> is rather small and my tail keeps getting in the way.

Ook!

(Or was that some other thread? ;))

Post a reply to this message

"David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> >> The graphics routines in John Beales wonderful
> >> heightfield programs don't work, though the rest of the program does.
> >
> > The name doesn't ring a bell.
> >
>
> You took me aback! I had to call up Pov-Ray links to make sure had had
> the name right.
> Have you every played with heightfields? I can't imagine anyone who has
> not being familiar
> with John Beale's "Gforge".

Indeed I haven't done much heightfield stuff.

Post a reply to this message

Jim Henderson wrote:
> Oh, there have been much longer threads in here.... :-)

So... is religion good or bad? :)

<ducks>

-- 
Chambers

Post a reply to this message

Chambers wrote:
> David H. Burns wrote:
>> You took me aback! I had to call up Pov-Ray links to make sure had had 
>> the name right.
>> Have you every played with heightfields? I can't imagine anyone who 
>> has not being familiar
>> with John Beale's "Gforge".
> 
> (Warning!  Thread is becoming dangerously on-topic! :) ).
> 
> I'm aware of it, but I never used it.  I prefer making my height fields 
> with POV-Ray instead :)
> 
Gforge has a lot of tools for modifying  the basic heightfield. It's fun 
to play with
in itself. It has its own display routine (16 bit) but this fails on XP 
and maybe on 98 and
2000 -- I can't remember.

David :)

Post a reply to this message

clipka wrote:
> the file to look at there is "pvdisplay.cpp" in the
> "windows" subdirectory, which defines a WinLegacyDisplay object (well, an
> object class, to be precisely).

Well, it *is* complicated. I'm still not convinced that, even with 
legacy considered,
that it need be so. But since it is, that's what I'll have to work with.

The 3.6 code that I have doesn't have "pvdisplay.ccp"
but I take it that the code wherever it is (pvengine, I suspect) is 
similar. It looks like
I am going to have to delve into the mysteries of WINAPI (which I have 
already looked
into a little.) Your post should help. Unfortunately Microsoft 
documentation is rather obscure
too me, and I don't read well for very long on a computer screen. It's 
gonna be a long learning curve, the
question is, is it worth it? I'm beginning to think not. But, then, when 
once mastered, I should be
able to write routines that could with relative ease be adapted to about 
any language. I need
not fear that they won't work on future Windows versions, because unless 
I go completely senile,
I will *never* purchase another Windows machine! Even now I'm wondering 
if graphic programming
with a Mac is this complicated.

Thanks a lot. I will study this and will no doubt have "stupid" 
questions. :)

David :) :)

Post a reply to this message

clipka wrote:

> BTW, in C you can actually peek & poke around as you like on virtually all
> platforms, simply by assigning an arbitrary integer value to a pointer and then
> accessing the memory location pointed to.

I didn't know that, if I ever did, I had forgotten it. Thanks :)
> 
> May result in the application getting terminated for an access violation though,
> courtesy of Intel's "protected mode" and paging mechanisms, which can be used to
> automatically trigger a hardware interrupt when certain memory address ranges
> are accessed, so that the OS can take over and handle the access accordingly
> (killing a misbehaving program, swapping virtual memory back in, or the like).
> 

I blamed those "access violations" that occasionally show up on Windows. So
their really due to a "safety" feature in Intel's hardware. Is that why 
machines with
AMD processor's (reportedly) crash and hangup less frequently?

David :)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > A convenient excuse anyway. "Everybody needs someone to look down on. If you
> > ain't got nobody else, well help yo'self to me!" -Kris Kristofferson
> > (quoted from
> > memory) :)
>
> "Jesus was a capricorn"

"Capricorn, eh? What are they like?"
"He is the son of God, our Messiah! King of the Jews!"
"And that's capricorn, is it?"

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "David H. Burns" <dhb### [at] cherokeetelnet> wrote:
> > A peek function would still be useful, but a poke function on a multi
> > tasking system where
> > the operating system is in RAM ... well at best, you might reboot a lot.
>
> Would be very boring these days: At worst, poking around would get that
> particular app jam itself, and you'd have to kill it via the task manager.

In my particular example, of course, none of that applied. Being able to write
directly to memory from BASIC on the Acorns meant you could store large amounts
of data more efficiently without having to resort to assembler. And, since the
screen memory was in main RAM, you could write to the screen by storing your
pixel values directly to that block... :)

Post a reply to this message

clipka <nomail@nomail> wrote:
> Neeum Zawan <m.n### [at] ieeeorg> wrote:
> >  I wonder when such editors came around. Ever since I used BASIC, there
> > was the RENUM command. Of course, I _started_ using BASIC long, long
> > after its invention.

> IIRC one of the main factors of BASIC's popularity - the all-time famous C-64 -
> did *not* have a "RENUM" command.

> The first computer *I* used, the Amstrad CPC, *did* - hehe :P

  Of course even in editors which did have a renum command, it would mess
up any numbering scheme you might have been using. For example, if you
started every subroutine using line numbers starting from multiples of 1000
(so that you could easily remember that "this subroutine started at line
3000, and that one at line 5000" etc) the renumbering would mess up all
that and you lost the semi-logical numbering.

  There were some BASIC interpreters (eg. in the ZX Spectrum) which supported
jumping to a line which number was specified by a variable. In other words,
you could do a "GOTO xyz" where xyz was a variable. The interpreter would
then jump to the line which number was the value of that variable, or the
next line closest to that number if it didn't exist. (This allowed writing
some elementary switch/case constructs etc.) Naturally the renumbering command
would have no idea about this, and it would break your code.

  Overall, BASIC programs were quite hard to read and understand. Most
editors in the old days did not support such a basic technique as code
indenting (iow. even if you tried to indent the code manually, the editor
didn't support it and you couldn't). This means that every single line of
code started from the same column, which made reading long nested blocks of
code a bit difficult.

-- 
                                                          - Warp

Post a reply to this message