A Cup of Conquer

I got bored during Java class - and since I can't access my project due to internet problems back at my apartment.... this happened.

[Only registered and activated users can see links. Click Here To Register...]

I have no idea if I'll continue it or not. It'll only be worked on when I'm in that class probably. It uses an Asynchronous socket system that I thought would be appropriate. The goal (if I continue it) is to create a portable server that anyone can work on from anywhere. Cheers.

This would be nice time cutting one Fang

Cheers, mate.

sooooo classic

Qonquer was java, that worked well from what I saw.

It's funny how the Dalvik VM is optimized like HELL on Android, yet C# apps still run faster. Stupid Google.

Quote:

Originally Posted by _DreadNought_ Qonquer was java, that worked well from what I saw.

Conquer poses no challenge as far as efficiency is concerned. That's why so few people have bothered using C++ for conquer sources. The theoretical performance boost can hardly be argued for when weighed against the rapid prototyping power of something like C#, Java or other managed languages.


PS: Qonquer had insane amounts of issues. Not that they were all due to being Java but using it as a benchmark is a bit silly.


Look at something like minecraft. Large procedurally generated worlds with some spacial partitioning going on and you really start to care about efficiency. Simple 2d coordinate worlds with a rather small max player base is hardly a 'challenge'.

Well, after all this, where the fuck does C++ fall into?

Yeap, that's right, c++ is much more professional and work wise, that is why, I'm learning it more and more everyday.

Java is not the best language in term of performance. The JVM eat a lot of memory and CPU for small tasks. A developer already stated that it was really hard to make a powerful game on Android due to Java. The cellphones might have better CPU/memory than the iPhone, Java can't beat Obj-C in term of efficiency. (Well, I really the Obj-C's syntax, but for a managed language which can interact with native C++ without any transitional layer, it's impressive).

I wouldn't use Qonquer as a reference, but well, it clearly worked well. Anyway, most problems with CO2 servers are related to the guys who code them. It's not a language issue. And anyway, CO2 isn't big enough to make a difference between languages as stated pro4never. It's like when Korvacs (I think) made an optimized map system (can't remember using which structure). Well, CO2 is small enough to put all players/monsters on a common dictionary for each map without affecting the performance.

I do use Java for school. I dislike the language (lack of features/efficiency) Each time I launch a Java application, I know it without looking to the binary... In comparison to true Cocoa/Carbon app (or Qt), they're really slow. (e.g. JDownloader, NetBeans) It's my opinion.

The purpose of the project isn't to make an efficient server (although I was thinking about it while I was writing it for fun). Really, the goal of the project is to make a managed server that is easy to work on (for the people who download it), and easy to host ($3 for a Linux host vs. $25+ for a Windows host). Taken, there are ways around that with C# (Mono), but you get where I'm coming from. In no way am I making the assumption that Java is an efficient language to write a server in. It's targeted more at the consumer than anything else. I'm not going to work on this project though - this was just for fun. I will release the socket system though when it's done.

Interesting. Did you use NIO2's java.nio.channels.AsynchronousServerSocketChannel or did you roll your own? Also, how are you compensating for the difference in endianness, are you using java.nio.ByteBuffer for that?

This thread, wasn't even meant to be about the console his server uses to run, all Fang did was post a picture of a customized JAVA server.
If you ask me, the threads kind of getting off-topic.

Quote:

Originally Posted by Aegolius Interesting. Did you use NIO2's java.nio.channels.AsynchronousServerSocketChannel or did you roll your own? Also, how are you compensating for the difference in endianness, are you using java.nio.ByteBuffer for that?

Yah, I am using the AsynchronousServerSocketChannel class from java.nio.channels. I'm also using the grouping that goes with it for the thread pooling and ByteBuffer for compensating for the difference you mentioned (managed by a passport class, inherited by the client class). It really was just for fun though. Just wanted to show something I thought was interesting. My friend might continue with it but it's a bit advanced for him still. We'll see. I made it because we were working together and got done with our work early (in java class).

Quote:

Originally Posted by Fаng Yah, I am using the AsynchronousServerSocketChannel class from java.nio.channels. I'm also using the grouping that goes with it for the thread pooling and ByteBuffer for compensating for the difference you mentioned (managed by a passport class, inherited by the client class). It really was just for fun though. Just wanted to show something I thought was interesting. My friend might continue with it but it's a bit advanced for him still. We'll see. I made it because we were working together and got done with our work early (in java class).

Nice. Exactly how far did you get? Were you able to successfully implement the cipher in Java? Also, what client version are you targeting? It'd be nice to receive updates if either of you choose to continue working on it.

Quote:

Originally Posted by Aegolius Nice. Exactly how far did you get? Were you able to successfully implement the cipher in Java? Also, what client version are you targeting? It'd be nice to receive updates if either of you choose to continue working on it.

Currently, it's targeted at any client. It only connects to the client and tells me where the connection came from. I ran out of time in class during my client passport implementation. I was just planning out my receive methods. The client version I was using in the picture above was 4294. If I continue, I'll be downgrading it to 4274 since it's documented for my friend.