Posté le 27/11/2019 15:12
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 95 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 02/10/2024 16:00 | #
Yup, t'as toutes les infos du coup. Il est pas nécessaire d'écrire les shaders en assembleur, d'ailleurs je conseille de toujours les écrire en C au début pour les debugger aisément. Par contre si tu veux les perfs maximales il faut les écrire en assembleur oui. Mais si t'en fais des intéressants (e.g. triangles avec textures affines ou depth-correct) je pourrai les convertir en échange de les ajouter à la bibliothèque de shaders pré-construits.
Citer : Posté le 03/10/2024 21:50 | #
Okay ! Merci pour toutes ces infos, j'ai pris le temps d'essayer de comprendre et pour le moment je pense que je vais finalement rester pendant un moment sur le système de rendu de base. C'est qu'Azur est comment dire... Compliqué
Au moins j'ai déjà tous les outils et les infos pour quand je m'y mettrai.
Mais ok si un jour je fais le shader pour les textures je te le transmettrai .
Albert Einstein
Citer : Posté le 07/10/2024 19:10 | #
Hello !
J'ai un soucis avec le fxsdk, je veux créer un custom_converteur et pour faire des tests j'ai fait ça :
def convert(input, output, params, target):
if params["custom-type"] == "model":
o = convert_model(input, params)
fxconv.elf(o, output, "_" + params["name"], **target)
return 0
return 1
def convert_model(input, params):
cells = bytes()
for y in range(2):
for x in range(2):
cells += bytes([ 1 ])
s = fxconv.Structure()
s += fxconv.u16(42)
s += fxconv.ptr(cells)
return s
Et j'obtient à chaque fois cette erreur :
/tmp/tmpo8_m3ea1: Assembler messages:
/tmp/tmpo8_m3ea1:5: Error: misaligned data
error: as returned 1
make[2]: *** [CMakeFiles/myaddin.dir/build.make:278: CMakeFiles/myaddin.dir/assets-cg/Models/TestCube.json.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/myaddin.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
Albert Einstein
Citer : Posté le 07/10/2024 19:14 | #
Ajoute quelques octets en plus à ta struct (en C et dans le convertisseur) pour que tes données soient bien alignées.
Citer : Posté le 07/10/2024 19:19 | #
Ajoute quelques octets en plus à ta struct (en C et dans le convertisseur) pour que tes données soient bien alignées.
C'est ça dire ? De combien ? Et pourquoi ?
Techniquement c'est sensé fonctionner j'ai repris grossièrement le convertisseur de Azuray.
Ma struct est comme ceci :
typedef struct {
u16 test;
u8 *data;
} model_asset;
Albert Einstein
Citer : Posté le 07/10/2024 19:27 | #
Il faut que tes donnés 32bit ou plus (ça inclut les pointeurs) soient alignés sur 4 octets sur sh, autrement dit que leur adresse soit un multiple de 4. Les 16bit sur 2 octets, et les 8bits sur 1 octet (donc pas alignées mais bref.)
Ici ton problème c'est que tu as 2 octets puis une donnée de 4o, donc ça passe pas. Faut que tu passe le premier en u32 ou que tu rajoute un u16 dit de padding entre
Caltos : G35+EII, G90+E (briquée
Citer : Posté le 07/10/2024 23:29 | #
Okay ! Merci ça marche en effet maintenant !
Albert Einstein
Citer : Posté le 15/10/2024 20:11 | #
Hello les gens, j'ai fait quelques tests avec Azur et je voulais avoir une confirmation.
J'ai essayé de dessiner des triangles mais je me suis rendu compte que les "découpes d'affichage" sont visibles, je voulais savoir si c'est normal ou si je dois changer des choses dans mon code.
#include <gint/display.h>
#include <gint/keyboard.h>
#include <gint/defs/util.h>
#include <gint/gint.h>
#include <gint/clock.h>
#include <azur/gint/render.h>
#include <math.h>
#include <libprof.h>
class Vector2Int {
public:
int x;
int y;
Vector2Int(int x, int y) : x(x), y(y) {}
};
void draw_quad(Vector2Int points[4], int color) {
azrp_triangle(points[0].x, points[0].y, points[1].x, points[1].y, points[2].x, points[2].y, color);
azrp_triangle(points[0].x, points[0].y, points[2].x, points[2].y, points[3].x, points[3].y, color);
}
int main(void)
{
prof_init();
azrp_config_scale(1);
Vector2Int pos(0, 0);
while(1) {
azrp_perf_clear();
azrp_clear(C_WHITE);
Vector2Int points[4] = {{100, 100}, {200, 100}, {396, 200}, {0, 200}};
for(int i = 0; i < 4; i++) {
points[i].x += pos.x;
points[i].y += pos.y;
}
for (size_t i = 0; i < 20; i++)
draw_quad(points, C_RED);
azrp_update();
clearevents();
if(keydown(KEY_EXIT) || keydown(KEY_MENU)) break;
if (keydown(KEY_LEFT)) pos.x -= 5;
if (keydown(KEY_RIGHT)) pos.x += 5;
if (keydown(KEY_UP)) pos.y -= 5;
if (keydown(KEY_DOWN)) pos.y += 5;
}
return 0;
}
Albert Einstein
Citer : Posté le 17/10/2024 15:56 | #
Ça veut dire quoi découpes d'affichage ? Ton code a l'air bon. Y'a un peu de tearing que tu peux contrer en accélérant la fréquence de rafraîchissement de l'écran via un registre un peu obscur (... je retrouve pas le code là tout de suite désolé), généralement ce que t'as c'est des petit flickers où t'as des lignes qui bougent un peu. C'est plus ou moins inévitable ça je crains...
Citer : Posté le 17/10/2024 21:23 | #
petit flickers où t'as des lignes qui bougent un peu. C'est plus ou moins inévitable ça je crains...
C'est de ça dont je parle pour les "découpes d'affichage". C’est-à-dire que je vois l'image se dessiner.
Et du coup c'est inévitable, zut.
Albert Einstein
Citer : Posté le 17/10/2024 21:28 | #
Attends on parle pas de la même chose je crois... tu vois l'image se dessiner ? Il prend combien de temps ton frame là ?
Citer : Posté le 17/10/2024 21:29 | #
Ce dont je parle est visible dans Azuray : https://www.planet-casio.com/Fr/forums/topic17720-1-mini-projet-azuray-un-raycaster-avec-azur.html
Tu peux comparer et me dire. Si t'as un g3a de ton programme je veux bien aussi
Citer : Posté le 17/10/2024 22:26 | # |
Fichier joint
Ha non c'est pas la même chose en effet. Je ne sais pas combien de temps elle mets.
Ca fait comme sur les télé cathodique, un drawing de haut en bas.
Tiens le g3a
Albert Einstein
Citer : Posté le 17/10/2024 22:41 | #
Oui c'est ce que j'imaginais au début ton frame est juste trop lent. C'est-à-dire que ton quad il couvre, allez, entre un quart et un tiers de l'écran, et tu le dessines 20 fois, donc tu rastérises entre 5 et 7 fois la surface totale de l'écran. Ce genre d'overdraw est difficile à avaler même pour la fonction ultra-optimisée qui est dans Azur.
Note que j'utilise les coordonnées barycentriques + bounding box dans azrp_triangle() et ton quad est découpé d'une façon sous-optimale (0/1/2 + 0/1/3 serait mois allongé), donc il est pas impossible que Bresenham soit plus rapide et que tu puisses gagner un peu en perfs si j'implémente l'algo de rendu à base de Bresenham. Mais genre faut juste dessiner moins de triangles massifs.
Pour contexte si tu contrôles ton overdraw et que tu restes dans 1-2 fois la surface totale de l'écran tu es supposé tourner à 30 FPS sans problème : https://www.planet-casio.com/Fr/forums/topic17134-1-yatislephe-industries.html#188835
Bon évidemment avec des textures autre paire de manches, mais une chose à la fois.
Citer : Posté le 17/10/2024 22:53 | #
Entendu, à la base je faisais juste un test de performance pour voir combien de face je peux dessiner. Mais je vois que j'aurai du mal à faire de la vraie 3D avec Azur, rien que lire les textures ou même faire un Z Buffer risque de bien ralentir le frame rate.
Albert Einstein
Citer : Posté le 17/10/2024 23:06 | #
Ah ben un moteur 3D générique n'existe pas encore tout à fait pour une bonne raison. Encore que Windmill marche pas mal et le Minecraft de 010elle010 pousse bien les limites.
Lire les textures je ne suis pas inquiet, c'est les calculer qui prendra du temps. Idéalement tu veux pas faire du depth-correct, vaut mieux rester en linéaire et découper les triangles pour esquiver les distortions les plus violentes.
Le z-buffer c'est plus contentieux, mon intuition c'est que t'as envie de le fragmenter comme la VRAM. Ça limite un peu tes options de post-processing mais je pense que c'est la dernière préoccupation à ce stade.
Du reste, tu peux essayer de faire la même en VRAM, mais avec le clear, l'update et dump 6 fois la surface de l'écran au doigt mouillé je donne pas cher de tes chances de dépasser 15 FPS. Ton problème là c'est pas le nombre de faces c'est juste la surface totale brute que t'essaie de couvrir. Si tu paves l'écran sans overdraw tu peux mettre 100 quads sans trop de souci.
Citer : Posté le 17/10/2024 23:25 | #
Okay ! Merci pour toutes ce infos j'en prend note. Je vais voir ce que je peux faire avec
J'avais déjà réussi à dessiner 100 faces sans azur et sans overclock, avec une texture UV Map j'avais réussi à avoir plus de 15 fps mais dès que je rajoute les textures je chute en fps
Albert Einstein
Citer : Posté le 17/10/2024 23:31 | #
Si tu as une comparaison directe du "même" code avec et sans Azur je suis preneur parce qu'Azur devrait être plus rapide à tous les coups mais quelque chose peut m'avoir échappé.
Citer : Posté le 17/10/2024 23:34 | #
Faudrait d'abord que j'arrive à prendre en main Azur pour faire la comparaison.
Mais oui, si un jour je l'adapte avec Azur je ferai signe
Albert Einstein