What, no mention of COPYA, Muffin, Disk Muncher or Locksmith ?;-)
I still remember how Copy ][+ had 1 BIG sector on tracks 2 and 3. The thing loaded *FAST*.
"Cracking Techniques" was a bunch of text files describing how to break each game protection. It even had a 'tut on Copy ][+. Copy the ROM over to the language card. Modify the RAM so that reset would enter the "monitor" (built in disassembler on the Apple), and then finally make the 16K language read only. Copy ][+ never checked for the language card, so voila, you had a memory image. Moving the memory down so that DOS 3.3 wouldn't clobber it, and then BSAVE COPY ][+, A$800,L$8E00:) (Dos3.3 started at 0x9600)
> all those cool things...like modified TOC's....
Sad, that I still remember that the DOS3.3 TOC was on track 17 after all these years. I like how some games would embed control-chars in the filename.
{rant} My 8-bit Apple had 20 character filenames. Who's the dumbass that limits filenames to 8.3 in CPM and MSDOS ? {/rant}
> Half tracks....
The Apple drive was actually capable of 1/4 tracks. I believe Broderbund games made use of it. Write a small section on track 0. Increment to track 1/4, write another small section. Repeat. Normally, tracks were 4 quarter tracks apart, due to interference from data written on quarter tracks.
> Modified sector headers....
The thing that made Apple games disk so much fun to backup was that the drive couldn't write 2 consequetive zeros (aside from Sync Bytes, which was 0xFF, followed by two zero bits.) Ah, the days of 5+3 (13 sector tracks) and 6+2 encoding (16 sector tracks). For 6+2, you expand a sector of 256 bytes out to 384 bytes.) Some interesting technical info here http://www.enteract.com/~enf/afc/apple2
Then someone figured out that you *could* write a few "illegal" bytes, such as C5.
> having to use the nibble editor
Copy ][+ had a ton of options for it's nibble editor. And if you still couldn't make a backup, there was always the option of boot tracing the program. Remember how the first sector had to be delimited by D5 AA 96 because thats what the Disk Prom checked for.
Some interesting cracking technique from yore:
Wildcard and Replay were 2 interesting products. They generated a NMI and let you enter the disassembler. I wanted one, but found out that I didn't really need one after I learnt about that language card trick.
The other trick to "stop" a game, was to search for 30 C0, since that was the address of the speaker! (I was *so* thankfull Copy ][+ ver 7 added a search bytes function!) Change a few bytes, and now the game will stop when it tries to play a sound.;-)
> You've got to wonder, is this yet another load of Nvidia corporate hype (a la "HW TnL will revolutionise gaming")
Have you *even* done *any* 3d graphics programming?? HW TnL *offloads* work from the CPU to the GPU. The CPU is then free to spend on other things, such as AI. Work smarter, not harder.
I'm not sure what type of revolution you were expecting. Maybe you were expecting a much higher poly count with HW TnL, like 10x. The point is, we did get faster processing. Software TnL just isn't going to get the same high poly count that we're starting to see in today's games with HW TnL.
> it takes a few months till anyone really knows if this is good or bad.
If it means you don't have to waste your time writing *two* shaders (one for DX, and other for OpenGL) then that is a GOOD THING.
> but why do we have to spend twenty years devising languages that are not quite as good as Smalltalk (in the name of efficiency, or compatibility,
Now Smalltalk may great at certain things, but it isn't the end-all or be-all. There are *reasons* new languages get invented -- to solve a problem more elegantly / efficiently / compactly then older languages. Sometimes speed (runtime) DOES matter.
i.e. Let me know when I can use Smalltalk on the PS2. Until then, it's C++ and custom assembly, because when it comes to graphics, speed is more important then flexibility especially when you need to use every trick in the book to get a good framerate on consoles.
> Smalltalk is the only language I've ever used that I felt truly extended my reach as a programmer
That's great that the language maps to your problem domain. (Lucky B@$tard;-) In my line of work, Smalltalk would be one of the worst possible languages to use because it doesn't interface with the hardware efficiently. Use the right tool for the job, yada yada yada.
That's the great thing about programming in multiple languages -- you get to learn why they are better at solving certain problems then other languages.
Sorry if my rebuttal sounds a little harsh but your post sounded like the beginnings of a "Holy War" and it's hard to tell if you're jazzed about other languages.
"...as Neo runs through the old womens' apartment, an episode of "The Prisoner" (1967) is airing, with the image of one of the Number 2's (in a black coat). Furthermore, there are different Number 2's for nearly every episode, with Patrick McGoohan portraying Number 6."
I wonder what movie references Matrix 2 and 3 will include?
-- "Every person you meet has two things to teach you. Something about other people, and something about yourself"
- Anonymous
> There is no easier way to make code ugly and unreadable than to use hungarian notiation.
Using tradional HN I agree. See my above post for how I use a variation which I find usefull.
> nCount is not in anyway more readable that cnt,
Those are both bad examples. I don't like playing the guess-which-vowel-or-letters-I-left-out-of-the-var iable game. It's a waste of another programmers time.
nCount is redundant. Count doesn't tell you anything about the variable.
NumPlayers, MaxPlayers are much better descriptive examples.
I allways (when applicable) add a prefix to my variables that identifies the type. Name then becomes sName, etc.
I know this does not work for everybody,
Hehe, why are programmers so passionate about HN. Seems like coders tend to fall into 2 camps - they hate it, or they see the underlying merits, and use a modified version.
Years ago I absolutely hated Hungarian Notation. IMHO it was far too meticulousness - you spent more time trying to keep your variables up to date, then coding! (Ok, it wasn't that bad, but close.)
Does one *really* need to be that preverse about specifying the difference between byte, char, short, long, dword? Sheesh !
(Notice how this pattern shows up when you take any good idea / methodolgy and become a "zealot" about it, but I digress.) Most of the time you don't need to split hairs over ints, floats, bools, chars, strings, etc. You're just making busy-work for yourself.
That said, here's a heavily modified HN (namely a lot less restrictive) for C++ that I find extremely handy:
s static
g globals
_ member variables
There are a few variations on this:
Microsoft uses m_ (I don't care for this style, as this is too "wordy" IMHO),
Some of the well know C++ gurus (forgot if it was Eckel or Meyers) use a trailing _ (again too easy to miss IMHO)
p pointers
(s, g, _, p are always in this order)
I find these to be a good compromise:
n for any number / int / float
i index / iterator
a array
r reference
And since I'm dealing with so much 3D math I also use:
v vector
m matrix
q quaterions
To keep track of what I'm converting to/from.
~ 2 ~
Having a standardized coding standard at work has been a Good Thing (TM) in the long run. I didn't like it at first, (habits and all:) but it's made working on other peoples code easier.
~ 3 ~
I can't stress this next tip enough:
Use *descriptive* variables names.
A descriptive name almost takes away the need for comments (almost;-)
i.e.
If you iterating over a set, or range, say it !
for( iCard = 0; iCard < nCards; iCard++ )
~ 4 ~
Use whitespace. Align the columns of your tables up. There is a reason tables exist - to make it easier to read.
~ 5 ~
If you have a function that does some complex calculation, document where you got the formula from.
i.e. See Graphics Gems Volume N, Pages nn-nn
~ 6 ~
As you come up with ideas for how the block of code you're working on could be better, made more robust, effiecient, etc, put a comment:// TODO: rewrite so is cleaner
This way you can do a search to see which parts of the code needs to rewritten.
Cheers
--
"The issue today is the same as it has been throughout all history,
whether man shall be allowed to govern himself or be ruled by a small elite."
- Thomas Jefferson
Not a bad article - only one bugaboo (typo)
on
The Age of Nvidia
·
· Score: 2
Those features, with names like "stencil," "destination alpha," "full-time multitexture"
Not sure why the author used the adjective "full-time" because it doesn't mean aything. Maybe he meant single-pass to distinguish from multi-pass techniques.
Re:how about for non-comic viewers?
on
Review: Spiderman
·
· Score: 2
> Ok, here's how the movie is not like the Amazing Spider-man:
>{ snip }
Nice summary.
In the comics Peter Parker is always trying be friends with Liz, a high school classmate. In the movie it was Mary Jane, the next door neighor. The movie didn't have any mention of Betty Bryant either.
In the comics, the Green Goblin has the flying wings the *2nd* time he meets up with Spider-Man (first time was his flying broomstick.) Also, the GG was MUCH smaller -- like "goblin" size. Difference the movie had: someone who wore a metal suit that was bigger then Spider-Man.
It's interesting how the comic book would point out how most of the villians (And Spider-Man at times) used technology. i.e. Vulture uses anti-magneticism to fly, Spider-Man had "web cartridges", Spidey's beam of light that shows his face (ala Batman) etc.
Even though the movie was quite different from the comics, I enjoyed it. I think they did a great job re-telling the story. I too liked the foreshadowing with the criminal who took the wrestlers promoter money.
> But, last time I checked, when you share somebody else's stuff, it's called stealing.
That is a fallacy - you're logic is not valid due to your definitions being ambigious.
If I borrow a tool from my brother, and then lend it out to a friend, my friend isn't stealing.
It's called [physical] stealing when you take someone else's stuff WITHOUT their permission (And it logically follows: AND they don't have access to it while you have it.)
Now obviously digital stealing is NOT quite the same as physical theft since when digital assests are shared, the original owner still has access to the orginal. Digital theft is ALSO copyright violation, since you don't (YET!) have the right to copy it (or use it.)
Notice that buying an item is equivalent to paying for the "right" of use. Even if the item is free, doesn't mean you necessarily have the "right" to use it.
When I was submitting the story, I couldn't remember which 'C' word to use. I checked dictionary.com and found centrifugal. I wasn't quite sure if it was accurate, but I think its a more compact word (i.e. layman's usage) then "the destructive velocity tangent to the disc", so I used it.;-)
Sounds like you haven't read:
- "Desin and Evolution of C++" by Stroustrup and/or
- "Multi-Paradigm Design for C++" by James Coplien.
C++ is WAY better then C
1 - It's a better C (better type checking, cleans up that cruft with typedef struct {}, etc) 2 - Supports OOP synatix natively (Yes, you *can* do OOP in C, but it's tedious) 3 - Supports generic programming (templates)
> but the only thing that other languages taught me was how BAD C++ really is.
True enough. Also, interesting, is that when I learnt C++, it showed me how bad C is.
I agree learning multiple languages is always "A Good Thing" -- you get exposed to new idioms and design patterns.
> I believe in the original C language philosophy. Small, simple, fast, powerful.
So why not use just the C subset of C++? You'd gain all advantage and no disadvantages.
If I want to play a simulation, I want as much realism as possible. i.e.
Flight Sim, Driving Game, etc. i.e
If I hit a stationary object at high speed, my car should roll, tumble, and be smashed to pieces.
For other games, I want as much "fun" as possible *at the expense* of realism. i.e.
Diablo and Dungeon Siege don't have encumbrance. Why? Because it's tedious, and slows down the gameplay.
Fun and Realism are orthogonal concepts in games. A game can be:
1) Fun and unrealistic,
2) Fun and realistic
3) Unfun and Realistic
4) Unfun and unrealistic.
Confusing the two, shows a lack of understanding game design.
The hard part is trying to nail down how much realism a game needs.
> This is noting that having over 32MB of memory has proven to be of NO benefit in benchmarks outside of the occasional 1 or 2 FPS difference (and when you are getting over 100FPS any ways. . ..).
I agree.
> Texture size is REALLY not a problem.
It IS when your PC game is being ported to consoles and you ONLY have ~ 2.5 Megs of VRAM say like on a PS2 ! (Yes the PS2 has 4 Megs of VRAM, but you need space for the framebuffer and zbuffer.)
Now consoles make up for the lack of video memory by having a high bandwidth (i.e. PS2 can DMA ~20 Megs of Textures per frame) but I'd rather upload my textures ONCE, not every bloody frame. Yes, you be more efficient at texture uploads (draw the last model from the last frame, first this new frame, etc) but you're still tying up the BUS.
> The ONLY way to get good texturing done is to DISPENSE with the concept of textures all together.
I don't compeletely agree, but you raise an interesting point, because of the fact that textures are a form of (color) compression. If we take this to its logical conclusion we should be able to have a triangle PER pixel, and that would negate the need for textures. Unfortunately that has its own problems -- there's no way we can send a million vertices across because we'd saturate the bus! Doh! (Give a reward to the person in the back who said, well let's move to paramateric surfaces then!)
In the "Real World" (TM) we have a *unique* texture per pixel (ala ray tracing) however we don't have the memory to store that, unless we calculate them parametricaly. Sure we can get nice "marble" ala Perlin Noise, but it's going to be a while before we can mathmatically generate EVERY texture !
> But why do games look better you ask?
> Mostly because video cards have any number of fancy TnL units that can independently create some rather nifty effects while working AROUND or OUTSIDE of the plain old texturing model.
You'd be amazed at what multitexturing and multipass render does. Even a simple repeatable base texture with a "random" noise texture overlaid with a bump-map, looks OK.
> The color is an INTEGRAL PART of what an object is. You cannot separate the two.
You *can* get away with this, but you have to be aware of the tradeoffs. One common "solution" is to crank up the bit-depth.
i.e. If you use 16-bit color channels ala 64 bits per pixel, then you don't have to throw out your whole rendering functionality -- you just extend it. Not a perfect solution by any means, but "its good enough."
Take a look at "Titanic" The ship was rendered via tradional textures, and it looks pretty good. The hard part is getting that quality in real-time with so little memory;-)
Cheers
--
"The issue today is the same as it has been throughout all history,
whether man shall be allowed to govern himself or be ruled by a small elite." - Thomas Jefferson
Who needs a programming language, when a shell will do ! (Can't believe no one has posted this yet...;-) (I'd post the jokes, but the blood lameness filter prevents it.)
When will companies learn, that forcing advertising/spam onto customers does not help you get more customers. All it does is leave a bad taste in the ones they DO have, and gets the company known by word of mouth as one to avoid.. Similiar to how a bad game gets mentioned in usenet, and everyone stays away from it.
> Intellectual property is fundamental to the peaceful progress of such societies and, without them, everything does break down to the very concept of "might makes right" that RMS claims to fear now.
> Why do you elitist h4X0r5 immediately discount Visual Basic just cause it's easy to program in? I know for a fact that many corporations use VB for interfacing with electronics for testing and remote control through a serial data stream.
You've mixed up in ease of use with power. VB doesn't support multiple paradigm programming. C++ supports functional, object-orientated, and generic programming. When you use (and need) all 3, VB looks like a toy compared to C++. Does that mean you can't use VB for "real" apps? Of course not. Why use a complicated language when a simpler one willl do? It depends on your design and implementation constraints.
Secondarily, when VB runs on a PS2, XBox, or Gamecbue, let me know! For the field I'm in, game programming (PC & Console) assembly and C/C++ have no competition because performance is the 1st priority.
> Just cause you write something in a more difficult language such as C or C++ doesn't make you any more l33t if you wrote an easier program that accomplishes the same task with less headache in VB or LabView!
Very true. It's about using the right tools for the job.
> How many of you actually experienced OS/2's preemptive multitasking - compared to whatever it is that Windows has?
Which version of Windows?
Win3.1 -- cooperative multitasking
Win95/98 -- pre-emptive multitasking (but for only 32 bit apps) The 16-bit subsystem can stall the kernel, since Win32 is built on top of it.
WinNT/2K/XP -- pre-emptive as well. The Win16 subsystem is cooperative, since it emulates Win3.1, but can never stall the kernel, since it sits on top of Win32.
OS/2 pre-emptive multitasking isn't any better then NT's.
More power would be cool in the PS3. Something like having the GS as powerfull as a GeForce3 (Get we get a "real" stencil in the PS3 ?!)
Ignoring power for the moment, less complexity would be even better. It's a real b!tch having to manage ** 6 ** CPUs in parallel !! (EE, VU0, VU1, GS, IOP, and SPU) Throw in DMA transfers on top of that and it's enough to make a person pull their hair out.
> I've got OpenBSD running on a PPro 200 with 32 megs of RAM, and it's great.
Yeap, you certainly don't need much horsepower if you're running a firewall/server. Walnut Creek used to serve *thousands* of users off a T1 with their PPro 200 back in the mid 90s. I forget which BSD they used though.
Couple of questions, if you don't mind: - Which version of OpenBSD are you running? - Are you running X on your PPro, or is it "just" a server? - If you're running it as server, got any good links for setting up BSD firewalls? (TrinityOS rocks for Linux firewalling, but I haven't seen anything like it for BSD:-(
I currently have a PPro 200 w/ 64 Megs running Mandrake, but I've been looking at switching over to OpenBSD once I get some free time.
Slashdot Mirror
I'm sure everyone has their favorite code that MSVC 6 chokes on.
/* missing: () */
fatal error C1001: INTERNAL COMPILER ERROR
class Test
{
public:
Test();
};
Test::Test
{
}
Anyone know if this bug still exists in MSVC 7 ?
Now the US can have monopoly money like Canada ;-)
> Remember Copy II+"
;-)
:) (Dos3.3 started at 0x9600)
;-)
What, no mention of COPYA, Muffin, Disk Muncher or Locksmith ?
I still remember how Copy ][+ had 1 BIG sector on tracks 2 and 3. The thing loaded *FAST*.
"Cracking Techniques" was a bunch of text files describing how to break each game protection. It even had a 'tut on Copy ][+. Copy the ROM over to the language card. Modify the RAM so that reset would enter the "monitor" (built in disassembler on the Apple), and then finally make the 16K language read only. Copy ][+ never checked for the language card, so voila, you had a memory image. Moving the memory down so that DOS 3.3 wouldn't clobber it, and then BSAVE COPY ][+, A$800,L$8E00
> all those cool things...like modified TOC's....
Sad, that I still remember that the DOS3.3 TOC was on track 17 after all these years. I like how some games would embed control-chars in the filename.
{rant}
My 8-bit Apple had 20 character filenames. Who's the dumbass that limits filenames to 8.3 in CPM and MSDOS ?
{/rant}
> Half tracks....
The Apple drive was actually capable of 1/4 tracks. I believe Broderbund games made use of it. Write a small section on track 0. Increment to track 1/4, write another small section. Repeat. Normally, tracks were 4 quarter tracks apart, due to interference from data written on quarter tracks.
> Modified sector headers....
The thing that made Apple games disk so much fun to backup was that the drive couldn't write 2 consequetive zeros (aside from Sync Bytes, which was 0xFF, followed by two zero bits.) Ah, the days of 5+3 (13 sector tracks) and 6+2 encoding (16 sector tracks). For 6+2, you expand a sector of 256 bytes out to 384 bytes.)
Some interesting technical info here http://www.enteract.com/~enf/afc/apple2
Little bit of history here http://apple2history.org/history/ah15.html
Then someone figured out that you *could* write a few "illegal" bytes, such as C5.
> having to use the nibble editor
Copy ][+ had a ton of options for it's nibble editor. And if you still couldn't make a backup, there was always the option of boot tracing the program. Remember how the first sector had to be delimited by D5 AA 96 because thats what the Disk Prom checked for.
Some interesting cracking technique from yore:
Wildcard and Replay were 2 interesting products. They generated a NMI and let you enter the disassembler. I wanted one, but found out that I didn't really need one after I learnt about that language card trick.
The other trick to "stop" a game, was to search for 30 C0, since that was the address of the speaker! (I was *so* thankfull Copy ][+ ver 7 added a search bytes function!) Change a few bytes, and now the game will stop when it tries to play a sound.
Cheers
> You've got to wonder, is this yet another load of Nvidia corporate hype (a la "HW TnL will revolutionise gaming")
Have you *even* done *any* 3d graphics programming?? HW TnL *offloads* work from the CPU to the GPU. The CPU is then free to spend on other things, such as AI. Work smarter, not harder.
I'm not sure what type of revolution you were expecting. Maybe you were expecting a much higher poly count with HW TnL, like 10x. The point is, we did get faster processing. Software TnL just isn't going to get the same high poly count that we're starting to see in today's games with HW TnL.
> it takes a few months till anyone really knows if this is good or bad.
If it means you don't have to waste your time writing *two* shaders (one for DX, and other for OpenGL) then that is a GOOD THING.
> but why do we have to spend twenty years devising languages that are not quite as good as Smalltalk (in the name of efficiency, or compatibility,
;-) In my line of work, Smalltalk would be one of the worst possible languages to use because it doesn't interface with the hardware efficiently. Use the right tool for the job, yada yada yada.
Now Smalltalk may great at certain things, but it isn't the end-all or be-all. There are *reasons* new languages get invented -- to solve a problem more elegantly / efficiently / compactly then older languages. Sometimes speed (runtime) DOES matter.
i.e. Let me know when I can use Smalltalk on the PS2. Until then, it's C++ and custom assembly, because when it comes to graphics, speed is more important then flexibility especially when you need to use every trick in the book to get a good framerate on consoles.
> Smalltalk is the only language I've ever used that I felt truly extended my reach as a programmer
That's great that the language maps to your problem domain. (Lucky B@$tard
That's the great thing about programming in multiple languages -- you get to learn why they are better at solving certain problems then other languages.
Sorry if my rebuttal sounds a little harsh but your post sounded like the beginnings of a "Holy War" and it's hard to tell if you're jazzed about other languages.
Cheers
This immediately raises the question: Where in the movie is an episode of The Prisoner playing?!
I *finally* found the answer on Jen's Matrix FAQ
I wonder what movie references Matrix 2 and 3 will include?
--
"Every person you meet has two things to teach you.
Something about other people, and something about yourself"
- Anonymous
> There is no easier way to make code ugly and unreadable than to use hungarian notiation.
r iable game. It's a waste of another programmers time.
Using tradional HN I agree. See my above post for how I use a variation which I find usefull.
> nCount is not in anyway more readable that cnt,
Those are both bad examples. I don't like playing the guess-which-vowel-or-letters-I-left-out-of-the-va
nCount is redundant. Count doesn't tell you anything about the variable.
NumPlayers, MaxPlayers are much better descriptive examples.
I allways (when applicable) add a prefix to my variables that identifies the type. Name then becomes sName, etc. I know this does not work for everybody,
Hehe, why are programmers so passionate about HN. Seems like coders tend to fall into 2 camps - they hate it, or they see the underlying merits, and use a modified version.
Years ago I absolutely hated Hungarian Notation. IMHO it was far too meticulousness - you spent more time trying to keep your variables up to date, then coding! (Ok, it wasn't that bad, but close.)
You can see how painfull raw HN is:
Microsoft Hungarion Notation
Does one *really* need to be that preverse about specifying the difference between byte, char, short, long, dword? Sheesh !(Notice how this pattern shows up when you take any good idea / methodolgy and become a "zealot" about it, but I digress.) Most of the time you don't need to split hairs over ints, floats, bools, chars, strings, etc. You're just making busy-work for yourself.
That said, here's a heavily modified HN (namely a lot less restrictive) for C++ that I find extremely handy:
There are a few variations on this: Microsoft uses m_ (I don't care for this style, as this is too "wordy" IMHO), Some of the well know C++ gurus (forgot if it was Eckel or Meyers) use a trailing _ (again too easy to miss IMHO)
- p pointers
(s, g, _, p are always in this order)I find these to be a good compromise:
And since I'm dealing with so much 3D math I also use:
To keep track of what I'm converting to/from.
~ 2 ~ Having a standardized coding standard at work has been a Good Thing (TM) in the long run. I didn't like it at first, (habits and all :) but it's made working on other peoples code easier.
~ 3 ~ I can't stress this next tip enough: Use *descriptive* variables names.
A descriptive name almost takes away the need for comments (almost ;-)
i.e.
If you iterating over a set, or range, say it !
for( iCard = 0; iCard < nCards; iCard++ )
~ 4 ~ Use whitespace. Align the columns of your tables up. There is a reason tables exist - to make it easier to read.
~ 5 ~ If you have a function that does some complex calculation, document where you got the formula from.i.e. See Graphics Gems Volume N, Pages nn-nn
~ 6 ~ As you come up with ideas for how the block of code you're working on could be better, made more robust, effiecient, etc, put a comment: // TODO: rewrite so is cleaner
This way you can do a search to see which parts of the code needs to rewritten.
Cheers
--
"The issue today is the same as it has been throughout all history, whether man shall be allowed to govern himself or be ruled by a small elite."
- Thomas Jefferson
Not sure why the author used the adjective "full-time" because it doesn't mean aything. Maybe he meant single-pass to distinguish from multi-pass techniques.
You can read more about multitexturing here at http://www.web3d.org/TaskGroups/x3d/quadramix/mul
Here's an interesting link that shows what the origin of the BAR really is.
t m
http://www.theawaregroup.com/hidingbehindthebar.h
> Ok, here's how the movie is not like the Amazing Spider-man:
;-)
>{ snip }
Nice summary.
In the comics Peter Parker is always trying be friends with Liz, a high school classmate. In the movie it was Mary Jane, the next door neighor. The movie didn't have any mention of Betty Bryant either.
In the comics, the Green Goblin has the flying wings the *2nd* time he meets up with Spider-Man (first time was his flying broomstick.) Also, the GG was MUCH smaller -- like "goblin" size. Difference the movie had: someone who wore a metal suit that was bigger then Spider-Man.
It's interesting how the comic book would point out how most of the villians (And Spider-Man at times) used technology.
i.e. Vulture uses anti-magneticism to fly, Spider-Man had "web cartridges", Spidey's beam of light that shows his face (ala Batman) etc.
Even though the movie was quite different from the comics, I enjoyed it. I think they did a great job re-telling the story. I too liked the foreshadowing with the criminal who took the wrestlers promoter money.
How long do we have to wait for the sequel ?
> But, last time I checked, when you share somebody else's stuff, it's called stealing.
That is a fallacy - you're logic is not valid due to your definitions being ambigious.
If I borrow a tool from my brother, and then lend it out to a friend, my friend isn't stealing.
It's called [physical] stealing when you take someone else's stuff WITHOUT their permission (And it logically follows: AND they don't have access to it while you have it.)
Now obviously digital stealing is NOT quite the same as physical theft since when digital assests are shared, the original owner still has access to the orginal. Digital theft is ALSO copyright violation, since you don't (YET!) have the right to copy it (or use it.)
Notice that buying an item is equivalent to paying for the "right" of use. Even if the item is free, doesn't mean you necessarily have the "right" to use it.
Whoa, sparked a lively discussion! He He He.
;-)
When I was submitting the story, I couldn't remember which 'C' word to use. I checked dictionary.com and found centrifugal. I wasn't quite sure if it was accurate, but I think its a more compact word (i.e. layman's usage) then "the destructive velocity tangent to the disc", so I used it.
Thx for pointing out both definitions!
> What the deal is with C++.
Sounds like you haven't read:
- "Desin and Evolution of C++" by Stroustrup and/or
- "Multi-Paradigm Design for C++" by James Coplien.
C++ is WAY better then C
1 - It's a better C (better type checking, cleans up that cruft with typedef struct {}, etc)
2 - Supports OOP synatix natively (Yes, you *can* do OOP in C, but it's tedious)
3 - Supports generic programming (templates)
> but the only thing that other languages taught me was how BAD C++ really is.
True enough. Also, interesting, is that when I learnt C++, it showed me how bad C is.
I agree learning multiple languages is always "A Good Thing" -- you get exposed to new idioms and design patterns.
> I believe in the original C language philosophy. Small, simple, fast, powerful.
So why not use just the C subset of C++? You'd gain all advantage and no disadvantages.
Cheers
> but there have always been some things you couldn't do. Yelling fire in a crowded theater is the classic example.
n dness.com/FREEDOM990628.htm
That is a fallacious argument. You might want to read this to see why.
http://216.239.39.100/search?q=cache:www.fatalbli
Can realism destroy the amount of "fun" in game?
That *completely* depends on the game!
If I want to play a simulation, I want as much realism as possible.
i.e.
Flight Sim, Driving Game, etc.
i.e
If I hit a stationary object at high speed, my car should roll, tumble, and be smashed to pieces.
For other games, I want as much "fun" as possible *at the expense* of realism.
i.e.
Diablo and Dungeon Siege don't have encumbrance. Why? Because it's tedious, and slows down the gameplay.
Fun and Realism are orthogonal concepts in games.
A game can be:
1) Fun and unrealistic,
2) Fun and realistic
3) Unfun and Realistic
4) Unfun and unrealistic.
Confusing the two, shows a lack of understanding game design.
The hard part is trying to nail down how much realism a game needs.
I agree.
> Texture size is REALLY not a problem.
It IS when your PC game is being ported to consoles and you ONLY have ~ 2.5 Megs of VRAM say like on a PS2 ! (Yes the PS2 has 4 Megs of VRAM, but you need space for the framebuffer and zbuffer.)
Now consoles make up for the lack of video memory by having a high bandwidth (i.e. PS2 can DMA ~20 Megs of Textures per frame) but I'd rather upload my textures ONCE, not every bloody frame. Yes, you be more efficient at texture uploads (draw the last model from the last frame, first this new frame, etc) but you're still tying up the BUS.
> The ONLY way to get good texturing done is to DISPENSE with the concept of textures all together.
I don't compeletely agree, but you raise an interesting point, because of the fact that textures are a form of (color) compression. If we take this to its logical conclusion we should be able to have a triangle PER pixel, and that would negate the need for textures. Unfortunately that has its own problems -- there's no way we can send a million vertices across because we'd saturate the bus! Doh! (Give a reward to the person in the back who said, well let's move to paramateric surfaces then!)
In the "Real World" (TM) we have a *unique* texture per pixel (ala ray tracing) however we don't have the memory to store that, unless we calculate them parametricaly. Sure we can get nice "marble" ala Perlin Noise, but it's going to be a while before we can mathmatically generate EVERY texture !
> But why do games look better you ask?
> Mostly because video cards have any number of fancy TnL units that can independently create some rather nifty effects while working AROUND or OUTSIDE of the plain old texturing model.
You'd be amazed at what multitexturing and multipass render does. Even a simple repeatable base texture with a "random" noise texture overlaid with a bump-map, looks OK.
> The color is an INTEGRAL PART of what an object is. You cannot separate the two.
You *can* get away with this, but you have to be aware of the tradeoffs. One common "solution" is to crank up the bit-depth.
i.e. If you use 16-bit color channels ala 64 bits per pixel, then you don't have to throw out your whole rendering functionality -- you just extend it. Not a perfect solution by any means, but "its good enough."
Take a look at "Titanic" The ship was rendered via tradional textures, and it looks pretty good. The hard part is getting that quality in real-time with so little memory ;-)
Cheers
--
"The issue today is the same as it has been throughout all history, whether man shall be allowed to govern himself or be ruled by a small elite." - Thomas Jefferson
Who needs a programming language, when a shell will do ! (Can't believe no one has posted this yet... ;-)
(I'd post the jokes, but the blood lameness filter prevents it.)
http://www.lns.cornell.edu/~pvhp/perl/unix.html
*sigh*
When will companies learn, that forcing advertising/spam onto customers does not help you get more customers. All it does is leave a bad taste in the ones they DO have, and gets the company known by word of mouth as one to avoid.. Similiar to how a bad game gets mentioned in usenet, and everyone stays away from it.
> Intellectual property is fundamental to the peaceful progress of such societies and, without them, everything does break down to the very concept of "might makes right" that RMS claims to fear now.
... ?
And your proof is
Methinks you need to read:
Against IP
The Libertarian Case Against Intellectual Property Rights
> Why do you elitist h4X0r5 immediately discount Visual Basic just cause it's easy to program in? I know for a fact that many corporations use VB for interfacing with electronics for testing and remote control through a serial data stream.
You've mixed up in ease of use with power. VB doesn't support multiple paradigm programming. C++ supports functional, object-orientated, and generic programming. When you use (and need) all 3, VB looks like a toy compared to C++. Does that mean you can't use VB for "real" apps? Of course not. Why use a complicated language when a simpler one willl do? It depends on your design and implementation constraints.
Secondarily, when VB runs on a PS2, XBox, or Gamecbue, let me know! For the field I'm in, game programming (PC & Console) assembly and C/C++ have no competition because performance is the 1st priority.
> Just cause you write something in a more difficult language such as C or C++ doesn't make you any more l33t if you wrote an easier program that accomplishes the same task with less headache in VB or LabView!
Very true. It's about using the right tools for the job.
> While the distance decreased by half, so did the time to cross that distance.
True, but I prefer this alternate solution: time and space are quantized.
i.e. There comes a point when you can't subdivide them.
> How many of you actually experienced OS/2's preemptive multitasking - compared to whatever it is that Windows has?
Which version of Windows?
Win3.1 -- cooperative multitasking
Win95/98 -- pre-emptive multitasking (but for only 32 bit apps) The 16-bit subsystem can stall the kernel, since Win32 is built on top of it.
WinNT/2K/XP -- pre-emptive as well. The Win16 subsystem is cooperative, since it emulates Win3.1, but can never stall the kernel, since it sits on top of Win32.
OS/2 pre-emptive multitasking isn't any better then NT's.
More power would be cool in the PS3. Something like having the GS as powerfull as a GeForce3 (Get we get a "real" stencil in the PS3 ?!)
Ignoring power for the moment, less complexity would be even better. It's a real b!tch having to manage ** 6 ** CPUs in parallel !! (EE, VU0, VU1, GS, IOP, and SPU) Throw in DMA transfers on top of that and it's enough to make a person pull their hair out.
> I've got OpenBSD running on a PPro 200 with 32 megs of RAM, and it's great.
:-(
Yeap, you certainly don't need much horsepower if you're running a firewall/server. Walnut Creek used to serve *thousands* of users off a T1 with their PPro 200 back in the mid 90s. I forget which BSD they used though.
Couple of questions, if you don't mind:
- Which version of OpenBSD are you running?
- Are you running X on your PPro, or is it "just" a server?
- If you're running it as server, got any good links for setting up BSD firewalls? (TrinityOS rocks for Linux firewalling, but I haven't seen anything like it for BSD
I currently have a PPro 200 w/ 64 Megs running Mandrake, but I've been looking at switching over to OpenBSD once I get some free time.