Citer : Posté le 27/08/2016 19:14 | #

---

Ça fait quand même vachement limité pour l'écran

Citer : Posté le 27/08/2016 19:27 | #

---

Après c'est pas vraiment un problème de ratio, si l'écran de la Casio faisait 71*64, ça serait pas possible non plus … x)

Citer : Posté le 28/08/2016 09:47 | #

---

Après, la prizm a un écran suffisamment grands, un processeur suffisant, mais seulement 2Mo de ram au lieu de 8
edit : Je suis, stupide, c'est 8ko pour la gbc, pas 8Mo( donc tout va bien )

Citer : Posté le 28/08/2016 10:54 | #

---

En effet, je ne sais donc pas lire..., un emulateur gbc sur prizm serait donc possible

Citer : Posté le 28/08/2016 12:06 | #

---

Techniquement il y a assez peu de différences à prendre en compte. La grande majorité de gint doit être compatible. Voilà une liste quasi-exhaustive pour appuyer mon propos...
- Driver du clavier (le principe doit être le même, si les touches sont identiques ça pourrait fonctionner tout seul)
- Driver de l'écran (celui qui prend 10 lignes pour la fx-9860G...)
- Moteur de gris (...)
- Ah oui, et le dessin. Mais c'est pas un très grosse affaire (beaucoup de code mais aucune difficulté)

---

Citer : Posté le 28/08/2016 12:34 | #

---

Un des problèmes "bloquant" au niveau graphique, c'est vraiment la quantité de données à transférer à chaque mise à jour de l'écran, et là je ne suis pas sûr qu'on puisse faire grand chose ; déjà qu'on laisse la charge du transfert à une unité spécialisée sur laquelle on a pas vraiment le contrôle (je veux dire on lui file les adresses, et on lui dit de commencer et c'est elle qui fait le transfert, sans qu'on ait à gérer de boucle de copie ou autre, ce qui décharge le processeur qui a priori serait moins performant pour cette tâche). On a quand même 165ko à transférer de la VRAM à l'écran à chaque frame, et là je ne pense pas qu'on puisse vraiment faire grand chose, gint ou non, puisqu'on "délègue" le transfert…

Et surtout je ne suis pas sûr que porter gint soit vraiment intéressant : on a déjà du gris à la pelle si on veut, on a de quoi utiliser le clavier de toute les Prizms sans disjonction pour l'instant, les routines de dessins sont quand même assez différentes, puisqu'en aucun cas on a de décalage de bits à gérer, on remplit juste des shorts, voire des longs si l'adresse est correctement alignable, et je ne sais pas si on peut vraiment gagner là aussi.
(À part bien entendu l'idée de libérer un maximum de fonctionnalités, mais il faut savoir qu'un gestionnaire d'interruption avait été commencé côté anglophone, mais l'auteur a rapidement briqué sa calto pendant le développement, les Prizm étant plus sensibles à ce genre de problème manifestement…)

Après y'a des moyens de partiellement contourner ça : j'avais tenté le coup du triple buffering, ça se fait et donne des résultats intéressants, mais j'avais pas réussi à faire quelque chose de propre… (Autrement dit j'hardocodais l'adresse du troisième buffer dans une zone que j'espérais ne pas atteindre lors de l'exécution du programme, sauf que c'était pas du tout exclu vu que c'était une zone dans la stack, et qui en représentait quand même ~30% :E, enfin c'était juste du "proof of concept" bancal quoi, et j'ai jamais réussi à gérer la zone proprement… :-/ ). Je ne sais pas à combien de fps tournait la GBC, mais un triple buffering pourrait permettre de gérer correctement l'émulation en se libérant un peu de ces temps de transfert graphiques, en partie seulement évidemment !
Sinon, l'écran de la GBC est également plus petit que celui de la Prizm, ça peut permettre de raffraichir seulement une partie de l'écran, ce qui, si bien géré, permet effectivement de gagner du fps (notre projet avec TheProg pour le concours de l'été y'a deux ans tournait sans overclock à 25 fps tranquillement comme ça).

Mais en fait la "lenteur" graphique est vraiment liée à la quantité de données à écrire puis transférer, et je ne sais pas si un projet du type de gint y pourrait vraiment quelque chose (après je ne sais pas vraiment comment il fonctionne en interne, donc je n'exclue rien non plus ! ).

---