Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Menu

Mostrar Mensajes

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.

Mostrar Mensajes Menu

Temas - KILE

#1
General / Ordenata Nuevo
19 de Septiembre de 2005, 04:40:51 AM
 Ya que he visto ultimamente algunos posts referentes a compra de nuevo micro y tal y ahora mismo estaba buscando un equipo nuevo pues me gustaría escuchar tambien vuestra opinion del mismo.
La cosa sería mas o menos:

AMD 64 3200+ sk939: 156€
Memoria 1GB DDR400: 103€
SVGA 256Mb XFX 6600GT PCX DVI SLI: 230€
Y la placa base que no lo tngo muy claro aun:
- ECS KN1 EXTREME sk939 DDR PCX WIFI: 139€
- ASUS A8N-SLI DELUXE sk939: 164€

Un saludillo y a ver q decis ;)
#2
Programación gráfica / Lightmaps dinamicos
29 de Enero de 2003, 09:00:45 PM
                                Bueno otra de lightmaps jejeje. Ahora lo que estoy trabajando es con lightmaps dinamicos (Sin generación de sombras). Estoy usando opengl y mi dudilla es que a la hora de renderizar la escena con el lightmap dinamico, si tengo ya lightmap estatico y la textura de cada objeto pues tengo ya ocupadas las 2 extensiones de multitextura que suelen soportar la mayoría de las tarjetas. No es plan de intentar buscar una tercera multitextura :P asi que lo unico que me quedaba era usar blending :( y hacer 2 pasadas. De hecho 1 con multitextura + textura y otra con multitextura + textura lghtmap dinamico. Hay alguna manera de hacerlo mas rapidillo? :P
Y segunda pregunta que opinais entre hacer los lightmaps al estilo clasico de tener la lista de UV de cada poligono e ir actualizando las coord de textura en cada movimiento de la luz o por el contrario usar texture projection trabajando con la matriz de textura? :P

Un saludo                                
#3
                                Pues nada que estaba haciendo un generador de lightmap cutrecillo para intros 64k y me he encontrado algunos problemas. El mas importante es que en los filos de algunos poligonos salen unos bordes un tanto desagradables :P mirad en http://usuarios.tripod.es/andromeda_studios/asynkro el fichero lightmaptest.zip (No pongo la url completa xq tripod le ha dao por redireccionarte a la index para q veas la web entera :S )
Total probad solamente los 3 ultimos porque los primeros no vienen al caso. Una cosa que pense a la hora de descartar poligonos cuando se testean es ver si entre el poligono actual y el que estamos testeando hay veritces en comun, de esta manear nunca podria cortar el rayo no? :P Es que no se me ocurre otro metodo para evitar eso. Lord trancos algun consejo? O:) jejej
Thanks                                
#4
Programación de audio / Escuchar un MIDI
01 de Enero de 1970, 01:00:00 AM
                                Buenas :lengua: hasta ahora para escuchar un midi simplón cogia y lo cargaba via MCISendCommand( o SendString(open midifile.mid alias as ...
y luego play alias...
Total que hasta aqui todo muy bien me abria el fichero se escuchaba y muy bonito todo.
Pero hay alguna opcion para teniendo el midi almacenado en un buffer de memoria ejecutarlo? (No me digais qescribir ese buffer a fichero y luego cargarlo eh? :ojo: ). He mirado la doc el MSDN en el sendstring parace q no soporta eso.
thanks :lengua:                                
#5
General Grafistas / Demoscene en andalucia :P
01 de Enero de 1970, 01:00:00 AM
                                Si ya se que puede estar un poco offtopic este tema, pero lo mismo le interesa a alguien de este foro. El motivo de este post se debe a que hace unos dias estube hablando con los organizadores de la conectados party (www.conectados.org - malaga) Y les comenté que porqué no hacian concursos dmoscene al igual que en la mayoria de las partys españolas (vease euskal party, bcnparty). Total que me dijeron que si habia suficiente peña se haria y aqui estoy para ver si hay peña a la que le interese esto :sonriendo: Las competiciones serian como es habitual demos, gfx, music...
Si os mola la idea, poned algo en http://foro.conectados.org/index.php?board=3

Un saludo :ojo:                                
#6
General / Demoscene en andalucia :P
01 de Enero de 1970, 01:00:00 AM
                                Si ya se que puede estar un poco offtopic este tema, pero lo mismo le interesa a alguien de este foro. El motivo de este post se debe a que hace unos dias estube hablando con los organizadores de la conectados party (www.conectados.org - malaga) Y les comenté que porqué no hacian concursos dmoscene al igual que en la mayoria de las partys españolas (vease euskal party, bcnparty). Total que me dijeron que si habia suficiente peña se haria y aqui estoy para ver si hay peña a la que le interese esto :sonriendo: Las competiciones serian como es habitual demos, gfx, music...
Si os mola la idea, poned algo en http://foro.conectados.org/index.php?board=3

Un saludo :ojo:                                
#7
General Programadores / Demoscene en andalucia :P
01 de Enero de 1970, 01:00:00 AM
                                Si ya se que puede estar un poco offtopic este tema, pero lo mismo le interesa a alguien de este foro. El motivo de este post se debe a que hace unos dias estube hablando con los organizadores de la conectados party (www.conectados.org - malaga) Y les comenté que porqué no hacian concursos dmoscene al igual que en la mayoria de las partys españolas (vease euskal party, bcnparty). Total que me dijeron que si habia suficiente peña se haria y aqui estoy para ver si hay peña a la que le interese esto :sonriendo: Las competiciones serian como es habitual demos, gfx, music...
Si os mola la idea, poned algo en http://foro.conectados.org/index.php?board=3

Un saludo :ojo:                                
#8
General Programadores / El formato JPEG se patenta :(
01 de Enero de 1970, 01:00:00 AM
                                Pues nada para quien no se haya enterado ahi va un copypaste:

You can read the whole press release here: http://ir.forgent.com/ireye/ir_site.zhtml?...&item_id=314044.

This might mean you should reconsider using JPEG's in your games as paying a licence fee might be required.                                
#9
Programación gráfica / Sobre Shaders
01 de Enero de 1970, 01:00:00 AM
                                Hola de nuevo :riendo: pues nada aqui estamos para intentarlo
Saludos :lengua:                                
#10
Programación gráfica / Sobre el formato del quake 3
01 de Enero de 1970, 01:00:00 AM
                                Buenas a todos, llevo unos dias en los que he estado haciendo muchas modificaciones en el formato de fichero de las escenas de mi motor, con el fin de poder abarcar todas las características deseables en este tipo de ficheros. Ahora mismo tengo ya una versión "estable" exportada correctamente del max y que difiere mucho de la que ya os postee hace algun tiempo. Aunque he estado mirando el formato del quake3 y tengo una gran duda sobre su estructura interna. Por lo que he podido ver, y no comprobar aun puesto q no tengo ningun editor de niveles q3, parece ser que la geometría la almacena contiguamente sin hacer reutilización de vértices O.o y es que me he quedado un poco rallado pero por lo que he traceado creo que si. Es decir si tenemos un rectangulo (formado por dos tri) en total tendríamos 4 vértices y 2 caras.
Pues bien lo óptimo sería poner:
0-----------3
|      ____/|
| ____/     |
1/__________2

ListaVertices (4 elementos): 0,1,2,3
ListaCaras (2 elementos):
  Cara1.PrimerVertice=0
  Cara1.PrimerIndice=0
  Cara2.PrimerVertice=0
  Cara2.PrimerIndice=3
ListaIndices (6 elementos): 1,3,0, 1,2,3
                           -C1--  -C2--

Pero al parecer lo que hace el quake es recorrer cada cara y por cada cara ir llenando el buffer de vértices que correspondan a esa cara, estén o no repetidos ya. Al estilo de lo siguiente:

ListaVertices (6 elementos): 1,3,0,1,2,3
ListaCaras (2 elementos):
  Cara1.PrimerVertice=0
  Cara1.PrimerIndice=0
  Cara2.PrimerVertice=3       Cara2.PrimerIndice=3
ListaIndices (6 elementos): 1,3,0, 1,2,3
                           -C1--  -C2--

Pues algo mas o menos así sería, y vamos despues de darle algunas vueltas a la chota la única idea que se me ha ocurrido es que de esta manera luego no tienes que transformarlos para meterlos en vertex buffer cuando renderices partes de la geometría de la escena ya que no tienes que recorrer la lista de vertices solamente tienes que copiar secuencias de 3 a partir del vertice inicial y secuencias tambien de 3 a partir del indice inicial.
  Si alguien sabe mas concretamente como organiza esta geometría del bsp le agradecería que me dijera si es como yo la expongo y si alguien tiene algun editor del q3 y sabe manejarlo :sonriendo:
 Pues nada un saludillo a todos y thanks :lengua:                                
#11
                                Bueno este tema no tiene nada que ver con programación pero vamos lo pongo por si alguien me puede ayudar :sonriendo:
La cuestion es que hace un tiempo me compré un placa base Asus A7V133 (Chipset via kt133) 256Mb de SDRAM PC133 y un K7 1'2Gz. Total que todo me iva bien hasta que se me jodio el micro y me lo cambie por un XP1700. Me bajé los ultimos drivers de la bios de la placa que ponia soporte para XP y los meti ynada sin problemas me lo pillaba y muy bien. Pero cuando iniciaba Windows se me reiniciaba cada dos por tres. Esto era con la configuración de multiplicador x11 y el bus a 133Mhz, sin embargo si ponia el multiplicador a x11 y el bus a 100Mhz (O sea, que fuera a 1100Gz) pues me furulaba bien. Incluso cuando pasaba el test Memtest86 (www.memtest86.com) con el bus a 100 me furulaba bien pero con el bus a 133 no. Me gustaría saber si alguien sabe que puede ser o al menos si alguien tiene este tipo de placa para ver si le daba algun tipo de fallo.
Muichas thanks :lengua:                                
#12
                                Me cierran la academia así q os posteo lo mismo q puse en flipcode, si alguien no lo entiende lo posteo luego en español. Sorry :riendo:

Hi all, I have some problem working with static/dynamic libraries. First of all, I'm develop an engine which consist
in three different modules:

- KSysWin32: Static library that implement System dependent functions (File access, memory allocate,...)
- K3DEngine: Static library used for 3D stuff like octrees, bsp, geometry, models, ...
- KRendOGL: Dynamic Library (DLL but without generating .lib, for runtime load). That implement a render interface.

The problem is that in my first program I link this one with KSysWin32.lib K3DEngine.lib and then in runtime I load
the KRendOGL.DLL. I have one "IRender *Render" defined in main.cpp that point to the class implements in KRendOGL.dll.
And then in my K3DEngine.lib I also used this interface (Writing "extern IRender *Render"). The problem cames when I
make a call (from my main program) to a function implemented in KSysWin32.lib that use Render. For example

(main)
  Octree->Render();

(KSysWin32)
Octree::Render()
{
   Render->DrawFaces();
}


(KRendOGL.DLL)
Render::DrawFaces()
{
...
}


Appears the following error message:
"The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared
with one calling convention with a funtion pointer declared with a different calling convention"


Ah, by note, if I make the following, this run oks.

(main)
   Render->DrawFaces();

(KRendOGL.DLL)
Render::DrawFaces()
{
...
}


So the problem is to use an extern pointer to the Render interface. How I can make this one? :_(
Thanks to all                                
#13
Programación gráfica / Sobre Octrees
01 de Enero de 1970, 01:00:00 AM
                                Ayer me dio la vena de implementar octrees en el motor para ver como tiraba con geometría grande. Como habreis visto hace unos dias postee unas imagenes renderizando niveles del quake3. TAl y como abro la escena de estos niveles digamos que hay tantas mallas como materiales, por lo que le pasas (en el caso de opengl):
for (nummallas)
  UpdateMaterial(i)
glDrawElements(ArraydeMalla)

Y renderiza la mar de bien y hace exactamente los cambios mínimos puesto q no repites textura por malla.
Pues eso que me puse a implementar el octree, basicamente iba almacenando en cada hoja los indices de las caras que pertenecian a esas hoja y al fnial de general todo el octree creaba en cada hoja un paquetillo (display list) de la geomet´ria que había en esa hoja. Luego a la hoar de renderizar pues recorria recursivamente el arbol y tal e iba llamando a las display list de cada nodo. Claro está que este método no ordenaba por materiales y al final... menos FPS que con el método inicial. Pensé que seríap orque enviaba paquetillos más pequeños y hacia mas cambios de estado que en el primer método :_(
Total que he estado pensando si sería mas ventajoso en lugar de crear las display list de cada nodo, tener la geometría de cada nodo transformada (Por software, en lugar de cargar la matriz, es decir si traslada dos unidades, en lugar de multiplicar por la matriz, mueves todos los vertices dos unidades) y al tenerla así cuando renderizamos un nodo buscamos todos los subnodos visibles y creamos una lista con la geometría ya transfoormada. De manera que podriamos tener:
KFaces *Faces[NUMMATERIALES]
y en cada array vamos metiendo las caras segun el material al que pertenezcan y al final solo tenemos que
for NumMtariales
  LanzarRender(Faces)

Es que este método de cara a renderizar es videntemente lo más rápido, pero no se yo lo de transformación por software como se lo come, el T&L está pra algo X'D

Alguna sugerencia? :ojo:


                               
#14
Proyectos / Imagenes Niveles Quake 3
01 de Enero de 1970, 01:00:00 AM
                                Bueno aunque ya empiezan los agobios con los examenes uno siempre se puede relajar un poquillo programando :sonriendo: por eso el otro dia me decidí a crear un cargador de niveles BSP del quake 3. Al principio cree una clase específica dentro del motor para albergar este tipo de fichero pero luego pensé que podría ser mucho más ultil crear un conversor BSP->Ks (El formato de mi fichero de escena) y así lo hice. De tal modo que ahora mismo tengo el BSP2KS.exe que le metes un fichero bsp y te genera un .KS (Con un formato parecido al que pudisteis ver en la versión 0.1 que subi a mi web, aunque ya va por la 0.4 ;P y entre otras cosas alberga los lightmaps en su interior). La gracia de esto radica en que si alguien está interesado en usar el formato BSP en su motor no tiene porque usar mi motor si no que puede coger mi exportador/importador y hacer Bsp->Ks->Importador->3D Studio MAX :ojo:
Pues nada ahi os dejo las imagenes que he hecho (Están al final de la página de proyectos/K3D):
http://usuarios.tripod.es/andromeda_studios

concretamente
http://usuarios.tripod.es/andromeda_studio...oyectos/K3D.HTM

En algunas imagenes podreis ver Q3_CurveX es para que se aprecie el detalle de las curvas que si bien ahora mismo soy un poco menso y los paso a triangulos (Aun no he currado lo suficiente con renderización de superficies curvas :ojo: ) pero vamos que da el resultado bastante bueno.

Sobre el motor en si ya os pondré dentro de poco mas noticias porque ahora mismo estoy liado con la demo que vamos a prensentar en la Euskal 10, para cuando lo termine (A mediados de julio) supongo que el motor estará lo suficientemente robusto como para que se pueda usar.
Mucha gente me ha preguntado que porque no he sacado ya versiones Beta para que la gente intente hacer algo con ellas y les he respondido con un rotundo NO, porque me parece una locura sacar un motor que lleves con el tan poco tiempo y esté tan básico que seguramente cuando lo vayas avanzando cambien tantas cosas que lo unico que hagas sea enredar a la gente que lo use. Así que nada :ojo:

Pues eso un saludillo y espero que os gusten las capturas

PD: Emotion where are you?








                               
#15
                                Hi
Bueno hace unos dias ley un post sobre programación grafica en Linux y como hacía tiempo que tenia pensado subir unos artículos de este tema que escribí para la Solo Programadores Linux pues me decidí ayer por la noche a subirlos (Aun solo el primero) por si le pueden servir a alguien para empezar en este sistema.
  Debo comentar que he quitado algunas cosas ya que la mayoría vienen explicadas en los demas tutoriales y tampoco era cosa de repetir definiciones. Inicialmente escribí 4 artículos que van desde la configuración del sistema (Linux, KDevelop y OpenGL), usar SDL para la gestion de eventos e inicialización de video,... carga de superficies  (BMPS) usando SDL, transformaciones geométricas y finalmente carga de modelos desde un fichero.
  Como podeis imaginar estos artículo no son exclusivos de Linux sino que son portables a Windows por lo que podría ser un buen momento para practicar con la lib SDL (Que es batante potente por cierto).
  De todas formas los que quieran programar en Linux, despues de leer los tres primeros artículos en los que se inicializa todo el sistema, se leen texturas sin usar funciones Win32, etc... pueden seguir con la serie de tutoriales inicialmente creada para windows a partir del tutorial de inicialización de OpenGL.
  Pues nada espero que os sirva para algo :ojo:

Un saludo


PD: Tengo problemas al poner el formato de los tutoriales, lo hago en plan bestia pero me gustaría que se me adaptase los margenes al tamaño de la ventana que se abra y además se quedase justificado (En plan los de Nehe) Si alguien me puede ayudar pues le estaría muy agradecido :ojo:                                
#16
Proyectos / K3D Engine
01 de Enero de 1970, 01:00:00 AM
                                Bueno como ya sabeis estaba desarrollando un motor 3D, al igual que el 99% de la peña que pasa por aqui :lengua: y como dije en otro foro estaba liado con un plugin que en principio nacio para ser usado unicamente con el motor K3D aunque he pensado que tambien podría servir para exportar al formato nativo y que otros programadores pudieran usarlo en sus propios proyectos ya que da todas las características que puede dar el ASE junto con algunas adicionales y sin tener ese tamaño tan horrendo :lengua:  La razón de este post es que he subido un PDF con la versión actual del formato, por si alguien quiere echarle un vistazo y comentarme algo para cambiar en proximas revisiones.
Una captura del plugin en acción es:
http://usuarios.tripod.es/andromeda_studio...arga/plugin.jpg

y el formato:
http://usuarios.tripod.es/andromeda_studio...carga/K3DFF.pdf

(Perdonad por el formato del PDF pero lo hice así para ser mas facil para la impresión y que no ocupara tantas páginas, pondré posteriormente una versión mas legible :lengua:)

Un saludo :lengua:                                





Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.