SoloCodigo

Pues se aprende programando.  

Es importante que pienses como el compilador: la máquina hará todo lo que le ordenes, sin "adivinar" ni "suponer" ABSOLUTAMENTE nada. El C da grandes libertades al programador y es lo más cercano a la máquina sin bajar a nivel de ensamblador.

Aunque los compiladores actualmente tienen buenos optimizadores de código, realizan advertencias de todo tipo, facilitan la visualización del código, etc.  NO SON varitas mágicas. Su nivel de análisis semántico es muy reducido y casi nulo: NO ENTIENDEN LO QUE QUIERES HACER y se limitarán a producir código máquina del código C o C++ que escribiste, así sea todo lo contrario de lo que querías escribir.

Recuerda no hacer barbaridades si quieres codigo eficiente, por muy bueno que sea el optimizador si el codigo C o C++ de entrada no es bueno, pues los esfuerzos del optimizador serán en vano.

Asi que agarra un Open Source y si entiendes el código ve modificando el programa para ver los resultados que obtienes, claro se supone que los resultados esperados deberán ser iguales a los obtenidos.  

1.- Necesitas lograr enviar/recibir datos byte a byte por serial, paralelo, etc, el cable que tengas a mano.
2.- Verificar que lo que te llega no es basura con algún método de control de suma, paridad o lo que veas conveniente.
3.- Mantener un buffer de recepción/envio
4.- Guardar el buffer cuando se llene a un archivo o llenarlo leyendo de un archivo para luego enviarlo.

Para la comunicación (1 y 2):

Busca algún componente que trabaje con puertos seriales para aprender como hacerlo y luego en base al componente crear tu propio programa para lo que quieras hacer:

http://www.torry.net/

El conocido sourceforge... tal vez encuentres algún proyecto que te sirva aqui: (Quien sabe... tal vez encuentres uno para manejar serial, paralelo, usb, etc.)

www.sourceforge.net

El problema es que en windows las "interrupciones" no son como en DOS. Las cosas se complican por que tienes corriendo varios programas a la vez, problemas de seguridad, etc. Generalmente el sistema operativo detectará los eventos generados por el hardware y enviará un "mensaje" a todas las aplicaciones que corresponda.

Por lo que estas cosas en windows se hacen respondiendo a mensajes.

En el siguiente ejemplo el procedimiento CMExit sólo será llamado si windows envia el mensaje "CM_MOUSELEAVE" dicho mensaje será enviado si el cursor del ratón abandona el componente notificado.

type
  TCMExit = TWMNoParams;
...
    procedure CMExit(var Message: TCMExit); message CM_MOUSELEAVE;
...
procedure CMExit(var Message: TCMExit);
begin
  ....
end;

Creo que buscar un OPEN SOURCE para manejo de puerto paralelo en windows te resolvería bastantes dudas y te permitiría modificarlo para suplir tus requerimientos.

Me temo que usan las CONSTANTES de colores basicos... El típico cyan magenta amarillo azul rojo, verde, etc.... no creo que sea editable La verdad que el conjunto de colores que tiene no va para tener el fondo oscuro sino uno claro.


P.D. Para los que no usaron DOS:

En vga estándar existía el naranja en lugar del amarillo oscuro y todos los colores (16 básicos del antiguo modo sólo texto) eran más claros, así que era mejor tener fondo oscuro.

Primero busca si la biblioteca de clases que utilizas tiene algún método para exportar la base de datos a texto, sino...

Supongo que no tienes problemas para acceder a los datos de la tabla, por tupla y luego por cada campo.

Usa las funciones de archivos de texto que son las mismas de pascal con los nombres algo más específicos para guardar un archivo .txt

No es cosa del otro mundo y es rápido y simple... podrías preparar cada linea de texto a guardar a partir de los campos de un tupla. Recorriendo la tabla de principio a fin.

Usar archivos de texto u cadenas en delphi es extremadamente simple. Y mejor si te consigues una biblioteca de funciones extra para cadenas para hacer todo tipo de operaciones con las cadenas como en PHP.

Defininiendo el procedimiento:


Implementación de un procedimiento que cambia el estado de TODOS los botones de la clase Tbutton.

La verdad que no creia que se pudieran hacer este tipo de juegos en flash y que además sean de tamaño razonable. (El juego ocupa casi 2MB que los valen bit a bit.)

Seguramente alguien ya lo vio por que ya hace 2 años que lo terminaron, pero para los que no lo vieron ahi va:

[Play this game]
http://www.newgrounds.com/portal/view.php?id=73449

Juro que nunca en mi vida vi esa versión de asm.  

Es que una cosa es PROGRAMAR un "ej. un simulador da redes neuronales artificiales" y otra cosa es ENTRENAR una determinada "ej. una red neuronal artificial".

Lo digo por que existe una diferencia fundamental: AL programar uno especifica cada paso, instrucción, orden, operación etc que seguirá la máquina. Es como armar un Árbol navideño de plástico. Al entrenar cuidas de hacer saber a la entidad que estás entrenando cuando está equivocándose y cuando lo está haciendo bien, de forma que eventualmente vaya perfeccionándose. Es como cultivar un árbol ornamental, podarlo y colocar puntos de apoyo para que el árbol vaya tomando la forma que quieres.

P.D.
"Amaestrar" implica una relación amo-esclavo que no me gusta para nada.

Creo que el problema es este:

(ushort)  


Una cosa más... esto depende de la forma de especificar el color en 24 o 32 bits... pero ¿No se intercambian el color rojo por el azul?

Editado: Faltaba la última máscara.  

"Entrenar" diría que es una mejor palabra que "programar" para este caso.  

Por ejemplo para preparar gimnastas para las olimpiadas: Su entrenamiento debe comenzar a temprana edad, existe un tiempo adecuado. Pasado este tiempo no digo que no sea imposible pero sin duda será necesario muchísima mayor cantidad de trabajo y esfuerzo comparándo al caso anterior y los resultados no serán tan buenos.

Saludos al foro!!

Y que tal provando con el color Magenta directamente como su valor entero y no como triada RGB:

$3E0F (15 bits.)

$F81F (16 bits.)

$FF00FF (24 bits)

$00FF00FF (32 bits)

El color negro siempre funciona por que obviamente el R:0,G:0,B:0 que es el negro siempre es 0 en 15,16,24,32 bits.

De esa forma es muy lento (pixel por pixel). Lo mejor es enviar toda la imagen lista a la memoria de video que refresca la pantalla o por lo menos una buena parte de la imagen.

Lo siguiente es una vista a "vuelo de pájaro" de como hacerlo con el GDI pero ahí va:

Para realizar esto de forma rápida puedes valerte del DirectX (con el lock/unlock) o del GDI de windows mediante el BitBlt. (Es decir que lo no haces "personalmente", sino mediante una biblioteca de funciones que al final usará los drivers del fabricante de la tarjeta de video para asegurarte velocidad en la transferencia de memoria.)

El BitBlt permite copiar la imagen de un "HDC" a otro realizando conversión de profundidad de color, poniendo tu superficie de 15 bits en memoria a otra de  8,15,16,24 o 32 bits.

HDC : handle of device context, un puntero a una estructura que define un conjunto de objetos gráficos del GDI.


En Delphi existe un objeto llamado TBitmap que encapsula el GDI de windows, haciendo las cosas más fáciles (recuperar, escribir archivos .BMP, acceso a la misma imagen para edición, etc). Así que en la versión de compilador C++ que estas usando existirá algún objeto que encapsule el GDI.

Utilizando los objetos que encapsulan el GDI podrás obtener el HDC del bitmap que quieres poner en pantalla utilizando el bitblt o también acceder al área de memoria de la imagen que es mucho mejor que sea un DIB "Device Independet Bitmap" para como su nombre dice evitar que el bitmap sea dependiente de la profundidad de color de la resolución actual de la pantalla.