Way back when DirectMusic was first released (mid '90's sometime) I loved it. As a game dev and musician I had access to a low latency system that could play rich, textured music that suited what was physically happening on screen.
Let me explain further. The game was one of the first 3D of the Command and Conquer style. When your base was under attack, I could blend in (programmatically) more sounds (drums, bass) that had been pre-recorded to work with the current 'song'. I would also then adjust the tempo by about 10 beats a minute.
The result was increased gamer heart rate, simply because I was positively reinforcing what the gamer was seeing onscreen
As the game action died down (the two forces stopped fighting), I would also gradually bring down the 'level' of sound.
Too bad 3D sound was only just taking off then. I would have done much much more. As it was I was limited to very primitive doppler effects of projects as they whizzed by.
The reason it didn't take off? Mainly because gamers like to play their own music on top of the games rather than shipping what was originally scored.
No, what he's saying is that in this day and age the GPU is becoming programmable. He then states that he wants to be able to program it. In itself, this is fine. The first thing anyone does with highly powerful and low-level hardware instructions is to wrap it up into a nice little API
Boost, STL, and C++ itself are tools that we use to make life better. Of course OpenGL and DirectX will change with the times. If I were on the teams writing those APIs I'd be looking at ways to do realtime ray tracing and the like on next gen (programmable) hardware. The APIs will be here for a while, although admittedly, there is always opportunities for other APIs to come to the fray
ooops. conntinued....
When these queues also overload you need to restart them and they take ages (a fast restart is 20mins). Sometimes this makes the problem even worse (due to poor performing code) and they can't resurrect themselves faster than new incoming requests to buy and sell. Hence the day is lost.
Financial trading systems are vastly different beasts when comparing against a simple client-server arrangement that simply reads and writes to a DB. In these environments data is generally queued and pooled in very elaborate and highly redundant ways (where the end result might be a DB). The previous comment of '1000 trades in 3 secs' is a more accurate way of representing what is going on, although from my experience, that still seems a bit slow
The critical part of this system is when the matched orders (ie the trades) arrive is falling behind and the queues get too big. Hence, LSE pulls the pin and tries to restart.
Unfortunately, this places more pressure on the input queues (eg I want to buy xyz at 14, I want to sell abc at 12)....which are also spooled to disk. When these queues also overload you need to restart them and they take ages (a fast restart is
Considering that I live in Australia...I can tell you straight up that I am NOT paying $990/mo.
The second report shows New Zealand speeds >10mb.
I've been told that the speeds of New Zealand is much slower than Australia (not listed in 2nd report).
Perhaps some better 'facts' could be useful here.
As a developer with so many languages 'under your belt' then the Java language itself should be a snap.
I concur with the parent however wrt picking a 'path' to try out. My choice was mobile applications and consequently I now know j2me pretty darn well.... and I still don't know anything about TomCat or jsp.
So, choose applets/utilities to write that are helpful to you and ask questions specific to that.
A few years ago I griped at mozilla about this argument (about cacert.org's lack of support in fact). I made the suggestion that 'trust' is a community thing and shouldn't be left with any one individual/company.
I proposed that a browser could/should a) display a particular websites's trustworthiness (and it includes it's CA) and b) a method for a user to give a site the thumbs up or thumbs down, just like any voting scenario we have.
It is an easy system to implement and it would quickly reflect on bad CA's who do not check their client's certification (if at all possible).
Slashdot Mirror
Like, everyone needs caps lock don't we? ffs!
Microsoft's XNA Gaming platform. It's free (if you use Visual Studio Express) and it's all about games.
My teen nephew is getting right into it (despite the fact that he still wants to be a policeman!)
Ironcially, the flying toasters first appeared on a Mac:
link
What was really scary for me was when I was losing at Space Invaders and those little suckers were about to land AND I was on my last coin!
It won't work on my Arduino, it's only got 1k RAM.
http://www.arduino.cc/
...and one of the first things they did as a sample was to write Pong.
Finally! Game play has come full circle.
http://communityclips.officelabs.com/Video.aspx?videoId=a89a217b-fc38-4a6c-87f8-ab59a2028391
Way back when DirectMusic was first released (mid '90's sometime) I loved it. As a game dev and musician I had access to a low latency system that could play rich, textured music that suited what was physically happening on screen.
Let me explain further. The game was one of the first 3D of the Command and Conquer style. When your base was under attack, I could blend in (programmatically) more sounds (drums, bass) that had been pre-recorded to work with the current 'song'. I would also then adjust the tempo by about 10 beats a minute.
The result was increased gamer heart rate, simply because I was positively reinforcing what the gamer was seeing onscreen
As the game action died down (the two forces stopped fighting), I would also gradually bring down the 'level' of sound.
Too bad 3D sound was only just taking off then. I would have done much much more. As it was I was limited to very primitive doppler effects of projects as they whizzed by.
The reason it didn't take off? Mainly because gamers like to play their own music on top of the games rather than shipping what was originally scored.
No, what he's saying is that in this day and age the GPU is becoming programmable. He then states that he wants to be able to program it. In itself, this is fine. The first thing anyone does with highly powerful and low-level hardware instructions is to wrap it up into a nice little API
Boost, STL, and C++ itself are tools that we use to make life better. Of course OpenGL and DirectX will change with the times. If I were on the teams writing those APIs I'd be looking at ways to do realtime ray tracing and the like on next gen (programmable) hardware. The APIs will be here for a while, although admittedly, there is always opportunities for other APIs to come to the fray
ooops. conntinued.... When these queues also overload you need to restart them and they take ages (a fast restart is 20mins). Sometimes this makes the problem even worse (due to poor performing code) and they can't resurrect themselves faster than new incoming requests to buy and sell. Hence the day is lost.
Financial trading systems are vastly different beasts when comparing against a simple client-server arrangement that simply reads and writes to a DB. In these environments data is generally queued and pooled in very elaborate and highly redundant ways (where the end result might be a DB). The previous comment of '1000 trades in 3 secs' is a more accurate way of representing what is going on, although from my experience, that still seems a bit slow
The critical part of this system is when the matched orders (ie the trades) arrive is falling behind and the queues get too big. Hence, LSE pulls the pin and tries to restart.
Unfortunately, this places more pressure on the input queues (eg I want to buy xyz at 14, I want to sell abc at 12)....which are also spooled to disk. When these queues also overload you need to restart them and they take ages (a fast restart is
Considering that I live in Australia...I can tell you straight up that I am NOT paying $990/mo. The second report shows New Zealand speeds >10mb. I've been told that the speeds of New Zealand is much slower than Australia (not listed in 2nd report). Perhaps some better 'facts' could be useful here.
As a developer with so many languages 'under your belt' then the Java language itself should be a snap. I concur with the parent however wrt picking a 'path' to try out. My choice was mobile applications and consequently I now know j2me pretty darn well.... and I still don't know anything about TomCat or jsp. So, choose applets/utilities to write that are helpful to you and ask questions specific to that.
A few years ago I griped at mozilla about this argument (about cacert.org's lack of support in fact). I made the suggestion that 'trust' is a community thing and shouldn't be left with any one individual/company. I proposed that a browser could/should a) display a particular websites's trustworthiness (and it includes it's CA) and b) a method for a user to give a site the thumbs up or thumbs down, just like any voting scenario we have. It is an easy system to implement and it would quickly reflect on bad CA's who do not check their client's certification (if at all possible).