|
|
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 - Amilius
Páginas: 1 ... 7 8 [9] 10 11 ... 27
201
« en: Domingo 12 de Febrero de 2006, 00:41 »
Bueno hace tiempo que doy la misma respuesta y sigue siendo válida.  No uses un Timage para tus bitmaps, usa un Tbitmap. Creas los tbitmaps, los cargas con los bmp, o asignas jpeg. (no olvides de destruirlos!!!) Luego colocas en tu formulario un Tpaintbox y en su evento OnPaint pintas los bitmaps en la posicion que quieras. Incluso puedes revisar si realmente necesitas pintarlos todos o solo algunos dependiendo de la zona de clip. Supongo que lazarus seguira la misma idea respecto a Tbitmap, TCanvas y TPaintbox En si el Tbitmap sirve literalmente como pedazo de memoria para tener almacenado tu bitmap. Mejor si le asignas el tipo DIB (Device independet bitmap, osea en memoria RAM y no en video en caso que quieras trabajar sobre la imagen) El Tpaintbox no tiene memoria asignada de ningun tipo, sólo sirve para saber en que posicion de la memoria de video tiene que poner nuestros bitmaps y responde a eventos como onPaint que ocurre cuando otra ventana se puso encima de la nuestra y luego se necesita repintar nuestra ventana. El Tcanvas es el que tiene la capacidad de pintar (graficos de todo tipo, texto, bitmaps, etc.) en memoria de video(en este caso el Tpaintbox) o en RAM (un bitmap DIB)
202
« en: Miércoles 8 de Febrero de 2006, 03:10 »
A ver, lo hiciste con outtextxy, los colores de letra y de fondo son distintos, x,y estan en la pantalla, pues debe funcionar.
203
« en: Miércoles 8 de Febrero de 2006, 00:23 »
204
« en: Miércoles 8 de Febrero de 2006, 00:14 »
Primero crea la cadena y asignas el contenido con sprintf() para simplificar las cosas.
205
« en: Martes 7 de Febrero de 2006, 22:42 »
Xp viene con uno incluido: control panel / speech.
En msdn puedes investigar como puedes sacar provecho de esto. Por lo menos debe ser posible mandar una cadena al sistema de speech y que este reproduzca el sonido correspondiente.
206
« en: Martes 7 de Febrero de 2006, 21:48 »
Veo que te falta base matemática, lo que necesitas es la funcion arco de la tangente, y mejor el clasico "atan2", que recibe los delta x y delta y y de devuelve el angulo. Incluso se hace en ensamblador con 4 instrucciones.  FLD Y FLD X FPATAN FWAIT P.D. Lo natural siempre es usar radianes. Desecha los "grados", eso solo sirve para mostrar informacion final, nunca los metas en tus calculos internos.
207
« en: Martes 7 de Febrero de 2006, 21:43 »
Aqui:
PaintBox1.Canvas.Draw(10+i,10,G);
Estas pintando directamente sobre el paintbox. Es mejor pintar primero sobre OTRO bitmap, como "SuperficieDeRender" que hace de buffer y luego pasar el resultado final al paintbox cuando sea necesario, algo como:
PaintBox1.Canvas.Draw(0,0,SuperficieDeRender);
Esto ultimo en el evento onpaint del PaintBox.
De esta forma evitas parpadeo al evitar trabajar sobre la memoria de video que tenga asignado el paintbox.
Para invalidar y forzar que sea pintado usas .invalidate(); o bien puedes llamar a .repaint().
208
« en: Martes 7 de Febrero de 2006, 17:12 »
Puede que sea obvio pero no tiene porque ser siempre cierto.
¿Herramiento obtusa? Supongo que te referis a Watcom o Builder o Delphi ... Obtuso es pretender hacer cosas para las cuales una herramienta no fue diseñada y no es eficaz. No se que tengas en contra de Borland, pero esa es una opinion muy personal. En cambio si MS VC++ fuera la maravilla que dices nadie se estaria pasando a Csharp .NET, que debo decir fue diseñado por la misma persona que diseño Delphi, claro cobrando 10 veces más  La realidad es que Csharp.NET es la nave insignia mientras que MS VS++ esta cada vez más relegado. Claro que son distintos y usan distintos leguajes, pero repito, si fuera tan buena herramienta no estaria perdiendo terreno tan rapidamente.
209
« en: Martes 7 de Febrero de 2006, 17:08 »
Hay un detalle con todos los teclados estandar: si estas presionando unas cuatro teclas o cinco y presionas otra, ya no detecta que presionaste la ultima, no existe ningun evento que informe de ese detalle, eso es facil de verificar mostrando la matriz de teclas en pantalla, esto varia dependiendo de la combinacion de teclas, pero en general con muchas combinaciones de varias teclas presionadas al mismo tiempo al presioanar otra ya no genera un evento ni nada. Esto es bastante perjudicial si piensas hacer un juego para 2 personas usando un solo teclado. Ej. Mortal Kombat
210
« en: Martes 7 de Febrero de 2006, 16:48 »
Pues yo entendi que el detector de colisiones es el que hace el ciclo con todos los objetos en pantalla.  Pero se podria generalizar a un detector de colisiones que sirviera incluso para juegos 3d, haciendo el proceso preliminar para determinar si dos sprites estan lo suficientemente cerca como para colisionar. Luego pasariamos a un proceso más fino y especifico de colisiones 3d o deteccion de colision por pixeles. Este proceso preliminar tendria mucha importancia para ganar en eficiencia, para no tener que usar los procesos mas detallados y pesados con todos los objetos. Y el problema principal es que detectar colisiones "todos contra todos" es un algoritmo cuyo consumo de CPU se incrementa geométricamente al incrementar el numero de sprites en el juego. ------- Al grano: (Es complicado pero creo que seria mas eficiente) La idea es evitar hacer el test de colision básico con todos los objetos, solo con aquellos suficientemente cerca para tener chances. Por ejemplo tener dividido toda la zona del juego en varias areas, no demasiado grandes que contengan demasiados sprites ni tan pequeñas que haya que actualizar frecuentemente las listas de sprites por zonas. Cada zona tendria una lista dinámica de sprites. Al moverse un sprite a otra zona tendriamos que moverlo a la lista de esa zona. Para detectar colisiones solo tendriamos que revisar entre los sprites de la zona actual y si esta muy cerca de otra u otras zonas, lo suficiente para hacer colision, revisar tambien en esas listas. Si por ejemplo tenemos 1000 sprites en todo el mapa de juego, pero en nuestra zona sólo tenemos a 3 sprites ganamos muchisimo al evitar comprobar colisiones con los otros 997. Y asi reducimos el tiempo de CPU necesario para calcular si podemos mover o no a nuestro sprite, claro que existe algo extra de consumo de CPU para revisar si hemos pasado a otra zona y en ese caso modificar las listas, pero esto solo lo hacemos una vez por sprite. Asi que el tiempo de CPU no se incrementa geometricamente como seria el caso de aumentar mas sprites a nuestro juego y seguir con el proceso de revisar todos contra todos. Pero esto no solo se queda en colisiones, tambien sirve para determinar los sprites suficientemente cerca para ser por ejemplo atacados, potenciales enemigos, para envio de mensajes entre sprites que colaboran entre si, o para saber cuales sprites estan suficientemente cerca de la zona que tenemos que dibujar para mostrarlos en pantalla.
211
« en: Sábado 4 de Febrero de 2006, 16:20 »
Si tambien existe Watcom e Intel C++ que genera un codigo muy optimizado pero ninguno, ninguno, le llega a los talones a VC++ en cuanto a utilidad para escribir codigo para Windows. Ya sea aplicaciones visuales, nativas o drivers.  Más obvio no puede ser. Si el compilador es de Intel pues es para procesadores intel que de eso se supone que deben conocer y es más es la mejor forma de mostrar el potencial que tienen. Y si hablamos del VC++ obviamente que debe sacar lo mejor de microsoft windows, que se supone que de eso saben.  Pero igual ganar una insignificancia extra de rendimiento, en algunos casos contados y escenarios específicos, no justifica usar una herramienta tan obtusa exclusiva para windows. No existe mejor compilador, cada cual tiene objetivos bien definidos y no es difícil saber cual es el que necesitas.
212
« en: Sábado 4 de Febrero de 2006, 00:27 »
Creo que hay que actualizar el mapa. Con .NET vs 2005 y sql server 2005 estan avanzando a paso firme y hay que aumentar un nuke contra OpenGl y en algun lado hay que poner al Xbox 360.
213
« en: Lunes 30 de Enero de 2006, 22:34 »
Saludos, Bueno el mensaje de error que sale es este: "The designer could not be shown for this class because none of the classes within it can be designed. The designer inspected the following classes in the file..." No es el caso común donde el formulario no puede ser dibujado por que simplemente existe un error en el código. En el caso especifico use herencia en los formularios, para tener un prototipo con varias cosas implementadas y heredarlas al resto. Por alguna razon todo funciona bien pero ALGUNAS veces no puedes ver el formulario de ALGUNOS formularios heredados en tiempo de diseño. Todo funciona correctamente si haces correr el programa. Ahora explico por que me parece un bug: En la documentacion indica que al hacer modificaciones en la clase padre es necesario recompilar toda la solución. Pero aún asi el formulario no aparece en tiempo de diseño. Luego encontre un truco para volver a ver los formularios: borrar todos los uses del cs con el codigo del formulario padre, intentar compilar todo, volver a colocar los uses, compilar y salir de la aplicacion, al volver a entrar como arte de magia aparecen nuevamente todos los formularios en tiempo de diseño. En teoría no modifique el código, por que luego de volver a pegar lo que corte el código esta tal cual estaba antes. Pero obviamente algo cambio para que pudiera ver nuevamente esos formularios.
214
« en: Viernes 27 de Enero de 2006, 23:02 »
usas el objeto TjpegImage (uses JPEG si mal no recuerdo), configuras las opciones de calidad a 40 a 60 para la compresion tipica y le asignas una imagen en bmp y luego lo guardas como jpg.
215
« en: Viernes 27 de Enero de 2006, 01:21 »
No depende del lenguaje mas que para facilitarte las cosas. La programacion orientada a objetos hace maravillas para lograr esos efectos sin tener volverse loco en el proceso. De hecho veo que delphi es mas potente en ese sentido y toda esa potencia esta copiada en csharp pero de forma menos elegante.
Pues puedes crear tus propios componentes a partir de un custom o un control como un paintbox, hacer que responda a mayor variedad de eventos y controlar tu mismo todo el proceso de pintado de los botones, textos, grids, nuevos eventos, etc, etc, etc. En mi caso utilice un Tpaintbox para hacer un componente: un boton que queria que tuviera apariencia y comportamiento especial. En delphi seguramente viste que hay versiones "custom" de los controles mas importantes y estan pensados para que a partir de ellos crees tu propia versión mas "colorida y dinámica". Claro que la forma mas rapida es buscar componentes ya hechos o comprar alguno, en algunos casos solo tienes que arrastrar y soltar el componente en tu aplicación, elegir el skin que te gusta y toda tu aplicacion tiene un nuevo "look and feel".
216
« en: Jueves 26 de Enero de 2006, 20:49 »
procedure TForm1.Button1MouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer); begin G:= TBitMap.Create; G.LoadFromFile('E:\molecule14.bmp'); Timer1.Enabled:=true; end;
No pues asi no  Crea el bitmap al crear tu form, destruyelo al destruir el form. Para mejor control utiliza un Tpaintbox para definir el area grafica dinamica de tu form. Luego en su evento on paint pintas el tbitmap, solo la parte que necesita ser pintada, informacion que te da el clip (OJO que no modificas tu Tbitmap al responder a este evento). Mejor si haces eso con un bitblt() directamente y no con el lento draw. En el evento ontimer preparas la imagen en tu Tbitmap e inmediatamente invalidas el control Tpaintbox o lo refrescas para que llame a su paint y este a la vez al evento on paint.
217
« en: Miércoles 25 de Enero de 2006, 19:50 »
lo mismo,
visual basic es el pasado, si acaso te servira visual basic.net y direct draw ya no existe en directX 9 (deprecado) y seguro sera totalmente elinimado en una proxima version si es que ya no lo fue. En realidad Direct Draw nunca paso de servir solo para reservar memoria y hacer un bitblt donde como mucho podias indicar un color como transparencia y reflejar la imagen en horizontal. 
218
« en: Miércoles 25 de Enero de 2006, 19:31 »
pues con un puntero apuntando a la zona de datos donde esta alojada la cadena y un buen casting a char o widechar, dependiendo del caso, deberian bastar.
219
« en: Martes 24 de Enero de 2006, 14:25 »
Hmm... seria bueno ver si existe alguna por ahi... Generalmente lo que hago es hacer que el programa me informe de los tiempos que toma hacer cada proceso, o por lo menos sacar un promedio, asi como analizar que procesos/objetos consumen mas memoria, analizar el codigo y ubicar las partes mas criticas para ver como optimizarlas.
P.D. Optimizar el consumo de memoria, dependiendo del tipo de aplicacion, tambien puede ayudar a optimizar el consumo de cpu por mover menos memoria.
220
« en: Lunes 23 de Enero de 2006, 20:39 »
Hmm... en realidad lo que no tiene sentido es hacerlo TODO con asm, solo las partes claves que necesitas optimizar o tomar control total del codigo que quieres que se ejecute.
221
« en: Lunes 23 de Enero de 2006, 16:28 »
Hola saludos o todos. 
saben, hace tiempo tuve que hacer un puqueño programa de procesamiento de imagenes, cargaba un bmp y le aplicaba algunas tecnicas, deteccion de bordes y cosas asi.
El problema es que era lento porque cargaba el bmp y lo pegaba en la ventana, para posteriomente procesar pixel a pixel con las funciones Getpixel y Putpixel,
quisiera saber si hay alguna forma de cargar el bmp y guardarlo en la memoria como una matriz , procesarlo en memoria y luego pegar el bmp procesado algo asi como lo que hace matlab Yo he trabajado bastante con ese tema, pero en delphi. En delphi tienes una propiedad scanline, que te devuelve un puntero a una fila, con eso aceleras muchisimo el proceso de tratamiento de imagenes. En C++ seguramente existe una propiedad similar que te permita trabajar con toda una linea a la vez. O bien puedes tener un puntero a toda la imagen y alguna informacion extra como cuantos bytes ocupa una linea de tu imagen para moverte a la linea deseada (a la manera de directX). De todos modos la forma mas rapida de procesar la imagen es hacerlo secuencialmente, evitas multiplicaciones innecesarias y a base de sumas e incrementos en un puntero que apunte al pixel que estas trabajando vas analizando toda la imagen. En la seccion de delphi subi una clase que permite crear un bitmap en memoria y trabajarlo directamente con un puntero, en base a llamadas estandar de windows que son iguales en C++ y en delphi, asi que no deberias tener problemas en utilizar el ejemplo como base.
222
« en: Lunes 23 de Enero de 2006, 16:07 »
Holas
en realidad el setup.exe es el mismo para todos los proyectos de instalacion que puedas generar, este setup.exe es que ejecuta el msi (este en si es el que contiene el aplicativo que quieres instalar)
Ahora como sabe que msi ejecutar, pues lo lee del archivo "ini" que viene como resultado de tu proyecto de instalación.
Y claro, tal como dice Amilius, puedes ejecutar el msi sin necesidad del setup.exe, ahora, por mi parte he ejecutado cualquiera de los dos, y no he notado problemas, solo que el setup.exe es el que activa el msi, de alli, el resto de cosas como validaciones de requisitos (cosas como que te falte el framework, o similares...), las hace el msi.
Saluos
J. las validaciones de requisitos las puedes hacer en el msi o en el setup, donde te sea mas comodo. El msi viene con varias opciones para validacion pero no siempre estan todas las que necesitas, al menos cuanto mas exigentes y especificos sean tus requerimientos. La ventaja de hacer las validaciones antes es para no tener limitaciones en cuando libertad de Interfaz grafica. P.D. No tengo aun el ejemplo de animacion grafica, aun busco la forma de hacer un simple bitblt que funcione en csharp  sin tener que usar sus metodos graficos "draw" que son demasiado lentos para lo que quiero hacer.  Se supone que esto deberia funcionar, pero solo funciona para COPYMODE: BLACKNESS y WHITENESS. /* * GDI32 Bitblt */ public static class GDI { [System.Runtime.InteropServices.DllImport("gdi32.dll")] internal static extern int BitBlt ( IntPtr hdcDest, int nXDest, int nYDest, int nWidth, int nHeight, IntPtr hdcSrc, int nXSrc, int nYSrc, int dwRop); } /* (Does not work with HdcSrc by some reason) BITBLT. */ IntPtr HdcDst = e.Graphics.GetHdc(); if (HdcDst != null) { IntPtr HdcSrc = RenderSurfaceCanvas.GetHdc(); if (HdcSrc != null) { //GDI.BitBlt(HdcDst, e.ClipRectangle.Left, e.ClipRectangle.Top, e.ClipRectangle.Width, e.ClipRectangle.Height, HdcSrc, 0, 0, 0xCC0020); GDI.BitBlt(HdcDst, 0, 0, 50, 50, HdcSrc, 0, 0, 0x00CC0020); //GDI.BitBlt(HdcDst, 10, 10, 260, 60, HdcSrc, 30, 100, 0xFF0062); RenderSurfaceCanvas.ReleaseHdc(HdcSrc); } e.Graphics.ReleaseHdc(HdcDst); }
223
« en: Viernes 20 de Enero de 2006, 00:47 »
Hmmm... Tal vez con una poderosa herramienta que analice que tipo de instrucciones utiliza el programa, con que frecuencia, como utiliza los registros, la forma de manejar llas llamadas... es algo muy complicado que no lo puedes hacer manualmente... pero es posible que una herramienta de ese tipo te permita saber si existe algun segmento de codigo algo "distinto" al resto, claro desde un punto de vista matematico. P.D. Si quieres ver el codigo ASM que incluiste en tu programa pon codigo que nunca apareceria, alguna cosa como XOR CX,CX repetido varias veces... Luego con un dissasembly buscas la secuencia.
224
« en: Lunes 16 de Enero de 2006, 22:31 »
el .msi es la base de datos y puede instalarse sin el .exe el .exe generalmente se usa para capturar parametros y pasarlos al .msi, esto si quieres efectos fuera de lo comun en tu instalador, como un pinche grafico animado. O verificaciones de prerequisitos demasiado complicados como para usar dlls hechas en C++
225
« en: Domingo 15 de Enero de 2006, 20:49 »
hola a todos
estoy trabajando con OpenGl en VC++ (da lo mismo), pero lo que necesito es como detectar una colision.
puedo decir que tengo una 'mano' que 'toma' un 'objeto'. y especificamente lo que necesito es saber cuando la 'mano' esta en contacto o no con el 'objeto'.
existira alguna tecnica o algoritmo para ello?
no me sirve una matriz con 0 y 1.. pk estoy trabajando en 3D, y ademas las posiciones de los objetos pueden variar.
alguna idea?????
gracias
Bueno, tecnicas y algoritmos hay desde las mas simples como calcular la distancia entre 2 puntos hasta tan complicadas como ir calculando vectores perpendiculares a cada plano triangular de tu mesh en forma recursiva... Todo depende de que es lo que quieres lograr.
Páginas: 1 ... 7 8 [9] 10 11 ... 27
|
|
|
Mostrar Mensajes
