Well if you are interested really is what tax do i, could i owe. Then consider that personal income tax is not the same as company income tax. Setting up as a company and being naive about how you take the money out for your self can get you a double tax. But really most countries do provide quite a lot of help and advice on the topic. At least NZ, Austria and Switzerland anyway. Typically most things are roughly "taxed" once with the exception of VAT. Steams cuts is not however a tax.

Also while there is no money, there is no tax. But you may want to keep track of any real outgoings, since they are often valid for deductions for a few years (Austria its like 5 years, NZ 7). Even if you don't do the company thing. 

I think you want to normalize by the range of a band. So for this matrix it would be 16/65 for 16 levels per channel. Or 4/65 for 64 levels per channel. I am assuming the range is 0-255.

To sort of back that up. Note that if a value is overflowing before a call to closestCol, it can still be overflowing after. So it seems the dithering values should be a portion of between color range.

Oh right order of precedence. I never write code that way since you can't tell what you meant by it. ie a/b*b or did you mean a/(b*b). So i would write (a/b)*b.

Note that you get a different result from (b*a)/b too. So best be explicit. Brackets don't hurt anyone.

So yea I think the normalization in the wiki is the problem. Note the matrices they show are normalized to be less than 1. So its just not clear what range colors are suppose to take. Well not without more work.

You don't appear to finding the "closest" color correctly. Currently you are dividing by 64*64=4096. That seems way too high. Why to you square that bd?

Also i don't really follow how the wiki is normalizing the color values. The paper linked is too old and a bad scanned copy for me to bother reading it.

Note you can also do probabilistic dithering. Probably works about as bad as normal dithering tbh.

And for performance code, opengl is FAR easier than java2d. Perhaps FX may change that. But i won't hold my breath.

That comment was clearly not directed you . And lets face it, a lot of UDP is $THIS or $THAT mostly from circulated internet rumors. When you really measure things, its a different story.

I call the quake protocol rare in that you do need the whole state to fit into a packet. What people often miss with UDP is that you can send packets that are larger than the MTU. The ip stack fragments them and resembles, clearly in order. But will not request a missing fragment, but let the reassembly timeout. That means you need to fit it into 1400 bytes or so in practice (its mostly 1500MTU these days i think). That is not a lot of entities or data really.

Long story short. Everything works when you have a good connection. Mostly nothing works when you don't. And since when things stop working they often stop working in different ways, its hard to have a protocol that will work in that case, let alone all other possible cases.

Kev, i was trying to not confuse those new to networking. Your protocol is basically the quake3 protocol and is the very rare case of UDP being a good idea. There is flow control and even a solution to the 2 generals problem built in to it.

But i will take issue with the TCP slower comment. The only time you get "reordering" is with packet loss in practice. The internet is not the same place it was in the 90s.  In this case even the quake protocol doesn't work well in practice either (jittery lag). Also since for a lot of games you don't fit the whole state into a packet, you need the missing ones anyway. And now your implementing TCP on top of UDP again. Which a lot of people seem hell bent on doing. And doing badly.

FWIW I have done plenty with both. And even things like IPX stuff. Sure it can all work. But for most TCP "just works" and when it doesn't, the alternatives don't either. And they won't work without a huge amount of effort and experience and testing in REAL WORLD CASES. Not that LAN your working on. 

Ok so some totally terrible advice here, and some stuff that is just plain wrong. Don't take it personally, but i get a feeling there is a lot of regurgitated "i heard that you do it this way".

For any first cut, just use TCP. Only TCP. It does a bunch of hard stuff for you and has been tuned over the years to be pretty darn good. Only consider UDP if TCP is not working out. And then only if you understand the next points and you understand that its TCP that is causing the problems. Since your not networking with someone on the moon or mars, this seems very unlikely.

If you have never heard of flow control, or congestion collapse, then don't use UDP.

If you don't know what the 2 generals problem is then don't use UDP.

There are other things you should know too before you do UDP. But mostly just don't use it. TCP is *not* slower, its the same packets over the same network. In some cases it is still faster for reasons that its statefull and some routers and firewalls cache information about it, and ISPs typically prioritise TCP over UDP.

UDP packets *can* fragment and still incur  reassembly cost on the IP stack anyway.

When you have enough packet loss to make TCP slow, UDP is also slow. You can't change the fact that its still IP packets, and the packets get lost/reordered when you have congestion. TCP at least will deal with it properly (flow control).

TCP is far simpler since its doing everything for you and it just looks like a stream. Simple is good. Anything probably won't work at all.

Network code is most games is total shit. Really. Just look at the forums for the different games about all the network issues.  Right now a lot of games are moving back to TCP from UDP. Perhaps they finally didn't get a game programmer for the network code and got someone who knows what they are talking about.

Your blocking is a thread issue most likely. . There is no way, unless you are on a 9600baud rate modem that 20 packets a second will do anything to a 10Mbit Ethernet connection or even a 14k connection. Doing both TCP and UDP is fine from a technical perspective. But there really is no point. Once congested, both TCP and UDP will be crap. Otherwise they both just work. Right now there are lots of TCP and UDP happening from your computer at the same time.  

Note you can still do Asynchronous IO with just the streams that a TCP socket gives you. For a 2 player game there really is no need for the complications of NIO which is not really intended for such simple cases. Turn based listening could also work. Simple 2 threads with very little interaction could also work well.

I am not saying UDP is wrong. What i am saying is that its mostly used when TCP is better, and when its used its used Wrong. Very wrong. The overuse of UDP is based on the myth that its "faster". This is not the case. If you don't believe me. Test it.

If you don't know what you are doing, its probably not a good idea to do a tutorial about it. A basic prerequisite for teaching is to know your material well.

However that aside, I would answer that question with a question. What data structure would *you* store "ground" information in?

Tulips. Big money in Tulips.

Line 7 reassigned  the local variable 'map' to point to a different map object from the one passed in.

Would work.

You could put things into the provided map. As in you don't create a new map object just use the map object that is passed in. Otherwise this is pretty much how it needs to be done due to type erasure.

Also total volume sold every day on gox is pretty low, so you don't have much liquidity.

But the mining thing is really simple in concept. It is hash cash. There is a hardness setting that determines how many zeros at the end the hash must have. Mining means picking a random nouce, hashing, Does it have the required numbers of zeros? No do it again.

From the math, we know that if the last 16bits need to be zero, then you need on average 65536 hashes (and random nounces) to get a "hit". With 20 bits of hardness its about a million. 30 bits is about a billion. The new ASIC miners are advertising 30 billion hashes a second.

Personally i don't like the idea of work without utility. Also almost all the bitcoins are owned by a few people that started quite early. Personally i wouldn't touch it. Too volatile, too speculative.  Invest in platinum or copper instead.

I have been programming for many years, and *i* did it in this thread too. I didn't read the first post properly.

There are times where you just have to suck it up because you really did write stupid, brain dead code. You become a better programmer when you can learn from criticism. This is even more true when your starting out.

Riven even does it sometimes 

You know for most people the distributor they sign with becomes the master of their destiny. It is highly unlikely that you can get another deal if the first deal turns sour.

As for a gatekeeper. Yea they are a bit. And its a concern. If they really stuff it up and do something stupid. I think you will see different services popping up. And lets face it, its better than amazon being the gate keeper. At least for now.

The math is wrong. You would get duplicates a little bit more than 1% of the time. Given that you have a duplicate it will be the smallest number just a little bit more than half the time. So a total error of more than one true of a little over .5%

The little over are for 3 way ties.

And still this thread refuses to die... Its a Zombie. Eating unsuspecting brains for breakfast.

[edit] This is assuming as in the previous post that the ints are chosen between 0 and 99 (aka nextInt(100))

Roquen got it right.

However if you are still trying to do it yourself, the only way to do this is a game is to cheat. Game physics engines cheat. Plain and simple. Cheating for this sort of thing means permitting some overlap. Usually providing some extra force to push it out of overlap, but not too much or it will fly off the screen.

If you look carefully at most games, you can see lots of overlapping objects.

People forget sometimes its not just what you can get on the service, but also what you can't get. That is if its on steam its probably of at least a particular standard, or at the least will "mostly work". While any free or almost free implies no curation (that costs time and money) which means any old piece of crap, and malware gets on.

riven is right of course. I should also at least read the first post.

That is an awful random boolean. There is no guarantee on the resolution of the timer. They are never accurate to the nanosecond. So you have good odds that 2 calls in a row would give the same result. In fact that would almost always happen.

Seriously what is wrong with random.nextBoolean()? 

Also this is a good example why sometimes we want to use the top "random" case because it will give better math properties on some problems. For example stochastic integration.

Now we have thoroughly confused the new guy... Our work is done.

princec was being overly modest and nice. Fact is princec finished the games or at least some of the games they start. That is the trick. And that makes princec a better programmer.

You know the steam folks came out with numbers that showed higher performance on linux than windows. But 30% is meh... You going to get far bigger range of performance from different grfx cards. No point super optimizing for one specific case.

Yes they will look different. Without calibrating both devices and using  a proper color space like sRGB it will always be like this. Even doing that it will genrally look different. Brightness even more so, since even age of the monitor/screen will affect that. Screens are different, look different in different lighting conditions (your eyes do a bit white balance as it turns out), etc.  doubly so on phones where screens are definitely  not high end desktop publishing quality aka are not the calibration kind.

Its not suppose to look identical on different devices. Its suppose to look sort of the same.

I would immediately consider drivers, driver settings and your xorg setup. Turn off desktop composing for example. Also check your clocking performance. Perhaps the cpu is always throttled?

Quite simply there should not be a big performance difference between the platforms in general.  I would expect no more than 20% tops in either direction.

 In fact how much is the difference. If you have gone from 100fps to 60, well yea perhaps you have vsync?

I know that there are NDAs.

However there are plenty of posts around were people strongly sugest what the terms are. At least the companies i know who have products on steam are under non exclusive. ie they are allowed to sell it else where. They never wanted to sell it cheaper than steam. Also steam IIRC can do promotions and sell your game cheaper at times. Since you get advertising these guys didn't complain much since it increased their total income quite a bit. Their next game they are going to use steam exclusively since its just easier and really quite a good rate (30% was whispered under a table somewhere). Compare to traditional distributors, where they can often take 50% or more *and* then take advertising and promotion out of your cut!

Cas will probably chime in. But again most of us do take our NDA's seriously. Even more so with companies where we feel they are at least being honest. Which is certainly steams reputation to a point.

Just a FYI: There are no dumb questions but there are dumb topic/subject titles. Ask the question, that way people who can/want to help will read your post. Things like "help please" "I have a question" are really bad since most people will not read the thread to see what you asked. Many forums will delete such topics.

But we are nicer around here.   

I would still think something like a quad/oct tree would work better. It can partition the space at wall/room boundaries.

BSPs got popular because Doom then quake used them. Back when doom was doing it, it was because you can do the painters algo pretty easy and add some tricks to that to improve things even more. Remember that Opengl was something only million dollar machines had at the time..Well at least a few 100k.

The painters algo is simply drawing things far away first. BSP allow you to easily traverse in a depth order from where ever the viewer is quickly.

They are perhaps not really a good match for modern hardware, but then again it depends.

I wrote one way back when i was still young. There are a few tricks to make sure the BSP is balanced. Also you need to "cut" large flat surfaces a lot when there are lots of little surfaces. So there are lots degenerate cases that you must consider. BSP take in triangle, for each triangle the space is cut into 2, the side "above" the triangle and the side below the triangle. As you can imagine, there are some triangles that are both above and below. These need to be cut.

So yea. Can't see why one would use BSP these days. Perhaps there are some cases where you can "compile" the map and then make some of the drawing code faster. But i can't see it being easier or better than some of the other spacial tree structures theses days.