|
|
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 ... 13 14 [15] 16 17 ... 27
351
« en: Jueves 21 de Julio de 2005, 23:45 »
Es que trato de hacerlo en lenguaje c. Esto de reservar memoria no es invento mio, sino que lo eh visto en varias paginas de programacion grafica y coinciden en el mismo codigo, pero no advierten ningun inconveniente que pueda aparecer.
pd. no se mucho de prog. de video juegos, pero que es api?
Si no es mucha molestia te pediria si no me podes recomendar alguna pagina o tutorial para bajar que explique programacion de videojuegos en c
gracias Hace años que ya se hacen procesadores a 64bits, y existe el xp para 64bits, ¿Me podrías dar una buena razón para utilizar 16bits cuando todo el mundo programa POR LO MENOS a 32 bits? Es que es frustrante el tema de los 16bits... es una de esas cosas que es mejor olvidar y no recordar nunca más... "640K ought to be enough for anybody." Bill Gates, 1981
352
« en: Jueves 21 de Julio de 2005, 22:40 »
Si alguna vez quieren hacer un campo de estrellas esférico, aqui va un ejemplo para delphi. (funciona en d3 para arriba) Utiliza la clase TDIB que permite acceso rápido a pixeles de forma cómoda la cual adjunté en la sección delphi. Hay que crear un nuevo proyecto y asignar estos eventos en el form: procedure FormCreate(Sender: TObject); procedure FormDestroy(Sender: TObject); procedure FormPaint(Sender: TObject); procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X,Y: Integer); No se olviden de ninguno!. NOTA: no modifiquen el acceso a pixeles a menos que sepan lo que están haciendo. unit main; {AUTOR: Sergio Alex Chávez Rico} interface uses Classes, Controls, Forms,windows, DIBitmap,dialogs,sysutils; type TForm1 = class(TForm) procedure FormCreate(Sender: TObject); procedure FormDestroy(Sender: TObject); procedure FormPaint(Sender: TObject); procedure FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer); private { Private declarations } MOUSE_X,MOUSE_Y:integer; DIB:TDIB; procedure Pintar; public { Public declarations } end; var Form1: TForm1; implementation {$R *.DFM} //de Math.pas: function ArcTan2(Y, X: Extended): Extended; asm FLD Y FLD X FPATAN FWAIT end; procedure SinCos(Theta: Extended; var Sin, Cos: Extended); asm FLD Theta FSINCOS FSTP tbyte ptr [edx] // Cos FSTP tbyte ptr [eax] // Sin FWAIT end; const ANCHO_BMP_RENDER=512; ALTO_BMP_RENDER=512; BITS_POR_PIXEL=16; procedure TForm1.FormCreate(Sender: TObject); begin color:=0; DIB:=TDIB.Create(self.handle,ANCHO_BMP_RENDER,ALTO_BMP_RENDER,BITS_POR_PIXEL); DIB.left:=40; DIB.top:=144; end; procedure TForm1.Pintar; type TPixeles=array[0..ALTO_BMP_RENDER-1,0..ANCHO_BMP_RENDER-1] of word; var Pixeles:^TPixeles; procedure PintarEstrellas; { De esférico a cilíndrico: r=p*cos(phi) theta=theta h=p*sin(phi) De cilíndrico a cartesiano: x=r*cos(theta) //z y=r*sin(theta) z=z //x De cartesiano a cilíndrico: r = sqrt(x*x+y*y); theta =arctan2(y/x); z = z De esférico a cartesiano: theta: cilindrico, phi: latitud x=p*sin(phi)*cos(theta);//z y=p*sin(phi)*sin(theta); z=p*cos(phi); //x } var i,c,px,py:integer; phi_0,theta_0,theta_R,theta_R2,phi,theta,r,x,y,z:double; sin_theta,cos_theta,sin_phi,cos_phi:extended; begin Pixeles:=DIB.lpSurface; bitblt(DIB.DIBhdc,0,0,DIB.width,DIB.height,0,0,0,blackness); RandSeed:=10101; theta_R2:=(MOUSE_Y)/1024*pi*2+pi/2; theta_R:=(MOUSE_X)/1024*pi*2; for i:=0 to 10000 do begin c:=(random(32) shl 5) or (random(32) shl 10); //definimos en esférico phi_0:=random*pi*2; theta_0:=random*pi*2; {p=1;} theta:=theta_0+theta_R;//podemos girar de esta forma en esférico phi:=phi_0; //pasamos a "cilíndrico eje x": //primero debemos pasar de esférico a cartesiano sincos(theta,sin_theta,cos_theta); sincos(phi,sin_phi,cos_phi); x:=sin_phi*cos_theta;//z z:=sin_phi*sin_theta; y:=cos_phi; //x //luego de cartesiano a "cilíndrico eje x" (x <-> z): r := sqrt(sqr(z)+sqr(y)); theta :=arctan2(y,z)+theta_R2;//podemos girar el otro ángulo z := x; //luego de "cilíndrico eje x" a cartesiano sincos(theta,sin_theta,cos_theta); if (r*cos_theta){z}<0 then continue;//no dibujar los que están "ocultos" py:=round((z)*254+256); px:=round((r*sin_theta)*254+256); pixeles[px and $1ff,py and $1ff]:=c or $3FF; pixeles[(px+1) and $1ff,py and $1ff]:=c; pixeles[px and $1ff,(py+1) and $1ff]:=c; pixeles[(px-1) and $1ff,py and $1ff]:=c; pixeles[px and $1ff,(py-1) and $1ff]:=c; end; end; begin PintarEstrellas; DIB.draw;//Mandar a memoria de video end; procedure TForm1.FormDestroy(Sender: TObject); begin DIB.free; end; procedure TForm1.FormPaint(Sender: TObject); begin DIB.draw; end; procedure TForm1.FormMouseMove(Sender: TObject; Shift: TShiftState; X, Y: Integer); begin MOUSE_X:=x; MOUSE_Y:=y; pintar; end; end.
353
« en: Jueves 21 de Julio de 2005, 04:34 »
¿Que tipo de juegos esperas programar?
Por que las herramientas que vayas a necesitar dependen mucho de ese punto.
354
« en: Sábado 16 de Julio de 2005, 01:28 »
Bueno hasta ahora se han enfocado en el aspecto informático, pero esto del windows vs linux va más allá:
El gran problema de windows no es su aspecto informático, el gran problema es que es propiedad de microsoft corporation. Si fuera open source otra sería la historia.
Como es propiedad de una corporación es víctima de políticas que nada tienen que ver con la informática, ni con informáticos. (vean el ejemplo de su antispyware y Claria/gator).
Y finalmente analizando este texto del "windows vs linux":
" Muchos estudios independientes han establecido claramente que la ventaja de la gratuidad del sistema operativo se ve opacada por los costos de entrenamiento, o bien outsourcing, o bien costos por asistencia que son necesarios cuando el entorno carece de gente entrenada para administrar y operar Linux. "
Esto significa:
Windows= más dinero para bill, menos para los informáticos.
Linux, u otro que no sea "fácil" de usar por los "no-informáticos" = menos dinero para bill, más para los informáticos.
355
« en: Domingo 3 de Julio de 2005, 16:56 »
A menos que exista un gigantesco agujero de seguridad NO SE PUEDE y NUNCA SE DEBERÍA PODER modificar directamente cualquier archivo del usuario. Los archivos cookies están pensados para evitar que un servidor malicioso haga estragos en la máquina cliente, aún así es posible hacer estragos, imagínate lo que sería si puedes abrir y escribir cualquier archivo del cliente.
356
« en: Domingo 3 de Julio de 2005, 01:08 »
Por cierto, lo de dudar en si se ha llegado a la Luna es lo mismo que decir que Kennedy sigue vivo o que han visto a Elvis Presley. Ahhh...  Aqui era... Pues prefiero un millón de veces dudar que estar seguro de una mentira.
357
« en: Domingo 3 de Julio de 2005, 01:03 »
Antes de leer esto francamente a mi cualquier insecto no me parecía más que un robot (muy avanzado por supuesto):
Hablando de una mosca: "En el interior, dentro de su diminuto cerebro, ¿no tiene percepción de realizar decisiones, ni consciencia de su propia existencia? ¿Ni un miligramo de autoconsciencia? ¿Ni un poquito de esperanza para el futuro? ¿Ni siquiera un poco de satisfacción por un trabajo cotidiano bien hecho? Si su cerebro tiene una millonésima de la masa del nuestro, ¿vamos a negarle una millonésima de nuestros sentimientos y consciencia? Y si después de ponderar cuidadosamente estos asuntos insistimos con que es 'sólo' un robot, ¿cuán seguros estamos de que este juicio no se aplica también a nosotros?" [Carl Sagan]
358
« en: Jueves 30 de Junio de 2005, 03:05 »
Por si acaso revisa si liberaste toda la memoria correctamente: con el memproof, buena herramienta!!
puse el enlace en trucos... de delphi, pero funciona con compiladores borland.
359
« en: Jueves 30 de Junio de 2005, 00:26 »
Pues felicidades CodigoDavid y recordarte nuevamente que aunque no te guste el inglés es el lenguaje natural defacto del mundo del intercambio de información y si realmente quieres alcanzar tus metas NECESITAS poder leerlo por lo menos.
360
« en: Miércoles 29 de Junio de 2005, 20:35 »
El recurso que agrego contiene una clase para poder acceder a pixeles y mostrar el bitmap en pantalla de la forma mas rapida posible usando la GDI de windows. La clase TDIB, "Bitmap independiente de dispositivo" (Delphi 3 adelante) soporta 16, 24 y 32 bits por pixel.
Los nombres de las propiedades y metodos estan en ingles para corresponder a los que comunmente son usados en delphi (create, destroy, width, height, draw, top, left, etc).
El acceso directo al area de datos de los pixeles (mediante un puntero) asegura velocidad, pero tambien es necesario tener el cuidado de no leer ni escribir fuera de esta area.
Incluyo un ejemplo de uso con un interesante efecto de colores.
P.D. por alguna razon todos los acentos que puse aparecen como "?", asi que los quite.
Autor: Sergio A. Chavez R.
361
« en: Martes 28 de Junio de 2005, 02:18 »
en definitiva, que si quiero graficos como por ejemplo 1024x768x32bits con la misma velocidad de windows, la unica opcion es la API de Windows/opengl/direct3d no? pues vaya m***** por que abres una de esas cabeceras y uno no se entera de nada.................pero es que encima los que no sabemos ingles que?(por que yo no tengo ni #### idea)de la api de windows si hay libros en castellano pero.............................................y de directX? por que todavia no he visto ningun libro de DirectX en castellano, ademas de que es imposible cojer la cabezera de DirectX e ir probando funciones para cojer experiencia por que simplemente esas cabezeras son un lio(todas desordenadas, sin tabulaciones ni espacios, vamos que todo esta amontonado), por mi que los programadores de esas api no saben lo que es la legibilidad............................. Es un lio gigantesco, especialmente d3d de directX por que lo primero que hay que hacer es revisar que cosas soporta y que cosas no soporta la tarjeta aceleradora, por eso que en los juegos aparece la leyenta "soporta las tarjetas de pepito, manuelito y joselito, no soporta las de juanito y no pensamos hacer que las soporte" Por eso mismo que existen los engines de juegos 3d, para no tener que hacer uno desde cero. Ni siquiera la industria de videojuegos se anima asi por asi a construir su propio engine 3d y muchas veces se ve que se prefiere pagar por utilizar uno ya existente y dedicar el dinero y tiempo al juego en sí.
362
« en: Martes 28 de Junio de 2005, 02:04 »
Eso era un ejemplo de modos VGA, no de los VESA. "Deprecado": Cuando una funcionalidad o característica es reemplazada por una mejor o más potente. Como no puedes eliminar funciones o características de un procesador o de un sistema operativo sin comprometer su compatibilidad se recurre a deprecar en lugar de simplemente remover dichas funcionalidades o características. Así una función o una característica deprecada generalmente funciona más lento, a manera de ser "emulada" por las nuevas funciones. Eventualmente las funciones y características deprecadas ya no son soportadas por las nuevas versiones. Por ejemplo en HTML.4 están deprecados en favor de las hojas de estilos: BASEFONT, CENTER, FONT, S, STRIKE, U Recientemente me di cuenta que una función del bios que hacía una pausa en microsegundos en las 386 fue deprecada y removida (o el bios de mi máquina no lo soporta)... ya no existe seguridad que funcione siempre... ese el riesgo de usar cosas deprecadas. Seguramente los modos VGA y VESA no serán removidos, pero son EXTREMADAMENTE LENTOS. En mi maquina hacer 600 multiplicaciones a 32 bits (además de unas 1200 operaciones lógicas y 600 accesos a memoria) es más rápido que poner un pixel en vga!! 
363
« en: Martes 28 de Junio de 2005, 01:14 »
OpenGL? pero si se usa dentro de la API de Windows.........., y pregunto, entonces que utilidad tiene VESA? mejor dicho, entonces uno tiene que joderse? por que, yo es que a este tema de programar directamente el hardware le veo mucho secretismo por parte de las empresas si se me permite decirlo................................pero es que entonces ya estamos, los que programan este tipo de cosas¿donde lo aprenden?¿es que yo no puedo aprenderlo tambien? ¿o es que son semi-dioses? creo yo que son programadores humanos normales y corrientes, aver, si por ejemplo ahora a mi una empresa me pide que le haga un driver en ensamblador para su super-ultimo-chachi-guay modelo de targeta 3D, que conocimientos necesito, por que si existen estos trabajos digo yo que existe documentacion sobre el tema, por que si no estoy en otra dimension......... VESA esta igual que los modos "estándar" como el 640x480x4bits, o el 320x200x8bits o el "xlat"= soportados pero deprecados.
Claro que puedes hacer los drivers, y si los haces gratis para cualquiera de esas empresas seguro estarán felices. Seguramente te entregarían un manual gigante con todo lo que puedes hacer y lo que no debes hacer para manejar el modelo "y" de la tarjeta "x" en la empresa "z". Y no es que sea mucho secretismo, es que eso de programar el driver se supone que lo tienen que hacer ellos por que no es algo estándar, además el agp tiene sus días contados por que vienen nuevas tecnologías para reemplazarlo.
364
« en: Martes 28 de Junio de 2005, 00:14 »
es posible con VESA hacer graficos en 3D(a partir de las primitivas 2D..........) con un buen rendimiento? me refiero a graficos 3D en modo como minimo 800x600 con 16 millones de colores y utilizando miles de poligonos y texturas, iluminacion en tiempo real.............. Ni en sueños,  VESA fue desarrollado antes que las tarjetas aceleradoras de gráficos 3d coparan el mercado, en esos tiempos del VESA poder ver en tu pantalla 1024x768 pixeles a 24 bits de color era mucha cosa, un sueño. Si quieres ver como funcionaría tu programa con vesa inicia el windows XP en modo a prueba de fallos y me cuentas como va la velocidad. Si quieres un estándar para 3d tienes al Opengl. Si existe alguien en este planeta que sepa como hacer un juego 3d en asm son estos señores: http://www.theprodukkt.com/ 96KB !!!, cuando me lo mostro un amigo juraba que era una broma. Requerimientos MINIMOS: * A 1.5GHz pentium 3 / athlon or faster. * 512MB of RAM. * a GeForce4Ti (or higher) or ATI Radeon8500 (or higher) graphics card supporting pixel shaders 1.3, preferably with 128MB or more of VRAM. * some kind of sound hardware. * DirectX 9.0b. Link al archivo: http://kk.kema.at/files/kkrieger-beta.zip
365
« en: Lunes 27 de Junio de 2005, 14:28 »
 Basta mirar el .help , tipos de números con punto flotante te informa todo lo que necesitas saber. Existen usan 4 y representan una mantisa exponente todo en binario obviamente.
366
« en: Lunes 27 de Junio de 2005, 01:55 »
tengo una duda sobre el siguiente codigo:
procedure visual (cadena:string);
begin
write(copy(cadena,1,1);
if cadena <> copy(cadena,lenght(cadena),1) then
begin
visual(copy(cadena,2,lenght(cadena)));
write(copy(cadena,1,1))
end;
else
write(copy(cadena,1,1);
end;
Lo que hace este codido dado una palabra escribe esa palabra y la inversa todo junto
Ej: mariposa
salida del mensaje : mariposaasopiram
Bueno aca va mi pregunta segun me dijieron en la recursividad no es eficiente cuando usas otras funciones dentro de la recursividad? esto es verdad agradeceria su ayuda Cada vez que se anidan llamadas recursivas se tienen que copiar todos los parámetros de la función a la pila antes de hacer la llamada recursiva y luego volver a sacarlos de la pila y copiarlos a su posición de memoria original. Esto consume tiempo de CPU y memoria en los apilamientos sucesivos. Si puedes convertirlo en iterativo te ahorras todos esos apilamientos. En tu ejemplo pasas como parámetro una cadena, asi que cada vez que se anida tu proceso recursivo se hace una copia de esta cadena y se guarda en la pila. Otro lio es ese "write" que apenas escribe un caracter en medio de tu código recursivo. Así tu código sea recursivo o iterativo, utilizar un "write" para escribir un sólo caracter es desperdiciar recursos. Mejor guarda tu resultado en memoria, en otra cadena, y al final muestra en pantalla el resultado final con un solo write.
367
« en: Domingo 26 de Junio de 2005, 16:14 »
Según tengo entendido primero envia el mensaje común de "salir", el mismo de alt+f4 o el boton "x". Luego de un tiempo, si no responde, mata el proceso "a la mala".
(cuando se apaga o se reinicia estoy seguro que hace lo anterior, pero cuando matas el proceso... no estoy seguro si manda el primer mensaje siempre)
368
« en: Domingo 26 de Junio de 2005, 14:46 »
haz un programa chico que te capture los códigos con getch, los imprimes en pantalla todo dentro un ciclo que termine cuando el caracter sea el 27 (escape). Cuando presiones ctrl+'A' o alt+'a' aparecerán códigos distintos a los que aparecerían simplemente apretando 'a'. Muchos códigos (incluyendo los alt+tecla) empiezan con '0' (te vota un 0 primero), indicando que hay que leer el siguiente byte para capturar el caracter extendido. Un ejemplo que viene con el compilador "turbo c": int main(void) { int c; int extended = 0; c = getch(); if (!c) extended = getch(); if (extended) printf("The character is extended\n"); else printf("The character isn't extended\n"); return 0; }
369
« en: Domingo 26 de Junio de 2005, 06:32 »
Este truco es para graficar rápidamente con delphi, aplicable a juegos 2d y para tratamiento de pixeles: Esto me costó unas buenas horas de investigación con los archivos de ayuda de delphi (win32.hlp), una buena página de funciones de windows: http://www.winprog.org/tutorial y también una revisada al archivo fuente "graphics.pas". La idea es pasar lo más rápido posible un pedazo de memoria cuyos bits puedes manejar de la forma que quieras a la pantalla. Generalmente al usar Delphi esto significa tener un Tbitmap y acceder a los pixeles con el scanline. El problema es que no quería llamar al scanline (vieron todo el codigo que tiene?*) por cada línea. Tampoco llamar al .draw (vieron todo el codigo que tiene?*) cada vez que tenga que mostrar una imagen en pantalla. * Se que ese código extra le da toda la potencia y simplicidad de uso del GDI al Delphi, pero para este caso específico donde sólo tu parte de código trabaja con el bitmap y lo que más quieres es velocidad todo ese código no es pertinente. De todas formas se puede utilizar las comodidades de las clases de delphi, como el Tbitmap.loadFromFile() y copiarlo al hbitmap con el bitblt() y Tcanvas.handle para obtener el "HDC". IMPORTANTE: + EL ejemplo es para pixeles de 16 bits. + El formato de color a 16bits es A-5-5-5, 5 bits para cada canal RGB. + Hay que tener en cuenta que cada línea del bitmap DEBE estar alineado a DWORD. Si ANCHO_BMP_RENDER es múltiplo de 4 no hay problema para cualquier número de bits por pixel. Para 16bits basta que sea múltiplo de 2, pero para 24 y 8bits tiene que ser múltiplo de 4. Para 32bits no hay problema. EN EL FORMULARIO: Agregar un botón, enlazar el evento "onclick" a "Button1Click", enlazar el oncreate y ondestroy al form1. unit main; interface uses Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs, StdCtrls, DIB, ExtCtrls; const ANCHO_BMP_RENDER=256; ALTO_BMP_RENDER=128; PIXELES_BMP_RENDER=ANCHO_BMP_RENDER*ALTO_BMP_RENDER; BYTES_BMP_RENDER=PIXELES_BMP_RENDER*2; type TForm1 = class(TForm) Button1: TButton; procedure Button1Click(Sender: TObject); procedure FormCreate(Sender: TObject); procedure FormDestroy(Sender: TObject); procedure FormPaint(Sender: TObject); private { Private declarations } hdcBuffer:HDC; hbmBuffer,hbmBufferOriginal:HBITMAP; InfoBM:PBITMAPINFO; fPixeles:pointer; procedure CrearBitmapRender; procedure EliminarBitmapRender; public { Public declarations } end; var Form1: TForm1; implementation {$R *.DFM} function GDICheck(n:integer):integer; begin result:=n; if n=0 then showmessage('Error GDI: #'+inttostr(GetLastError)); end; procedure TForm1.CrearBitmapRender; var HDCPrincipal:HDC; begin getMem(infoBM,sizeof(TBitmapInfo)); with InfoBM^,bmiHeader do begin biSize:=sizeof(TBITMAPINFOHEADER);//40 biWidth:=ANCHO_BMP_RENDER; biHeight:=-ALTO_BMP_RENDER;//Para un Bitmap "TOP->DOWN" biPlanes:=1; biBitCount:=16; biCompression:=0; biSizeImage:=BYTES_BMP_RENDER; biXPelsPerMeter:=0; biYPelsPerMeter:=0; biClrUsed:=0; biClrImportant:=0; end; HDCPrincipal:=getDC(handle); if longbool(HDCPrincipal) then begin hdcBuffer:=CreateCompatibleDC(HDCPrincipal); hbmBuffer:=GDICheck(CreateDIBSection(hdcBuffer,InfoBM^,DIB_RGB_COLORS,fPixeles,0,0)); hbmBufferOriginal := SelectObject(hdcBuffer, hbmBuffer);//Viene con uno que no usaremos releaseDC(handle,HDCPrincipal); end; end; procedure TForm1.EliminarBitmapRender; begin if (hdcBuffer<>0) then begin SelectObject(hdcBuffer, hbmBufferOriginal);//Para que sea eliminado junto con el hbitmap DeleteDC(hdcBuffer); end; if (hbmBuffer<>0) then DeleteObject(hbmBuffer); if InfoBM<>nil then freemem(InfoBM); end; procedure TForm1.FormCreate(Sender: TObject); begin CrearBitmapRender; end; procedure TForm1.Button1Click(Sender: TObject); type TPixeles=array[0..ALTO_BMP_RENDER-1,0..ANCHO_BMP_RENDER-1] of word; PPixeles=^TPixeles; TPixeles2=array[0..PIXELES_BMP_RENDER-1] of word; PPixeles2=^TPixeles2; var i:integer; begin //Tres formas de acceder a los pixeles for i:=0 to 5000 do PPixeles(fPixeles)[random(ALTO_BMP_RENDER),random(ANCHO_BMP_RENDER)]:=random(32); for i:=0 to 5000 do PPixeles2(fPixeles)[random(PIXELES_BMP_RENDER)]:=random(32) shl 5; for i:=0 to 5000 do word(pointer(integer(fPixeles)+(random(PIXELES_BMP_RENDER) shl 1))^):=random(32) shl 10; BitBlt(canvas.handle, 0, 0, ANCHO_BMP_RENDER, ALTO_BMP_RENDER, hdcBuffer, 0, 0, SRCCOPY); end; procedure TForm1.FormDestroy(Sender: TObject); begin EliminarBitmapRender; end; procedure TForm1.FormPaint(Sender: TObject); begin BitBlt(canvas.handle,0,0, ANCHO_BMP_RENDER, ALTO_BMP_RENDER, hdcBuffer, 0, 0, SRCCOPY); end; end.
370
« en: Martes 21 de Junio de 2005, 17:22 »
Gracias por la publicación radical, pero....
esos boletines son bastante antiguos... de hace 3 años (del 2002)
Dudo que muchos tengan esas versiones tan antiguas del winamp. (2.xx)
371
« en: Lunes 20 de Junio de 2005, 14:46 »
Probaste con 2 capas, moviendo su posición con el evento. A la capa que no quieres que salga la mandas fuera de pantalla (no recuerdo si arriba o a la izq, prueba para que no se aloquen los "scrollbars"). Cuando el navegador quiera dibujarla comprobará primero que parte sale en pantalla, como no sale nada no la dibuja.
372
« en: Domingo 19 de Junio de 2005, 23:18 »
Publico este enlace a una valiosa herramienta GRATUITA para compiladores de la familia Borland: http://www.automatedqa.com/downloads/memproof/A partir de tu .exe informa detalladamente cuanta memoria no has liberado, cuantos ".free" o "freemem" olvidaste.
373
« en: Viernes 17 de Junio de 2005, 18:25 »
Creo que se refiere a las restricciones:
Por ejemplo:
+ Cuales registros puedes modificar a gusto y cuales tienes que preservar.
+ Si defines toda una función en asm: como acceder a los parámetros y como devolver el resultado.
+ Que pasa si ocurre un error como "dividir entre cero".
Pero esto es mejor saberlo de la ayuda del compilador que uno está utilizando.
374
« en: Lunes 13 de Junio de 2005, 21:32 »
Esto va para 32 bits:
1.- En realidad todos los bloques de memoria sean "estáticos" o "dinámicos" trabajan de la misma forma para la computadora. Las diferencias las hace el compilador. La ventaja de lo "estático" es que tienes al compilador que te hecha una mano avisándote cuanto estás saliendo de los límites y se encarga de otros detalles más que tendrías que hacerlo por tu cuenta como liberar y reservar memoria.
2.- Recuerda que trabajas con TODA la memoria de la computadora en su totalidad, como si fuera un arreglo gigante y totalmente estático de bytes, así que escribes y lees de la posición que indiques para bien o para mal.
3.- Una referencia a memoria ("puntero") es un simple número en 32 bits que indica la posición donde quieres escribir o quieres leer.
4.- Naturalmente tienes que indicar si quieres leer/escribir 1,2 o 4 bytes por que la máquina no supone ni adivina nada. Para eso esta el type casting: para indicar cuanto quieres leer/escribir.
5.- Hasta ahora todo es simple, pero esto tiene que estar organizado, sincronizado o se convierte en un total desastre por que todos los programas que corren en la máquina meten mano a la memoria del sistema. Asi que aparece el lio de "reservar" y "liberar" memoria.
7.- "Reservar memoria": con esto indicas que pedazo de la memoria (ese gigantesco arreglo estático) utilizará tu programa. Es lógico que indiques desde que parte a que parte de la memoria quieres "reservarla" para que no la modifiquen, ni la lean.
Si no RESERVAS MEMORIA, los otros programas NO TENDRÁN FORMA de saber que parte de la memoria estás usando, asi que probablemente escribirán y modificarán y quien sabe que cosas harán con ese pedazo de memoria que se te ocurrio utilizar.
8.- "Liberar memoria": cuando no necesites usar más el pedazo de memoria que "reservaste", si no lo "liberas", los otros programas NO TENDRAN FORMA de saber que efectivamente ese pedazo de memoria ya no está siendo utilizado. Así que eventualmente no quedará pedazo de memoria que se pueda "reservar" y en el resto de los programas saltarán los errores de "no pude reservar, falta memoria" y por mecanismos de memoria virtual el disco duro empezará a trabajar en exceso.
9.- Como ya te darás cuenta al reservar memoria NO impides que esa parte de la memoria pueda ser modificada o leida por otros programas, ¿Te imaginas lo lento que sería hacer el control de que programa es propietario de que pedazo de memoria cada vez que tengas que leer o escribir en la memoria? Así que tienes que ser cuidadoso de no pasarte al escribir o leer de "tu parte" de memoria que reservaste.
10.- Un programador tiene que estar conciente que las operaciones de reservar y liberar memoria son pesadas y deben evitarse en bucles que se quieran optimizar. Existen muchas técnicas para evitar reservar y liberar unos cuantos bytes de memoria todo el tiempo y hacerlo en bloques más grandes (1kb para arriba)
11.- Reservar y liberar bloques de memoria tan chicos como 1, 2 o 4 bytes es una gran forma de fragmentar la memoria y hacer más lenta una aplicación.
12.- Reservar bloques gigantes de memoria (actualmente 4MB para arriba*) es una buena forma de hacer trabajar al disco duro en exceso haciendo malabarismos con la memoria virtual para mantener ese gigantesco bloque de memoria en RAM. Esto último generalmente sucede con las imágenes pesadas (>1MB), es mejor trabajar con pedazos de memoria para cada línea de la imagen y no uno gigantesco para toda la imagen.
* Esto es fácil de percibir al programar una aplicación que trabaja con imágenes alojadas en un gran y único pedazo de memoria.
375
« en: Sábado 11 de Junio de 2005, 20:34 »
Claro: hide; Lo dificil es que aparezca en la barra de residentes
Páginas: 1 ... 13 14 [15] 16 17 ... 27
|
|
|
Mostrar Mensajes
