Programmation shmup

Pour tout ce qui est fan arts, homebrew, shooters codés à la main, rip de sprites, doujins et toute autre productions artistiques ou logicielles faites maison.
Répondre
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

Avis aux codeurs fous.

J'aurais 2/3 questions:

-pour le background qui scroll, vous le chargez en une surface unique que vous faites défilez ou bien vous marchez par morceaux que vous chargez au fur et à mesure puis les coller juxtaposé dans le backbuffer au bon moment ?
-Pour un shmup arcade et dreamcast par exemple, la résolution de l'ecran est 640/480/16bpp ou plus?
-Lors des déplacements des sprites, vous réaffichez le fond complet ou bien juste la portion qui correspond à la zone de déplacement des sprites qui ont bougés?

Merci pour votre aide.
tam
Radiant Silverpost
Messages : 1466
Inscription : 31 août 2003, 22:07
Localisation : geneve
Contact :

tu codes sur quoi ?
en général sur console (hors GP32 :p ) tu as pas à te soucier de redessiner le fond puisque ils appartiennent à un layer indépendant, tu le gères seul.
pour le fond tu as des limites de tailles, si elles sont suffisantes tu peux cycler ton scroll sinon tu charges par petits morceaux en faisant un roulement.
sur arcade en général les résolutions "classiques de nos bons vieux shoots" sont assez basses (320 * 240 max) sur DC tu dois en avoir de plus hautes mais tu dois avoir le choix.

bref c'est assez flou comme question, difficile de répondre correctement si tu précises pas un peu ton support / ta lib.
-Caz-
Radiant Silverpost
Messages : 1036
Inscription : 25 mars 2005, 11:52

Y'a pas vraiment de meilleure façon de faire, en fait ca dépend surtout de ce que tu as comme matériel/mémoire/performances a ta disposition...

par exemple pour le scroll, la plupart des jeux old-schools juxtaposent des blocs; ce qui correspond soit à des possibilités intrinseques de la machine, soit à un moyen de limiter l'espace mémoire occupé par les graphs; mais ensuite la taille des blocs dépend la aussi de bcp de parametres.

Pareil pour les sprites, si ta machine les geres en hard ou avec une bonne librairie, tu ne t'occupe de rien; si tu dois te les recogner a la main (Atari ST, de mémoire...) tu les programme en fonction de tes autres routines graphiques pour optimiser le tps passé : en général avec un scroll, ce qui se faisait c'était tout réafficher a zéro dans le buffer, si je me souviens bien la aussi.

(réponse qui ne fait pas vraiment avancer le schmillblick, et n'apporte rien de plus que celle de Tam... :D )
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

ok, je code en C++ avec SDL pour pc pour l'instant mais on sait jamais. J'utilise la memoire video.
Pour le scorlling vertical du petit bout de code que je suis en train de faire, j'ai fait une map pour le fond.
Ma resolution est de 640/480/16 comme sous DC apparament.
Je copie l'image dans ma structure surface, je la blitt dans le buffer et je flip, puis à chaque tour, je la decale. Evidemment, ça passe impec, mais je perd grave en fps (même si c'est encore correct comme fluidité). Ma map est assez grande (640*5000) et je la charge en un coup, donc je deplace à chaque tour une image de 640*5000 alors que seul 640*480 sont affiché mais c'est tres simple à faire au moins.

Je me disais que on faisait ptet ça completement différement dans les jeux.
Je peux pas faire de tuile parce que le fond est trop complexe à decouper en morceaux qui se ressemble. par contre, j'avais dans l'idée de le couper en morceaux de 640*480 et donc de les coller par deux dans le backbuffer au moment de l'affichage. Comme ça, je ne charge et n'affiche que 640*960 à chaque tour.
Je pense tout de même que tous les morceaux doivent etre mis en memoires au lancement pour eviter les appels disc durant le scrolling mais en terme d'affichage, je devrais etre gagnant.

Voilà, je sais pas si ma demarche est bonne et j'aurais voulu savoir si vous aviez des techniques.
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

l'histoire du layer independant d'accord. J'ai un offscreen indépendant aussi pour mon fond mais quand tu copie tous tes elements dans le buffer pour l'afficher, ils sont confondu. Je pense que sur console c'est la même chose mais c'est pur spéculation logique. donc apres, à l'affichage suivant si tu ne recole pas dans le buffer à nouveau le fond puis les elements mais que tu deplace juste les sprites que tu les colles et que tu affiches, tu vois encore les anciens et c'est tout pas beau evidemment ;-)
je pense que mon explication n'est pas tres clair, on verra bien ;-)
rom1frommars
Sniper Fou
Messages : 353
Inscription : 24 sept. 2004, 13:56
Localisation : Marseille

L'utilisation de SDL/C++ est un très bon début sur Pc. Car sinon il faut passer à DirectX et là ça se complique beaucoup. La 2D n'est pas gérée et on est obligé de passer par de la 3D "à plat" pour faire de la 2D performante. Mais bon en contre partie directx est largement plus puissant que SDL.
-Lors des déplacements des sprites, vous réaffichez le fond complet ou bien juste la portion qui correspond à la zone de déplacement des sprites qui ont bougés?
Dans la théorie, afficher seulement les parties du decors sur lesquelles sont "passées" les sprites est bonne. Cependant dans la pratique au vu du nombre de sprites à l'écran ça n'a plus aucun intéret. Qui plus est dans un shoot le decor est quasiment toujours en mouvement donc on doit le modifier à chaque frame.

Pour l'affichage du fond par mosaïque, cette méthode est surtout due aux limitations techniques du hardware. Donc de nos jours et sur Pc tu peux zapper cette technique. Le plus simple et le plus efficace est de découper ta map en plusieurs maps de 640*480 (ta résolution). Vu la capcité mémoire des pc tu peux tout charger au début sinon il faut avoir recours à la programmation par thread (programmation parallèle).

Voila, je pense avoir répondu à ton problème :-D
Image
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

Merci pour la reponse :-) c'est super. Je suis pas programmeur à la base (enfin pas graphique) alors c'est une aventure à chaque nouveau probleme! :-)

PS, pas question d'utiliser directx, dejà parce que directdraw n'existe plus et puis quit à faire de la 3d projeté pour simuler la 2d, je prefere utiliser opengl. Je veux du portable.
ludogood
No-bullet mode
Messages : 27
Inscription : 11 août 2004, 20:36

Japi a écrit :PS, pas question d'utiliser directx, dejà parce que directdraw n'existe plus et puis quit à faire de la 3d projeté pour simuler la 2d, je prefere utiliser opengl. Je veux du portable.
DirectDraw n'existe plus ??? la DLL est pourtant toujours présente dans DirectX! 8O
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

oui, c'est un composant de directx version 7.0, des la 8 et maintenant la 9, il n'existe plus mais directx est à compatibilité ascendante donc ça marche encore mais t'as plus les librairies dans le SDK du dx9 par exmple. maintenant, il faut utiliser directgraphics si je me souviens bien qui regroupe direct3d et directdraw ensemble.
ludogood
No-bullet mode
Messages : 27
Inscription : 11 août 2004, 20:36

Ok, je verrai si je peux encore compiler ma vieille appli DDraw faite en builder...
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

je pense que oui, si tu as encore les librairies et tout, sinon, il faudra ptet modifier le nom des fonctions un poil. Je suis pas du tout spécialiste du truc.
-Caz-
Radiant Silverpost
Messages : 1036
Inscription : 25 mars 2005, 11:52

rom1frommars a écrit :L'utilisation de SDL/C++ est un très bon début sur Pc.
ca m'interesse! :) c'est quoi SDL?
Je suis un peu réfractaires aux environnements de dev lourds, style Visual, ou meme les Builder :oops:
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

SDL c'est une librairie de fonction multimedia ultra portable. (simple directmedia layer)

elle permet l'acces à la carte 3d, au clavier, souris, cdrom, de faire du multitache, de jouer des sons et de disposer de fonctions graphique et de buffer pour l'affichage. tout ce qu'il faut pour coder un jeu 2d en gros.

Portable puisque sa compilation peut se faire sous linux, windows mais aussi macOs, beOs, certaines consoles comme la DC, pleins de trucs, quasi tout, je suis une endive..

SDL a par exemple permi de faire le jeu civilisation si je me trompe pas et pleins d'autres trucs. C'est beaucoup utilisé dans la 2d, pour la 3d, les gens passent plus sur opengl.

C++, c'est un langage ;-)

il n'y a rien là dedans qui soit un IDE (environnement de dévellopement) donc le choix est libre, builder, VC++, anjuta, programmation avec un editeur de texte comme emacs ou vi ou bien devc++.

moi je suis sous devc++ pour windows et je code sous emacs sous linux.
Avatar de l’utilisateur
Henes
Ampoule aux Pouces
Messages : 474
Inscription : 10 juil. 2004, 14:25
Localisation : Paris (94)
Contact :

Japi a écrit : par contre, j'avais dans l'idée de le couper en morceaux de 640*480 et donc de les coller par deux dans le backbuffer au moment de l'affichage. Comme ça, je ne charge et n'affiche que 640*960 à chaque tour.
Tu peux faire ça mais ce n'est toujours pas assez optimisé.

Quoi que tu fasse, tu devrais faire en sorte que seule la partie visible de l'image soit affichée/transférée.
Si tu as une énorme image de 640x5000 alors n'affiche que la partie 640x480 voulue (joue avec le SDL_Rect de la source dans ton appel SDL_BlitSurface).
Si tu prédécoupes en plusieurs images 640x480, alors n'affiche que les deux parties nécessaires (les 640x80 du bas de l'image 1 et les 640x400 du haut de l'image 2, par exemple).

Cela dit, même si tu ne peux pas utiliser de tuile pour constituer ton décor, tu peux tout de même découper tes énormes images en petites tuiles pendant le chargement.
Cela te permettra par exemple de faire un véritable scrolling multidirectionnel sans afficher plus que nécessaire.
Et si tu prédécoupes les images sur disque, cela te permettrait même de streamer de longues maps :)
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

j'utilise dejà les structures SDL_Rect et quelque soit la taille de mes images par xmple 640*5000, je n'affiche que 640*480 et je decalle de 1 les parametres .x et .y de la structure Rect pour faire le scrolling. En fait, j'ai jamais pensé qu'on pouvait afficher une image de 640*5000 sur un buffer qui en faisait que 640*480. De plus, comme je travail avec des tables de sprites qui contiennent toutes les décompositions des mouvements du vaisseau , je dois forcement utiliser cette methode.

Malgré ça. vu que je n'affiche tjrs (et quelque soit la méthode) que 640*480, je me demandait si je gagnerais en performance en decoupant. Ce n'est pas forcement le cas puisqu'au final j'affiche la même surface à chaque loop mais ptet que le gain ne viendrait pas de là. A tester.

"Et si tu prédécoupes les images sur disque, cela te permettrait même de streamer de longues maps :)"

tu veux dire que je pourrais les charger pendant le scrolling? et ainsi libéré la memoire occupée par ces images en cours de défilement? ça serait genial, j'y avais pas pensé vu que je me disais que faire un acces au disk pendant le jeu allait forcement ralentir tout ça mais en fait, c'est vrai que si les morceaux sont petits, ça peut etre bien...je vais tester ça. merci
Avatar de l’utilisateur
Henes
Ampoule aux Pouces
Messages : 474
Inscription : 10 juil. 2004, 14:25
Localisation : Paris (94)
Contact :

Oui mais streamer implique multithreader si tu veux bien faire (c'est à dire placer les accès disque dans un thread séparé et synchroniser tout ça avec sémaphore&co)... sinon les perfs risquent de s'en ressentir.
Il n'y a qu'à voir tout ces jeux qui "bloquent" un cours instant en cours de partie (surtout les FPS, quoique avec le débit des disques actuels cela se ressent moins).

Pour gagner des perfs côté affichage, tu devrais aussi faire des essais avec des surfaces hardware ou pas.
C'est à dire placées en mémoire vidéo ou pas.

Si tu utilises SDL_SetAlpha, cela implique lire le bitmap destination ce qui est extrèmement lent avec les surfaces hardwares sur les configurations faisant les opération de blit au cpu. Et je n'ose pas imaginer le résultat sur un unix si la surface doit être transférée à travers le réseau :-)
Il y a d'autres cas plus simples ou cela peut-être lent, suivant ce que font tes routines de sprite.

Cela mérite quelques essais, en tout cas.
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

ok.
Oui, j'utilise SDL-SetAlpha, mon plus gros soucis est de savoir si mes surfaces sont bien en memoires videos ou pas. Dans la déclaration de SDL, j'ai mis le flag HWSURFACE pour etre en hardware et utiliser la ram video mais je suis pas bien sur que il le fasse vraiment. Comment est-ce que je pourrais verifier ça? ya une histoire de lock en memoire video, j'ai pas bien pigé ça encore.
Avatar de l’utilisateur
Henes
Ampoule aux Pouces
Messages : 474
Inscription : 10 juil. 2004, 14:25
Localisation : Paris (94)
Contact :

Je ne sais pas si on peut vérifier si une surface est en mémoire vidéo ou pas. Mais est ce important ? :-)
Si tu demandes une surface hw, j'imagine que le système essayera tant bien que possible de le faire afin que de profiter des fonctions de blit accélérées hw.
Ce qui est par contre sûr et certain, c'est que si tu crée une surface sw alors elle ne sera jamais logée en mémoire vidéo et les accès cpu resteront très rapides.

Tu as uniquement besoin de locker une surface si tu y accèdes toi même sans passer par les fonctions de blit de sdl. Mais dans ce cas tu dois gérer tous les formats de pixels existants et ce n'est donc pas forcément recommandé pour débuter :-)
La raison est que le système peut décider de changer la surface de place s'il a besoin de réorganiser des choses... il peut même passer une surface hw en dehors de la mémoire vidéo si tu arrives au bout de celle ci. La version windows de sdl peut même virer ta surface à tout moment quand tu bascules en dehors du mode plein écran je crois
En lockant, tu t'assures que la surface ne bouge pas jusqu'à ce que tu la délock.
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

ok, merci alors le lock, je regarderais plus tard. Je vais rester en HW.

Sinon, je cherche à faire un anti-aliasing. J'ai aps trouvé de fonction, je dois donc le coder? ya pas des fonctions de la carte 3d pour faire ça? sinon , ça va pas aller tres vite si je fais les calculs sur toute l'image.

là j'ai un background qui defile à chaque cycle + mon vaisseau que je dirige avec les touches du clavier (la table de sprite est composée de 20 états différents), une couche de nuage transparent qui bouge aussi et un compteur fps en mode text grace à SDL_ttf. le tout en full screen en 640*480 je suis à 135fps sur un AMD-Athl64 3200+ CG 6600GT 128Mo ou 86fps sur un AMD-K7 1.2G CG gforceMx64 32Mo.

J'ai bloqué mon nombre de cycle à 60fps. En fait, si je vais plus vite que 60fps je rajoute un delay à chaque cycle qui comble le temps inférieur à la durée d'une frame pour que je retombe sur 60fps. J'ai vu que les gens font pas trop ça mais plus ralentir ou accélérer la vitesse de déplacement en fonction du nombre de fps.
Sojiro
Power Up !
Messages : 88
Inscription : 10 août 2004, 20:59

Tiens, on parle de la SDL... donc je rapplique 8)

Pas grand chose à ajouter aux réponses déjà formulées... mais j'en profite pour refaire un peu de pub sur mes anciens projets (tous en SDL).

http://realkogure.free.fr

La prog est loin d'être parfaite (même si g bcp progressé), mais ils tournent tous avec une bonne fluidité d'affichage ^^

Bye,
Jérémy
Ma petite page : http://realkogure.free.fr
Avatar de l’utilisateur
Alec
King Fossile
Messages : 15772
Inscription : 12 juil. 2004, 18:04
Localisation : nstc-j

Thunder heaven ....... j'essaies tout de suite !


merci !

Aaaaah la chance que vous avez de savoir faire tout ça.....
ImageImageImage
Sojiro
Power Up !
Messages : 88
Inscription : 10 août 2004, 20:59

alec a écrit : Aaaaah la chance que vous avez de savoir faire tout ça.....
Ouais... enfin, il y a des jours où je préfèrerai être graphiste que programmeur :)
Ma petite page : http://realkogure.free.fr
-Caz-
Radiant Silverpost
Messages : 1036
Inscription : 25 mars 2005, 11:52

Japi a écrit :SDL c'est une librairie de fonction multimedia ultra portable. (simple directmedia layer)
(....)
il n'y a rien là dedans qui soit un IDE (environnement de dévellopement) donc le choix est libre, builder, VC++, anjuta, programmation avec un editeur de texte comme emacs ou vi ou bien devc++.
(...)
moi je suis sous devc++ pour windows et je code sous emacs sous linux.
Merci pour ces précisions!
Avatar de l’utilisateur
lmn4096
Ampoule aux Pouces
Messages : 498
Inscription : 18 juin 2003, 04:36
Localisation : ex-Osaka

si on aime le challenge, on peut aussi coder en D et SDL.
comme le fait Kenta Cho. mais il est plus porté sur la 3D.

on peut voir son travail ici :
http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html
Japi
Brute du bouton A
Messages : 233
Inscription : 09 sept. 2005, 14:42
Localisation : Strasbourg

c'est un langage "D"?

Le truc genial sinon, c'est le couple SDL OpenGL. SDL pour la fenetre et les fonctions multimédia et OpenGL pour la 3d.
Répondre