Stendhal 0.30: Items y un nuevo sistema de combate

Stendhal es un juego de aventuras multijugador desarrollado usando un framework desarrollado en Java que actua como middleware para el desarrollo de juegos multijugador en linea: Marauroa. Todo esta hecho usando Java y Java2D. Y ademas es open source ( GPL ).



Esta "esperada" version 0.30 añade finalmente los items para que los puedas usar: espada, mazo, escudo y armadura. Puedes obtenerlos comprandolos en la taberna.



Esta version desafortunadamente no añade inventario porque requeria una gran modificacion del GUI. Esperamos tener algo para dentro de un par de semanas.



Descarga

http://prdownloads.sourceforge.net/arianne/stendhal-0.30.zip?download



Por favor... cualquier duda/pregunta/sugerencia/fallo comentadnoslo.

Netbeans 4.1 vs Eclipse 3.1

En Javalobby un usuario de IntellyJ ha hecho una pequeña comparacrión entre Netbeans 4.1 vs Eclipse 3.1 en base a una evaluacrión bastante limitada que ha llevado a cabo. En la evolucrión Torbjýrn Gannholm comenta sus aventuras y desventuras al intentar poner a funcionar un proyecto que tenýa en un CVS en ambos IDEs y realizar unas cuantas operaciones býsicas con ellas. El resultado final: ninguno de ellos le convence y cree que la herramienta de IDEA va bastante más allí que cualquiera de ellos, pero puestos a elegir un ganador se queda con netbeans ya que en ýl al menos fue capaz de llevar el proyecto un estado en el que podýa trabajar.



Esta evaluacrión, muy býsica, no puede considerarse, ni mucho menos, una comparativa detallada de ambas herramientas. Si puede ser un indicio de lo intuitivas que son, y desde su punto de vista Netbeans 4.1 parece superar a Eclipse 3.1. En cualquier caso, este post ha creado un interesante debate en Javalobby y espero que tambrión lo cree aquí: ¿alguien aprobado ambas herramientas? ¿qué impresiones ha tenido? Y los que sýlo habýis probado una ¿qué es lo que más os ha gustado de Netbeans 4.1 /Eclipse 3.1?.

Mitos sobre el rendimiento de Java (Azul Systems)

Cliff Click, de Azul Systems enumerý en JavaOne una serie de mitos sobre prácticas que influyen en el rendimiento de la ejecucrión de código Java. El problema de dichos mitos es que su seguimiento "empeora" la legilibilidad del código injustificadamente.



En resumen:



1) Los métodos "final" hacen más rýpido el código que sin dicha palabra clave (métodos virtuales). Falso.



2) Los bloques try/catch o no influyen o influyen mucho en el rendimiento. Ambos son errýneos como mýximas, depende, en el ýmbito de bucles pueden ser costosos en otros casos no.



3) Usar Run-Time Type Info (instanceof) mejor que llamar a métodos virtuales. Ambos son comparables, el RTTI da lugar a código más "feo".



4) La sincronizacrión es muy lenta. No es cierto, tiene impacto pero pequeño y con los aráos cada vez menor.



5) Usar pools de objetos reusables en vez de crear nuevos y dejar al garbage colector liberarlos. La primera opcrión es problemýtica cuando hay varios hilos al necesitar sincronizarse la coleccrión disminuyendo el rendimiento buscado, complica además el programa. Es "rentable" en grandes colecciones de objetos.



6) Las mejoras introducidas en la Java Platform Standard Edition 5.0 son costosas en rendimiento. No es cierto, enums, autoboxing y varargs no influyen en el rendimiento. Sýlo el método values() de los enums es lento.



¿Y tu que opinas? ýutilizas estas prácticas de mejora del rendimiento?

Java ya existe en tiempo real

Sun ha publicado su versrión en tiempo real de Java, diseríada para dispositivos y capaz de responder a eventos de alta prioridad en un tiempo limitado de antemano.


La JVM de tiempo real ejecuta cualquier programa de la Java Standard Edition pero añade extensiones que garantizan que ciertos eventos crýticos son ejecutados dentro de un cierto tiempo. Esta caracterýstica es esencial en el mundo de la robýtica.

UE: la directiva de patentes software se votarý el

El Parlamento Europeo votarý el mriórcoles de la prýxima semana la patentabilidad de software.



Segun elpais.es : "se desconoce todavía el sentido que tendrý el voto de los eurodiputados, puesto que en primera lectura rechazaron la patentabilidad del software, pero la comisrión de Asuntos jurýdicos ha dicho lo contrario en segunda lectura. Tampoco está clara la posicrión al respecto de los Estados miembros, puesto que en la primera votacrión. España se pronuncrió en contra, pero Italia, Bélgica, Dinamarca y Austria se abstuvieron, lo que no consigurió ser una minorýa de bloqueo para impedir la tramitacrión."