Space Dementia v0.8 et Edit3D v0.95 - Page 2

Pas a deux sur la même calc :
pour diriger un vaisseau dans l'espace il faut avoir un minimum de touches et à deux c'est pas pratique, en plus je me vois mal faire pivoter l'écran de 90°...

link powaa !!

Autre chose, ce serait de pouvoir faires des niveau fixes, avec éventuellement des bords (histoire de simuler une vallé).

Oué, ou un fond d'écran, pour simuler un fond étoilé ou autre.

a ué, pas bètes aussi le background, ça peut aider pour le déplacement.

Quelques essais en vue de Space Dementai II

C'est fait avec mon new moteur + flat shading (lumière provenant d'une direction fixe)


+ d'infos sur mon site (lien en dessous)

ué, mais ça rame, maintenant

moitib: quelles routines utilises-tu pour marquer les FPS et les nombres en bas de l'écran ?

Et tu utilises quoi pour tes lignes horizontales ?

#35 : bof, ça reste encore correct là (le framerate indiqué est le vrai maintenant, et il vaut ~10 on calc).

Autre chose, là les points subissent deux sequénces de rotations, une pour faire tourner le vaisseau sur lui-même, une autre pour la caméra.
Dans le jeu, si la caméra est lockée sur le vaisseau pas besoin de transformer du tout les points, donc gain de temps, et en vue cockpit même pas besoin de dessiner le vaisseau.
Donc je garde espoir...
De toute manière ca sera toujours plus rapide que ce que je pourrais faire comme jeu de bagnole (avec là tout un terrain à afficher...).

#36 : les routines de l'AMS, mais ce n'est qu'une fois par frame, ca change pas grand chose au framerate... (j'ai essayé sans).

#37 : Une routine de mon propre cru en ASM qui affiche par paquets de 16 bits.

J'ai aussi fait la routine de triangle qui appelle ces fonctions de lignes horizontales en ASM, et maintenant je crois que je vais faire un fillRectangle en ASM aussi parce que j'affiche principalement des rectangles...

Un FillRectangle, c'est vraiment beaucoup plus rapide qu'un FillTriangle
Sinon, pour tes lignes horizontales, essaie ça, dont voici le prototype (ce ne sera peut-être pas plus rapide, mais ça peut...)
Tiens moi au courant, si ce n'est pas plus rapide

Merci. Le code à l'air plus court que le mien.
Je peux le modifier pour écrire dans les deux buffers en un seul passage ?

Ah, au fait, moi je calcule l'adresse du début de ligne dans la fonction triangle, en ajoutant 30 à chaque fois donc je pense que c'est un peu plus rapide que de passer y et l'adresse du buffer en argument à chaque fois...

jackiechan a écrit :
Un FillRectangle, c'est vraiment beaucoup plus rapide qu'un FillTriangle

En fait je voulais dire un fillquadrilatère
Qui sera plus rapide que deux fillTriangle (déja deux divisions de moins).

#41> C'est ce que je fais aussi, c'est plus rapide.

moitib
a écrit : Ah, au fait, moi je calcule l'adresse du début de ligne dans la fonction triangle, en ajoutant 30 à chaque fois donc je pense que c'est un peu plus rapide que de passer y et l'adresse du buffer en argument à chaque fois...

Oui, je fais ça aussi dans Baballe, c'est une bonne idée. Tu peux modifier ma fonction pour pouvoir continuer à le faire, si tu veux.
Alors, c'est plus rapide avec ma fonction ou avec la tienne ?

Bah, il doit pas exister plus rapide qu'avec des mask pour une HLine ... donc apres, si ton code est tres optimisé jackiechan, c forcément bien

Pour le sprintf, il ne doit pas y avoir une énorme différence (encore qu'en faisant avec un itoa optimisé et plein de strcats, tu devrais faire mieux, mais ça va être assez gros).
En revanche, il y a matière à faire nettement mieux à l'affichage. Ca dépend de la version d'AMS, mais faire 10x plus rapide que DrawStr est parfaitement faisable sous AMS 2.xx, sans dérouler la boucle d'ailleurs.

10 fois ? Pour l'instant aucune librairie n'offre autant de vitesse il me semble. Extgraph 2 va a cette vitesse là ?

nEUrOne> je ne sais pas trop si mon code est vraiment optimisé. J'ai une ou deux petites idées pour l'optimiser (utilisation de dbra par exemple [je ne connaissais pas cette instruction quand j'ai écrit la fonction]), mais je ne suis pas sûr que ça apporte vraiment (ou bien ça apporterait peut-être seulement sur les grandes lignes d'au moins la moitié de la largeur de l'écran).

oui, en effet, ca ne doit pas apporter bcp sur des petites ... mais bon, je pense qu'une bonne partie de ses lignes font une largeur raisonnable...

XDanger: je ne vois pas comment faire plus rapide qu'un affichage de sprite tres optimisé pour affichier des caractères ... alors quelle fonctionnalité de AMS 2.xx utiliserais-tu pour faire 10x ?

> 10 fois ? Pour l'instant aucune librairie n'offre autant de vitesse il me semble. Extgraph 2 va a cette vitesse là ?
Il n'y a pas de routines de dessin de caractères / de chaînes de caractères dans ExtGraph, il n'y en aura jamais. Elles seront dans TIGCCLIB, je l'ai déjà dit. Je relancerai ce topic tôt ou tard sur notre forum...

Je n'invente rien: PpHd a fait une routine de DrawStr qui est 6 fois plus rapide que celle d'AMS 1.xx, il en a déjà parlé. Nos routines respectives sont autour de ce ratio avec AMS. Et la routine DrawStr d'AMS 2.xx est plus lente que celle d'AMS 1.xx, précisément à cause de cet overhead dû à l'appel des fonctions de FlashApp pour avoir les attributs de fonts...
L'ordre de grandeur, au moins, est bon !

aRf ... oki oui, bah on arrive a 7/8 fois AMS 1.xx avec des routines optimisées

"Optimisées" quoi, aussi ? Taille (boucle simple non déroulée, deux shiftings) ou vitesse (boucles déroulées, deux shiftings) ?
Et comme DrawStr de AMS 2.xx est plus lente que DrawStr d'AMS 1.xx... on arrive à 10 fois ou plus. Nous sommes bien d'accord, et je n'ai pas exagéré.

Vitesse ... (boucle non déroulée)

Oui, nous sommes d'accord

moitib a écrit :
En fait je voulais dire un fillquadrilatère

FillQuadrangle en anglais correct.

nEUrOne a écrit :
aRf ... oki oui, bah on arrive a 7/8 fois AMS 1.xx avec des routines optimisées

Heu ué je dois être à environ 7 fois plus avec qFont, boucles non déroulées, pas de double shifting.

jackiechan a écrit :
Oui, je fais ça aussi dans Baballe, c'est une bonne idée. Tu peux modifier ma fonction pour pouvoir continuer à le faire, si tu veux. Alors, c'est plus rapide avec ma fonction ou avec la tienne ?

Euh, dsl, j'ai pas encore testé.
De toute facon il faudrait que je l'adapte aussi pour écrire dans les deux buffers simultanement pour pouvoir comparer...

Je crois que je vais plutôt m'inspirer de ton code pour optimiser le mien (mais ils sont pas très différents).
D'ailleurs le mien fait aussi un clipping sur la largeur de l'écran (deux tests au début).

#54 : Je parle franglais si je veux non ??

J'ai fait une boucle non déroulée, mais un double shifting. Le 24-(x&15) des routines de Sprite8 (une routine de dessin de caractères n'est qu'une Sprite8 légèrement modifiée et une routine de dessin de chaîne de caractères une routine de dessin de caractères avec une boucle sur le caractère) est très pénalisant si x&15 est petit devant 15...
C'est ce qu'on a fait dans les Sprite8 d'ExtGraph -> une amélioration de l'ordre de 20% par rapport aux routines précédentes en C avec un seul shifting.
Le principe du bench est toujours le même, dessiner un sprite quelconque à chaque x et y où c'est possible (de 0 à 239-8 pour x et 0 à 127-8 pour y).

Jackiechan, ta routine est plus rapide, ca c'est clair.
Mé une fois implantée dans mon prog je gagne à peine une frame par seconde...
C'est toujours ça

et avec la copie rapide de buffer ?