lunes, 11 de agosto de 2008

Respuesta al Ejercicio BH 59

thunder [yuniet02015@hab.jovenclub.cu]

Ejercicio:
==========
Los números 46 y 96 tienen una curiosa propiedad, su producto no se altera aunque las cifras que lo integran cambien de lugar.
46 * 96 = 4416
64 * 69 = 4416
Confeccione un programa para imprimir todos los números de dos cifras que cumplen esta propiedad.



'=========================================
'= Respuesta en Visual Basic =
'= al pequeño ejercicio =
'= de la edicion #59 =
'= de la revista =
'= BlackHat =
'=========================================

Private Sub Command1_Click()
  On Error Resume Next

  For a = 9 To 98
    num1 = a + 1
    rev1 = StrReverse(num1)
    For i = 9 To 98
      num2 = i + 1
      result1 = num1 * num2
      rev2 = StrReverse(num2)
      result2 = rev1 * rev2

      If result1 = result2 Then
        Text1.Text = Text1.Text + Str(num1) + " -" + Str(num2) + vbCrLf
        c = c + 1
        Label2.Caption = c
      End If

    Next
  Next

End Sub

Private Sub Command2_Click()
  Text1.Text = ""
  Label2.Caption = ""
  Command1.SetFocus
End Sub

Archivos relacionados

Respuesta.zip

Continuar leyendo

Cut File

Alien [blackhat4all@gmail.com]

Este código no es ni será catalogado como la gran invención del año, pero si puede ser de utilidad para muchos que quieran meter en un dispositivo de poca capacidad un archivo de audio o video que supera el tamaño de la unidad en la que se quiere introducir.

CLS
'Definimos el buffer, que no es más que la cantidad de bites que serán leídos en cada pasada.
'Mientras mayor sea el buffer más rápido terminará
DIM buffer AS STRING * 32000
OPEN ("k:\nuevo\a.dat") FOR BINARY AS #1
  OPEN ("c:\b.dat") FOR BINARY AS #2

'Hacemos un ciclo hasta la cantidad de Megas que queremos copiar (en este caso son 490 Mb)
    FOR i = 1 TO 490 * 1048576 STEP 32000
      GET #1, i, buffer
      PUT #2, i, buffer

'Nos paramos en la primera línea y mostramos el progreso...
      LOCATE 1, 1
      PRINT "Guardando: "; INT(i / 1048576); " Mb"
    NEXT
  CLOSE #2
CLOSE #1


Sabiendo de antemano que un archivo de audio o video puede funcionar aún faltandole parte de este, este código lo que hace en sí es definir un tamaño (siempre menor que el del archivo) y empezar a copiar hasta que se llegue a ese tamaño. En este caso el tamaño definido es de 490 Mb. Al terminar, se tendrá solo la primera parte del archivo hasta que este llegue al tamaño especificado.

Si se sabe el tamaño de la cabecera del archivo, se pudiera hacer un programa que, en lugar de solo llevar a parte los primeros x Mb del archivo, divida al mismo en varios pedazos, pero bueno, eso será en otra edición xD.

Continuar leyendo

Geometry.cpp

Alex17 [marisolriech@infomed.sld.cu]

Es este un interesante código que le dará la posibilidad a los que logren dominarlo de hacer algunas otras cositas con el trabajo de los discos duros.

// Get Disk Geometry.cpp : Defines the entry point for the console application.
//

#include "stdafx.h"
#include <windows.h>
#include <stdio.h>
#include <winioctl.h>

DISK_GEOMETRY SupportedGeometry[20];
DWORD SupportedGeometryCount;

VOID
GetSupportedGeometrys(HANDLE hDisk)
{
  DWORD ReturnedByteCount;

  if(DeviceIoControl(hDisk,IOCTL_DISK_GET_DRIVE_GEOMETRY,NULL,0,SupportedGeometry,sizeof(SupportedGeometry),&ReturnedByteCount,NULL))
    SupportedGeometryCount = ReturnedByteCount / sizeof(DISK_GEOMETRY);

  else
    SupportedGeometryCount = 0;
}

VOID
PrintGeometry( PDISK_GEOMETRY lpGeometry )
{
  LPSTR MediaType;

  switch ( lpGeometry->MediaType )
  {
    case F5_1Pt2_512:
      MediaType = "5.25, 1.2MB, 512 bytes/sector";
    break;
    case F3_1Pt44_512:
      MediaType = "3.5, 1.44MB, 512 bytes/sector";
    break;
    case F3_2Pt88_512:
      MediaType = "3.5, 2.88MB, 512 bytes/sector";
    break;
    case F3_20Pt8_512:
      MediaType = "3.5, 20.8MB, 512 bytes/sector";
    break;
    case F3_720_512:
      MediaType = "3.5, 720KB, 512 bytes/sector";
    break;
    case F5_360_512:
      MediaType = "5.25, 360KB, 512 bytes/sector";
    break;
    case F5_320_512:
      MediaType = "5.25, 320KB, 512 bytes/sector";
    break;
    case F5_320_1024:
      MediaType = "5.25, 320KB, 1024 bytes/sector";
    break;
    case F5_180_512:
      MediaType = "5.25, 180KB, 512 bytes/sector";
    break;
    case F5_160_512:
      MediaType = "5.25, 160KB, 512 bytes/sector";
    break;
    case RemovableMedia:
      MediaType = "Removable media other than floppy";
    break;
    case FixedMedia:
      MediaType = "Fixed hard disk media";
    break;
    default:
      MediaType = "Unknown";
    break;
  }
  printf(" Media Type: %s\n", MediaType );
  printf("Cylinders%d,Tracks/Cylinder%d,Sectors/Track%d\n",lpGeometry->Cylinders.LowPart,lpGeometry->TracksPerCylinder,lpGeometry->SectorsPerTrac); }

int main(int argc, char* argv[])
{
  HANDLE hDrive;
  UINT i;

  hDrive = CreateFile(
"\\\\.\\C:",
  0,
  FILE_SHARE_READ,
  NULL,
  OPEN_ALWAYS,
  0,
  NULL);
  if (hDrive == INVALID_HANDLE_VALUE)
  {
    printf( "Open failed: %d\n", GetLastError());
    ExitProcess(1);
  }

  GetSupportedGeometrys( hDrive );
  printf( "\nDrive C supports the following disk geometries\n" );
  for( i=0; i<SupportedGeometryCount; i++ )
  {
    printf("\n");
    PrintGeometry (&SupportedGeometry[i]);
  }
  printf("\n");
  system ("pause");
  return 0;
}

Continuar leyendo

RenderToTexture

h0aX [hoax_ws@yahoo.es]

A raíz de un magnifico artículo publicado por JKS titulado "Retorno al 3D" y de una confusión igualmente excelsa en imaginación y en derroches de especulaciones he recibido varios correos sobre mi supuesto "motor 3D para shooters".

Todo aquel que me conoce en el plano personal sabe que padezco de un laconismo con tendencias al aburrimiento que resulta especialmente irascible para aquellos amantes y fieles emprendedores de las opiniones insulsas y los comentarios ramplones. Lo cierto es que me desagrada la controversia a menos que me sea producente, así que me limitaré a decir justo lo que requiere ser sabido y no complaceré a nadie con una palabra de más. Quisiera que por favor se prestara especial atención a la oración que a esta precede para así ahorrarme el trabajo de responder algunos correos que últimamente estoy recibiendo. Yo NO estoy haciendo un motor 3D para juego alguno, el framework 3D que me he fabricado sobre OpenGL (y que algunos beodos artistas se han empeñado en pintar como "motor 3D") es solo una herramienta con "fines experimentales" que ni por mucho está pensada para quedar ensamblada como un entumecedor de cerebros somnolientos, verbigracia, un adocenado juego para niñitos aburridos. El objetivo de mis trabajos extraoficiales con gráficos generados (que ya parece haberse hecho público de la peor manera posible) está mucho más vinculado con la investigación científica y sus resultados están enfocados en disímiles temáticas: diseño de nuevos dispositivos de control de interfaces 3D, simulación de elementos mecánicos vinculados a la robótica, simulación de sistemas físicos, etc. Mi motivación por el desarrollo de juegos no va más allá de mis horas de extenuación en que dispongo algún que otro elemento simple de mis sistemas de modo "juguetón", como el estudiante del MIT que aburrido hace un circuito para una cajita de música y se lo obsequia a su novia. Aclarada la duda, todo aquel que tenga interés en explotar el 3D como herramienta de trabajo puede escribirme y de ello intercambiaremos toda la información que desee. En cambio, aquel cuya intención fundamental es sentarse a desarrollar juegos, aquí les va un consejo: Usen DirectX, yo he tenido oportunidad de trabajar con tan exquisita API y les garantizo que para hacer juegos es la ideal. Mientras en OpenGL debes sentarte a pensar el -cómo hacer- en DirectX solo deberás pensar en -qué hacer- porque todo esta dispuesto justo para ese propósito, la creación de entumecedores de mentes. Creo que con esto quedan más que contestadas las dudas de la comunidad, aunque aún quisiera responder a nivel personal esta pregunta:
- ¿Por qué no usas un motor ya hecho?

No lo uso porque me desagradaría hacerlo, y me desagradaría por la misma razón que me desagradan los lenguajes scripts e interpretados. Aprecio a un programador por la manera que hace uso del control que el lenguaje pone en sus manos. Yo disfruto tiranizar estos aparatos electrónicos con sentencias C++ escritas con tal organización que parezcan un soneto de Quevedo... ese es mi hobby. No obstante cuando me piden un trabajo en PHP, jamás me he dispuesto a programar mi propia aplicación servidora en C++, en vez de eso he sabido agradecer las bondades del lenguaje que para esas nimiedades me ha sido ofrecido. Llegará el momento en que el desarrollo de un juego solo requiera alta destreza con el botón Siguiente y el Atrás, será ese el pináculo del desarrollo de la industria de video juegos, pero mientras de placer se trate, seguirá h0aX escribiendo sonetos en C++;

¿Qué captas, noturnal, en tus canciones,
Góngora bobo, con crepusculallas,
si cuando anhelas más garcivolallas
las reptilizas más y subterpones?

[El demo]

Hoy les propongo un demo en el que estuve experimentando las curiosas aplicaciones de la función glCopyTexImage2D para renderizar la escena en una textura dinámicamente :o.

Por último aclararé que nadie debe suponer por mis opiniones aquí expresadas que sea yo un retractor de los video juegos (solo de su uso excesivo) y no debe ningún curioso sorprenderse al encontrar en mis demos alguna evidentísima referencia a PerfectDark, GoldenEye o Zelda de Nintendo64, pues fueron estos los títulos clásicos que coincidieron con mi etapa de jugador.

Solo me resta agradecer a Shiika de #Hero por permitirme usar sus bellos ojos en el diseño de mis demencias tridimensionales. (Pss, a que no me equivoqué)

[Rendimiento]

En aras de conseguir el máximo de rendimiento para cada máquina he definido algunas opciones con las que se pueden cargar la aplicación.

Para definir el nivel de detalles del viewport de las cámaras puedes llamar el programa con una de las siguientes opciones en la línea de comandos:

-VERY_HIGH_QUALITY
-HIGH_QUALITY
-MEDIUM_QUALITY
-LOW_QUALITY
-VERY_LOW_QUALITY

ej: "rtt.exe -MEDIUM_QUALITY"

Para visualizar el demo a pantalla completa se debe usar el parámetro "-fullscreen", ej: "rtt.exe -fullscreen".

No sobra aclarar que esta vez he agregado un limitador de frames para mantener los FPS por los 60. De este modo el programa deberá correr a la misma velocidad con una ATI de 128 que con una de 1024. Pensando siempre en el poco tiempo que tuve para debugear dicho limitador, cualquiera a quien le de problemas puede desactivarlo con el parámetro "-NoFPSLimiter", ej: "rtt.exe -NoFPSLimiter".

Acta est fabula.

Archivos relacionados

RenderToTexture.zip

Continuar leyendo