La gif que je fournie là a été enregistrée sur un émulateur en overclock  * 16 ..

Etant donné que c'est codé avec les pieds en C lourdingue .. je pense pouvoir atteindre cette vitesse sans overclock au prix de sérieuses optimisation et d'un codage en assembleur.

Mais voilà .. je pense que je n'aurais pas du oublier de préciser ce détail qui n'en ai pas un.

Actuellement je cherche à voir si le rendu est suffisamment potable pour mériter que je m'attelle à faire tomber les cycles.

Bref, tout cela n'est pas le même principe que ce que tu veux faire, mais cela m'y a un peu fait penser.

Ce que tu me montres là est époustouflant !!

Je ne me sens pas (encore) capable de faire ce genre de chose.

Mais c'est clair que ça fait envie ...

Personnellement, je réduirais la taille de la fenetre pour réduire la consommation de mémoire. 32ko pour l'image, cela laisse peu de marge pour le software ;

C'est une bonne idée .. il faut que je rende paramétrable la taille du "viewport".

Pour l'instant j'utilise une image en 256*128 pixels car cette image doit couvrir 360° avec une résolution écran de 78*64 texels.

Si je réduis le nombre de texels à l'écran (et donc la largeur de l'angle de vue), je dois effectivement pouvoir diminuer la taille de l'image .. :-)

A suivre ..

Sinon, cela m'a fait penser à quelque chose d'autre, sur cpc, il y a une démo qui streame à partir de la disquette (regarder après la 2ème minute) : https://www.youtube.com/watch?v=yTBjuX4EYIY En revanche, je ne sais plus trop comment cela marche

Dans le même style, il serait possible de faire la démo STNICCC : comparaison snes/megadrive https://www.youtube.com/watch?v=uxpeMQiqT-Q

Bref, tout cela n'est pas le même principe que ce que tu veux faire, mais cela m'y a un peu fait penser.

@jibe : toujours aussi impressionnant

Personnellement, je réduirais la taille de la fenetre pour réduire la consommation de mémoire. 32ko pour l'image, cela laisse peu de marge pour le software ; trop peu je pense pour avoir un moteur de jeu d'aventure correct

Cela compliquera un peu mais pas tant que ca la tache du graphiste

Salut,

Cela dépend si Jibe veut le faire tournant sur la carte, dans ce cas, le pb de ram est moindre, puisqu'on a disposition 512KB de RAM en banking.Je n'ai pas prévu qu'un programme fasse plus de deux banques, mais cela pourrait s'envisager

Personnellement, je réduirais la taille de la fenetre pour réduire la consommation de mémoire. 32ko pour l'image, cela laisse peu de marge pour le software ; trop peu je pense pour avoir un moteur de jeu d'aventure correct

Cela compliquera un peu mais pas tant que ca la tache du graphiste

Je bosse sur une idée de 3D sur Oric à base de photosphère style réalité virtuelle.

Dans le principe, ça devrait donne un truc un peu dans ce style:

ATTENTION : Overclock x 16

Dans cette image, le décor est mappé sur une photosphère qui pèse 32ko en mémoire (256*128 px) et mon idée c'était d'ouvrir la porte à des jeux d'aventure en 3D où on pourrait se déplacer d'endroit en endroit en chargeant ces 32 Ko lorsqu'on change d'endroit.

Mais pour l'instant je cherche encore à produire des images qui offrent un bon rendu à une si faible résolution et ce n'est pas facile. Celle que j'affiche là est une des plus jolie que je suis parvenu à obtenir pour l'instant.

Je ne suis pas vraiment un artiste 2D/3D et donc je galère un peu ..

Mais si j'arrive à faire des photosphères correctes, ça voudra dire que le procédé peut avoir de l'intérêt. Surtout s'il est possible de charger rapidement ces 32ko entre deux scènes du jeu.

Bref, il faut d'abord que je m'assure qu'il y ait un réel intérêt / potentiel esthétique avant de me lancer dans un développement plus avancé.

Merci Jede et Assinie pour vos réponses.

En l'état actuel de ma compréhension du sujet , il me paraît hasardeux de me lancer dans cette aventure pour de l'audio.

Mais il s'avère que je travaille actuellement à un autre sujet qui pourrait tout à fait tirer profit du XFREAD.

C'est un projet dans lequel il faudrait pouvoir copier 32k de donnée de la carte sd vers la mémoire de l'Oric en un seul bloc.

Je vais tâcher de faire un prototype de mon idée avec OSDK .. et si ca donne bien .. je l'implémenterai en cc65/ca65 pour bénéficier du XFREAD.

Entre temps je vous montrerai de quoi il s'agit pour que vous me disiez si vous pensez que ça a un intérêt et si c'est possible.

Je vous tiens au courant.

Salut,

De toutes manières, passer par le Kernel est forcément plus long puisque cela fait des checks à droite à gauche et j'ai prévu de faire du mapping de device. C'est à dire qu'un fopen pourrait aussi se faire sur vrai drive disquette (ainsu qu'un XFREAD) si on monte un drive dans /mnt. Cette partie n'est pas faite, mais j'ai déjà le squelette pour gérer les points de montages.

Tout cela pour dire que le kernel est conçu pour tout faire, mais pas nécessairement pour aller le plus vite possible. C'est pour cela que je propose le format .tap qui peut profiter du hardware de la carte sans interférer avec le kernel ou bien avoir une utilisation non prévue (c'est à dire qu'on pourrait très bien dans orix monter une vraie K7 sur un vrai magneto, et lire à partir de là avec le fopen/fread : puisque le device sera masqué par l'OS).

Concernant OSDK, tu peux facilement utiliser les primitives du kernel avec xa.

Il suffit de déclarer la macro BRK_KERNEL dans xa, et l'appeler avec le bon param.

Je n'utilise plus xa car j'utilise beaucoup de structures en asm et cela devenait trop compliqué à gérer avec xa65. Et surtout je peux facilement remapper avec les includes de cc65 car le code du kernel essaie de garder les mêmes errno etc.

        ldy #$00
loop:
        lda CH376_DATA		
        sta (PTR),Y		
        iny			
        dex			
        bne loop		

X contient le nombre d'octets à lire et Y sert d'index pour la copie en mémoire.

La durée d'exécution de la boucle est de 17 cycles ce qui donne 3 parcours en 50 cycles (51)

On peut accélerer cette boucle de différentes manières:

• suppression de l'utilisation de l'un des registres (nécessite que les données soient écrites à l'envers dans le fichier par bloc de 256 octets: ie le premier octet dans le fichier est le 256ième en ram, le second est le 255ième,..., elles seront dans le bon ordre en mémoire)
  • gain: 2 cycles par boucle
• utilisation de l'instruction sta PTR,Y au lieu de sta (PTR),y
  
  • gain: 1 cycle par boucle
• dérouler complètement la boucle en mettant:

  • 	lda CH376_DATA		
    	sta PTR			
    	lda CH376_DATA		
    	sta PTR+1		
    	...	

  • on descend alors à 8 cycles par octets soit 6 octets transférés en 48 cycles
• la même, mais PTR=0 et donc un chargement en page 0, ce qui n'est probablement pas envisageable mais permet de gagner encore 1 cycle par octets soit 7 cycles et donc un transfert de 7 octets en 49 cycles.

Les deux premières optimisations combinées permettent de passer à 14 cycles par boucle soit un gain près de 18% sans augmentation de la taille du programme.

Il reste toujours le délai de WaitResponse qui est relativement incompressible et est exécuté deux fois pour 256 octets transférés si je ne dis pas de bêtise. Je n'ai pas mesuré sa durée moyenne et je pense qu'elle dépend de la carte SD/USB utilisée.

C'est peut être possible en passant par le noyau Orix pour la lecture du fichier en utilisant le truc des trois ou quatres jeux de buffers comme expliqué dans mon post précédent, il faudrait vérifier.mais ça ne me parait pas infaisable.