The simple idea behind tile-based rendering is to divide the screen into square patches (8x8 or 16x16 usually) and, for each patch, find which of the triangles intersect the patch, do a quick depth sort to detect complete occlusions, and draw.
There is a good article on it, as applied to the powervr (which is using the same kind of architecture) at http://www.ping.be/powervr/PVRSGRendMain.htm. As others already said, you can see the results on the Dreamcast, or on the arcade version, the Naomi.
The strenghts are obvious:
Lower fillrate required because of the per-petch occulted triangles elimination
The currently-rendered tile memory can be on-die, L1-grade, releasing the bandwitch for texture reading
The weaknesses are a little less obvious:
Rendering start delayed because it requires having all the triangles available. Can be somewhat hidden by multi-buffering
Alpha-blending slows things down hard, because it increases the required fillrate very fast, and these cards are designed with a lower fillrate in mind
There is no Z-buffer anymore (at least at peak speed, it's not copied back to the main memory), and we know that the 3D programmers love to do tricks with the Z-buffer
As a result, these cards are nice, but mostly represent another set of tradeoffs, not necessarily a revolution.
: I don't understand why they specifically mentioned TV and radio.
Large vocabulary (but somehow predictible), speaker trained to overarticulate, no superposition between different speakers, slightly simpler language model (complete phrases, language close to written).
State-of-the-art recognizers have an error rate of ~10% on that test, which until last year was one of the evaluation tests at the speech group at NIST. Check http://www.nist.gov/speech/tests/index.htm for details.
Since the point of disminishing returns was reached, the test in going to be replaced with a new one, a audio/video recorded meeting transcription. Much, much harder.
With the current tendancy[1] of moving major projects to the GPL and the release of a large amount of previously closed code to under that license, there are only two major licenses remaining: the GPL, and the MIT one (aka Apache, BSD next generation). Or, as was named an interesting thread on Technocrat, the GPL becomes the industry standard license.
It is probably going to stay that way since these two beasts are compatible.
So, as a result, every new potentially open source license has to be checked against these two. And since the MIT license is essentially a "no constraints" one, the GPL is the only one with which issues can appear. And incompatibility with the GPL has become a killer. It's simply a matter of leverage.
The problem here is not whether NASM-licensed code "accepts" to be linked with GPLed code. It is whether GPLed code would accept to be linked with NASMed code. It seems like the answer is no.
It's not easy to make a GPL-compatible license. I personally see that as a feature.
Looks a lot like spanish is on the way to become in 20, 30 years the official US language anyway. Mostly everything administrative is done both in english and is spanish, and there seem to be more people not able to speak english than not able to speak spanish.
But heh, maybe in 50 years ubiquitous translation technology will make language barriers inexistant (and, according to Douglas Adams, cause an impressive number of wars in the process;-).
- Split blocks on the dots
- Do a 4->3 binhex-like decoding with the table [a..z][A..Z][0..9][+-]. Drop any incomplete byte
- Xor each value with 67
- Print as ascii
The first block is some kind of serial number, the second the type of barcode (UPA, C39, 128...), the third the barcode itself.
Well, the original poster was talking about the atari st, so I placed myself in that time frame. The ST hardware was definitively of the "framebuffer" category. You'll notice that the STE added hardware scrolling and a blitter.
BTW, the ST has an hblank (on both timer B or maybe C, I'm not completely sure, and irq level 2).
Older home computers were inheriting from the arcade games/text console era. The VIC20, C64, ZX81... had a tile based architecture. The evolution started with the Spectrum and the Oric, which had an intermediate representation between tiles and framebuffer. The Amstrad is one of the first widely used pure framebuffer implementations.
Well, tile-based graphic modes are nice for action games, but not that nice for aventure games with non-tiled graphics, not nice for showing how the kid can easily draw a circle with a simple basic command, and definitively a pain for any windowing system (look at the gem and/or workbench, compare to the pc text-mode interfaces of the time).
Once you have implemented (in hardware) a framebuffer, which is a simple linear memory read + color palette lookup + DAC, you'd rather spend time and money accelerating its use thru blitters, coppers and equivalents (Amiga) or not accelerate anything at all and reduce the costs (Atari) rather than having to add a tile-based display system.
The video subsystems were completely different for computers than for arcade machines at this time[1].
Computers:
- framebuffer
- hardware support for scrolling of the pixels
- blitters
- hblank interrupt for effects
Arcade games:
- n planes of tile oriented video (i.e, the screen is divided into 8x8 elements selected by number)
- sprites generator (usually a plane of its own)
- priority manager
- hardware support for global scrolling of the tile planes
- horizontal and vertical line scrolling
- vblank interrupt only
There were numerous variants, of course, and some games used a framebuffer (williams games, mostly), but this is the usual architecture. It trades off genericity (you can't really draw a line in a no-framebuffer, tile-based system) for efficiency (zero-cpu-cost layers, independant busses for the graphic roms which are directly connected to the tile/sprites ICs, etc....). That's mostly what made them so impressive compared to the quite feeble CPUs they were using.
OG, mamedev
[1] Now everything has been unified under a common 3d-oriented architecture.
The source is pushed back. But the source may have a lot more energy available than the sail, and/or being setup on something of a high mass (like the moon, for instance).
The momentum of a photon is independant of its velocity (which is c no matter what) or its mass (0 no matter what either). It is known as h/l, where h is the Planck's constant and l the wavelength. So if there was a loss of momentum what would happen is a frequency shift.
But, in practice, there is no noticeable loss in the absolute value of the momentum, only a change in the direction of the vector, which becomes the mirror image of what it was when coming in. The difference between the two vectors is the amount of reaction given to the sail.
Because flash memory is not standard memory. In particular it has slower access times and does not like to be written to often that much. This makes using caches necessary for good performance (especially on 200+ Mhz handhelds).
But if you use caches, there's always the question of what happens in the case of a power outage (as in, the battery just popped off). Journaling allows to go back quickly to a reasonable state 99.9% of the time (at least). To the point that the user will probably not notice the problem.
Incidentally, a jfs does _not_ protect against disk crashes at all, it is not designed for that. If you want protection against (most) disk crashes, what you need is RAID.
Actually, if you want very reasonable data security without daily backups, especially given the current cost of large disks and comparable-size backup systems, you probably need a jfs+raid combination.
Al is currently rewriting half of vfs because of the devfs integration, mind you. Which tends to make 2.3.99-pre* badly unstable (as in, 2-3 weeks ago half of the time you couldn't unmount some of the filesystems). This is going to push back 2.4 even more...
Never played with pervasive interfaces for now, heh?
The Trek interface has two major points right, at least:
- A keyword to have it to start listening for commands, i.e. they always start their interactions with "Computer"[1]
- An voice acknowledgement of all commands ("Processing", etc...) as soon as they are understood
The only really unrealistic part in there is the blinkenlight orgy.
OG, creating real-world trek-like interfaces for a living
They already did. The speed difference in FPU operations between the K6 and the Athlon is impressive, and I even often see an 500Mhz Athlon be somehow (feels 5-10%) faster than a 550Mhz PIII Xeon in some FPU intensive operations (mp3 compression with a nontrivial psychoacoustic model).
You're missing one thing: the self-congratulating people usually aren't the ones who actually write the code. A real programmer always have something that itches him in his code.
So leave 'em out of our way bragging, and let's go back to the code.
OG.
PS: The.ifo files are one of the most perverted format I've ever played with:-)
Slashdot Mirror
UCITA is state law, DMCA is federal law, federal law trumps state law. So no, no matter what.
OG.
There is a good article on it, as applied to the powervr (which is using the same kind of architecture) at http://www.ping.be/powervr/PVRSGRendMain.htm. As others already said, you can see the results on the Dreamcast, or on the arcade version, the Naomi.
The strenghts are obvious:
The weaknesses are a little less obvious:
As a result, these cards are nice, but mostly represent another set of tradeoffs, not necessarily a revolution.
OG.
: I don't understand why they specifically mentioned TV and radio.
Large vocabulary (but somehow predictible), speaker trained to overarticulate, no superposition between different speakers, slightly simpler language model (complete phrases, language close to written).
State-of-the-art recognizers have an error rate of ~10% on that test, which until last year was one of the evaluation tests at the speech group at NIST. Check http://www.nist.gov/speech/tests/index.htm for details.
Since the point of disminishing returns was reached, the test in going to be replaced with a new one, a audio/video recorded meeting transcription. Much, much harder.
OG.
Of course they can. Heh, the BSD license even allows you to change the license of Kicker and KWin to GPL if that makes you feel safer.
OG.
OG.
XML because after a while everybody becomes tired of writing Yet Another Parser[tm], while slapping in the libxml works perfectly.
OG, converting all the config files of his program to XML
So, as a result, every new potentially open source license has to be checked against these two. And since the MIT license is essentially a "no constraints" one, the GPL is the only one with which issues can appear. And incompatibility with the GPL has become a killer. It's simply a matter of leverage.
OG.
[1] Mozilla, Qt
The problem here is not whether NASM-licensed code "accepts" to be linked with GPLed code. It is whether GPLed code would accept to be linked with NASMed code. It seems like the answer is no.
It's not easy to make a GPL-compatible license. I personally see that as a feature.
OG.
Looks a lot like spanish is on the way to become in 20, 30 years the official US language anyway. Mostly everything administrative is done both in english and is spanish, and there seem to be more people not able to speak english than not able to speak spanish.
;-).
But heh, maybe in 50 years ubiquitous translation technology will make language barriers inexistant (and, according to Douglas Adams, cause an impressive number of wars in the process
OG.
- Split blocks on the dots
- Do a 4->3 binhex-like decoding with the table [a..z][A..Z][0..9][+-]. Drop any incomplete byte
- Xor each value with 67
- Print as ascii
The first block is some kind of serial number, the second the type of barcode (UPA, C39, 128...), the third the barcode itself.
OG.
Well, the original poster was talking about the atari st, so I placed myself in that time frame. The ST hardware was definitively of the "framebuffer" category. You'll notice that the STE added hardware scrolling and a blitter.
BTW, the ST has an hblank (on both timer B or maybe C, I'm not completely sure, and irq level 2).
Older home computers were inheriting from the arcade games/text console era. The VIC20, C64, ZX81... had a tile based architecture. The evolution started with the Spectrum and the Oric, which had an intermediate representation between tiles and framebuffer. The Amstrad is one of the first widely used pure framebuffer implementations.
OG.
Well, tile-based graphic modes are nice for action games, but not that nice for aventure games with non-tiled graphics, not nice for showing how the kid can easily draw a circle with a simple basic command, and definitively a pain for any windowing system (look at the gem and/or workbench, compare to the pc text-mode interfaces of the time).
Once you have implemented (in hardware) a framebuffer, which is a simple linear memory read + color palette lookup + DAC, you'd rather spend time and money accelerating its use thru blitters, coppers and equivalents (Amiga) or not accelerate anything at all and reduce the costs (Atari) rather than having to add a tile-based display system.
OG.
The video subsystems were completely different for computers than for arcade machines at this time[1].
Computers:
- framebuffer
- hardware support for scrolling of the pixels
- blitters
- hblank interrupt for effects
Arcade games:
- n planes of tile oriented video (i.e, the screen is divided into 8x8 elements selected by number)
- sprites generator (usually a plane of its own)
- priority manager
- hardware support for global scrolling of the tile planes
- horizontal and vertical line scrolling
- vblank interrupt only
There were numerous variants, of course, and some games used a framebuffer (williams games, mostly), but this is the usual architecture. It trades off genericity (you can't really draw a line in a no-framebuffer, tile-based system) for efficiency (zero-cpu-cost layers, independant busses for the graphic roms which are directly connected to the tile/sprites ICs, etc....). That's mostly what made them so impressive compared to the quite feeble CPUs they were using.
OG, mamedev
[1] Now everything has been unified under a common 3d-oriented architecture.
The source is pushed back. But the source may have a lot more energy available than the sail, and/or being setup on something of a high mass (like the moon, for instance).
The momentum of a photon is independant of its velocity (which is c no matter what) or its mass (0 no matter what either). It is known as h/l, where h is the Planck's constant and l the wavelength. So if there was a loss of momentum what would happen is a frequency shift.
But, in practice, there is no noticeable loss in the absolute value of the momentum, only a change in the direction of the vector, which becomes the mirror image of what it was when coming in. The difference between the two vectors is the amount of reaction given to the sail.
OG.
MPEG2 is very very close to MPEG1. The DCT is still there, and in fact, identical.
Now, future standards may use wavelets.
OG.
Because flash memory is not standard memory. In particular it has slower access times and does not like to be written to often that much. This makes using caches necessary for good performance (especially on 200+ Mhz handhelds).
But if you use caches, there's always the question of what happens in the case of a power outage (as in, the battery just popped off). Journaling allows to go back quickly to a reasonable state 99.9% of the time (at least). To the point that the user will probably not notice the problem.
Incidentally, a jfs does _not_ protect against disk crashes at all, it is not designed for that. If you want protection against (most) disk crashes, what you need is RAID.
Actually, if you want very reasonable data security without daily backups, especially given the current cost of large disks and comparable-size backup systems, you probably need a jfs+raid combination.
OG.
Injurious?
Al is currently rewriting half of vfs because of the devfs integration, mind you. Which tends to make 2.3.99-pre* badly unstable (as in, 2-3 weeks ago half of the time you couldn't unmount some of the filesystems). This is going to push back 2.4 even more...
OG.
Never played with pervasive interfaces for now, heh?
The Trek interface has two major points right, at least:
- A keyword to have it to start listening for commands, i.e. they always start their interactions with "Computer"[1]
- An voice acknowledgement of all commands ("Processing", etc...) as soon as they are understood
The only really unrealistic part in there is the blinkenlight orgy.
OG, creating real-world trek-like interfaces for a living
[1] Our is called "Scooby", though
..but rather the start up software. I.e., a CD (or a DVD, I don't know, I don't own one).
That sucks for Sony, but it is definitively not as bad as having to recall the consoles themselves.
OG.
DVDs can only do 25 or 29.97 fps. Not 24.
OG.
...an especially appropriate strip.
:-)
The whole archive is here, and the original strip here.
OG.
PS: The author is obviously an Amiga lover too
They already did. The speed difference in FPU operations between the K6 and the Athlon is impressive, and I even often see an 500Mhz Athlon be somehow (feels 5-10%) faster than a 550Mhz PIII Xeon in some FPU intensive operations (mp3 compression with a nontrivial psychoacoustic model).
OG.
Count in hours of film, then.
DVDs are max 10Mb/s, usually arounf 6Mb/s. So these 75GB, that's ~28H of film. Not _that_ much if you think computerized VCR.
OG.
Please, tell us, what should we do?
OG.
You're missing one thing: the self-congratulating people usually aren't the ones who actually write the code. A real programmer always have something that itches him in his code.
.ifo files are one of the most perverted format I've ever played with :-)
So leave 'em out of our way bragging, and let's go back to the code.
OG.
PS: The