bonjour a tous je voudrais me lancer dans la programmation d'un jeu en 3d
isometrique sur un ordi 8 bits (amstrad) j'aime beaucoup le style de batman
ou heads over hils mais je ne sais pas trop comment m'y prendre est ce qu'il
existe des livres traitant le sujet ou un site pour m'aider?
Il te faut deux images : une qui contient le sprite (sur fond blanc ou noir), et une autre en noir et blanc qui ne contient que sa silhouette (sur fond inverse). Tu fais un XOR de la silhouette sur la zone de fond: seuls les pixels correspondant au blanc (ou au noir, je sais pu trop) resteront. Ensuite tu fais un ET entre l'image de fond que tu viens de detourer et ton sprite (qui est deja detoure a l'inverse).
(Prends le temps de verifier les operations logiques, ca doit etre faux, je suis pas bon pour ca de tete, et ca depend si en memoire le 0 c'est le noir ou le blanc).
je vais essayer ca merci pour le renseignement
Il te faut deux images : une qui contient le sprite (sur fond blanc ou
noir), et une autre en noir et blanc qui ne contient que sa silhouette
(sur fond inverse). Tu fais un XOR de la silhouette sur la zone de fond:
seuls les pixels correspondant au blanc (ou au noir, je sais pu trop)
resteront. Ensuite tu fais un ET entre l'image de fond que tu viens de
detourer et ton sprite (qui est deja detoure a l'inverse).
(Prends le temps de verifier les operations logiques, ca doit etre faux,
je suis pas bon pour ca de tete, et ca depend si en memoire le 0 c'est le
noir ou le blanc).
Il te faut deux images : une qui contient le sprite (sur fond blanc ou noir), et une autre en noir et blanc qui ne contient que sa silhouette (sur fond inverse). Tu fais un XOR de la silhouette sur la zone de fond: seuls les pixels correspondant au blanc (ou au noir, je sais pu trop) resteront. Ensuite tu fais un ET entre l'image de fond que tu viens de detourer et ton sprite (qui est deja detoure a l'inverse).
(Prends le temps de verifier les operations logiques, ca doit etre faux, je suis pas bon pour ca de tete, et ca depend si en memoire le 0 c'est le noir ou le blanc).
je vais essayer ca merci pour le renseignement
GzavSnap
"philippe-duhamel" a écrit dans le message de news:4606cbb8$0$27386$
> > J'aurais pas déjà 50 projets sur le feu je t'aurais bien codé ça :-)) > -- c'est gentil mais ce qui m'interesse ce n'ai pas d'avoir un jeu fini clef
en
mains mais de le programmer moi meme mais merci de tes conseils tu me conforte dans mes choix le probleme que je n'ai pas encore resolu (he je debute) c'est de gerer la transparence du sprite de mon perso pour l'afficher dans le decor sans pour cela laisser une bordure blanche autour (comme pour l'aigle d'or sur oric par ex)
Faisons simple !
Alex a entièrement raison... c'est l'usine à gaz! Dans ton cas, il ne faut pas raisonner "blocs de sprites" et intecéption de bits pour délimiter tes actions. Ca complique tout! Il faut faire plusieurs types de masques invisibles et visibles. - Masque de déplacement. - Masque d'action. - Masquage graphique de transparence. ... et là on ce rapproche plus d'un programme PC qu'Amstrad. Il faudra trop de tests pour avoir une animation et une jouabilité suffisante. Dans ton cas, il faut éliminer les problèmes ... tu n'as que 128k de mémoire. Il faut donc simplifier au maximum le jeux pour éviter les buffers (écran et déplacement) divers. Eviter les tests de pixels et autre générateurs de buggs d'affichage. Eviter les appels de routines superflues ... on n'est pas en Directx et les routines seront compexes.
Comme Alex l'a proposé, simplifier le déplacement au maximum. Faire un buffer de déplacement avec un tableau codé qui va permetre un codage sur 8bits (ex: B00=déplacement, B01=porte Nord, B02=porte Est ...). Un déplacement au curseur sur cases contigües avec une animation de transition de A vers B dans toutes les directions. Un affichage du personnage avec plaquage des textures de décore sur les cases de déplacement (A et B). Maitenant, il faut choisir un mode d'affichage, 0-1 ou 2. Pour le mode 0 et 1, la couleur de transparence peut-être une couleur ... mais pour le mode 2, il faut un masque. Il faut penser qu'avec un masque, cela double la taille de la base de donnée graphique.
Personellement, je profiterai de pouvoir utiliser un lecteur de disquette, pour stocker les fonds d'écran de chaques pièce, et de les recharger à la demande en C000... mais : cela prend de la place sur disquette et il y a appel du fichier d'affichage à chaque fois (plutôt long à chaque changement de salle... surtout si on se trompe et que l'on doit revenir à la piéce précédente). Le masque de déplacement serai dans un buffer de données 8bits. Le masque graphique serai une couleur en mode 1.(incluse dans l'écran chargé) Simplement rafraîchir l'écran à chaque déplacement (après le mouvement). Mais, ici, la 3d isométrique ne s'applique qu'au personnage. Ca semble simple... mais il y a du boulot!
Xav.
"philippe-duhamel" <philippe-duhamel@wanadoo.fr> a écrit dans le message de
news:4606cbb8$0$27386$ba4acef3@news.orange.fr...
>
> J'aurais pas déjà 50 projets sur le feu je t'aurais bien codé ça :-))
> --
c'est gentil mais ce qui m'interesse ce n'ai pas d'avoir un jeu fini clef
en
mains mais de le programmer moi meme mais merci de tes conseils tu me
conforte dans mes choix le probleme que je n'ai pas encore resolu (he je
debute) c'est de gerer la transparence du sprite de mon perso pour
l'afficher dans le decor sans pour cela laisser une bordure blanche autour
(comme pour l'aigle d'or sur oric par ex)
Faisons simple !
Alex a entièrement raison... c'est l'usine à gaz!
Dans ton cas, il ne faut pas raisonner "blocs de sprites" et intecéption de
bits pour délimiter tes actions.
Ca complique tout!
Il faut faire plusieurs types de masques invisibles et visibles.
- Masque de déplacement.
- Masque d'action.
- Masquage graphique de transparence.
... et là on ce rapproche plus d'un programme PC qu'Amstrad.
Il faudra trop de tests pour avoir une animation et une jouabilité
suffisante.
Dans ton cas, il faut éliminer les problèmes ... tu n'as que 128k de
mémoire.
Il faut donc simplifier au maximum le jeux pour éviter les buffers (écran et
déplacement) divers.
Eviter les tests de pixels et autre générateurs de buggs d'affichage.
Eviter les appels de routines superflues ... on n'est pas en Directx et les
routines seront compexes.
Comme Alex l'a proposé, simplifier le déplacement au maximum. Faire un
buffer de déplacement avec un tableau codé qui va permetre un codage sur
8bits (ex: B00=déplacement, B01=porte Nord, B02=porte Est ...).
Un déplacement au curseur sur cases contigües avec une animation de
transition de A vers B dans toutes les directions.
Un affichage du personnage avec plaquage des textures de décore sur les
cases de déplacement (A et B).
Maitenant, il faut choisir un mode d'affichage, 0-1 ou 2.
Pour le mode 0 et 1, la couleur de transparence peut-être une couleur ...
mais pour le mode 2, il faut un masque.
Il faut penser qu'avec un masque, cela double la taille de la base de donnée
graphique.
Personellement, je profiterai de pouvoir utiliser un lecteur de disquette,
pour stocker les fonds d'écran de chaques pièce, et de les recharger à la
demande en C000... mais : cela prend de la place sur disquette et il y a
appel du fichier d'affichage à chaque fois (plutôt long à chaque changement
de salle... surtout si on se trompe et que l'on doit revenir à la piéce
précédente).
Le masque de déplacement serai dans un buffer de données 8bits.
Le masque graphique serai une couleur en mode 1.(incluse dans l'écran
chargé)
Simplement rafraîchir l'écran à chaque déplacement (après le mouvement).
Mais, ici, la 3d isométrique ne s'applique qu'au personnage.
Ca semble simple... mais il y a du boulot!
"philippe-duhamel" a écrit dans le message de news:4606cbb8$0$27386$
> > J'aurais pas déjà 50 projets sur le feu je t'aurais bien codé ça :-)) > -- c'est gentil mais ce qui m'interesse ce n'ai pas d'avoir un jeu fini clef
en
mains mais de le programmer moi meme mais merci de tes conseils tu me conforte dans mes choix le probleme que je n'ai pas encore resolu (he je debute) c'est de gerer la transparence du sprite de mon perso pour l'afficher dans le decor sans pour cela laisser une bordure blanche autour (comme pour l'aigle d'or sur oric par ex)
Faisons simple !
Alex a entièrement raison... c'est l'usine à gaz! Dans ton cas, il ne faut pas raisonner "blocs de sprites" et intecéption de bits pour délimiter tes actions. Ca complique tout! Il faut faire plusieurs types de masques invisibles et visibles. - Masque de déplacement. - Masque d'action. - Masquage graphique de transparence. ... et là on ce rapproche plus d'un programme PC qu'Amstrad. Il faudra trop de tests pour avoir une animation et une jouabilité suffisante. Dans ton cas, il faut éliminer les problèmes ... tu n'as que 128k de mémoire. Il faut donc simplifier au maximum le jeux pour éviter les buffers (écran et déplacement) divers. Eviter les tests de pixels et autre générateurs de buggs d'affichage. Eviter les appels de routines superflues ... on n'est pas en Directx et les routines seront compexes.
Comme Alex l'a proposé, simplifier le déplacement au maximum. Faire un buffer de déplacement avec un tableau codé qui va permetre un codage sur 8bits (ex: B00=déplacement, B01=porte Nord, B02=porte Est ...). Un déplacement au curseur sur cases contigües avec une animation de transition de A vers B dans toutes les directions. Un affichage du personnage avec plaquage des textures de décore sur les cases de déplacement (A et B). Maitenant, il faut choisir un mode d'affichage, 0-1 ou 2. Pour le mode 0 et 1, la couleur de transparence peut-être une couleur ... mais pour le mode 2, il faut un masque. Il faut penser qu'avec un masque, cela double la taille de la base de donnée graphique.
Personellement, je profiterai de pouvoir utiliser un lecteur de disquette, pour stocker les fonds d'écran de chaques pièce, et de les recharger à la demande en C000... mais : cela prend de la place sur disquette et il y a appel du fichier d'affichage à chaque fois (plutôt long à chaque changement de salle... surtout si on se trompe et que l'on doit revenir à la piéce précédente). Le masque de déplacement serai dans un buffer de données 8bits. Le masque graphique serai une couleur en mode 1.(incluse dans l'écran chargé) Simplement rafraîchir l'écran à chaque déplacement (après le mouvement). Mais, ici, la 3d isométrique ne s'applique qu'au personnage. Ca semble simple... mais il y a du boulot!
