In the era of the 1980 home computers, It was an advanced programming technique, on the same level as VGA programming in the 1990's, or GPU shader programming is now. It was more of technological curiosity, with only one or two games used it (Tetris), since the results varied from TV to TV. It did seem strange how using a 320x200 monochrome screen could generate red, green, yellow or blue pixels just because the pixel size was smaller than the sampling rate of the CRT tube.
There is an article on the history of video recording in the production industry. The tapes (Ampex VRX-1000) weren't destroyed as in thrown out, crushed or incinerated. They were re-used to record new programming until the iron oxide was worn out. Given the relative costs of storage and purchase of each cassette, limited budgets, tight deadlines, the fact that copies were made for distribution, no producer or accountant would have given a second thought to overwriting the tapes for new programming. The same happens with server disk space for rendering these days. Once you've got the final reel out to the client, all that space is free for the next project. Someone with decades of experience might have seen the importance of saving all those clips for re-use, or using scraps for experimenting with, but then there would not have been the space to store them, or even the funding for archival.
Basic marketing.. it was like that 25 years ago with floppy disks. One time I went into the local branch of ComputerWorld to buy some floppy disks - they had a plastic box case of ten pre-formatted 3.25" floppy disks for just 100 pounds ($150). Just because there was a oil company up the road where admins/sysmanagers would come running out whenever a sales-exec needed to back up some files.
There is always going to be some customer willing to pay whatever asking price just because they need to have the latest tech for whatever reason.
That's in theory - but you only have to be lucky once. It may be like trying to find a needle floating around somewhere in the solar system, but if you've got spare clock cycles, there's nothing to lose by just running a background process making random guesses. Several months will be nothing but a small moment of time.
The odds of winning the grand-prize in a state lottery can get as low as 1 in 80,000,000, but usually at least one person wins.
But if you can encode the problem using some physical phenomena like light or sound interference patterns, then a solution could be found instantly.
Dijkstra was complaining about the first versions of BASIC which had line numbers and didn't have any flow control like IF-THEN-ELSE or WHILE-ENDWHILE . Combine that with code-monkey practises of banging in code in without any design or layout, and you would end up with spaghetti-code-monsters of applications where GOTO's would be used to jump out to what would be a subroutine (no local variables), a conditional GOTO to return to whichever routine actually made that call.
BASIC did support subroutines through GOSUB and RETURN. Though some versions didn't have an ELSE statement, so you had to use a GOTO to skip over exclusively mutual code segments. Some variants dispensed with line numbers and just had 'proc's' - procedures defined with 'defproc' and 'endproc' along with 'callproc'. Acorn Basic and Sinclair QL SuperBasic come to mind.
Most times, you could avoid the use of IF-THEN statements and associated GOTO's:
1010 IF (DX0 ) THEN X=X+1 1030... and just have:
1010 X = X+(DX>0)-(DX0)
It works for GPU shader languages 30 years later...
Chris Crawford's (of Atari) articles on writing modular BASIC programs in Personal Computer World were the first introduction to design that I read about... Keep line numbers 10.. 999 for the high level order of function calls. Keep different blocks of line numbers for the different types of functions with lines 1000 to 2000 to set up page 6/player-missile graphics, 2000-3000 for the titles, 3000-4000 for main-loops and menus, 4000+ for data, and lines 10000+ for auto-renumbering...
10000 ST=PEEK(136)+256*PEEK(137):INPUT S,E,F,I 10010 L=PEEK(ST)+256*PEEK(ST+1):IF L>=S AND L=E THEN A=INT(F/256):B=F-A*256:POKE ST,B:POKE ST+1,A:F=F+I 10020 IF L=E THEN ST=ST+PEEK(ST+2):GOTO 10010
It was the first time that computer graphics were used intensively to make a movie (terrains, vehicles, tanks and ships). Wikipedia states 15-20 minutes worth . They couldn't combine live action with computer animation so they had to jump between the different shots. I'd guess they'd have to jump quickly between shots faster than they normally would in order to keep the continuity going.
The PDP-10 that they used, only had 2 MBytes of memory and 330 MBytes of backing store. There were reviews in other magazines which explained how they did some thing - one of the problems was the reflections off the studio floors of the costumes (the backlit animation) and the different ages of the photographic plates which caused different levels of exposure, leading to all the flickering.
You haven't see some computing labs these days - it's really how many PC's and students can we cram into the room before they start complaining? With so many buy-to-rent landlords, a two bedroom apartment with living room/dining becomes a four-bedroom student flat.
Happened in one place in London - a whole department of ten people squeezed into the space of five desks. There was just enough space for a keyboard and a shuttle PC and that was it.... You couldn't get any work done on your PC without your neighbor making a comment... either wanting to get involved with what you were doing or looking at your E-mails (getting an official E-mail username took about two weeks).
There are different types of research paper. If you are first to pioneer a particular field to solve a particular problem, you'll get cited as writing a "seminal paper", even if it was written 20-30 years ago. Another way to get cited is to write STAR paper (State of The Art Report), where you survey all the research that everyone else has done... Other research papers involve performing performance/accuracy comparisons between a new techniques against existing techniques, or describing a novel combination of hardware/software.
If you try and base your research on 3rd party API's, you can have the rug pulled from under your feet if that API is suddenly replaced or discontinued. So most researchers will use their own languages rather than rely on something industrial or commercial.
I remember going to this talk by research team on laser scanning. They had developed a new technique of visualising scans of surfaces by placing all the sample points in a rectangular grid and bilinearly interpolating between the points. Their current research on applying perspectively correct projection to these sample grids was looking promising...
That's my experience as well. I played around with TMS340x0 (TIGA) graphics accelerator cards back in the in the early 1990's. One half was the regular VGA standard of the time (256 colors). The other half was 2 Megabytes of memory, a TMS34020 32-bit graphics coprocessor with (if you were lucky), one or more TMS34082 floating point coprocessors. It was really only intended to accelerate paint programs like Tempra and the 2D rendering of AutoCAD. There were some 3D demos written for it like 'flysim', but that was about it.
Anything written for the VGA half is still portable and usable now. Anything written for those processors is now more or less bit-dust.
It happens at local levels too - bureaucrats in local government send out gagging order related to poor quality of service in hospital, schools or even refuse collection, or even suspend or fire anyone who speaks out.
You forget the cost of purchasing hardware or leasing supercomputing time. If you want your simulation running on a supercomputer at the nearest research unit, then you would have to get your algorithm or simulation written in OpenMP, parallel Fortran or whatever language was optimised for that system, and you would be tied to that hardware. Have a desktop system under your desk, and you have the freedom to use the system when you want.
I'll agree, it is bad that software has to be wrapped around one piece of hardware or another for performance. Going as far as splitting source code into 'kernels' and STL style 'foreach' loops should be as far as you need to go. I wonder how much of this is lock-in by vendors rather than actual performance tuning.
How can they have a balanced budget when all the taxes raised are going to be spent paying the interest on the debts that the banks racked up? That's why there are going to be "austerity measures", and things like a minimum wage salary are going to be thrown away.
Remember, Microsoft bought a whole load of patents from SGI relating to 3D graphics and rendering - there was at least one related to shader languages implemented in hardware.
Because at the time, every UNIX vendor (SGI,HP,Sun,Dec) implemented API's like pthreads, sockets, and GUI systems+widgets such as X-windows/Motif) with different features. It became a headache for application developers to support multiple API's on multiple systems. To support an application, they would have to purchase workstations from each vendor. On top of that they would have to pay extra for as end-user licences as well as the compilers.
POSIX was an attempt to standardize UNIX to make life simple for developers. It came out in 1997, just after Microsoft brought out MFC. Even then some vendors would have official "RS232" cables with extra pins and internal wiring that made sure that regular RS232 cables wouldn't work.
For a start-up like a new animation studio, it was all too much. Why pay extra for all these licenses, when they could just go down to a hardware store, buy some generic PC hardware, slap on Windows NT + Studio Max , and have a hardware party at the same time?
Thanks - I kindof forgot about the exact sequence of events.Microsoft came out with MFC in 1992 Java came out around 1995, as a solution to improve security and speed up application development by eliminating the use of pointers and delete memory operators..Net and C# came out in 2002.
Thought it was more the "lock-in" provided by the Window API. Microsoft didn't conquer the workstation market until around 1995 with Windows NT/95. One by one they got the workstation vendors to replace their UNIX OS's with Windows NT using a "UNIX is LEGACY" advertising campaign; DEC, Digital, then HP and SGI caved in, as application developers could really only support the three most popular OS's that their customers use. As Windows NT took over one vendor after another, they gradually reached No.1 position and forced customers and vendors to use Windows.
UNIX competitors didn't help themselves by charging "UNIX" prices for components like monitors and RS232 cables as well as having totally different API's for everything - remnants of this can be seen when reading Linux man pages - there will be references to POSIX behavior, parameters or result codes.
At this time, Microsoft Mail was the dominant E-mail server software, but even they had to adopt "sockets" in order to connect to web servers. Sun came out with this little PC on a board solution that ran a Windows desktop in a window in order to allow users to use Microsoft Office, before buying up StarOffice (renamed to OpenOffice) and released it to break the Microsoft stranglehold, then went on to provide JAVA as a rival to MFC,.NET and C#
You can stand up to Microsoft, but only through co-operation, quality and reliability. Make sure that whatever you develop is to an internationally agreed standard that literally leaves no bit unspecified (even in an API function call). Otherwise, Microsoft will just find a way of embracing, extending and extinguishing that specification through a patent on the use of that single bit. Similarly with "extension" based API's and formats. Tie down every single bit and avoid any sort of "extension format"
I always remember the Intel i860. Another attempt to create a graphics processor (or coprocessors as they were called back then). It had special instructions for perfoming combo Z-buffer and color buffer test and writes as well as vector processor instructions. They made it into early SGI workstations.
The full-page glossy advert pages of BYTE magazine used to have these pictures of really impressive (at the time) systems with transputer/i860/TMS34020 boards. Some with their own network and hard disk drive ports (the PC was too slow at the time to handle the data transfer). But every time a board came out, six months later, CPU's would have caught up and these boards/chips would become known as "graphics deaccelerators".
In the era of the 1980 home computers, It was an advanced programming technique, on the same level as VGA programming in the 1990's, or GPU shader programming is now. It was more of technological curiosity, with only one or two games used it (Tetris), since the results varied from TV to TV. It did seem strange how using a 320x200 monochrome screen could generate red, green, yellow or blue pixels just because the pixel size was smaller than the sampling rate of the CRT tube.
There is an article on the history of video recording in the production industry. The tapes (Ampex VRX-1000) weren't destroyed as in thrown out, crushed or incinerated. They were re-used to record new programming until the iron oxide was worn out. Given the relative costs of storage and purchase of each cassette, limited budgets, tight deadlines, the fact that copies were made for distribution, no producer or accountant would have given a second thought to overwriting the tapes for new programming. The same happens with server disk space for rendering these days. Once you've got the final reel out to the client, all that space is free for the next project. Someone with decades of experience might have seen the importance of saving all those clips for re-use, or using scraps for experimenting with, but then there would not have been the space to store them, or even the funding for archival.
Couldn't you just use a scanner with an automatic document feeder, and then use some image processing software to read the holes on the cards?
Basic marketing .. it was like that 25 years ago with floppy disks. One time I went into the local branch of ComputerWorld to buy some floppy disks - they had a plastic box case of ten pre-formatted 3.25" floppy disks for just 100 pounds ($150). Just because there was a oil company up the road where admins/sysmanagers would come running out whenever a sales-exec needed to back up some files.
There is always going to be some customer willing to pay whatever asking price just because they need to have the latest tech for whatever reason.
They should have a FAQ List, just like the one that exists for every proposed solution to defeating spam mail.
Hale and Pace sketch
That's in theory - but you only have to be lucky once. It may be like trying to find a needle floating around somewhere in the solar system, but if you've got spare clock cycles, there's nothing to lose by just running a background process making random guesses. Several months will be nothing but a small moment of time.
The odds of winning the grand-prize in a state lottery can get as low as 1 in 80,000,000, but usually at least one person wins.
But if you can encode the problem using some physical phenomena like light or sound interference patterns, then a solution could be found instantly.
Dijkstra was complaining about the first versions of BASIC which had line numbers and didn't have any flow control like IF-THEN-ELSE or WHILE-ENDWHILE . Combine that with code-monkey practises of banging in code in without any design or layout, and you would end up with spaghetti-code-monsters of applications where GOTO's would be used to jump out to what would be a subroutine (no local variables), a conditional GOTO to return to whichever routine actually made that call.
BASIC did support subroutines through GOSUB and RETURN. Though some versions didn't have an ELSE statement, so you had to use a GOTO to skip over exclusively mutual code segments. Some variants dispensed with line numbers and just had 'proc's' - procedures defined with 'defproc' and 'endproc' along with 'callproc'. Acorn Basic and Sinclair QL SuperBasic come to mind.
Most times, you could avoid the use of IF-THEN statements and associated GOTO's:
1010 IF (DX0 ) THEN X=X+1 ...
1030
and just have:
1010 X = X+(DX>0)-(DX0)
It works for GPU shader languages 30 years later ...
Chris Crawford's (of Atari) articles on writing modular BASIC programs in Personal Computer World were the first introduction to design that I read about ... Keep line numbers 10 .. 999 for the high level order of function calls. Keep different blocks of line numbers for the different types of functions with lines 1000 to 2000 to set up page 6/player-missile graphics, 2000-3000 for the titles, 3000-4000 for main-loops and menus, 4000+ for data, and lines 10000+ for auto-renumbering...
10000 ST=PEEK(136)+256*PEEK(137):INPUT S,E,F,I
10010 L=PEEK(ST)+256*PEEK(ST+1):IF L>=S AND L=E THEN A=INT(F/256):B=F-A*256:POKE ST,B:POKE ST+1,A:F=F+I
10020 IF L=E THEN ST=ST+PEEK(ST+2):GOTO 10010
Wikipedia has a good biography of all the hardware used for the original movie/a.
It was the first time that computer graphics were used intensively to make a movie (terrains, vehicles, tanks and ships). Wikipedia states 15-20 minutes worth . They couldn't combine live action with computer animation so they had to jump between the different shots. I'd guess they'd have to jump quickly between shots faster than they normally would in order to keep the continuity going.
The PDP-10 that they used, only had 2 MBytes of memory and 330 MBytes of backing store. There were reviews in other magazines which explained how they did some thing - one of the problems was the reflections off the studio floors of the costumes (the backlit animation) and the different ages of the photographic plates which caused different levels of exposure, leading to all the flickering.
Don't forget the lead shielding ..
You haven't see some computing labs these days - it's really how many PC's and students can we cram into the room before they start complaining? With so many buy-to-rent landlords, a two bedroom apartment with living room/dining becomes a four-bedroom student flat.
Happened in one place in London - a whole department of ten people squeezed into the space of five desks. There was just enough space for a keyboard and a shuttle PC and that was it.... You couldn't get any work done on your PC without your neighbor making a comment ... either wanting to get involved with what you were doing or looking at your E-mails (getting an official E-mail username took about two weeks).
There are different types of research paper. If you are first to pioneer a particular field to solve a particular problem, you'll get cited as writing a "seminal paper", even if it was written 20-30 years ago. Another way to get cited is to write STAR paper (State of The Art Report), where you survey all the research that everyone else has done ... Other research papers involve performing performance/accuracy comparisons between a new techniques against existing techniques, or describing a novel combination of hardware/software.
If you try and base your research on 3rd party API's, you can have the rug pulled from under your feet if that API is suddenly replaced or discontinued. So most researchers will use their own languages rather than rely on something industrial or commercial.
I remember going to this talk by research team on laser scanning. They had developed a new technique of visualising scans of surfaces by placing all the sample points in a rectangular grid and bilinearly interpolating between the points. Their current research on applying perspectively correct projection to these sample grids was looking promising...
That's my experience as well. I played around with TMS340x0 (TIGA) graphics accelerator cards back in the in the early 1990's. One half was the regular VGA standard of the time (256 colors). The other half was 2 Megabytes of memory, a TMS34020 32-bit graphics coprocessor with (if you were lucky), one or more TMS34082 floating point coprocessors. It was really only intended to accelerate paint programs like Tempra and the 2D rendering of AutoCAD. There were some 3D demos written for it like 'flysim', but that was about it.
Anything written for the VGA half is still portable and usable now. Anything written for those processors is now more or less bit-dust.
It happens at local levels too - bureaucrats in local government send out gagging order related to poor quality of service in hospital, schools or even refuse collection, or even suspend or fire anyone who speaks out.
You forget the cost of purchasing hardware or leasing supercomputing time. If you want your simulation running on a supercomputer at the nearest research unit, then you would have to get your algorithm or simulation written in OpenMP, parallel Fortran or whatever language was optimised for that system, and you would be tied to that hardware. Have a desktop system under your desk, and you have the freedom to use the system when you want.
I'll agree, it is bad that software has to be wrapped around one piece of hardware or another for performance. Going as far as splitting source code into 'kernels' and STL style 'foreach' loops should be as far as you need to go. I wonder how much of this is lock-in by vendors rather than actual performance tuning.
With two more walls/screens, it could become the cubicle of the future.... wait, make it four walls, I don't want to be interrupted while working.
How can they have a balanced budget when all the taxes raised are going to be spent paying the interest on the debts that the banks racked up? That's why there are going to be "austerity measures", and things like a minimum wage salary are going to be thrown away.
Remember, Microsoft bought a whole load of patents from SGI relating to 3D graphics and rendering - there was at least one related to shader languages implemented in hardware.
Because at the time, every UNIX vendor (SGI,HP,Sun,Dec) implemented API's like pthreads, sockets, and GUI systems+widgets such as X-windows/Motif) with different features. It became a headache for application developers to support multiple API's on multiple systems.
To support an application, they would have to purchase workstations from each vendor. On top of that they would have to pay extra for as end-user licences as well as the compilers.
POSIX was an attempt to standardize UNIX to make life simple for developers. It came out in 1997, just after Microsoft brought out MFC. Even then some vendors would have official "RS232" cables with extra pins and internal wiring that made sure that regular RS232 cables wouldn't work.
For a start-up like a new animation studio, it was all too much. Why pay extra for all these licenses, when they could just go down to a hardware store, buy some generic PC hardware, slap on Windows NT + Studio Max , and have a hardware party at the same time?
Thanks - I kindof forgot about the exact sequence of events.Microsoft came out with MFC in 1992 .Net and C# came out in 2002.
Java came out around 1995, as a solution to improve security and speed up application development by eliminating the use of pointers and delete memory operators.
Thought it was more the "lock-in" provided by the Window API. Microsoft didn't conquer the workstation market until around 1995 with Windows NT/95. One by one they got the workstation vendors to replace their UNIX OS's with Windows NT using a "UNIX is LEGACY" advertising campaign; DEC, Digital, then HP and SGI caved in, as application developers could really only support the three most popular OS's that their customers use. As Windows NT took over one vendor after another, they gradually reached No.1 position and forced customers and vendors to use Windows.
UNIX competitors didn't help themselves by charging "UNIX" prices for components like monitors and RS232 cables as well as having totally different API's for everything - remnants of this can be seen when reading Linux man pages - there will be references to POSIX behavior, parameters or result codes.
At this time, Microsoft Mail was the dominant E-mail server software, but even they had to adopt "sockets" in order to connect to web servers. Sun came out with this little PC on a board solution that ran a Windows desktop in a window in order to allow users to use Microsoft Office, before buying up StarOffice (renamed to OpenOffice) and released it to break the Microsoft stranglehold, then went on to provide JAVA as a rival to MFC, .NET and C#
You can stand up to Microsoft, but only through co-operation, quality and reliability. Make sure that whatever you develop is to an internationally agreed standard that literally leaves no bit unspecified (even in an API function call). Otherwise, Microsoft will just find a way of embracing, extending and extinguishing that specification through a patent on the use of that single bit. Similarly with "extension" based API's and formats.
Tie down every single bit and avoid any sort of "extension format"
I always remember the Intel i860. Another attempt to create a graphics processor (or coprocessors as they were called back then). It had special instructions for perfoming combo Z-buffer and color buffer test and writes as well as vector processor instructions. They made it into early SGI workstations.
The full-page glossy advert pages of BYTE magazine used to have these pictures of really impressive (at the time) systems with transputer/i860/TMS34020 boards. Some with their own network and hard disk drive ports (the PC was too slow at the time to handle the data transfer). But every time a board came out, six months later, CPU's would have caught up and these boards/chips would become known as "graphics deaccelerators".