Hi,
no se si es esto lo que quieres, pero ahi va de todas formas:

Código [Seleccionar] Expand

#include <string.h>
char *strtok( char *str1, const char *str2 );


strtok te devuelve el puntero al siguiente "token" de la cadena str1, donde str2 contiene el separador de los "tokens" de str1. Cuando ya no encuentra mas tokens devuelve NULL. Asi que la primera llamada a strtok deberia ser con la cadena a ser "separada" en str1 y el delimitador en str2. El resto de llamadas hasta que te devuelva NULL deberia ser con str1 a NULL y str2 con el delimitador.

Código [Seleccionar] Expand


#include <stdio.h>
#include <string.h>

int main(){

char cadena[] = "Ejemplo@tipico@Hola@mundo";
char delimitador[] = "@";
char* cadenaResultado = strtok( cadena, delimitador);

while( cadenaResultado != NULL ) {
   printf( "El resultado es: %s\n", cadenaResultado );
   cadenaResultado = strtok( NULL, delimitador );

}

return 0;

}


La salida seria:
El resultado es: Ejemplo
El resultado es: tipico
El resultado es: Hola
El resultado es: mundo

Espero que te haya servido,
Un saludo,
-Rubén-

 Hi,
aunque no conozco a nadie de Stratos hace bastante que sigo el sitio y recientemente me he metido de lleno en esto. Ahora mismo estoy con el "framework"(manejo de graficos, input, modelos,...) pero , espero, que dentro de un par de semanas tenga algo decente para poder presentarlo. Os podria poner un visualizador de peliculas de redes neuronales tipo I&F que hice como "intro al mundillo" pero es algo muy sencillito.:rolleyes:

En fin, que soy de Madrid, asi que seguramente me pasare a conoceros y poneros caras.  (ole)

Un saludo,
-Rubén-  

 Hi,
a la perfección se tiende con la ganancia de experiencia  (ole)

Gracias por las revisiones de codigo. Tengo que pensar lo del N^2 porque nunca se me habia pasado por la cabeza (nooo)  (nooo) , aunque realmente tampoco me pense mucho la condicion de parada.Simplemente estaba mas atento al algoritmo en si que a como implementarlo....  :(

Por cierto, sigo diciendo que es un problema con ciertas suposiciones , sin entrar a si es un buen metodo para escoger a gente en entrevistas de trabajo. A mi personalmente, me van mas las preguntas generales . :rolleyes:

Un saludo,
Rubén  

 Hi,
no se por que la pantalla del "editar mensaje" me hace cosas extrañas asi tendre que meterlo en este post.

Seryu ya he pillado lo que has dicho , mas vale tarde que nunca (nooo)  (nooo)

Teoricamente el problema te pide que devuelvas/almacenes  la cadena invertida en la misma memoria que te pasen. Si no tambien se podria hacer recursivamente sin memoria auxiliar con printf´s "al comienzo de la vuelta atras".

Un saludo,
-Rubén-

 Hi,

nvertir una cadena sin usar memoria intermedia de ningun tipo... ¿alguien puede poner el algoritmo por ahí?

Explicación usando XoR:
A = x
B = y
donde A y B son los elementos que quieres intercambiar y x e y los valores que toman.
Ademas se supone que x xor x => se eliminan las x

1)
A = A xor B = x xor y

2)
B = A xor B = x xor y xor y = x

3)
A = A xor B = x xor y xor x = y

por lo tanto A = y , B = x.

Código [Seleccionar] Expand



char* reverse(char* s){
  int i = 0;
  int j = 0;

  for(i = 0, j = strlen(s) - 1; i < strlen(s); ++i, --j){
     s[i] ^= s[j];
     s[j] ^= s[i];
     s[i] ^= s[j];
  }
  return s;
}



Creo que deberia ser asi.

realmente, si no puedes usar memoria intermedia, la inversa de string es string. Lo importante no es el orden en el que se guarde, si no el orden en el que se imprima.. Nadie puede decirte que un buffer del tipo {A, B, C} vaya a imprimir en pantalla ABC, eso lo decide tu programa tongue.gif

No se que quieres decir con esto. :huh:

Un saludo,
-Ruben-

 Hi,

NB: Lo de usar el carácter de terminación de la cadena, según el tío que hacía la entrevista, "no vale". Pero puso cara de sorpresa biggrin.gif

La verdad es que esa solucion es muy chula, usando todos los recursos de los que dispones  :rolleyes: . Por cierto la del xor he tenido que buscarla por ahi por que no caia..... <_<  Ahora si me preguntan las distintas formas de invertir una cadena en una entrevista de trabajo o en un examen en su defecto se lo voi a clavar  (ole)

String.Invert();

:D  :D

Yo la verdad es que siempre me ha tirado para atrás los trabajos de programador, aunque es lo que me gusta, por este tipo de entrevistas. No creo que se me dieran muy bien, la verdad. Yo cuando programo siempre tengo a mano referencias, compilo continuamente cuando no me acuerdo si cierta cosa puede hacerse en C++ o no, etc. Y además detesto que alguien esté mirando mientras trabajo, así que tengo todas las papeletas para hacerlo fatal XD

A mi me recuerdan a los examenes de ciertas asignaturas de la carrera. A mi tampoco me gustan y tampoco se me dan excesivamente bien por que yo soi de los que tienen mil libros, webs, etc... y estoy todo el dia consultando. Pero si te lo preparas, dentro de lo que se puede preparar una entrevista de trabajo, creo que puede ser sencillo y entretenido de hacer. Por lo menos a mi esta clase de problemas(p.e: la inversion de una cadena sin usar variables auxiliares) me parecen muy divertidos  :P

Un saludo,
Rubén

Al pasar la prueba anterior, examen presencial. Primero escribir una función que invierta una cadena de caracteres. Cuando haces la solución inmediata te dicen que no uses una variable temporal, que solamente se puede usar la memoria de la cadena. Tras usar xor, te piden que lo hagas con otro tipo de operaciones. Si tienes dudas te las resuelven. El objetivo es ver cómo resuelves los problemas.

Hi,
me parece muy chulo ese problema. He estado pensando y me salen varias soluciones: variables temporales, recursion, xor, usando como temporal el byte de terminacion de cadena,.....  :D

Muy entretenido  (ole)

Un saludo,
-Rubén-

Personalmente a mi lo que más me llama la atención es programar, pero ello no significa que haya otras cosas en la informática como diseñar circuitos, el análisis de proyectos o el tema de redes.

Me ha llegado al alma, para diseñar circuítos ya estamos los electrónicos y telecos (sí, soy universitario, no pasa nada ) :). No sabía que en informatíca cursarais VHDL y ese tipo de cosas.

Hi,
perdon por el offtopic, pero por lo menos en algunas universidades donde se da ingenieria informatica, se que se imparten 3 o 4  asignaturas obligatorias y 2 o 3 asignaturas optativas directamente relacionadas con electronica, diseño de circuitos, estructura y arquitectura de computadores, VHDL, robotica,  etc...

Un saludo,
-Rubén-

 Hi,
si no has programado nada en ningun lenguaje, empieza por C o Pascal (aunque yo elegiría C). Cuando te encuentres comodo manejando memoria, con estructuras de datos, con tratamiento de ficheros, etc... pega el salto a un lenguaje orientado a objetos: java, c++ o c#. Java y C# son bastante sencillitos. C++ es algo mas complejo de dominar pero se consigue.

Si no vas a estudiar ningun curso/modulo/carrera de informatica, va a ser bastante duro aprender. Pero con practica, ganas, paciencia y tiempo se puede lograr. En las páginas de las asignaturas de las escuelas de informatica tienes normalmente practicas para poder hacer. En www.ii.uam.es solo tienes que buscar por las web de las asignaturas la seccion de practicas y veras enunciados/recursos/etc...

De todas formas, creo que para empezar a aprender a programar juegos deberias sentirte lo suficientemente comodo y seguro con tu programacion. Porque si no, puede que toda la ilusion que tengas se "vaya al traste" por intentar correr demasiado: despacito y con buena letra. :lol:

En fin, que yo tambien estoy intentando aprender los misterios de este mundillo.
(ole)

Un saludo y suerte,
-Ruben-

PD: Libros que te recomiendo:

-SOBRE VIDEOJUEGOS-
-Introduction to 3D Game Programming with DirectX 9.0
by Frank Luna   ISBN:1556229135
Wordware Publishing © 2003 (388 pages)

-Advanced 3D Game Programming Using DirectX 9.0
Peter Walsh
Wordware Publishing, Inc.

-Core Techniques and Algorithms in Game Programming
By Daniel Sánchez-Crespo Dalmau

-Strategy Game Programming With Directx 9.0.chm

- C++ -
Thinking in C++, 2nd ed. ©2000 by Bruce Eckel  

 Hi,
yo creo que las dos opciones son correctas desde un punto de vista de diseño de poo.
1)Composición: un modelo está compuesto por una lista de vertices y una lista de polígonos.
2) Herencia multiple: pero también, se podría pensar que un modelo(cModelo) es una lista de vertices(cListaV) y tambien es una lista de poligonos(cListaP).

Personalmente prefiero la primera, como Haddd (ole) , a mi me resulta mas sencilla: haces una composición y te dejas de problemas de posibles ambigüedades con la herencia multiple.

A ver que opina el resto de compañeros.

Un saludo,
-Rubén-

 anda leches si es en la otra web........... (nooo)  (nooo)

pues nada, gracias sync  (ole)  

 Hi,
¿os importaría poner el link directo a la demo? es que he estado buscando un buen rato en la web y no veo nada de nada.... :rolleyes:  :rolleyes:

Gracias  (ole)

Un saludo,
-AnGuS-

 Hi,
más que nada, la duda me entra al pensar que la lógica que cambia de un estado a otro de la aplicación ( no me estoy refiriendo a los de la fsm) la poneis siempre dentro del loop. ¿No debería estar fuera del bucle de juego? Son comprobaciones sencillas que al fin y al cabo no consumen apenas, pero ¿no sería mejor sacar la lógica de estados fuera del loop?

Basicamente yo lo que había pensado (Nota: ir a pirmer post apartado 1) antes es que cada estado tuviese su propio game loop y que de alguna forma la lógica de cambio de estado solo se ejecutase cuando se haya terminado un estado y hay que decidir a que estado ir.

Por cierto, estoy viendo que con este tema hay mil y una soluciones posibles. Intentaré decidirme por la que mas se ajuste a lo que necesito, aunque se que voy a tirar por la solución que mas chula este....... (genial)  (genial)

Un saludo,
-Rubén-

 Hi,
gracias por las respuestas.  (ole)

La verdad es que la idea de la pila esta muy chula, no se como no se me ha ocurrido. De esa manera el codigo de mi , desde ahora bautizado como, "chuper-framework"  :D , es mucho mas general y seguramente me valga no solo para juegos si no para futuras aplicaciones.

De momento voy a quedarme con la idea de la pila y a ver como lo desarrollo. No creo que necesite nada mas complejo que eso. Por cierto, ¿sabeis de algun libro que comente sobre diseño de software relacionado con juegos? He encontrado un libro y algun capitulo en el libro de Daniel Sanchez Crespo. Me gustaría tener otros puntos de vista distintos.

Pues nada, ya solo queda ponerse manos al "teclado"...  :P

Un saludo y gracias,
Rubén

 Hi,
he estado trasteando con DirectX 9.0c durante algun tiempo. He desarrollado un par de aplicaciones sencillitas en Visual C++, entre ellas un visualizador de animaciones 3D de una red neuronal de tipo I&F.

Creo que tengo los conceptos básicos pillados y voy a intentar meterme con algo más complicado. Asi que mi "chuper-diseño-para-ir-tirando-con-mil-variables-globales" se me ha quedado muy pequeño. Vamos, que ni loco me meto en algo un pelin mas complicado con el diseño de aplicacion que tengo ahora mismo. Es un suicidio....  (nooo)

Tengo pensado hacerme un marco de trabajo sencillito que me sirva como base para cualquier proyecto relacionado con juegos/simulaciones/etc....
En este marco habría una clase llamada cAplicacion que tendría como objetivo correr todo el sistema. El winmain estaría separado en un archivo y en el, se instanciaría cAplicacion para ejecutar el programa: inicializacion de graficos, sonido, etc.... Además tendría otras clases como cGraficos, cSonido, cInput para manejar el resto del sistema. Estas clases las usuaría cAplicacion.

Con esto como punto de partida tengo dos ideas:
1. Tener en cAplicacion metodos con nombre runX(), donde X es Menu, Intro, Juego... Cada metodo con su propio "game loop", de tal forma que en cada "game loop" solo habrá que manejar información del estado(Intro, Menu, Juego,Creditos,...) en el que te encuentras. Además tener un metodo run(), que se llamaría desde el winMain, despues de inicializar la instanciación de cAplicacion, claro esta.

2. Tener en cAplicacion un metodo con nombre run(). Este metodo tendra un "game loop" en el que se implementará la logica para pasar de un estado a otro de la aplicación. Asi que, en cada iteración del programa habrá que comprobar en que estado se esta y hacer lo correspondiente.

Ahi estan las dos opciones que se me han ocurrido. Personalmente, me parece mejor la primera. Aunque como no estoy seguro, prefiero que me aconsejeis vosotros.

Si teneis alguna otra opción mas interesante que las que he propuesto yo postearlas. (ole)

Un saludo y gracias,
Rubén