As other posters mentioned, I did miss the big sprawling maps. On a PC, that 5-part city map could have been all one map. Each mission could have been all one map as well. The best thing would be to use some warcraftish techniques to make the whole entire thing all one map;-)
I found the climbing gloves to be quite useful, actually. I used them a number of times in the city to avoid patrolls, and get to hidden tunnels or rooftop areas. I also used them in several missions to get up to ledges, etc. I did miss the rope arrows, though. Rope arrows are more challenging, and ultimately more fun. (and I expect that one reason they dropped it was consolification, despite what they say about the physics)
One improvement from Thief 2 was *I think* relative volume levels. In Thief 1&2, you could be in the middle of an incredibly noisy environment and a guard would still hear your footsteps, even though you the player couldn't even hear them. If I remember right, Thief3 actually let noise provide cover for you.
The cradle was awesome. awesome awesome awesome. There was no level in Thief2 that could compare.
One thing I didn't like about Thief2 was the annoying automated messages that the robots would speak. It was ok at first, but got really anoying by the end. I liked Thief3's audio a lot better. The stone golems had something similar, but much less annoying.
Thief3 had the wall-flatten, where you could suddenly need to hide, and rather than running for an alcove you would just dash over to the darkest part of the hall and flatten against the wall, almost eliminating your collision area. The guard then walks on past, and you resume stance behind him and knock him out.
But really... the thing I liked most about Thief3's gameplay?..... the shadows;-) It might seem like a cheesy thing to get excited over, being simply a graphic innovation, but there was something truly immersive about sneaking past a window and seeing your own shadow dance accross the far wall. If you had a light behind you, you could see the shadow of your blackjack rising up over the guards head before he went out cold. You could stand in an alcove and watch the shadow of the guard dance up the hallway to know where he was and how close, and which direction he was moving. In the city, you could even tell from the shadow whether it was a guard, an archer-guard, helmeted guard, creature, or a civilian. Thief3 just had some really masterful lighting/shadow algorithms, and I think it added a lot to the gameplay.
So... look up the Ultracapacitors that maxwell makes. They are 2700F. Yes. 2.7KF Not a true capacitor exactly, and low voltage, but they are usable for storing the energy of regenerative braking in electric cars. You can get these for about $50 as well, I think.
To second trochej, I don't understand why any program at all would have a single byte of memory on the thin client. I don't have any experience with Citrix, but I've seen terminal server. Above posts indicate that they are the same technology. In terminal server, all the client is doing is displaying a virtual desktop that it receives, in the form of graphics commands, from the server.
So, regardless of the type of application, the client just paints. It needs no more memory than the size of the screen that it is painting.
Having said that, I will admit that receiving images form the server will be slower than receiving line and fill commands. In cad, with fancy rendering you will likely need the 3D processing done on the server, and sent to the client. This could be slow if the program is designed with 3D acceleration in mind, but not many people actually do the 3D rendering (most of what I usually see people working on is wireframe). For rendering nice images to print, it seems like people could put up with some lag.
You're definately not going to be able to play 3D video games on a system like this, but it seems that if this is the problem, then the posts should be focused on it, like: "You can't do intensive graphics on Citrix because you don't get hardware accelerated 3D"
Um, you say the clients weren't up to it, or that Citrix couldn't handle it, but the clients wouldn't really be doing anything and other posters cite citrix as being efficient. I think your situation was a server that wasn't powerful enough for the number of clients. Either add more servers, or upgrade them to multiple gig of ram and quad processor, and you can handle more clients.
Well, in order to prime the other core.. I'd think you'd need to get its state to match the first one. Like, you can't start executing instructions that need the value of registers EAX and EBX unless you have the correct value stored in them, and the correct values are what is in the registers of the processor that chose the right branch.
Unfortunately, there's also a lot of other state that would need copied as well... like the contents of the entire pipeline, just about. But, you don't need them to be synchronized. Assume one processor is designed to always take branches (call it T), and the other is always designed to not take branches (call it NT). Lets say NT is wrong about a branch, and takes 4 clocks to get the state streamed from T. I'm assuming this is faster than dumping its pipeline and doing the calculations itself. It is now about 4 clocks behind. Suppose it is wrong again. It loads the state from T, and is still 4 clocks behind. Suppose we are in a loop, and it is wrong for the next 500 iterations. It is still 4 clocks behind. Now suppose the loop ends, and T is wrong, and NT is right. NT now becomes the "official" processor, and sends its state to T. T is now 4 clocks behind. (8 clocks behind where it was originally).
So basically, this would use two processors to reduce the penalty of a mis-predicted branch to some small number of clock cycles. I'm not sure if that would be worth it or not.
As one reply stated, you can't know which is right unless you had 3 cores.
But, with two cores, you could have a way to predict "branch" and "not branch" at every prediction spot. The core that gets it right sends the registers to the other core so they can continue as if every branch were predicted correctly...
That would only work if you had a nice fast way to copy registers accross in a very small number of clock cycles... so again, just a bunch of speculation. But it was a neat enough idea I had to say it.
There's a pretty wide gap between American Citizens and American Corperations. Corperations have this neat effect of being able to take a bunch of normal people and turn them into a soulless collective that relentlessly seeks money. Keep in mind that we were the first to get hit with waves of RIAA lawsuits.
I'd say the only American citizens who approve of the current copyright/patent package and want it spread to the rest of the world are the ones who run the large corperations and will make a proffit by doing so. This then carries over to the politicians who want the campaign contributions from them. Embarrasingly, the majority of "normal people" in America don't even have the concept that this is happening to the rest of the world.
The scary thing for the rest of the world (for America, too!) is that we've lost control over our political machine, and it's running amok accross the world while we play World of Warcraft and eat pizza and watch mindless TV (including mindless News!!).
SilverDirk's Theory of Compression:
(not that someone else probably hasn't said the same thing...)
For every compression algorithm, there exists a data stream which, when "compressed", will actually grow in size.
This is pretty easy to prove. Compression maps a string of N bytes to a string of M bytes. If you consider that there are 256^N strings of that length, and (-1+256^N)/255 strings shorter than N, then there will have to be strings which when "compressed", stay the same size. Moreover, an algorithm also needs to map strings smaller than N into the same space, and you can't have collisions if you expect to restore the original string via decompression. This means that some strings will need to get bigger.
If you look at it from the other side, a compressed string of M bytes can only represent 256^M possible uncompressed strings. For an example of M=1, you could design an algorithm that compresses the entire works of William Shakespeare, and 254 other works, into a single byte [1], but it would only be useful for those 255 data sets. Any other data set would need more bytes, and an additional byte at the start to indicate it was not one of the stock data sets.
The point is that a compression algorithm is only useful for the kinds of data it was designed for. Most compression is designed for data with repeating patterns. Data without patterns cannot be compressed by these algorithms. If they claim 25x compression, then they need to tell us which specific kinds of data they expect it to work with, because there exist many files which would get an actual ratio of 0.9999~.
[1] Shakespeare et. al. Compression Algorithm If first bytes is 0, return entire works of shakespeare. If {1..254} then return Work{1..254}. If 255, read all following bytes as entire contents of original file.
There's three things to consider when trying to use megaherts as a performance measure.
How many cycles does the average instruction take?
How many cycles are lost due to incorrect branch prediction?
How many cycles are lost while waiting for data from memory?
Probably some other things too, but those seem to be the real speed-killers. There is no "industry standard" solution. AMD chose a short pipeline, so instructions complete in fewer clock cycles. Intel chose a longer pipeline, so instructions eat more clock cycles. This is why my Athlon-2500XP is actually running at 1.8ghz, but performing slightly better than a P4-2.5ghz. Now, a lot of this performance is also based on cache memory speeds, main memory speeds, and branch prediction. When you go to one of the cheaper chip manufacturers, like Cyrix, they leave out some of the technology that accelerates the performance, in favor of lower cost and lower heat. Big elaborate branch predictors use lots of silicon and consume power. I've seen the inside of a gamecube. There's no processor fan. Same goes for the other consoles. These guys are going to be cutting corners and eliminating bits of standard chip design in favor of low heat output.
As my computer architecture prof. likes to say "The real problem is feeding the beast." If you can't deliver an instruction to the processor, it can compute your answer. In general, you can't ensure that the next instruction is always ready. If you miss your cache on a 1ghz processor, and need to wait 5ns for the next instruction to come from main memory, you just lost 5000hz worth of processing due to a stall. In desktop chips, they have tons of clever technology to help prevent cache misses. In mobile processors and game systems and handhelds, they have to peel some of this off to keep the heat consumption down.
I'll guarantee you that the StrongArm and X-Scale processors running at 600Mhz don't compare to the old desktop models, and they're all made by "industry leaders";-)
I've seen a notable number of people playing *real* video games, or even watching anime, not to mention the tons of people who just sit there browsing the web.
"You eventually have to consolidate the data of each file"
Not quite. They consolidate files now for efficiency in accessing them. If you have a device that can do random access without millisecond delays, and which is bad to have unnecessary writes, then you could just leave the files in the journal.
In other words, the entire disk can be the journal, and all files can be contained in it.
Imagine a file system where the entire disk is divided into stripes. You erase a stripe when its data is obsolete, and write a new stripe whenever you have enough data, combined from however many writes have occoured lately. As old blocks of data become outdated (because the block has been written again in a new stripe) you end up with stripes that are only partially filled with useful data. When you need to reclaim this space, you add all the blocks in the target stripe to the "current writes" list, so they get written again (in a new stripe). Then the entire old stripe is invalid, so you can write a new stripe over top of it. This sytem could even be used to do a round-robin on the entire drive, which would give you the longest drive life of all.
Do you not get it? he has TWELVE HUNDRED MACHINES that he would have to put this.bashrc on. TWELVE HUNDRED MACHINES. Shall I say it again? I think the idea is that he might not even have a personal profile on them, since then every tech's profile would be replicated on TWELVE HUNDRED MACHINES. More than likely, he logs in as some "admin" user, and then fixes whatever is wrong with the box. I really can't imagine a hosting company setting up a profile for each of their helpdesk employees on each machine.
You could argue that they should be using some kind of LDAP deal, but the machines might be spread accross the net, and/or they might just not want to bother with the extra setup involved. So, the question is whether there is a way to get his personal settings installed from his client. I imagine he might also have trouble with sub-shells.
So, my suggestion- assuming he isn't allowed to add files to the machines, I would reccomend a complete wrong-minded hack on the windows end to get things pasted into the client every time he logs in;-)
For instance, you could write a nice little Delphi program (or VB, *sigh*) that would register a system hotkey, and when triggered would copy some text into the clipboard and paste it into the active app.
Or, the less technical approach would be to have a copy of notepad open at all times with your bash commands, and then just alt-tab,ctrl-c,alt-tab,ctrl-v each time.
Hopefully someone somewhere on this discussion knows of a client that does an automatic batch of commands when it logs on;-)
Ok, lets fire up the creativity for a second. what if someone were to make a small cheap device that could send a signal via laser beam? what if these devices came with small tripods, so that you could set a couple in your windows and aim them at the neighbors? Imagine if you could put scopes on them to precisely aim at the receiver on your neighbor's device. What if these devices had a simple ethernet connector on the side, and a protocol to exchange routing tables with others of this device on the same ethernet?
Sell enough of them, and a whole city (provided enough technology enthusiasts) could network themselves, with no digging, and without clogging any wireless bands, and without interferance, and it would be nearly impossible to eavesdrop without being part of the network.
You'd need a clever routing protocol for the system, but that could be fun. Toss in some academic research on the subject, and you might get some efficiency out of the thing.
I do miss the days of $49.99 though. The new prices (and lack of a cheap 'standard' version) really is a shame. For a while, they offered a completely free 'personal' version which could only be used for non-commercial purposes, but they don't offer it for free download anymore.
Resizing is a very good thing, IMHO, and I always try to support it when I can. In Delphi, I would just play with the anchors properties (since about D5, I think) which control which edge each side of the component is 'anchroed' to. On the whole, this gives me exactly what I want. I can also set a minimum size for the application, to prevent controls from becoming unusable. (resizing only makes sense to a certian extent, after all, beyond which you'd need to re-think the UI)
Swing, on the other hand, was so painful to get things right that I never really did get the hang of it. It always seems like components are jumping around or getting bizarre positioning, and never stretch in the places where I want. Trying to ensure artistic 8-pixel gaps in the places where I want them is also irritating. Dynamically modifying the components at runtime is nightmarish compared to Delphi, where I would just show/hide things. I haven't tried NetBeans yet... and I suppose they could have fixed it up nicely, but I've still got a bad taste in my mouth from Swing. Resizing wasn't Swing's only problem, though...
Just to randomly rant a bit, <rant>Java also does horrid repaint optimizing. The usual suggestion to get rid of "flicker" in Java progs (which is a symptom of heavy overpainting) is to use double-buffering. This essentially just lets the inefficiency get drawn to the back-buffer, hiding it from the user. It also requires a back-buffer, which is an extra couple meg of wasted memory, if you fullscreen the app on a large true-color desktop. In all, it leaves your program running slowly, because of the overpainting and extra blit operation required (if you're actually lucky enough to get it accelerated- otherwise its an extra copy of a few meg done by the processor) and uses a ton of memory that isn't needed. The end performance has VB written all over it.
If you'd like to test this on your own, try to write a Java program that doesn't paint *anything* onto a rectangle of your window- a dead zone that gets whatever was on that region of the screen before it. If you can, it means that the painting you do on this area is not overpainting any work done by swing/awt, and you've reached some nice efficiency. I've only ever managed to accomplish this on Frame itself, not any of the Component derivatives. Everything else will fill with the background color, even if you'd like to just erase the background with some image of your own. </rant>
and, yes, Delphi did do efficient repainting, simply because it uses Windows' paint-callback system, and uses system-level windows to represent some of its widgets. Windows is smart enough to prevent overpainting of windowed components. You can even avoid having the background cleared for you if you create the window with the right flags, or just alter the message handling for that window, which can be done in Delphi by overriding a protected method of TWinComponent.
I'll second Delphi. It uses an OO form of the Pascal language, which might be a problem for some, but I'd take pascal any day compared to basic. Also, Delphi is every bit as easy to use as VB.
I used Delphi at a co-op job for six quarters, and it just plain made me feel powerful. I could throw together a nice GUI in minutes, and then "wire up" the events to real code after getting approval from the people who would be using the program. By the time I was done, i'd have a nice professional-looking app that was only about 700K, didn't need any funny DLL files, and was made out of nice strongly-typed OO code, and took advantage of the huge selection of freeware widgets on sites like http://www.torry.net/
Delphi is the perfect language for writing fast windows apps. Its also perfect for database access, and with the right packages, can be perfect for lots of other tasks, like serial port access. (and what I mean by that is that you can go fumbling around with the Windows Serial port API, or you can get a nice I/O package for Delphi and just drag/drop some components that give you nice events to play with.)
To top it off, if you look at the assembly generated by the compiler, its really pretty good. You might say it's equivalent to -O1 on C code, and thanks to its single-pass compiler, it compiles 10x as fast, so there's basically no wait.
Aah, the giants outside Elfland! That was great stuff;-) I seem to remember the trolls on the southeast corner of the world being better for grinding, though.
Slashdot Mirror
As other posters mentioned, I did miss the big sprawling maps. On a PC, that 5-part city map could have been all one map. Each mission could have been all one map as well. The best thing would be to use some warcraftish techniques to make the whole entire thing all one map ;-)
I found the climbing gloves to be quite useful, actually. I used them a number of times in the city to avoid patrolls, and get to hidden tunnels or rooftop areas. I also used them in several missions to get up to ledges, etc. I did miss the rope arrows, though. Rope arrows are more challenging, and ultimately more fun. (and I expect that one reason they dropped it was consolification, despite what they say about the physics)
..... the shadows ;-) It might seem like a cheesy thing to get excited over, being simply a graphic innovation, but there was something truly immersive about sneaking past a window and seeing your own shadow dance accross the far wall. If you had a light behind you, you could see the shadow of your blackjack rising up over the guards head before he went out cold. You could stand in an alcove and watch the shadow of the guard dance up the hallway to know where he was and how close, and which direction he was moving. In the city, you could even tell from the shadow whether it was a guard, an archer-guard, helmeted guard, creature, or a civilian. Thief3 just had some really masterful lighting/shadow algorithms, and I think it added a lot to the gameplay.
One improvement from Thief 2 was *I think* relative volume levels. In Thief 1&2, you could be in the middle of an incredibly noisy environment and a guard would still hear your footsteps, even though you the player couldn't even hear them. If I remember right, Thief3 actually let noise provide cover for you.
The cradle was awesome. awesome awesome awesome. There was no level in Thief2 that could compare.
One thing I didn't like about Thief2 was the annoying automated messages that the robots would speak. It was ok at first, but got really anoying by the end. I liked Thief3's audio a lot better. The stone golems had something similar, but much less annoying.
Thief3 had the wall-flatten, where you could suddenly need to hide, and rather than running for an alcove you would just dash over to the darkest part of the hall and flatten against the wall, almost eliminating your collision area. The guard then walks on past, and you resume stance behind him and knock him out.
But really... the thing I liked most about Thief3's gameplay?
So... look up the Ultracapacitors that maxwell makes. They are 2700F. Yes. 2.7KF Not a true capacitor exactly, and low voltage, but they are usable for storing the energy of regenerative braking in electric cars. You can get these for about $50 as well, I think.
See the bottom of http://www.earthtoys.com/emagazine.php?issue_numbe r=04.04.01&article=maxwell for comparisons.
Or specifically, this image: http://www.earthtoys.com/articles/04.04.01/maxwell /conten2.gif
I submitted that as a slashdot story once upon a time, but it probably looked like I was trying to advertise a product.
So, regardless of the type of application, the client just paints. It needs no more memory than the size of the screen that it is painting.
Having said that, I will admit that receiving images form the server will be slower than receiving line and fill commands. In cad, with fancy rendering you will likely need the 3D processing done on the server, and sent to the client. This could be slow if the program is designed with 3D acceleration in mind, but not many people actually do the 3D rendering (most of what I usually see people working on is wireframe). For rendering nice images to print, it seems like people could put up with some lag.
You're definately not going to be able to play 3D video games on a system like this, but it seems that if this is the problem, then the posts should be focused on it, like: "You can't do intensive graphics on Citrix because you don't get hardware accelerated 3D"
Um, you say the clients weren't up to it, or that Citrix couldn't handle it, but the clients wouldn't really be doing anything and other posters cite citrix as being efficient. I think your situation was a server that wasn't powerful enough for the number of clients. Either add more servers, or upgrade them to multiple gig of ram and quad processor, and you can handle more clients.
Unfortunately, there's also a lot of other state that would need copied as well... like the contents of the entire pipeline, just about. But, you don't need them to be synchronized. Assume one processor is designed to always take branches (call it T), and the other is always designed to not take branches (call it NT). Lets say NT is wrong about a branch, and takes 4 clocks to get the state streamed from T. I'm assuming this is faster than dumping its pipeline and doing the calculations itself. It is now about 4 clocks behind. Suppose it is wrong again. It loads the state from T, and is still 4 clocks behind. Suppose we are in a loop, and it is wrong for the next 500 iterations. It is still 4 clocks behind. Now suppose the loop ends, and T is wrong, and NT is right. NT now becomes the "official" processor, and sends its state to T. T is now 4 clocks behind. (8 clocks behind where it was originally).
So basically, this would use two processors to reduce the penalty of a mis-predicted branch to some small number of clock cycles. I'm not sure if that would be worth it or not.
But, with two cores, you could have a way to predict "branch" and "not branch" at every prediction spot. The core that gets it right sends the registers to the other core so they can continue as if every branch were predicted correctly...
That would only work if you had a nice fast way to copy registers accross in a very small number of clock cycles... so again, just a bunch of speculation. But it was a neat enough idea I had to say it.
I'd say the only American citizens who approve of the current copyright/patent package and want it spread to the rest of the world are the ones who run the large corperations and will make a proffit by doing so. This then carries over to the politicians who want the campaign contributions from them. Embarrasingly, the majority of "normal people" in America don't even have the concept that this is happening to the rest of the world.
The scary thing for the rest of the world (for America, too!) is that we've lost control over our political machine, and it's running amok accross the world while we play World of Warcraft and eat pizza and watch mindless TV (including mindless News!!).
For every compression algorithm, there exists a data stream which, when "compressed", will actually grow in size.
This is pretty easy to prove. Compression maps a string of N bytes to a string of M bytes. If you consider that there are 256^N strings of that length, and (-1+256^N)/255 strings shorter than N, then there will have to be strings which when "compressed", stay the same size. Moreover, an algorithm also needs to map strings smaller than N into the same space, and you can't have collisions if you expect to restore the original string via decompression. This means that some strings will need to get bigger.
If you look at it from the other side, a compressed string of M bytes can only represent 256^M possible uncompressed strings. For an example of M=1, you could design an algorithm that compresses the entire works of William Shakespeare, and 254 other works, into a single byte [1], but it would only be useful for those 255 data sets. Any other data set would need more bytes, and an additional byte at the start to indicate it was not one of the stock data sets.
The point is that a compression algorithm is only useful for the kinds of data it was designed for. Most compression is designed for data with repeating patterns. Data without patterns cannot be compressed by these algorithms. If they claim 25x compression, then they need to tell us which specific kinds of data they expect it to work with, because there exist many files which would get an actual ratio of 0.9999~.
[1] Shakespeare et. al. Compression Algorithm If first bytes is 0, return entire works of shakespeare. If {1..254} then return Work{1..254}. If 255, read all following bytes as entire contents of original file.
There's three things to consider when trying to use megaherts as a performance measure.
Probably some other things too, but those seem to be the real speed-killers. There is no "industry standard" solution. AMD chose a short pipeline, so instructions complete in fewer clock cycles. Intel chose a longer pipeline, so instructions eat more clock cycles. This is why my Athlon-2500XP is actually running at 1.8ghz, but performing slightly better than a P4-2.5ghz. Now, a lot of this performance is also based on cache memory speeds, main memory speeds, and branch prediction. When you go to one of the cheaper chip manufacturers, like Cyrix, they leave out some of the technology that accelerates the performance, in favor of lower cost and lower heat. Big elaborate branch predictors use lots of silicon and consume power. I've seen the inside of a gamecube. There's no processor fan. Same goes for the other consoles. These guys are going to be cutting corners and eliminating bits of standard chip design in favor of low heat output.
As my computer architecture prof. likes to say "The real problem is feeding the beast." If you can't deliver an instruction to the processor, it can compute your answer. In general, you can't ensure that the next instruction is always ready. If you miss your cache on a 1ghz processor, and need to wait 5ns for the next instruction to come from main memory, you just lost 5000hz worth of processing due to a stall. In desktop chips, they have tons of clever technology to help prevent cache misses. In mobile processors and game systems and handhelds, they have to peel some of this off to keep the heat consumption down.
I'll guarantee you that the StrongArm and X-Scale processors running at 600Mhz don't compare to the old desktop models, and they're all made by "industry leaders" ;-)
I've seen a notable number of people playing *real* video games, or even watching anime, not to mention the tons of people who just sit there browsing the web.
I think this teacher has a clue.
"You eventually have to consolidate the data of each file"
Not quite. They consolidate files now for efficiency in accessing them. If you have a device that can do random access without millisecond delays, and which is bad to have unnecessary writes, then you could just leave the files in the journal.
In other words, the entire disk can be the journal, and all files can be contained in it.
Imagine a file system where the entire disk is divided into stripes. You erase a stripe when its data is obsolete, and write a new stripe whenever you have enough data, combined from however many writes have occoured lately. As old blocks of data become outdated (because the block has been written again in a new stripe) you end up with stripes that are only partially filled with useful data. When you need to reclaim this space, you add all the blocks in the target stripe to the "current writes" list, so they get written again (in a new stripe). Then the entire old stripe is invalid, so you can write a new stripe over top of it. This sytem could even be used to do a round-robin on the entire drive, which would give you the longest drive life of all.
You could argue that they should be using some kind of LDAP deal, but the machines might be spread accross the net, and/or they might just not want to bother with the extra setup involved. So, the question is whether there is a way to get his personal settings installed from his client. I imagine he might also have trouble with sub-shells.
So, my suggestion- assuming he isn't allowed to add files to the machines, I would reccomend a complete wrong-minded hack on the windows end to get things pasted into the client every time he logs in ;-)
For instance, you could write a nice little Delphi program (or VB, *sigh*) that would register a system hotkey, and when triggered would copy some text into the clipboard and paste it into the active app.
Or, the less technical approach would be to have a copy of notepad open at all times with your bash commands, and then just alt-tab,ctrl-c,alt-tab,ctrl-v each time.
Hopefully someone somewhere on this discussion knows of a client that does an automatic batch of commands when it logs on ;-)
Ok, lets fire up the creativity for a second. what if someone were to make a small cheap device that could send a signal via laser beam? what if these devices came with small tripods, so that you could set a couple in your windows and aim them at the neighbors? Imagine if you could put scopes on them to precisely aim at the receiver on your neighbor's device. What if these devices had a simple ethernet connector on the side, and a protocol to exchange routing tables with others of this device on the same ethernet?
Sell enough of them, and a whole city (provided enough technology enthusiasts) could network themselves, with no digging, and without clogging any wireless bands, and without interferance, and it would be nearly impossible to eavesdrop without being part of the network.
You'd need a clever routing protocol for the system, but that could be fun. Toss in some academic research on the subject, and you might get some efficiency out of the thing.
Anyone else for a brainstorm?
I do miss the days of $49.99 though. The new prices (and lack of a cheap 'standard' version) really is a shame. For a while, they offered a completely free 'personal' version which could only be used for non-commercial purposes, but they don't offer it for free download anymore.
Resizing is a very good thing, IMHO, and I always try to support it when I can. In Delphi, I would just play with the anchors properties (since about D5, I think) which control which edge each side of the component is 'anchroed' to. On the whole, this gives me exactly what I want. I can also set a minimum size for the application, to prevent controls from becoming unusable. (resizing only makes sense to a certian extent, after all, beyond which you'd need to re-think the UI)
Swing, on the other hand, was so painful to get things right that I never really did get the hang of it. It always seems like components are jumping around or getting bizarre positioning, and never stretch in the places where I want. Trying to ensure artistic 8-pixel gaps in the places where I want them is also irritating. Dynamically modifying the components at runtime is nightmarish compared to Delphi, where I would just show/hide things. I haven't tried NetBeans yet... and I suppose they could have fixed it up nicely, but I've still got a bad taste in my mouth from Swing. Resizing wasn't Swing's only problem, though...
Just to randomly rant a bit, <rant>Java also does horrid repaint optimizing. The usual suggestion to get rid of "flicker" in Java progs (which is a symptom of heavy overpainting) is to use double-buffering. This essentially just lets the inefficiency get drawn to the back-buffer, hiding it from the user. It also requires a back-buffer, which is an extra couple meg of wasted memory, if you fullscreen the app on a large true-color desktop. In all, it leaves your program running slowly, because of the overpainting and extra blit operation required (if you're actually lucky enough to get it accelerated- otherwise its an extra copy of a few meg done by the processor) and uses a ton of memory that isn't needed. The end performance has VB written all over it.
If you'd like to test this on your own, try to write a Java program that doesn't paint *anything* onto a rectangle of your window- a dead zone that gets whatever was on that region of the screen before it. If you can, it means that the painting you do on this area is not overpainting any work done by swing/awt, and you've reached some nice efficiency. I've only ever managed to accomplish this on Frame itself, not any of the Component derivatives. Everything else will fill with the background color, even if you'd like to just erase the background with some image of your own.
</rant>
and, yes, Delphi did do efficient repainting, simply because it uses Windows' paint-callback system, and uses system-level windows to represent some of its widgets. Windows is smart enough to prevent overpainting of windowed components. You can even avoid having the background cleared for you if you create the window with the right flags, or just alter the message handling for that window, which can be done in Delphi by overriding a protected method of TWinComponent.
I'll second Delphi. It uses an OO form of the Pascal language, which might be a problem for some, but I'd take pascal any day compared to basic. Also, Delphi is every bit as easy to use as VB.
I used Delphi at a co-op job for six quarters, and it just plain made me feel powerful. I could throw together a nice GUI in minutes, and then "wire up" the events to real code after getting approval from the people who would be using the program. By the time I was done, i'd have a nice professional-looking app that was only about 700K, didn't need any funny DLL files, and was made out of nice strongly-typed OO code, and took advantage of the huge selection of freeware widgets on sites like http://www.torry.net/
Delphi is the perfect language for writing fast windows apps. Its also perfect for database access, and with the right packages, can be perfect for lots of other tasks, like serial port access. (and what I mean by that is that you can go fumbling around with the Windows Serial port API, or you can get a nice I/O package for Delphi and just drag/drop some components that give you nice events to play with.)
To top it off, if you look at the assembly generated by the compiler, its really pretty good. You might say it's equivalent to -O1 on C code, and thanks to its single-pass compiler, it compiles 10x as fast, so there's basically no wait.
(FF1, for those who missed out)
Here's the best listing of the crimes of Real Networks that I've seen...o bnoxious
http://jogin.com/weblog/archives/2004/02/29/real_