It runs MUCH better with XP than it did back in the 98 days. I currently use it on one of my logins to get a true OSX Panther window-look (uxtheme doesn't allow moving the buttons).
1080p30 = 1080i60 in terms of bandwidth. When talking in terms of complete frames, 1080p30 and 1080i60 are *exactly* the same. You can convert 1080i60 into 1080p30 pixel-for-pixel, but you'll have mice teeth on playback since 30fps sources are usually displayed frame-doubled on 60Hz displays, and you'd have to bob the video to display it smoothly at 60fps, since the original was at 60 fields/sec.
it seems you are implying that 720p is a higher resolution than 1080i.
No, they were right, but the term 'refresh' should really not have been used. 1080i has 540 lines per field - 540 per odd field and 540 per even field, displayed alternately on a screen refreshed at 60Hz. 720p has 720 lines per frame, and 720p supports 60fps operation on a screen refreshed at 60Hz. It also supports 30fps operation on a screen refreshed at 60Hz, frame-doubled.
With 1080i, the fields can be combined into a full frame, and you get the whole 1080 lines of resolution, but it comes from two distinct moments in time, and each of these distinct moments is only captured with 540 lines of the full 1080 lines of resolution. With 720p, each distinct moment in time is captured with the full 720 lines of resolution. So yes, 720p does have more temporal resolution than 1080i.
Also notice that I say 'lines of resolution' to mean literally what it says, and not the traditional video meaning of the term, which is too complicated to describe here, and should only be applied to digital video when attempting to compare it with NTSC.
If that's so, then why can we tell a difference between 24fps video (whether telecined or not) and 60fps? The only reason 24fps looks anywhere close to fluid is because of the presence of motion blur. Given otherwise identical content, 60fps is much more fluid than 24fps.
And yes, if we could do 120fps, without otherwise lowering the quality of the stream, I'd recommend it. We definitely don't have the bandwidth for it now. We *do* have the bandwidth to broadcast 60 discrete frames per second, as every station transmitting 720p is currently doing.
Perhaps for low-motion material, and material such as that shot for Discovery, 1080i might be best from a pure resolution standpoint. But for sports, music events, and generally any content with high motion, 720p should be preferred, as it gives a higher vertical resolution per 1/60th of a second (720p has 720 lines, 1080i has only 540). Also (and this doesn't apply to broadcast video, but would apply with an HD video format for the home), still images should always be stored at a 1080 line height, as this provides for native output with either 1080i or 1080p, and resampled output with 720p or lower.
Converting 480i to 480p isn't as graceful as you make it sound. I do this sort of stuff for a living, and there is no justification for "mice teeth" in video, ever. If you have to convert to progressive, far better to use interpolation filters during encoding, rather than using bob or weave in the receiver. Interlacing, while it definitely does suck on projected images, is still a good idea for TVs and you're wrong, it was not used as a cheap analog way of compressing the signal at a 1:2 ratio. It was used as a way to get rid of flicker on your TV. 30 frames per second simply isn't fast enough when shown on a CRT Tube. The image has a very noticable flicker. Using 60 fields, and showing them interlaced, promptly doubled the number of pictures visible on screen, and cut the flicker in half. It's still visible if you look, but for the most part, it's fine. Unless of course you have a very big TV, but then again, the NTSC standard was never meant to be seen on anything bigger than 12" anyway.
Well, we're both right on the original reason for interlacing, really. Of course 30Hz would have been a horrible refresh rate, but yet there wasn't enough bandwidth for a progressive 60fps signal. So, to compromise, the frame was split into fields to allow a 60fps motion rate and increase the total vertical resolution available at such a speed. Also, interlacing is clearly visible on even a small TV - but that's more the fault of graphics designers who think nothing of using one or two pixel horizontal lines with absolutely no interlace compensation.
I'll agree that the current use of interlacing in DTT is pretty much a religious issue - I hate interlacing for exactly the reason you probably at least have *some* dislike for it, because it makes it hard to display properly on a progressive display. I might agree that, in a professional setting, mice teeth aren't wanted. However, when archiving existing 480i material on a progressive medium, at high bitrates, I feel the best approach is to encode the material with no deinterlacing done during processing, followed by encoding with a codec that supports the necessary metadata to denote progressive/interlaced and top/bottom field first (to deal with the specific capture device used). Then, you record the closest signal you can to the original video, and thus can utilize better deinterlacing methods that mature in the future. Plus, at least on an LCD monitor, I've found that bobbing looks way better than many people claim it to - there is an almost imperceptible loss in vertical sharpness, but the increased motion fluidity more than makes up for this. I'll also agree that it mainly depends on the original source of the material in the first place - definitely the best thing to do with a telecined 24fps source is to reconstruct the original 24fps as best you can with IVTC techniques. Also, there is material that is recorded at 29.97fps progressive and recorded on standard NTSC videotape - this material can simply be archived as progressive, of course. But for native 480i material, and for the purpose of archiving, I feel that no processing (other than color correction and blemish removal, if desired) should be done to deinterlace the material prior to encoding. For production and broadcast, I agree that deinterlacing is a good idea, however.
Also, you're wrong that TV is locked into MPEG2 for DTT. The DTT doesn't really care what the compression scheme is, as long as it fits into the TS (transport stream) and that the receiver can decode it, so I think it's only a matter of time before some cable or satellite companies start using MPEG4 for at least some of their channels.
Well, by DTT, I of course meant Digital Terrestrial Television, so I'm not referring to cable or satellite at all. I'm merely referring to the ATSC requirement to broadcast at least one MPEG-2 stream. Not necessarily the use of MPEG-2 currently, as I realize it's quite mature. However, I don't know that the ATSC is so open-ended as to
You're probably both right on that, I'm pretty sure that 720p can be either 60fps or 30fps. I think it can also be 59.94fps or 29.97fps as well, but this is probably just used when upconverting NTSC material.
I've never heard about the duopoly issue with DTV channel assignments. It is my impression that every analog broadcast channel is entitled to a DTV channel as well during the transition. Do you have a reference on this?
My reference is the station I work for =P
We have two primary stations, an ABC affiliate and a UPN affiliate. Now, I would assume that part of this issue is because our UPN affiliate is a former LP station, now CA. And I am unsure if there are any duopolies with two full power stations (perhaps in larger markets, this is the 92nd DMA). However, we have a single DTV allotment that we run 1 HD stream (ABC HD or upconverted NTSC, depending on the hours), 1 SD stream at a good bitrate (the UPN station), a lower-bitrate SD stream that carries ABC News Now, and a couple of extra audio streams. I don't know the numbers, but I'm under the impression that we don't have much available bandwidth currently. There is absolutely no way we could carry UPN in HD, with our fulltime HD stream for the ABC station.
Again, I am unsure if there are duopolies that have two fullpower NTSC stations, and I am also unsure if any such stations would be entitled to two ATSC allotments. However, for any duopolies that incorporate an LP/CA station, they're getting screwed hard.
About the MPEG-2 issue - I agree with your points, but as I understand it, there wasn't much room left for the allowance of using a newer codec on your primary stream as they mature. I also understand that broadcasters can pretty much send out what they want, as long as they broadcast one MPEG-2 stream (SD or HD). But still, that MPEG-2 can take up a good chunk of your stream, if you run it at any quality rate. I'm not so much peeved at the simple fact that MPEG-2 is the primary codec in use *currently*, however - I'll definitely agree that MPEG-2 is the most mature codec in major use currently, at the average bitrates used.
Perhaps I'm just over-worried a bit about it. I don't discount the possibility that ATSC will make room for a different primary codec when (if) they mature and produce good live results. I also understand that realtime live encoding will never be as high quality as a good multipass offline encoder that can gain from bidirectional encoding - live encoders will never win this simply because they can't see in the future (unless the video is delayed a few frames, to allow the encoder to do some bidirectional encoding, but then it's not technically a 'live' encoder in the strictest sense of the word).
I don't see that as a problem. 720p is the current top-end for "real" HD. 1080i is not "real" in my eyes because it is interlaced.
It's time we dropped interlacing completely (funnily enough, I was told that was one of the big benefits to digital, that you get 60 discrete full-resolution frames per second, and not 59.94 or 29.97 or some fucked up number). Had I been in charge of the FCC, when CBS threatened to pull their HD over the broadcast flag, I'd have told them, "hahaha, go ahead and pull it, 1080i sucks cock anyway, and so does the broadcast flag".
Plus, devices that are natively 1080i will have to upconvert 720p, which will cause an immediate resolution loss of 1/2 the full 1080i pixel array, since you're converting from 60 full frames per second, to 60 fields per second. And that's not even figuring in the resizing process from 1920x1080 to 1280x720.
I'd rather see 1080i downconverted to 720p, so that the 720p signal will run at native resolution . 720p is the current sweet spot for quality in HDTV, and people completely miss it because "1080 is bigger, durrrrr".
Interlacing should have NEVER BEEN ALLOWED INTO THE DIGITAL STANDARD AT ALL. Legacy interlaced material running at 59.94 fields/sec can be converted to 480p/29.97fps with absolutely NO loss, only problem is you get mice teeth (but they could just bob it in the receiver). For material shot and produced for HD, there should NEVER be any interlacing, EVER. Interlacing was only used as a cheap analog way of compressing the signal at a 1:2 ratio. Now that we have the bandwidth, there is no reason we can't have 60 discrete frames per second.
Oh, and don't even get me started on why we are already locked into MPEG-2 for DTT, despite the availability of better compression methods. Or why companies that broadcast on two separate NTSC licenses (commonly known as 'duopolies') are only being given one 19Mbps ATSC license? Due to this, such companies can NOT offer true HD for both stations. If the analog side of your station broadcasts on two 6MHz channels (discounting translators, etc - just the main transmitter), then you should get two 19Mbps ATSC licenses, point blank.
Digital TV sucks. It will be the end of television, as we know it. Mark my words.
I have the Sonic 1 music driver in an extracted form, to be placed in my first Genesis demo when I actually get around to writing it. So my demo will have the exact music from the game =P
What the hell are you doing talking about Sonic 2 2p mode, in the middle of a sentence about the SNES? Sonic 2 2p mode is done in 99% hardware and 1% software. The hardware part is the Genesis switching to interlace mode 2 (doubles the cell resolution to 8x16 pixels, thus doubling the vertical resolution). All the game had to do, was set up the bottom playfield at the right time on the screen. It was no 'software trick', any more than water was in Sonic games. The Hblank IRQ is a hardware feature, and is what was used to set up both water AND 2p mode.
If the 'flickered insanely' you are referring to is just standard interlace flicker, then that's not a fault of any system that connects to a standard TV set - it's just the way things are. Analog TV is interlaced at it's highest resolution, and some games took advantage of it. All current-gen consoles run interlaced now, but with the added colors and better graphics hardware, everything can be antialiased and won't flicker as much.
As others have said, this should not apply with the President. In fact, I'd go even further and say that ALL public appearances by ANY public servant should be PUBLIC DOMAIN, with no copyright at ALL. Whether it's on TV or not. That MtP with Bush? That segment should be PUBLIC DOMAIN. Butler's photograph? It should be PUBLIC DOMAIN.
Anything dealing with the likeness of any public servant should be public domain. I don't foresee this, alone, to be a full solution, but it's a start.
I'll have to concur on that one. Years ago, I had a WDC 6GB drive. After having it for several years, it suddenly just refused to spin up. WDC replaced this with a brand new 6GB drive at no cost to me, all I had to do was get an RMA.
The thing is, you won't see the big names in news run such a story, because they're owned by the very people who WANT this legislation to go through.
If anything, LOCAL news needs to pick this story up. If we were still doing newscasts at my station, I'd try to get them to run it. But since our newscasts now come from 20 miles away, there's not much I can do.
That Flesh For Fantasy digi must have been one of the most widespread, because I've seen multiple copies of it turn up (I've also seen it with the filename 'Flash 4 Fantasy', IIRC).
And the flickering, at least in the case of Flesh For Fantasy, was the result of the replay routine writing the 4-bit digi samples to the border register as well as the SID volume register. The screen was disabled to remove badlines (otherwise the sound would glitch a bit every 8 scanlines as the VIC eats 40 cycles up of the normal 63/65 per line), and that's pretty much the extent of the visual effects with such a digi player.
In the case of most other demos, you're right though. PAL machines have 63 cycles per line and NTSC machines have 65. PAL machines also have 312 scanlines, while NTSC only has 263. NTSC does have more raw cycles per second, due to the higher framerate, but the lower scanline count means you can't do as much per frame, which lessens the oneframed demo effects you can do.
That's a decent idea, but in the mean time, if they need to access a 'new' site, they have to go hrough this process of visiting the site, being told it's blocked, then waiting for you to whitelist it.
Perhaps you could rig up a way to contact you over an IM session and report the blocked URLs in real time? Then, if the site was legitimate, you could unblock it right then instead of having to wait until the next day?
The only other option to fully control what they see, is to never allow them on the internet without you being present in the room.
Although, it's your hardware, you run it however you want, since there's no perfect solution, you'll always be able to say 'but there's x, y, and z problems with this solution' no matter WHAT you do.
What if a woman WANTS to be a so-called 'sex object'? How does that negate their emotions or humanity at all if she enters into such a situation willingly and of her own volition?
As long as you keep that belief to yourself and don't try to force it on anyone, you're more than welcome to PERSONALLY dislike porn. Where many people who agree with you fail, is that they try to FORCE it on others through laws, censorship, delaying of live TV broadcasts, and then this stupid COPA law.
So you're saying that should trump the right of someone to willingly appear in porn? That if I want to show my dick to interested parties, I can't, because I'm then somehow 'less than human', despite the fact that I chose to show my cock?
Every argument I've seen against porn in general has always been either wishy-washy and nonspecific, or Biblical in nature. Neither of those are valid reasons to have ANY laws regarding porn. If you can give me SPECIFIC examples of how porn can be dehumanizing, then I might entertain such a notion. But that won't happen anytime soon because THERE ARE NO EXAMPLES.
Filtering software should not be used by ANYONE unless it has a fully OPEN blacklist that the parents can double check and make sure there are no legitimate sites being blocked.
Or you can just say "Ok, this computer doesn't block any websites, but I will check the logs, and if you visit any sites that I feel are questionable, we're going to have a little talk." This is the best way because it leaves total control in YOUR hands, and there's no chance of a bad blacklist blocking a legitimate site.
No, that's COPPA. As far as I know, it's still in effect, and it only restricts commercial sites that want to obtain personal information from someone under 13. If you run a noncommercial message board and don't ask for any personal information, then you don't have to worry about COPPA.
This is a straw man argument argument. Anything properly done, when running in interlace, still looks just as smooth on a standard NTSC CRT. You don't believe me? Look at Sonic 2 on the Genesis - it's 2p mode uses hardware interlace - one of the few uses of true interlace in the 16-bit era.
But to be properly done, the best resolution to use is one with 480 scanlines, and enlarge the original image by EXACTLY 2x, with no filters. You might be able to fudge a little bit on the horizontal width, but you can NOT mess with the vertical size, or it WILL look like shit.
Properly done, it should look equally good on progressive AND interlaced.
Fine. Then they can implement a proprietary tag that will allow the developer to set 'compatibility' mode. If the page needs the current buggy rendering to appear properly, the developer need only add the tag. Hell, with many CMS's, it would be quite easy to add the tag once and have it apply to every dynamic page generated (static pages as well, if you use includes).
And the default mode should be 'strict standards'. Then, when this new IE version has been around for a while, and maybe even some version number bumps, standards-based coding will be much more prevalent. Microsoft can still have their proprietary stuff if they really need it (ActiveX pretty much), while still rendering standards-based sites correctly without requiring brainless hacks that only complicate web development and hinder the state of the Web as whole.
I know IE6 has something similar to this, that triggers on the DOCTYPE used, but it's my understanding that this is dodgy as hell, whereas the method I am proposing would be explicit and straightforward, not to mention it wouldn't break compatibility with other browsers that don't need the tag.
The only problem is, this would break pages that rely on the buggy rendering, and that are no longer being updated or maintained. But I think that is a small price to pay, to move towards standards-based web development. The requirement to incorporate hacks in your code for IE has precluded me from doing professional web development, as a personal decision. There are an assload of other industries that simply would fall apart without standards, and I don't see how the web development industry has made it as far as it has, with all the hoops that you have to jump through just to get a site that displays properly on the two most commonly used browsers. Especially if you want to use advanced features like transparent PNGs.
Slashdot Mirror
Old my ass.
It runs MUCH better with XP than it did back in the 98 days. I currently use it on one of my logins to get a true OSX Panther window-look (uxtheme doesn't allow moving the buttons).
1080p30 = 1080i60 in terms of bandwidth. When talking in terms of complete frames, 1080p30 and 1080i60 are *exactly* the same. You can convert 1080i60 into 1080p30 pixel-for-pixel, but you'll have mice teeth on playback since 30fps sources are usually displayed frame-doubled on 60Hz displays, and you'd have to bob the video to display it smoothly at 60fps, since the original was at 60 fields/sec.
- it seems you are implying that 720p is a higher resolution than 1080i.
No, they were right, but the term 'refresh' should really not have been used. 1080i has 540 lines per field - 540 per odd field and 540 per even field, displayed alternately on a screen refreshed at 60Hz. 720p has 720 lines per frame, and 720p supports 60fps operation on a screen refreshed at 60Hz. It also supports 30fps operation on a screen refreshed at 60Hz, frame-doubled.With 1080i, the fields can be combined into a full frame, and you get the whole 1080 lines of resolution, but it comes from two distinct moments in time, and each of these distinct moments is only captured with 540 lines of the full 1080 lines of resolution. With 720p, each distinct moment in time is captured with the full 720 lines of resolution. So yes, 720p does have more temporal resolution than 1080i.
Also notice that I say 'lines of resolution' to mean literally what it says, and not the traditional video meaning of the term, which is too complicated to describe here, and should only be applied to digital video when attempting to compare it with NTSC.
If that's so, then why can we tell a difference between 24fps video (whether telecined or not) and 60fps? The only reason 24fps looks anywhere close to fluid is because of the presence of motion blur. Given otherwise identical content, 60fps is much more fluid than 24fps.
And yes, if we could do 120fps, without otherwise lowering the quality of the stream, I'd recommend it. We definitely don't have the bandwidth for it now. We *do* have the bandwidth to broadcast 60 discrete frames per second, as every station transmitting 720p is currently doing.
Perhaps for low-motion material, and material such as that shot for Discovery, 1080i might be best from a pure resolution standpoint. But for sports, music events, and generally any content with high motion, 720p should be preferred, as it gives a higher vertical resolution per 1/60th of a second (720p has 720 lines, 1080i has only 540). Also (and this doesn't apply to broadcast video, but would apply with an HD video format for the home), still images should always be stored at a 1080 line height, as this provides for native output with either 1080i or 1080p, and resampled output with 720p or lower.
Interlacing, while it definitely does suck on projected images, is still a good idea for TVs and you're wrong, it was not used as a cheap analog way of compressing the signal at a 1:2 ratio. It was used as a way to get rid of flicker on your TV.
30 frames per second simply isn't fast enough when shown on a CRT Tube. The image has a very noticable flicker. Using 60 fields, and showing them interlaced, promptly doubled the number of pictures visible on screen, and cut the flicker in half. It's still visible if you look, but for the most part, it's fine. Unless of course you have a very big TV, but then again, the NTSC standard was never meant to be seen on anything bigger than 12" anyway.
Well, we're both right on the original reason for interlacing, really. Of course 30Hz would have been a horrible refresh rate, but yet there wasn't enough bandwidth for a progressive 60fps signal. So, to compromise, the frame was split into fields to allow a 60fps motion rate and increase the total vertical resolution available at such a speed. Also, interlacing is clearly visible on even a small TV - but that's more the fault of graphics designers who think nothing of using one or two pixel horizontal lines with absolutely no interlace compensation.
I'll agree that the current use of interlacing in DTT is pretty much a religious issue - I hate interlacing for exactly the reason you probably at least have *some* dislike for it, because it makes it hard to display properly on a progressive display. I might agree that, in a professional setting, mice teeth aren't wanted. However, when archiving existing 480i material on a progressive medium, at high bitrates, I feel the best approach is to encode the material with no deinterlacing done during processing, followed by encoding with a codec that supports the necessary metadata to denote progressive/interlaced and top/bottom field first (to deal with the specific capture device used). Then, you record the closest signal you can to the original video, and thus can utilize better deinterlacing methods that mature in the future. Plus, at least on an LCD monitor, I've found that bobbing looks way better than many people claim it to - there is an almost imperceptible loss in vertical sharpness, but the increased motion fluidity more than makes up for this. I'll also agree that it mainly depends on the original source of the material in the first place - definitely the best thing to do with a telecined 24fps source is to reconstruct the original 24fps as best you can with IVTC techniques. Also, there is material that is recorded at 29.97fps progressive and recorded on standard NTSC videotape - this material can simply be archived as progressive, of course. But for native 480i material, and for the purpose of archiving, I feel that no processing (other than color correction and blemish removal, if desired) should be done to deinterlace the material prior to encoding. For production and broadcast, I agree that deinterlacing is a good idea, however.
Well, by DTT, I of course meant Digital Terrestrial Television, so I'm not referring to cable or satellite at all. I'm merely referring to the ATSC requirement to broadcast at least one MPEG-2 stream. Not necessarily the use of MPEG-2 currently, as I realize it's quite mature. However, I don't know that the ATSC is so open-ended as to
You're probably both right on that, I'm pretty sure that 720p can be either 60fps or 30fps. I think it can also be 59.94fps or 29.97fps as well, but this is probably just used when upconverting NTSC material.
- I've never heard about the duopoly issue with DTV channel assignments. It is my impression that every analog broadcast channel is entitled to a DTV channel as well during the transition. Do you have a reference on this?
My reference is the station I work for =PWe have two primary stations, an ABC affiliate and a UPN affiliate. Now, I would assume that part of this issue is because our UPN affiliate is a former LP station, now CA. And I am unsure if there are any duopolies with two full power stations (perhaps in larger markets, this is the 92nd DMA). However, we have a single DTV allotment that we run 1 HD stream (ABC HD or upconverted NTSC, depending on the hours), 1 SD stream at a good bitrate (the UPN station), a lower-bitrate SD stream that carries ABC News Now, and a couple of extra audio streams. I don't know the numbers, but I'm under the impression that we don't have much available bandwidth currently. There is absolutely no way we could carry UPN in HD, with our fulltime HD stream for the ABC station.
Again, I am unsure if there are duopolies that have two fullpower NTSC stations, and I am also unsure if any such stations would be entitled to two ATSC allotments. However, for any duopolies that incorporate an LP/CA station, they're getting screwed hard.
About the MPEG-2 issue - I agree with your points, but as I understand it, there wasn't much room left for the allowance of using a newer codec on your primary stream as they mature. I also understand that broadcasters can pretty much send out what they want, as long as they broadcast one MPEG-2 stream (SD or HD). But still, that MPEG-2 can take up a good chunk of your stream, if you run it at any quality rate. I'm not so much peeved at the simple fact that MPEG-2 is the primary codec in use *currently*, however - I'll definitely agree that MPEG-2 is the most mature codec in major use currently, at the average bitrates used.
Perhaps I'm just over-worried a bit about it. I don't discount the possibility that ATSC will make room for a different primary codec when (if) they mature and produce good live results. I also understand that realtime live encoding will never be as high quality as a good multipass offline encoder that can gain from bidirectional encoding - live encoders will never win this simply because they can't see in the future (unless the video is delayed a few frames, to allow the encoder to do some bidirectional encoding, but then it's not technically a 'live' encoder in the strictest sense of the word).
I don't see that as a problem. 720p is the current top-end for "real" HD. 1080i is not "real" in my eyes because it is interlaced.
It's time we dropped interlacing completely (funnily enough, I was told that was one of the big benefits to digital, that you get 60 discrete full-resolution frames per second, and not 59.94 or 29.97 or some fucked up number). Had I been in charge of the FCC, when CBS threatened to pull their HD over the broadcast flag, I'd have told them, "hahaha, go ahead and pull it, 1080i sucks cock anyway, and so does the broadcast flag".
Plus, devices that are natively 1080i will have to upconvert 720p, which will cause an immediate resolution loss of 1/2 the full 1080i pixel array, since you're converting from 60 full frames per second, to 60 fields per second. And that's not even figuring in the resizing process from 1920x1080 to 1280x720.
I'd rather see 1080i downconverted to 720p, so that the 720p signal will run at native resolution . 720p is the current sweet spot for quality in HDTV, and people completely miss it because "1080 is bigger, durrrrr".
Interlacing should have NEVER BEEN ALLOWED INTO THE DIGITAL STANDARD AT ALL. Legacy interlaced material running at 59.94 fields/sec can be converted to 480p/29.97fps with absolutely NO loss, only problem is you get mice teeth (but they could just bob it in the receiver). For material shot and produced for HD, there should NEVER be any interlacing, EVER. Interlacing was only used as a cheap analog way of compressing the signal at a 1:2 ratio. Now that we have the bandwidth, there is no reason we can't have 60 discrete frames per second.
Oh, and don't even get me started on why we are already locked into MPEG-2 for DTT, despite the availability of better compression methods. Or why companies that broadcast on two separate NTSC licenses (commonly known as 'duopolies') are only being given one 19Mbps ATSC license? Due to this, such companies can NOT offer true HD for both stations. If the analog side of your station broadcasts on two 6MHz channels (discounting translators, etc - just the main transmitter), then you should get two 19Mbps ATSC licenses, point blank.
Digital TV sucks. It will be the end of television, as we know it. Mark my words.
I do.
YES!
;_;
I miss ANIM7
Hum it? HUM IT?
I have the Sonic 1 music driver in an extracted form, to be placed in my first Genesis demo when I actually get around to writing it. So my demo will have the exact music from the game =P
What the hell are you doing talking about Sonic 2 2p mode, in the middle of a sentence about the SNES? Sonic 2 2p mode is done in 99% hardware and 1% software. The hardware part is the Genesis switching to interlace mode 2 (doubles the cell resolution to 8x16 pixels, thus doubling the vertical resolution). All the game had to do, was set up the bottom playfield at the right time on the screen. It was no 'software trick', any more than water was in Sonic games. The Hblank IRQ is a hardware feature, and is what was used to set up both water AND 2p mode.
If the 'flickered insanely' you are referring to is just standard interlace flicker, then that's not a fault of any system that connects to a standard TV set - it's just the way things are. Analog TV is interlaced at it's highest resolution, and some games took advantage of it. All current-gen consoles run interlaced now, but with the added colors and better graphics hardware, everything can be antialiased and won't flicker as much.
As others have said, this should not apply with the President. In fact, I'd go even further and say that ALL public appearances by ANY public servant should be PUBLIC DOMAIN, with no copyright at ALL. Whether it's on TV or not. That MtP with Bush? That segment should be PUBLIC DOMAIN. Butler's photograph? It should be PUBLIC DOMAIN.
Anything dealing with the likeness of any public servant should be public domain. I don't foresee this, alone, to be a full solution, but it's a start.
I'll have to concur on that one. Years ago, I had a WDC 6GB drive. After having it for several years, it suddenly just refused to spin up. WDC replaced this with a brand new 6GB drive at no cost to me, all I had to do was get an RMA.
./ renders fine in Firefox for me. Need a screenshot?
The thing is, you won't see the big names in news run such a story, because they're owned by the very people who WANT this legislation to go through.
If anything, LOCAL news needs to pick this story up. If we were still doing newscasts at my station, I'd try to get them to run it. But since our newscasts now come from 20 miles away, there's not much I can do.
Oh, and hi SMT =P
Um, my C64 is extremely reliable, it still works perfectly. Can't say that about my 'modern' 300MHz PC, it's sitting here with a dead PSU.
That Flesh For Fantasy digi must have been one of the most widespread, because I've seen multiple copies of it turn up (I've also seen it with the filename 'Flash 4 Fantasy', IIRC).
And the flickering, at least in the case of Flesh For Fantasy, was the result of the replay routine writing the 4-bit digi samples to the border register as well as the SID volume register. The screen was disabled to remove badlines (otherwise the sound would glitch a bit every 8 scanlines as the VIC eats 40 cycles up of the normal 63/65 per line), and that's pretty much the extent of the visual effects with such a digi player.
In the case of most other demos, you're right though. PAL machines have 63 cycles per line and NTSC machines have 65. PAL machines also have 312 scanlines, while NTSC only has 263. NTSC does have more raw cycles per second, due to the higher framerate, but the lower scanline count means you can't do as much per frame, which lessens the oneframed demo effects you can do.
I mentioned that right afterwards, dipshit.
That's a decent idea, but in the mean time, if they need to access a 'new' site, they have to go hrough this process of visiting the site, being told it's blocked, then waiting for you to whitelist it.
Perhaps you could rig up a way to contact you over an IM session and report the blocked URLs in real time? Then, if the site was legitimate, you could unblock it right then instead of having to wait until the next day?
The only other option to fully control what they see, is to never allow them on the internet without you being present in the room.
Although, it's your hardware, you run it however you want, since there's no perfect solution, you'll always be able to say 'but there's x, y, and z problems with this solution' no matter WHAT you do.
What if a woman WANTS to be a so-called 'sex object'? How does that negate their emotions or humanity at all if she enters into such a situation willingly and of her own volition?
As long as you keep that belief to yourself and don't try to force it on anyone, you're more than welcome to PERSONALLY dislike porn. Where many people who agree with you fail, is that they try to FORCE it on others through laws, censorship, delaying of live TV broadcasts, and then this stupid COPA law.
So you're saying that should trump the right of someone to willingly appear in porn? That if I want to show my dick to interested parties, I can't, because I'm then somehow 'less than human', despite the fact that I chose to show my cock?
Every argument I've seen against porn in general has always been either wishy-washy and nonspecific, or Biblical in nature. Neither of those are valid reasons to have ANY laws regarding porn. If you can give me SPECIFIC examples of how porn can be dehumanizing, then I might entertain such a notion. But that won't happen anytime soon because THERE ARE NO EXAMPLES.
Filtering software should not be used by ANYONE unless it has a fully OPEN blacklist that the parents can double check and make sure there are no legitimate sites being blocked.
Or you can just say "Ok, this computer doesn't block any websites, but I will check the logs, and if you visit any sites that I feel are questionable, we're going to have a little talk." This is the best way because it leaves total control in YOUR hands, and there's no chance of a bad blacklist blocking a legitimate site.
No, that's COPPA. As far as I know, it's still in effect, and it only restricts commercial sites that want to obtain personal information from someone under 13. If you run a noncommercial message board and don't ask for any personal information, then you don't have to worry about COPPA.
This is a straw man argument argument. Anything properly done, when running in interlace, still looks just as smooth on a standard NTSC CRT. You don't believe me? Look at Sonic 2 on the Genesis - it's 2p mode uses hardware interlace - one of the few uses of true interlace in the 16-bit era.
But to be properly done, the best resolution to use is one with 480 scanlines, and enlarge the original image by EXACTLY 2x, with no filters. You might be able to fudge a little bit on the horizontal width, but you can NOT mess with the vertical size, or it WILL look like shit.
Properly done, it should look equally good on progressive AND interlaced.
Fine. Then they can implement a proprietary tag that will allow the developer to set 'compatibility' mode. If the page needs the current buggy rendering to appear properly, the developer need only add the tag. Hell, with many CMS's, it would be quite easy to add the tag once and have it apply to every dynamic page generated (static pages as well, if you use includes).
And the default mode should be 'strict standards'. Then, when this new IE version has been around for a while, and maybe even some version number bumps, standards-based coding will be much more prevalent. Microsoft can still have their proprietary stuff if they really need it (ActiveX pretty much), while still rendering standards-based sites correctly without requiring brainless hacks that only complicate web development and hinder the state of the Web as whole.
I know IE6 has something similar to this, that triggers on the DOCTYPE used, but it's my understanding that this is dodgy as hell, whereas the method I am proposing would be explicit and straightforward, not to mention it wouldn't break compatibility with other browsers that don't need the tag.
The only problem is, this would break pages that rely on the buggy rendering, and that are no longer being updated or maintained. But I think that is a small price to pay, to move towards standards-based web development. The requirement to incorporate hacks in your code for IE has precluded me from doing professional web development, as a personal decision. There are an assload of other industries that simply would fall apart without standards, and I don't see how the web development industry has made it as far as it has, with all the hoops that you have to jump through just to get a site that displays properly on the two most commonly used browsers. Especially if you want to use advanced features like transparent PNGs.