131–138 of 138 posts
Earlier quoted context omitted.
I'd find completely awesome if it weren't for tools aimed at killing people. I'm not sure I enjoy advances in that area.
It's just as easy to say it is a tool designed to save lives. Ultimately it's a tool, it's how you use it that's important.
Earlier quoted context omitted.
They couldn't bother to cite the image apparently but it's from a web comic called Gunshow
Those two panels are well-known as a meme image, over probably the past 4 years. Memes tend to transcend their original source; that's probably why the image wasn't properly cited.
If KC Green made an image macro and posted it on Reddit it would be one thing. But they didn't, they made a comic and put it on their own site.
I can't speak for KC but it's just bad taste not to cite things that are flat-out copyright somebody else.
Earlier quoted context omitted.
I agree with you in general, but I think it's worth pointing out that programming the NES's PPU is actually very similar to programming with a 2D graphics library today. NES games never wrote their own scrolling logic, or there own graphics logic. They wrote tile values into a background table and then told the NES how much to scroll the playing field, and the NES rendered and scrolled everything automagically. NES g…
> NES games never drew their own sprites. They just said "Hey NES, write the sprite at this x and y location" Yeah, but the hardware is so limited with weird corner cases that writing a bitblt might be easier. For example, some games have to reconfigure their sprites at the beginning of every horizontal scan line to overcome the hardware limitation on simultaneously displayed sprites (8).
Earlier quoted context omitted.
Those two panels are well-known as a meme image, over probably the past 4 years. Memes tend to transcend their original source; that's probably why the image wasn't properly cited.
"it's a meme" isn't an excuse for not giving credit. If KC Green made an image macro and posted it on Reddit it would be one thing. But they didn't, they made a comic and put it on their own site. I can't speak for KC but it's just bad taste not to cite things that are flat-out copyright somebody else.
Earlier quoted context omitted.
It's just as easy to say it is a tool designed to save lives. Ultimately it's a tool, it's how you use it that's important.
Just as easy maybe, but fundamentally incorrect. Its mechanism of action is killing people -- choosing to believe the claim that killing those people will save lives alters neither the purpose nor MO of the tool.
Tools are, simply put, devices that increase a user's leverage.
We live in a world full of tools capable of leveraging against life. We also live in a world with individuals and groups who - for whatever reasons - choose to use that leverage.
We can't get rid of tools like this. They are very straightforward inventions, especially as technical knowledge increases. The simplest nuclear fission reactor is a bomb. That does not make nuclear fission fundamentally worthless, and whether you agree that knowledge about it is a "good" or not, that knowledge is not going to simply disappear.
> choosing to believe the claim that killing those people will save lives alters neither the purpose nor MO of the tool.
How a tool is used does not change what it is or what it does. It does, however, define the purpose. If the purpose of killing someone is to prevent that individual from taking another life - or several other lives - then the purpose of the tool used is to save lives. The goal for perfecting a tool that is to be used for that purpose is to minimize the amount of lives taken, and damage done. That means a "better" bomb takes fewer lives, saving more.
If you choose to believe that an individual taking action against the life of another has not forfeit his/her own right to live, then you might consider this tool to have no legitimate purpose. Frankly, I disagree, and hope you will reconsider.
Earlier quoted context omitted.
> Nothing brings out creativity better than a limiting environment. This is so true as a life principle! I once read a book about the development of laser guided bombs [1], and in it it talked about how Texas Instruments made the first viable prototype [2] on a shoe-string budget even though they were competing against a large government contractor with a huge budget. Because of the budgetary constraints, TI couldn't…
I'd find completely awesome if it weren't for tools aimed at killing people. I'm not sure I enjoy advances in that area.
Earlier quoted context omitted.
Some things have been lost, though, and I'm not even referring to the usual claim about constraints facilitating creativity. Games of the 8- and 16-bit console generations, as well as all arcade games up until that point, were written with CRT monitors in mind and often used 'racing the beam' techniques. This resulted in games with extremely low latency, something you never find in a game of any sort today. The diffe…
> Games of the 8- and 16-bit console generations, as well as all arcade games up until that point, were written with CRT monitors in mind and often used 'racing the beam' techniques. This resulted in games with extremely low latency, something you never find in a game of any sort today. The techniques haven't been lost - if anything there are probably more people who know how to do those things today than there were…
I would expect the NES to perform similarly to the Apple, since it has the same CPU (6502) and also uses a CRT display.
Earlier quoted context omitted.
> NES games never drew their own sprites. They just said "Hey NES, write the sprite at this x and y location" Yeah, but the hardware is so limited with weird corner cases that writing a bitblt might be easier. For example, some games have to reconfigure their sprites at the beginning of every horizontal scan line to overcome the hardware limitation on simultaneously displayed sprites (8).
Which games? To my knowledge this is at best exceptionally rare because there are only ~114 CPU cycles in a scan line. The reports I've heard are that if you do any OAM changes mid-frame, you get something like four lines of glitches. More common is to just do a full OAM DMA during vertical blank, at least from the ROMs I've seen.