Test GFX hollywood

[Anonyme]

Anonyme

#7916

Bonjour,

J’ai essayer les différentes facon d’afficher des sprites :

Layers, Sprite, et double buffering

Le double buffering est bien plus rapide, bizarre, je croyais la cmd Sprite bien plus aboutie.

Et vous, d’après vos tests, quels est la cmd la plus efficace (j’ai des ralentissement assez flagrant en 800×600 surtout avec les cmd Sprite et Layers)

Je me demande si j’ai le bon Driver Gfx, parceque la, sa rame (surtout sous intuition) et étonnant dans un nouvel écran.

Je pense que je dois fermer l’OS, vous avez une solution?

Merci

Respect

[Tarzin]

Tarzin

#123045

C’est marrant parce que j’ai lancé les 3 en même temps en fenêtré sous WinUAE/AmiKit et je n’arrive pas à voir de différence. Pour moi les 3 vont à la même vitesse.

[Anonyme]

Anonyme

#123046

Salut,

Peut être que le problème est la… j’utilise un AmigaOne, tu émule quoi comme Amiga? je pense que ta config PC dois être largement supérieur, même en passant par l’émulation que mon miga. Attention, j’utilise pour ces tests la fonction de redimensionnement automatique avec du bitmap. Je vais essayer le vectorielle, se sera peut être sans incidence, je vérifie.

Respect

[Tarzin]

Tarzin

#123047

J’émule un 68040, vitesse plein pot avec maintient du timing.

[critonsgate]

critonsgate

#123048

J’ai les même soucis avec des résolutions en 800*600, je code ma démo sur du 640*480 pour rendre ma démo optimale et plus « portable ». Pour moi c’est pas une résolution super mais bon j’ai tout mes graphs sur des résolutions différentes donc je peux tester les perfs…

[Anonyme]

Anonyme

#123049

Salut,

As-tu essayer de modifier le type de moteur de rafraichissement d’écran?

essaie enablelayers, sa m’a l’air plus rapide que l’autoscalling.

D’après se que je ressent et la doc, l’autoscalling « redessine » l’écran complet alors que enablelayers ne « redessine » QUE se qui bouge (donc les sprites/bob, attention je parle comme un amos programmeur)

Pour infos et sur ma config, même resultat, la méthode doublebuffering+enablelayers(en preprocessing) est la meilleur.

Autre infos, quand les variable sont défini en méthode local, sa va un chouilla plus vite (surtout quand le nombre de variable devient conséquent)

Un prob de plus, un screen de 704×464 avec zone visible 640×480 (pour un scroll multidirectionnel) chute en rapidité, la zone qui est « redessiné » est en 704×464 (bob de 32×32 pixels) et non en 640×480 soit 64×64 pixel qui sont éternellement redessiner sans qu’il y es une utilité pour le joueur… Snif… je planche

Avez-vous essayer d’afficher du vectoriel? si oui, quel format et quel logiciels utilisé pour créer l’objet vectoriel?

Sa m’embeterai de passer par du font truetype pour créer un sprite

Merci

Respect

[Tarzin]

Tarzin

#123050

Autre infos, quand les variable sont défini en méthode local, sa va un chouilla plus vite

les variables local sont conseillées dès que possible, rien que pour des questions de gestion de mémoire.

Si tu as des questions ou suggestions posent les directement à Andreas via la Mailing-list (ça le motivera). En plus, il y passe quelques cerveaux de la programmation en Hollywood de temps en temps

Visiblement, tu es plus en avance que moi en programmation, de plus je programme un jeu de plateau qui est plutôt statique.

[Anonyme]

Anonyme

#123051

Salut,

En avance! je sais, pas, fait attention quand je parle car je me base sur les languages de programmation que je connais très bien (siemens S6 et PL7/PL7 junior de téléméca ainsi que le basic locomotive amstrad)

Pour le scroll multidirectionnel ou horyzontale ou verticale, il faut définir une zone ou ton scroll va démarrer, afin de ne pas avoir d’erreur d’afichage, il faut créer un écran plus grand que se que tu ne voi, les graphs doivent être un multiple de ton écran(après tu peux modifier), j’utilise une matrice de 32x32pixel (pour les gfx, c’est plus simple à dessiner)puis je colle plusieur fois cette image sur l’écran par l’intermédiaire de valeur:

1=bob 1

2= bob 2

puis je créé mon écran géant comme ceci (attention, sur basic loco)

data 1,1,1,1,1,1,1,1,1,1

data 1,2,1,1,1,1,2,2,1,1

avec cette exemple, on à un écran virtuelle de 10×32=320 pixel sur 2×32=64 pixel (2 lignes)

C’est modifiable à volonté, on peut créé un monde de 10000 pixel sur 10000 pixel, c’est géniale comme méthode, il en existe peut être d’autre, mais je ne les connais pas.

Attend de voir mes productions avant de dire que je suis en avance…

Respect

[Anonyme]

Anonyme

#123052

Bonjour,

Attention, sprite amos ou hollywood c’est le même concept

Les sprites afficher en grandes quantité, sa ne ralentit pas, à partir du moment qu’il ne dépasse pas une certaine taille en pixel.

Le double buffering est le mieux adapté pour l’animation de gros objets

Layers: pas trouver d’intéret pour le moment

Récap :

cmd Sprite : Excellent pour afficher une multitude de petit objets (30 à l’écran, sa rame pas en 640×480: taille de l’objet 32×32)

Cmd Double buffering : Excellent pour l’affichage de gros objet (limité en quantité, à partir de 8 objets en 100×100 sa rame en 640×480)

cmd layers : Heu… pas encore approfondie la commande, mais je vais trouver l’intéret. Peut être que c’est la meilleur cmd pour du scroll…

Je test

Respect

[critonsgate]

critonsgate

#123053

Intéressant tout ça, les layers j’ai tenté le coup, j’avoue que je vois pas trop de différences avec et sans par rapport au double buffering. Avec les layers c’est plus simple de gérer ses objets, on peut les gérer en les nommant et non plus par des ids.

En tout cas merci pour l’info sur tes techniques de scrolling horizontal je suis sûr que ça va me servir.

[Anonyme]

Anonyme

#123054

Salut,

D’accord avec toi pour la simplicité des layers.

Doublebuffering+brush : must pour le scroll (grande distance)

Layers : excelent pour scroller une image

Ex: image de 1024×768 sur un écran de 640×480. L’écran de 640×480 est une fenetre sur l’image (qui est plus grande), il faut déplacer l’image dans cette écran, grace au layer, sa ne ralenti pas.

Technique interressante pour un beatem all genre street fighter II qui demande un léger scroll.

La gestion des collision n’est pas excellente, il manque la définition de zone dans le sprite. La seul technique que j’ai trouver et de découper le sprite pour définir la zone critique d’attaque pour un jeu genre RPG (hero=1er sprite;Coup d’épée=2ème sprite collé au sprite 1)

Simple hollywood, mais sa demande quand même du bidouillage

REspect