|
|
Esta sección te permite ver todos los posts escritos por este usuario. Ten en cuenta que sólo puedes ver los posts escritos en zonas a las que tienes acceso en este momento.
Mensajes - Ruben3d
Páginas: 1 ... 8 9 [10] 11 12 ... 30
226
« en: Domingo 26 de Septiembre de 2004, 15:11 »
Hola.
Felicidades por el éxito. Gracias por compartir la solución. Parece una de las que te di (aunque usa porcentajes en vez de convertir directamente a coordenadas virtuales).
Un saludo.
Ruben3d
227
« en: Sábado 25 de Septiembre de 2004, 21:43 »
Me da la impresión de que es una mezcla de C++ y Visual Basic, y no le veo mucho interés. Además, la elección del nombre no ha sido muy afortunada, ya que se puede confundir con una versión mejorada de D Programming Languageque, en mi opinión, tiene más soporte y usuarios, además de más posibilidades (además, es compilado, y D++ es interpretado?). Un saludo. Ruben3d
228
« en: Sábado 25 de Septiembre de 2004, 14:54 »
PunterosCuarto link al buscar en Google 'punteros'.
229
« en: Sábado 25 de Septiembre de 2004, 13:38 »
cuando estudiaba era de 11 de la noche a 3 de la mañana... Yo, sinceramente, no podría. Necesito dormir un mínimo de horas para poder centrarme en la programación y en los estudios (no aplicable en fin de semana   ). Un saludo. Ruben3d
230
« en: Sábado 25 de Septiembre de 2004, 13:32 »
Hola.
No uso DirectX, pero con OpenGL me encontré con una situación similar. Cuando creo la ventana (digamos de 640x480) configuro el viewport donde se pinta al mismo tamaño (glViewport). A continuación (para gráficos 2D) uso glOrtho para configurar el rango de coordenadas. Si las configuro igual que las del viewport, si el mouse está en la coordenada del formulario (23,56) y lo pinto en el mismo lugar, coincidirá. Pero si el rango de coordenadas es diferente al tamaño del viewport ya no coinciden. Esto sucede cuando redimensiono la ventana: la cambio de tamaño y proporción, y las coordenadas virtuales para pintar siguen siendo 640x480, aunque el tamaño de la ventana sea otro. Esto viene bien porque todo lo que se pinte se cambia solo de proporción para ajustarse al nuevo tamaño, pero no coincide ya la coordenada del ratón.
Como solución, puedes averiguar el tamaño real del formulario y convertir la coordenada del ratón a coordenada virtual. Yo lo que hago es usar la API de Windows para establecer un cursor, así es el Windows el que se encarga de pintar en el lugar apropiado (aunque hay efectos que no se pueden realizar así).
Un saludo.
Ruben3d
231
« en: Sábado 25 de Septiembre de 2004, 13:14 »
1.) Puedo cambiarle en alguna parte al idioma español? Aún no, pero se podrá. 2.) Dònde puedo invitar a otra persona a que se afilie? Cada cierto tiempo te dan invitaciones. El link aparece en la bandeja de entrada, sobre los mensajes. Un saludo. Ruben3d
232
« en: Jueves 23 de Septiembre de 2004, 02:49 »
Hola.
Para cada tema concreto lo que hago es realizar una búsqueda en Google y ver lo que sale. Puedes preguntar aqui cualquier cosa particular (por ejemplo, especifica un poco qué problema tienes con la rotación, si estás usando matrices, si centroide es 'punto de pivote', etc).
Un saludo.
Ruben3d
233
« en: Miércoles 22 de Septiembre de 2004, 15:31 »
Mucha de la gente que entra es para preguntar dudas sobre prácticas que han de realizar. Es normal que en verano no haya mucha participación. Ya verás cuando estemos en torno a enero y en torno a mayo/junio cómo hay muchos mensajes.
Un saludo.
Ruben3d
234
« en: Miércoles 22 de Septiembre de 2004, 02:05 »
What language was RollerCoaster Tycoon programmed in?
It's 99% written in x86 assembler/machine code (yes, really!), with a small amount of C code used to interface to MS Windows and DirectX. Sacado de aqui: Frequently Asked Questions about Chris Sawyer & Game Development. Actualmente, creo que el porcentaje de ensamblador en los juegos es de... 0 % Half-Life 2 está programado íntegramente en C++ (o no he encontrado los archivos fuente en asm). E intuyo que lo mismo pasa con Doom 3. Las partes que tradicionalmente se hacían en ensamblador eran las de rasterización (pintar) y hoy en día eso lo hace la tarjeta gráfica. Así, lo único que se programa en ensamblador son los shaders (pixel y vertex shaders según DX, y fragment y vertex programs según OGL). Aunque esto ya tiende a desaparecer, gracias a CG, HLSL y GLSL. Según esto, mi consejo es que aprendas C++ y alguna librería gráfica, como DirectX u OpenGL. Un saludo. Ruben3d
235
« en: Miércoles 22 de Septiembre de 2004, 01:53 »
tu solucion es la misma solucion de blag.. no?
yop la veo igual... No. Blag está usando las referencias de C++. Bufalito está pasando los parámetros con punteros a là C, que también es llamado 'pasar por referencia'. En C++ este proceso se simplifica usando las referencias (que es herramienta del lenguaje), que evitan tener que usar explícitamente los punteros. Por ello es buena costumbre usar const con los parámetros que no se modificarán, para diferenciarlos. Un saludo. Ruben3d
236
« en: Miércoles 22 de Septiembre de 2004, 01:47 »
Usa flex. En el manual de la web viene todo lo necesario para aprender a manejarlo. Un saludo. Ruben3d
238
« en: Martes 21 de Septiembre de 2004, 12:12 »
Para imprimirlo por pantalla no tienes más que ir imprimiendo los valores por pantalla en vez de ir guardandolos en la matriz. Respecto a lo de usar estructuras de datos, habrás de decir qué estructura de datos (lista, cola, árbol, etc).
Un saludo.
Ruben3d
239
« en: Martes 21 de Septiembre de 2004, 12:07 »
Hola.
Con fscanf puedes leer palabra a palabra, de forma que te será más fácil encontrar una en concreto comparando con strcmp.
Un saludo.
Ruben3d
240
« en: Domingo 19 de Septiembre de 2004, 23:20 »
241
« en: Viernes 17 de Septiembre de 2004, 13:15 »
Hola. Yo lo que haría sería una función que me retornara los tokens de la cadena en una estructura. Por ejemplo, para "x+2^x" crearía una lista de elementos de este estilo: operando(x), operador(+), operando(2), operador(^), operando(x). Una vez hecho esto, voy construyendo un árbol leyendo de izquierda a derecha los elementos de la lista, usando la gramática del lenguaje que deberás tener definida. Una vez creado el árbol, cada nodo intermedio ha de ser un operador y cada hoja un operando. Ésto que te he explicado es una versión reducida (muy reducida) de lo que se explica aqui: Procesadores de LenguajesUn saludo. Ruben3d
242
« en: Viernes 17 de Septiembre de 2004, 13:02 »
Ves desarrollando los menores de los elementos de la primera fila, y así recursivamente para los menores aparecidos de orden n-1, hasta llegar a determinantes de orden 2, cuya solución es trivial. De esta manera te evitas tener que implementar el algoritmo que reduzca el determinante a su forma triangular.
Un saludo.
Ruben3d
243
« en: Jueves 16 de Septiembre de 2004, 14:30 »
Ahora no tengo mucho tiempo para revisar tu código, así que sólo te pongo cómo lo haría yo.
La manera más rápida que se me ocurre de realizar una ordenación es en tiempo O(n · log n). Para ello usamos el algoritmo quicksort. Crea un array de punteros a los nodos [O(n)], y ordenalos en el array (sólo es cambiar punteros)[O(n · log n)]. A continuación, recorre el array y reenlaza los nodos en el orden en que te van apareciendo [O(n)]. De esta manera, habrías reordenado los nodos con bastante eficiencia, aunque necesitas un espacio adicional de 4 bytes por nodo durante la ordenación (en máquinas de 32 bits). La eficiencia final del algoritmo sería:
O(n) + O(n · log n) + O(n) -> O(n · log n)
No me paro a calcular las constantes.
Un saludo.
Ruben3d
244
« en: Jueves 16 de Septiembre de 2004, 14:16 »
Umm no se pero creo que eismpre es umejor usar solo fromatos bmp para las imagenes ya que se mejora el tiempo de carga inicial... aunque en tu juego esto puede no ser relevante... El cuello de botella a la hora de cargar los gráficos está en el acceso al disco duro. El usar un formato que comprima el tamaño permite leerlo mucho más rápido, con una ganancia que hace despreciable el tiempo de proceso para descomprimirlo (al menos, con compresión RLE). Un saludo. Ruben3d
245
« en: Martes 14 de Septiembre de 2004, 02:01 »
Del link que puso AYCUL más arriba.
Por cierto, estoy en la misma situación que EugenioEnko. En un Intel Centrino a 1.5 GHz se me hace injugable debido a la velocidad. Deberías tener en cuenta la velocidad de ejecución en cada máquina para que en todas funcione a la misma velocidad.
Un saludo.
Ruben3d
246
« en: Lunes 13 de Septiembre de 2004, 12:01 »
Hola. A partir del código anterior, se puede poner ésto en el bucle central, que te irá dando el offset: int offset = (i<<6)|(j<<2);
Si te fijas, el valor va desde 0 a 1023-4, ya que el bucle se mueve de cuatro en cuatro bytes (por eso está el <<2). El <<6 es debido a que hay que hacer hueco a j, que ocupa cuatro bits y ha sido desplazado otros dos. El tamaño total es de 10 bits. Esto solo funciona si las variables i,j oscilan en el rango [0,16). El segmento es en todo caso 0, ya que no se superan los 64kb. Un saludo. Ruben3d
247
« en: Viernes 10 de Septiembre de 2004, 19:56 »
Si te fijas en la explicación, el código generado ha de incluirse entre los tag XCODE y /XCODE, no los clásicos CODE y /CODE, ni directamente sobre el post. Ésto hace que se conserven los espacios y el color.
Por otro lado, se agradecería ese IDE. Enviame un mensaje si te decides y quieres saber cómo conectar eso con otra aplicación en C. La versión por línea de comandos es muy pesada de utilizar.
248
« en: Viernes 10 de Septiembre de 2004, 19:52 »
Hola. Para analizar expresiones regulares complejas uso Flex. Es un programa que te genera códgo C que analiza texto en busca de tokens que se acomoden a las expresiones regulares que le indiques. Ésta es su descripción oficial: Flex is a fast lexical analyser generator. It is a tool for generating programs that perform pattern-matching on text. There are many applications for Flex, including writing compilers in conjunction with GNU Bison. Flex is a free implementation of the well known Lex program. It features a Lex compatibility mode, and also provides several new features such as exclusive start conditions. Con él he hecho este programa: Programa para postear código con la sintaxis en color.Un saludo. Ruben3d
249
« en: Viernes 10 de Septiembre de 2004, 19:40 »
se supone que es lo mismo, hasta donde tengo entendido.. En Windows, la mayor parte de los mensajes se almacenan en una cola, que se consulta desde la aplicación de manera síncrona. Con PeekMessage se extrae el primer mensaje de la cola, con TranslateMessage se traducen las teclas virtuales y con DispatchMessage se llama al WndProc (window procedure, definido por el usuario), que procesa el mensaje. En UNIX, las señales se reciben de manera asíncrona, en cualquier punto de la ejecución de tu programa. Si no se quiere que la mayoría de ellas te aborten la ejecución, hay que configurar un manejador para cada señal que se encargue de ellas, y no dejar la acción por defecto. Este código se ejecutará en el acto, y hay que tener en cuenta que se puede modificar algo que se hubiera quedado a medio hacer en el momento de recibir la señal. Ver ésto: Defining Signal Handlers. Acabo de mirar la lista de funciones de la librería de C de Minix, y se configuran las señales igual, con la función signal. A las señales se les ha llamado signals desde la primera versión de UNIX, y me sorprendería que una pequeña versión como Minix le cambie el nombre. Puede darse el caso de que se refiera a colas de mensajes implementadas por el sistema de ventanas, pero esto no forma parte del sistema operativo (es como el Windows 3.1, que se le instalaba al MS-DOS). Si estoy equivocado en algo corregidme, porque es la idea que tengo y no me gustaría estar equivocado (y no me valen cosas como "está mal porque sí", dadme algún link). Un saludo. Ruben3d
250
« en: Viernes 10 de Septiembre de 2004, 14:54 »
Pensaba que Windows era un sistema orientado a mensajes y Unix a señales. Lo de mensajes en Unix me ha dejado descolocado.
Un saludo.
Ruben3d
Páginas: 1 ... 8 9 [10] 11 12 ... 30
|
|
|
Mostrar Mensajes
