Salut, juste une petite question comme ça. Est il possible de mélanger de la 3D et de la 2D sur un Amstrad ?
L'idée serait alors la suivante : un jeux de foot genre PES.
Le terrain est en vue latérale avec perspective. C'est ce terrain qui serait en 3D en fait, il serait alors un peu comme une matrice virtuelle mais seul les lignes blanches seraient modélisées.
Ensuite par dessus on placerai des sprites 2D pour les joueurs et le ballon. Ces sprites seraient avec une pseudo perspective, en effet en fonction de la profondeur du point de la matrice où ils sont supposés être, bin ils on un sprite plus ou moins petit.
Genre 5 tailles différentes ça devrait suffir à faire illusion sans forcément trop pomper non plus (quoique).
Il y aurait alors un scrolling latéral, le terrain entrant en totalité dans la hauteur de l'écran de jeux (histoire de ne pas mettre un autre scrolling) grace notament à la perspective.
Esque ça a déjà été fait ? Esque c'est possible ? Esque c'est exploitable et pas trop gourmand donc.
En effet bien souvent les jeux de foot à la con en latéral (et la plupart des jeux de sport en fait) utilisent un terrain en isométrique fixe pour d'évidentes raisons de facilité (les jeux de Beat'hem all comme renégade aussi d'ailleurs). Scateball aussi me semble t'il (le jeux de patinage-ball violent, c'était bien ça son nom ?)
Mais je ne trouve pas ça trés top en fait.
Sinon il y a aussi le classique vue de dessus mais bon.
Merci des quelques indications que vous voudraient bien me donner.
le but c'est que les lignes blanche du terrain bougent et prennent une perspective en temps réel.
donc le trait serait vertical au centre de l'écran et de plus en plus en diagonale en fonction de l'éloignement par rapport au centre de l'écran.
Tu sais ? la perspective, en déssin, quand tu fait un truc en pseudo 3d : tu trace ton horizont, et les points de fuites ainsi que le point de convergeances. Ce qui est verticale le reste (les joueurs) les lignes que tu vois en travers restent horizontales et droites, mais les lignes qui parte de toi en se décalant convergent toujours vers le centre de l'horizont...
Or dans les jeux sur CPC en général on utilise un perspective artificiel, fixe et 2D, un simple dessin qui ne corrige jamais le fait que tu puisse te décaler donc ton point de focal/convergeance change.
Genre un jeux en 3D de foot moderne : PES donc typiquement. si la ligne de corner/cages et sur le bord de l'écran (pas au centre de l'écran donc) bin elle est oblique sur l'écran. Alors que si la vue est centrés sur cette ligne (lors d'un Corner par exemeple) elle est plus ou moins verticale sur l'écran (car la caméra est dans son axe.)
Bref le but serait plus ou moins de savoir si on peut reproduire cela sur un CPC. Seul le Terrain serait modélisé en 3D donc, mais les Sprites (2d) pourraient changer en dimension en fonction d'à quelle profondeur ils sont dans la perspectivez (il "suffit" de prévoir plusieurs modèles pour les sprites.)
Idéalement ça pourrait même se concevoir en usant entre autre des magnifications des sprites Hard d'un Amstrad Plus d'ailleurs.
maintenant regarde ce jeux sur Amstrad : http://www.phenixinformatique.com/CPCGA ... il&num=889 bin la ligne de milieux de terrain bien que complétement décalée sur le coté de l'écran...bin elle reste droite, car c'est une fausse perspective.
En effet ça ferait théoriquement un rendu genre le scroll différentiel. Car le but d'un tel scroll est justement de donner une impression de 3D/perpective/profondeur.
Mais l'idée c'est de le faire avec un truc en 3D. les lignes du terrain (dans le cas d'un jeux de sport) bin ça serait une 3D fil de fer finalement, sauf que on modélise une sorte de feuile plate passque le terrain il est plat.
Ok donc d'après toi sur CPC old on ne peux pas vraiment mélanger du sprite avec un fond intégrant une "figure 3D plane en perspective" mais en Amstrad PLUS (car c'est officièlement pas un "CPC") bin on peut sous réserve d'user des Sprites Hards qui sont plus ou moins indépendant donc (car "Hard" dit "cablés" et gèrés par l'Asic me semble t'il...)
D'ailleurs c'est pas forcément de la 3D mais en fait de la géométrie 2D finalement...juste quelques trapèzes intéractifs à calculer en fait. euh...voire des élipses aussi finalement.
Bin après pour être franc, je trouve dommage de se limiter au CPC old qui fut déjà lartgement bien exploité alors que le PLUS aurait encore à faire ses preuves je trouve. rien que parceque les Sprites et scrolls et autres, c'est quand même théoriquement "Plus" exploitable.
Pour les précalculs, c'est à dire ?
Esque ça pomperait boucoup de ressource ?
Peut on intégrer plusieurs "calques" aussi ? (par exemple un fond texturé derrière les lignes du Terrain...
Et intégrer un ou deux splitsscreens/rasters histoire que en Haut et en bas on puisse mettre une ou deux bandes avec du publique, des panneaux de scores, infos de jeux, etc...
Esque on y gagne par rapport à un Scroll multi ?
Et Quid des lignes blanches pleines et épaisses ?
L'idée serait de faire un moteur de jeux pour des jeux de sports en scrolling/vue latéral. Après, bin tout est possible niveau sport : d'un BloodBowl à un Speed/Skate ball au simple Basket, Foot, HandBall...etc...
Idéalement il faudrait un sport avec un format d'équipe limité aussi afin de ne pas trop vite bouffer tout les sprites Hards. Genre du Beach soccer...
Bien sur des sports violents et futuristes ont ma priorité...mais le coté fun à la Ocean Beach Volley, pourquoi pas non plus. ou le jeux de Footbal futuriste et violent sur NeoGeo SNK (et borne d'arcade donc).
Mais pour commencer il me faut une petite étude de faisabilité, et ce genre de mélange de techniques, bin des démomakers ils doivent savoir logiquement.
C'est un peu le genrez d'éffet que je souhaiterai en fait. Il y a bien une perspective pour les "sprites" et l'éffet de vue centrée donc les lignes fuyantes qui convergent au centre.
De plus on voit bien des surfaces pleines doncv possibilité de faire des lignes sur le Terrain qui bougeraient de la sorte. Après un terrain en pseudo dammier pourquoi pas non plus. Genre un Terrain comme pour le Jeux de plateau traditionnel BloodBowl qui avait des cases.
Resterai à voir les limitations en matière de "texturage". De même que en matière de profondeur de champ.
Je pense que les Techniques employées dans les simulateurs de voiture (Burnin'Rubber donc typiquement) seraient aussi exploitables.
Mais comme je le dit dans le post précédent, un simple calcul de figures géométriques, pourquoi pas alors.
Qui peut me donner plus de détails sur ces méthodes ou possibilités ? Voire qui serait motivé pour un tel codage ? (je sais que là ça va tout de suite moins se bousculer lol...)
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Si le fond d'écran est dynamique et que tu dois le reconstruire à chaque fois, il est bien évident qu'il n'y a pas de réel intérêt pour un scroll hard.
Si tu gères des sprites software par dessus, je pense que tu peux optimiser les routines en ne mettant qu'une seule couleur pour tes lignes de perspective. L'intérêt du fond généré c'est que tu es obligé de le reconstruire quasiment à chaque fois, donc il faut juste effacer sélectivement ces lignes et les sprites. Tu es obligé de toute manière d'envisager de bosser en flipping de page.
Si tu comptes utiliser le cpc+ pour les sprites hardware sur un terrain en perpective, il va quand même se poser le problème des priorités. Vu que ce n'est pas géré en hard, ça impliquera qu'à l'issue du tri des profondeurs, tu fasses des swaps de mémoire et de coordonnées, ce qui peut vite bouffer de la cpu si il y a bcp de choses qui bougent verticalement. De plus si tu considères que les sprites en question auront des animations (un joueur qui coure et se retourne, par exemple), ça suppose déjà de faire pas mal de copie. Si tu ajoutes en plus des tailles différentes en fonction de la profondeur, je ne suis pas certain que le zoom hardware soit vraiment approprié (c'est un peu brutal, le doublement de toutes les lignes verticales)
Pour le Zoom, je pensais en fait un truc plus graduel, et pas de x4 mais maximum du X2 en vertical... Après c'est clair que ça fait vite boucoup de sprites différents et d'animes différentes donc.
Mais en gros le plus dur serait déjà de répartir sur la "profondeur". Il faut aussi que ça parraisse réaliste. Mais pour les jeux de bagnoles, bin y'a bien une sorte de zoom de la sorte non ?
Et ça irait peut être d'un Sprite genre 8 pixels de haut et 8 pix mode2 en large pour tout au fond et loing, Jusqu'a 8 pix Mode0 et 16 pix mode x2 en version super grande. Enfin j'ai pas encore planché sur ces dits sprites car là je bosse boucoup IRL en ce moment... Mais on doit logiquement retrouver des mêmes sprites à échelles différentes parfois. Genre la version pix 1x1 (mode 1) et la version 2x2 (Mode 0 et 2pix de hauteur)... De même une version 2pix en y et 1 pix en X (Mode1) bin reviendrait au même qu'une version de type Mode 2...
Bref il me faudra déjà faire quelques déssins et schémas sur de la feuille quadrillée pour commencer.
Quoi qu'il en soit, il semble donc que c'est super chaud finalement.
Mais oui les lignes, je pensais un truc simple en 1 seule couleur sur un fond unis... Bref du Mode 1 quoi. Quoique pouvoir faire un ensemble de lignes "remplies" et épaisse en disont Blanc, et pouvoir surligner avec des lignes disont Noir simple (1 pixel de large donc) sur un fond d'une 3ème couleur...ça serait finalement idéal, lol.
Après je suppose qu'il y a aussi peut être plusieurs possibilitées pour générer ce genre d'effet.
Mais c'est clair qu'un jeux potable visuellement nécéssiterait déjà un split horizontal genre en haut de l'écran, avec donc une sorte de gradin/public/décors qui scrollerai à la même vitesse que la ligne du Haut.
Ensuite on peut dire que l'on peut aussi limiter le nombre de sprites (joueurs) à l'écran...genre dans speedball 2 sur 16 bits bin tu n'as pas souvent tous les joueurs affichés en même temps, lol... Et speedBall 1 bin y'a au total que pas boucoup de joueurs (combien déjà ?)
Mais euh...c'est si gourmand un simple ensemble de lignes et de trapèzes qui bougent de la sorte ?
Après il parrait aussi que les sprites Hards sont finalement hyper gourmands en fait, lol...la version 128Ko s'imposera forcément, ce qui n'accélère pas d'ailleurs.
Et oui un tel truc, je pense que quand même il faudrait mieux le faire sur un Plus passque... bin voilà quoi. Euh...on me dit aussi que c'est mieux encore sur un PC quadricore 7GHz...lol...
Plus sérieusement, je parle de scrolling, mais en fait ça ne serait pas je pense un véritable scrolling. L'ensemble de figures géométriques se modifie ce qui fait de fait un scroling, mais c'est pas vraiment comparable au scrolling d'un ensemble de tuile.
Puisque on générerai des figures, soit un ensemble de lignes géométriques voire de remplissages : droites, etc...
Après il y a un simili scrolling s'appliquant bien sur aux Joueurs en fonction de leurs actions et mouvements mais surtout en fonction de leur "profondeur" dans la perspective... Mais ça revient à modifier les déplacments des sprites, ce n'est peut être alors pas vraiment du scrolling donc.
Et la Bande de Graphismes en haut de l'écran (les "Gradins donc) bin elle elle scrolle vraiment par contre. Après elle est plus ou moins optionelle histoire de faire un jolie rendus quand même.
Donc ce genre de rendu, ça à été fait en démo sinon ?
C'est marrant ça, quand on voit les trucs que les Démomakers nous pondent en se la pétant, mais dès qu'il faut y donner une application concrète, ouillouillouille... à ça pour coller 15 textes qui défilent en Fullscreen à des vitesses différentes, se distordent en changeant de couleurs et affichant toute la palette...tout ça pour faire dire à ce texte que untel est un grosnaze du codages et que décidément je suis trop le meilleur car j'arrive à afficher du texte en couleur qui bouge... (même que ça défile trop vite et change trop de couleurs donc on arrive même pas à lire...)
Bon après c'est sympa aussi les démos et ça n'est pas que du texte qui défile. Mais finalement je trouve ça moins ambitieux que des Jeux. En même temps c'est aussi moins long à développer (quoique ?)
Ceci dit, j'avoue être mal placé pour faire de telles reflexions car oui je suis une quiches en prog. Donc j'éspère ne pas m'attirer de foudres...lol. En tout cas je ne vise absolument personne de particulier, c'est juste une petite impression et c'est un peu HS, mais bon, j'ai eut une rude journée.
Hééé oui MacDeath, tu ne fais que réaliser l'énormmmmeee gap entre un demomaker et un programmeur de jeu. Le 1er excelle dans le fake, le 2eme dans l'interactivité. Et l'interactivité, un demomaker, ca sait pas faire Et à tous ceux qu'ils pensent savoir programmer un gameplay.. et qu'ils savent réellement le faire, c'est encore une autre chose
Inscription : 28 Août 2008, 23:41 Message(s) : 258
Tant que tu n'as pas défini un minimum ce que tu veux faire, il est difficile pour toi de pouvoir dire si utiliser le plus te facilitera la vie ou pas.
Il est certain que pour faire un split et un scroll ralenti sur tes gradins, ça peut aider.
Pour ce qui est des sprites, ceux du plus présentent les problèmes décrits précédemment (priorités et transferts [1 octet pour 1 pixel sur un sprite hard]). De plus le zoom hardware max en y est quand même bien cradok visuellement. Après pour le côté stockage, tout dépend du nombre d'animations et de sprites, sachant que tes joueurs se "retourneront" ou pas dynamiquement.
Quelque soit ton choix (plus ou old), 128 ko pour avoir de belles animations me parait plus raisonnable. Il n'y a aucun lien entre ça et la vitesse.
Faire une démo à base de techniques hardwares n'a bien sûr rien à voir avec un jeu. Le temps de réalisation de la plupart des démos cpc est négligeable en comparaison de celui mis pour un jeu. Ce sont deux domaines différents car les objectifs sont différents. Beaucoup de codeurs de démos sont donc incapables de réaliser un jeu, mais l'inverse est aussi vrai. Car les motivations et l'intérêt des deux parties sont fondamentalement différents.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 84 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum