 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bill Pragnell wrote:
> "clipka" <nomail@nomail> wrote:
> 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... :)
>
I don't think you meant to imply that other PC BASIC's didn't have Peek
and Poke functions.
The BASIC in PET and TRS-80 certainly did and I think that Basica and
GWBasic did, but I'm
not altogether certain about them.
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bill Pragnell wrote:
> "clipka" <nomail@nomail> wrote:
>> "David H. Burns" <dhb### [at] cherokeetel net> 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?"
>
>
Well, I agree with the middle quote of the three. Of course whether He is a
Capricorn in astrological terms depends on the date of His birth, which is
disputed. Of course I doubt if that was what was meant. :)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> you could do a "GOTO xyz" where xyz was a variable.
What, ON GOTO and ON GOSUB weren't good enough for you? :-)
> which made reading long nested blocks of code a bit difficult.
Nested blocks?? We used to *DREAM* of nested blocks!
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/28/09 00:58, Chambers wrote:
> Jim Henderson wrote:
>> Oh, there have been much longer threads in here.... :-)
>
> So... is religion good or bad? :)
Good if it's Emacs.
--
ASCII and ye shall receive.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Back then, in order to be able to display multiple overlapping application
> windows at once, the solution was that whenever the position of a window would
> change, all windows previously hidden below it but now visible would have to be
> (partially) re-drawn by their respective applications.
That's one solution, but not really because of the memory. The Amiga had
only 128K or 256K, and it handled clipping windows and saving the clipped
parts elsewhere just fine. I suspect it was more a question of (a) amount of
effort put into the graphics layer and (b) the fact that there was no
hardware accel for Windows boxes so redrawing from scratch was probably
close to as fast as blitting the saved window anyway.
> I'm not sure if I get all these details right, but stuff along these lines added
> up to make the Windows graphics interface somewhat complicated to use,
Note that X Windows has all these same problems, except the user has to deal
with it all. In typical UNIX fashion, X will tell you what the screen looks
like and expect you to do all the work of making sure you're passing pixels
in the right format, rather than taking a device-independent drawing command
and adjusting it to the proper display.
> Yes, nowadays everyone is using 24-bit RGB graphics, and typically at 1:1 pixel
> aspect ratio, but that's something PC-users could only dream of in the early
> days of Windows.
Or even on sophisticated hardware. 1994 or so I needed to do compression
testing (i.e., figure out whether JPEG works), so I wound up buying a $3000
graphics board for the Sun workstation so I could see 24-bit color.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/27/09 18:56, clipka wrote:
> Warp<war### [at] tagpovrayorg> wrote:
>> Immediately when you started having different users with different
>> hardware setups, the whole graphics programming stumbled on a huge problem.
>
> Yup. DOS times were even worse than nowadays, as there was no accepted standard
> interface to graphics cards at all (except for standard CGA/EGA/VGA modes,
> which later graphics cards tried their best to remain hardware compatible
> with); so essentially each program came with its own proprietary set of
> graphics drivers, which fully supported only a selection of SuperVGA graphics
> cards available - and new graphics cards in turn would come with disks
> providing graphics drivers for only the most popular graphics-hungry
> applications.
Ever used Fractint on DOS? _That_ program probably supported more video
cards than any other. The amount of collaboration for that piece of
software was truly impressive.
--
ASCII and ye shall receive.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> That's one solution, but not really because of the memory. The Amiga had
> only 128K or 256K, and it handled clipping windows and saving the
> clipped parts elsewhere just fine.
Which model? I don't recall seeing one with less than 1MB RAM.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> The reason why languages like C++ don't come up with libraries which would
> be handy (such as graphics and sound) is complicated.
Actually, for graphics and sound and other ubiquitous stuff like that, it's
not all that hard to come up with a decent library. Win32, X, etc all fit
the bill.
My rant was more along the lines of higher-level stuff. Take, for example,
an HTTP client library. You would think it's straightforward, but how do you
allocate memory such that it's easy to free? (C++ solved this problem,
obviously, which is one of the big wins for C++ libraries over C libraries.)
How do you open a socket? How do you hash passwords for DIGEST
authentication? How do you keep from blocking on DNS lookups? Each of these
libraries has layers and layers under it, and nobody wants to redo all those
layers using only the standard libraries.
So the solution is to make the standard libraries bigger, and you start
getting things like Java and C#, which nobody wants to use because the
standard libraries are too big. :-)
I did read and understand the rest of your post, but I guess I wasn't really
clear in my late-night rant as to what I thought the problem was.
> Also such library would be highly non-portable. For example, if the C++
> standard dictated some kind of GUI library, how would you implement it eg.
> for the iPhone? You just can't. This would mean that for such systems you
> would have to use a crippled version of the language which may or may not
> compile some existing code.
Exactly! That's what I'm getting at. If it's not in the standard library,
then two chunks of code both wanting to do graphics are going to have
trouble working together. I want to play a video in a web page, but the web
client uses Qt and the video uses X, or something like that.
If it *is* in the standard library, then you either get something like "it
won't run on an iPhone" (say, .NET) or you get one "the standard library is
too big to fit on your hardware."
The most recent solution seems to be to put a layer of interpreter on top of
everything, using DOM and javascript as a graphics layer for your application.
> A standard library to play sounds would run into similar problems,
Here I think a framework would probably be sufficient. Unlike graphics,
programs don't seem to generate from scratch too many types of sounds. It's
mostly format-independent stuff, like "read a file and play it", or "here's
a gunshot that should sound like it's 20 feet away and off to the left a
bit" or some such. When they do generate from scratch (synthesizers, sound
editors, etc) they can use a decent open sound format and convert it when
they're done.
The problem here is layering it on top of other libraries. How do you
prebuffer the sound? What version of select/poll/threads/etc are you using
if you're pulling sound off a network connection? What standard are you
using to timestamp sounds so you can lip-sync to the video of the person
talking? If you want to build software to (say) play video (my current
bugaboo), you need all those things underneath first, and since they're not
standard, you can't mix-and-match the sound system with the video
decompression system with the content negotiation system with the DMA system
with the networking system.
These aren't hard problems to solve. The problem is they've been solved over
and over, and if you're trying to put multiple pieces of code together,
you're going to run into incompatibilities in the lower layers. Exactly like
with the graphics: the problem isn't that windowing systems are hard, but
that there are so many to choose from, and programs for one won't run on
others, even tho a simple adaption layer could make it work. But then
everyone writes their own adaption layer, and then you get adaptors between
the adaptors, and you get layers and layers of abstraction, all of which are
unnecessary for simple tasks but none of which you can throw away once it's
in the mix.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible <voi### [at] devnull> wrote:
> Darren New wrote:
>
> > That's one solution, but not really because of the memory. The Amiga had
> > only 128K or 256K, and it handled clipping windows and saving the
> > clipped parts elsewhere just fine.
>
> Which model? I don't recall seeing one with less than 1MB RAM.
The original Amiga 1000 came with either 256K or 512K memory. I had one of the
256K models. A pretty amazing machine for it time.
Isaac.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Which model? I don't recall seeing one with less than 1MB RAM.
Amiga 1000. From wikipedia
"Machines began shipping in September with a base configuration of 256 KB of
RAM at the retail price of 1295 USD."
Which fits my memory. I think the 500 had 128K? It wasn't a whole lot, but
the Amiga made efficient use of it.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
