Suggestions having App-Fights? "Lets discuss" thread.
dim, 03/24/2013 - 08:38
No, I do not mean an apple fight, or a food battle. Currently, the suggestions is filled with threads about apps. There are fights in those threads, and it must stop right now.
The main question is: "Does it actually work between Spiral knights and apps?"
Nobody knows 100%. The main thing that everyone is doing is fighting with their own opinion. Eventually, it gets ugly. Some people even go too far and go beyond negative. Something like "dude ur opinion sucks java works on everything u stupid [GM censor example]! it works on evertin. u dunt hav 2 run sk wit java. u just put username and u r logged in". That is what reminds me of those threads.
I really get paranoid for the fact that I go there, say it's impossible and that is my opinion, and then people start saying "dud ur argument is invalid gtfo". What? It's just opinions. We are just saying our own facts.
Now, don't get me wrong here. The only way to stop it is to follow what Oatmonster usually says in his posts which is "Google or GTFO!". Honestly, I find it really funny and at the same time, it's seriously true. Another way is to just say "It's only my fact and opinion. Don't get me wrong here". People cannot just say "Dude your fact was 100% stupid" because again, it's just an opinion and fact.
So tell me, can you please share your own facts and opinions without any rage? Discuss about how apps can and cannot work. If you say it works on everything, give a reason. Do not just come here and say "Invalid, Invalid, INVALID!!". No, you are going to have to give back up reasons and the next person discusses and so on.
Btw, this is not a game. Just a discussion.
dim, 03/24/2013 - 16:22
#2
APIs are, 99.5% of the time,
APIs are, 99.5% of the time, language-independent. Once someone has written/implemented an API with XML-RPC, SOAP, REST, whatever, all a client needs to know is the specific protocol used as well as the API calls available in order to use the API.
Spiral Knights the client, as it exists today, requires a JVM, LWJGL, and OpenGL. Running it on a platform currently requires all those pieces to be in place;
- LWJGL is fairly platform-independent.
- JVMs for non-mobile platforms are plentiful. Mobile platforms will likely require a rebuild to something that can run on them (Dalvik, native code); likely only OOO can do that with any reliability.
- Larger (e.g. PC) non-mobile platforms support OpenGL. The smaller non-mobile platforms don't support OpenGL, but rather OpenGL ES. Mobile platforms also support OpenGL ES. Porting the SK client to OpenGL ES is something that currently only OOO can do.
dim, 03/24/2013 - 18:00
#3
For the curious
(actual output was massaged slightly for cosmetic purposes, but is generally accurate)
$ bash -x javatest
+ cat > test.java << EOF
class test
{
public static void main(String[] args){
System.out.println("Hello from Java!");
}
}
EOF
# OpenJDK
+ java -version
java version "1.6.0_24"
OpenJDK Runtime Environment (IcedTea6 1.11.6) (fedora-71.1.11.6.fc16-x86_64)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
+ javac test.java
+ java test
Hello from Java!
# GCJ source -> native
+ gcj --version
gcj (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ gcj --main=test test.java
+ ./a.out
Hello from Java!
+ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, not stripped
+ ldd a.out
linux-vdso.so.1 => (0x00007fffd53ff000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003c0de00000)
libgcj.so.12 => /usr/lib64/libgcj.so.12 (0x0000003c10a00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003c0ca00000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c0d200000)
librt.so.1 => /lib64/librt.so.1 (0x0000003c0da00000)
libz.so.1 => /lib64/libz.so.1 (0x0000003c0d600000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003c0ce00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003c0c600000)
/lib64/ld-linux-x86-64.so.2 (0x0000003c0c200000)
# GCJ bytecode -> native
+ gcj --main=test test.class
+ ./a.out
Hello from Java!
# GCJ intermediate code
+ gcj -S test.java
+ cat test.s
.file "ccEnLImu.jar"
.text
.Ltext0:
.section .jcr,"aw",@progbits
.align 8
.quad _ZN4test6class$E
.text
.align 2
.globl _ZN4testC1Ev
.type _ZN4testC1Ev, @function
_ZN4testC1Ev:
.LFB0:
.cfi_startproc
(ZOMG, do it yourself if you want the whole thing...)
.LASF6:
.string "/home/ignacio/Work/tmp/javatest"
.LASF0:
.string ""
.LASF1:
.string "main"
.LASF2:
.string "_ZN4testC1Ev"
.ident "GCC: (GNU) 4.6.3 20120306 (Red Hat 4.6.3-2)"
.section .note.GNU-stack,"",@progbits
dim, 03/24/2013 - 18:52
#4
Just a small point on running
Just a small point on running the current Spiral Knight client on mobile devices: LWJGL encapsulates OpenGL, whose recent versions already seem to support OpenGL ES. That would mean that in regards to OpenGL, other than handling the proper distribution of the program code, it would not require OOO's intervention. This might be why this guy was probably able to do what he did ;)
Also, why are you posting the compilation results of a typical Hello World application? xD
dim, 03/24/2013 - 18:58
#5
Re LWJGL, the calls for
Re LWJGL, the calls for OpenGL and OpenGL ES are distinct, so you'd have to modify the client (or perhaps just part of Clyde) to use OpenGL ES instead.
I did that to show that Java source code (and bytecode) can be compiled to native code, which will allow it to run on a system that does not have a bog-standard JVM available.
dim, 03/24/2013 - 19:09
#6
LWJGL is open source, so the
LWJGL is open source, so the pertinent library calls could just be modified and repackaged for a hack job, but I see your point :) And thanks for that link to Clyde! I did not know threerings.net had a page on github ... This is going on my bookmarks!
dim, 03/24/2013 - 19:12
#7
Ignore if you want
But I usually see the OP as the person who dismisses things as invalid solely because of Java.
dim, 03/24/2013 - 20:11
#8
So...
Remember how I said SK will never work as a full game on a mobile device, since it uses Java?
Well apparently... I was wrong.
No vide proof of it working, so I can't tell if it's fake... but yeah. Apparently it's possible.
~Klipik's alt
lun, 03/25/2013 - 18:22
#9
Bump.
Anyways, to be honest, playing Spiral knights on the wii is impossible.
HOWEVER, you can connect your laptop to the TV, display it up and there you go. You can see Spiral knights on Tv! Depends on the type of Tv.
....