Buenas,

 yo tengo una HP 1510 multifuncion, no esta nada mal, y la calidad creo que es bastante buena. Y lo de hacer fotocopias sin encender el ordenador es más que comodo. Un punto en contra: para instalar el escaner, HP te "obliga" a instalarte un pack de herramientas inutiles+.net (+450mb); si no lo instalas, no puedes usar el escaner. Para mi fue una putada, porque esas herramientas no me sirven para nada. Pero si no te molestan, el escaner funciona de manera decente.


Saludos.

jeje... ahi vamos de nuevo!

Me da la impresion de que son AABB en coordenadas locales (del modelo), por eso xmin, ymin y zmin seran posiblemente negativas, de ahi que

x + xmin = 0 --> x = -xmin  (por ejemplo)

cualquier x que cumpla xmin < x < xmax, estara dentro del AABB


Saludos!

Buenas,

no soy un experto en OpenGL, pero me da la impresion (por lo que vi) de que las "display lists" se pueden implementar como vertex buffers (dentro del driver). Si es asi, no es de extrañar que las display lists y los VBO ofrezcan performance similar.
En cualquier caso, lo logico seria que una display list envie los vertices a la memoria de la tarjeta, y de ahi que sirvan solo para geometria estatica (a menos que uses un vertex shader).

No hay en opengl vertex buffers dinamicos, pensados precisamente para geometria dinamica?

Por otro lado, tambien hay otras cosas para optimizar:
-topologia de las mallas
-cantidad/tamaño de texturas, y cambio de texturas por frame
-Z-test

Saludos!

Segun he leido, mas alla de que uses d3d u ogl, lo mas rapido seria usar vertex buffers estaticos, y triangle strips.

1280x800 + 1440x900

Java.. si... y ademas nos da de comer.... y bastante bien ultimamente!

Creo que al final Blitz3d no se ha pronunciado... seria interesante saber mas qué tipo de cosas quiere programar, tal vez se lo pueda guiar mejor todavia, no?

Saludos!

En Smalltalk estan los mismo conceptos que manejamos dia a dia: "un fiat es un coche, un coche es un vehiculo... un fiat tiene puertas, porque un coche tiene puertas..." etc etc (etc simplificado)

En smalltalk no hay estructuras, ni saltos condicionales, ni bucles ni nada de esas cosas inventadas tan solo porque los ordenadores no pueden representar la realidad tal como la vemos nosotros.

En smalltalk solo hay clases, objetos y mensajes. Y ni hablar de lenguajes todavia mas cercanos a la realidad, como Self (donde ni siquiera hay clases).

En cuanto a que Pascal es mas facil de digerir... la verdad es que no tengo idea. Yo empece programando en procedural, el Pascal fue mi segundo lenguaje (despues del Basic), y nunca conoci a nadie que haya empezado programando en Squeak, Smalltalk o algo parecido.

Pero bueno, esto se esta transformando mas en una tertulia academica que en una ayuda al que empezo el thread   :wink:


Saludos!

...y por cierto quien es Kropotkin , yo no he dicho nada de el, por lo menos concientemente.

Piotr Kropotkin, pensador ruso, el autor de la frase que llevas en la firma...

Bueno. Yo empecé programanado basic en una calculadora hace 25 años o mas . Pero eso ni lo cuento xq eso fué progrmaación negativa. Una venganza

jeje... igual, resulta que al final es muy divertido programar en plataformas "raras" o "no convencionales".

eh.. no.

Hola, queria aclarar algunas cosas de tu Post, para que la gente no se confunda, los lenguajes que dijiste puede llevar a muchos vicios, pero a un buen programador no le pasaria, por que si sabe programar, programara bien.

Para programar bien, primero hay que aprender, y mientra se aprende, se cometen errores. Algunos (o mucho) de esos errores se transforman en vicios. Un lenguaje complejo de utilizar (como el c++ o el java), confunde al aprendiz, y por ende puede llevar a cometer errores, y a enviciar su modo de programar.

Pero decir que es un produce vicio el C, el unico vicio que produce es el de seguir programando, el C es unos de los mejores lenguajes de programcion a alto nivel del mundo, fue creado para poder hacer lo que ensamblador no podia, y es mas en un videojuego, logro que se pudieran portar los programas con cambios de 20 lineas o mas, en ves de cambiar todas las direcciones de memoria.

El C esta lejos de ser uno de los mejores lenguajes de programación del mundo. No hay mas que ver los distintos simposios y congresos que giran alrededor de paradigmas a los que un lenguaje como el C (o el C++) no puede hacer frente. Y en mi opinion, paradigmas como el de objetos o el de aspectos, desplazan al lenguaje C/C++ al nivel medio.

Es cierto que algunas cosas es mas facil hacerlas en procedural que en funcional, declarativo u objetos. Precisamente por eso hay tantos paradigmas, porque con un solo paradigma no puede hacerse todo (de manera prolija y correcta, claro). Pero aprender a programar en funcional y objetos da una serie de herramientas que el procedural no da, y que hoy por hoy son más que utiles (bueno, dudo del funcional para este proposito, pero ayuda mucho a estructurar la cabeza...).

En fin, si el chico quiere aprender a programar cosas concretas y nada mas, aprender un lenguaje procedural o pseudo-objetos esta bien, al final todos empezamos por ahi.


Por cierto, muy buena la frase de Kropotkin.

Saludos!

No se en qué es mas intuitivo hacer

Código [Seleccionar] Expand

var
 coche :Coche;

begin
 coche.color := ROJO;
 if coche.cabriolet = True then
   coche.desmontarTecho();
end.


a esto

Código [Seleccionar] Expand


coche <- Coche nuevo
coche color: ROJO
coche esCabriolet: [ desmontarTecho ]


por poner un ejemplo bien sencillito. Si tengo que explicar Pascal, tengo que explicar para que sirve var, begin, end, if, then, =, :=, el parentesis.... si tengo que explicar smalltalk (o squeak) es un poco mas facil: el :, los [], y poco mas. Además de la interfaz visual, el poco codigo que hay que escribir, y todo lo que se menciono antes...

igual, al final cada uno elige lo que quiere...

(como yo, que como no sabia, y empece con gwbasic... puaj!)


Saludos!

Hay un lenguaje que se llama gopher? Pensaba q era un protocolo.

Si, hay un lenguaje que se llama gopher... se usa mas que nada en ambientes academicos (al menos en mi caso). Y tambien es un protocolo (por cierto, alguien lo usa todavia?)

Lisp.... eso sigue? Pensaba q habia desaparecido hace muchos años.

Si, el Lisp sigue.. de hecho, todavia hay congresos, si no me equivoco. Otro lenguaje muy academico (aunque el Emacs lo usa para casi todo)

Smalltalk muy bueno. Pero casi no se usa por lo menos en Europa a nivel profesional. En cuanto a que Java y C++ son caca , culo, pis... pos bueno. Pero si quieres trabajar en el mundo real creo q son muy buenas elecciones . No voy a entrar a discutir otra vez el sexo de los ángeles. Solo estoy de acuerdo contigo en que el programar proceduralmente te hace adoptar malos hábitos en OOP. Pero vamos, si entiendes bien la OOP quitártelos es fácil y la procedural te hace falta.

Bueno, estaba hablando de aprender a programar... pero mi opinion sigue siendo que aprendiendo este tipo de lenguajes, pasar luego a cosas mas "reales" es relativamente facil, mientras se tienen herramientas de analisis muy fuertes, mucho mas dificiles de conseguir directamente con lenguajes procedurales.


Hay otra forma de aprender a programar... y es con el lenguaje que ya manejamos desde pequeños: programar se puede programar en cualquier lenguaje, incluso en español.

Si queres aprender a programar en serio... mi recomendación seria que aprendas primero los paradigmas funcionales y de objetos (oop). Si, contrariamente a lo que todo el mundo hace...

Una vez te manejes en estos dos paradigmas, aprender a programar en procedural (cosa que ya haces, seguramente), va a ser MUCHO mas facil.

Y como lenguajes: para funcional, supongo que haskell, gopher o lisp; para objetos, Smalltalk o Squeak.

Aprender a programar con lenguajes procedurales (basic, pascal, c, y otros) o hibridos mal hechos (java, c++) puede llevarte a adoptar muchisimos vicios, tanto de programacion como de diseño.

Y a programar, se aprende programando, como ya dijeron por aca. Algunos me van a decir que aprender directamente un lenguaje procedural es mucho mas facil...  si, probablemente lo se, pero tambien "invita" a ser muuuucho mas perezoso como programador (y en ultima instancia, MAL programador).


Saludos.

Yo te recomendaria que hagas un dibujo 3d de la cabeza en papel, si la haces desde 2 o 3 angulos diferentes, mejor. Una vez hecho esto, marca las lineas principales que definen la forma de la cabeza. Un tutorial sobre Box Modeling puede ayudar bastante.
Hay otras formas de hacerlo (con curvas Bezier, por ejemplo), pero creo que ya es un poco mas complicado. Y supongo que por ahi es mejor modelar los ojos por separado (puede que las orejas tambien)

Aqui hay un review de la 'lecture' que cita FANatiko:
http://www.gamedev.net/columns/events/coverage/feature.asp?feature_id=51

(no la he leido todavia)

Otra posibilidad es que te bases en la llamadas 'teorias psicologicas de la motivacion' o 'del impulso'.