quelques releases - Page 1

Comme il stagne un peu depuis quelques temps, voila une premiere release de mode7, un moteur de rendu type mode 7 intégré a une demo du jeu mario-kart (la version super-nes). Ne vous attendez pas a quelque chose de jouable, on ne peut que se ballader sur les circuits pour l'instant (et en creer avec l'editeur de niveau, mais il est quand meme assez dur a utiliser, et je n'ai pas encore fait de doc).
mode7
Et puis 2 autres trucs que j'ai codé pendant les vacances:
tetris, un clone de celui de Mardell, mais plus petit et qui permet de manipuler la piece tout en la deplacant (gestion de plusieurs touches en meme temps quoi), chose qui manquait a la version originale. Par contre, pas de mode 2 joueurs ni de mode B.
minicave, un petit cave-like qui prend moins de 500 octets (source commentee), utile pour ceux qui veulent apprendre l'asm.
Plus de détails dans les readme
voila, bon jeu

edit par Ximoon: liens fixés

J'oubliais: pas de version ti92plus ni v200 pour l'instant, mais il y a peut etre une chance que ca tourne sous titanium.

Sympa, je teste tout ça

Les liens sont incorrects
Par ailleurs, c'est du .rar d'après ce que je vois... Tu ne veux pas faire du zip ou du bz2 ?

Sympathique
Pour le mode 7, je te l'avais déjà dit, mais c'est dommage qu'on ne voie pas très loin devant soi, ça nuit à la jouabilité.

Sinon, pour info, tes jeux ne tourneront pas sur titanium, à cause de la façon dont tu détournes les interruptions (en utilisant le ghost_space [qui n'existe pas sur titanium]).

Ok merci, je vais corriger pour que ca tourne sous Titanium.
Pour la visibilité, je pense pas pouvoir faire mieux :/ Pour palier a ca, je pensais faire apparaitre une fleche a l'ecran pour pouvoir anticiper le virage, je verrais pour les prochaines versions

Allez, j'ai fait quelques screenshots :
Tetris :

Minicave :

Mode 7:


Encore bravo à Nerick, surtout que tout est codé en ASM pur.

Pour que tes redirections d'interruptions fonctionnent sur titanium, il faut désactiver la protection de la mémoire basse, je crois qu'il faut faire un bclr.b #2,$600001 (puis un bset après), mais je ne suis pas sûr des valeurs.

Oui voila, c'est a ca que je pensais
je re-uploade le tout

Salut, c'est du bon boulot ! C'est fluide et net cependant tu pourrais peut être augmenter la visibilité au loin en zappant des lignes de pixels devant (car tu ne peut pas augmenter la resolution je suppose pour garder des fps), tu perdrais en netteté mais ca serait plus agréable
On a critiqué mon f-zero sur la visibilité au loin et pourtant je dois "voir" 2 ou 3 fois plus loin que ton mode7 (je peux aller encore plus loin mais ca devient vraiment degueu pour les yeux, déja que je n'ai pas un resolution aussi grande que toi).

J'ai des questions :
1) Quelle est la résolution exacte du rendu ?
2) Est-ce que tu gèrera des sprites externes (concurrents) ?
3) Je ne m'y connais pas vraiment en asm mais j'ai essayé de regarder le code de ton mode7 (j'ai rien compris d'ailleurs) et je crois que toutes les operations sont codées en dur et que tu ne peux pas trop paramétrer la resolution ni l'angle de vue (je pense) donc ca risque d'être dur de changer pour que l'on voit plus loin. (ah merde c'était pas une question ca !)

Sinon c'est vraiment pas mal surtout que tout est en asm

PS : J'ai testé que le mode7, pas les autres jeux

1) 80x50
2) oui, mais ce n'est pas ma priorite pour l'instant.
3) effectivement la resolution est fixe (et mon format de donnee impose qu'elle le soit), mais tu peux modifier les differents parametres de la camera en triturant les constantes de mode7.h. Mais les valeurs sont choisies pour que la portion de map affichee puisse etre vue le + loin possible, et si tu essayes par exemple de remonter la camera, l'affichage bugera a l'horizon puisque le moteur tentera de faire le rendu d'une portion de la map qui n'a meme pas encore ete calculé. Le rendu se fait un peu a la maniere du TileMap engine de Sasume apres tout: Une portion du circuit (un peu plus grande que ce qui devra etre vu a l'ecran pour une frame donnee) est d'abord grossierement précalculée, puis le rendu de cette portion est effectuee jusqu'a ce que la camera aie parourue 32 unites de deplacement, auquel cas on recalcule une nouvelle portion de map. Je pourrais tres bien augmenter la taille de la portion précalculée pour le rendu (pour pouvoir augmenter la visibilité a l'horizon donc), mais je n'ai pas assez de Ram pour le faire.

Ouais moi pour la map en fait je charge tous les tiles que j'ai besoin une seule fois et la carte est en fait un tableau de pointeurs sur les tiles correspondant donc je peut voir toute la carte d'un coup.
Je ne comprend pas pourquoi tu n'as pas assez de ram car moi ce qui prend de la place c'est que je charge les tiles en prenant un char pour un pixel dans un plan (comme ça j'ai pas de masque a faire pour recupere l'information) et donc ca multiplie par huit la taille des tiles, sinon mon moteur seul ne prend pas plus de 15ko (je pense).
Tu ne pourrais pas faire comme ça pour y voir plus loin ?

Superbe
Je viens que de temps en temps mais c'ets le seul que je trouve vraiment super bien fait et tres original.
Pour être honnete je ne pense pas que je suis capable d'en faire autant...
Vraiment Bravo!

Pour pouvoir gérer des maps enormes commes les circuits de mario kart sur snes qui font 128x128 tiles, je suis obligé de procéder comme je le fais, en calculant la map par petits morceaux pendant le rendu. Chaque morceau doit pouvoir tenir dans un buffer prévu pour 256 pixels en largeur (ce qui m'économise quelques cyles par pixels dans la fonction mode7_display), donc la visibilité dépend finalement de la hauteur du buffer en nombre de pixels. Elle doit etre multiple de 32, donc 224 est la plus grande valeur possible pour que je puisse allouer le buffer (1 pixel en niveau de gris occupe 1 octet, on doit donc allouer 256x224 = 57344 octets). J'avais pensé a utiliser un hack pour pouvoir allouer + de 64ko, mais pour que la visibilité soit vraiment plus gande, il faudrait en fait beaucoup plus que 224 pixels, et je n'ai au final as assez de ram (j'utilise aussi beaucoup de ram pour decompresser le circuit, et précalculer le nécessaire pour que le rendu soit rapide).

Ok alors , c'est vraiment trop gore de pouvoir augmenter la vision...
Dommage mais ça reste excellent quand même!

Il y a surement une méthode a laquelle je n'ai pas pensé pour cette histoire de visibilité, puisque le mode 7 de Pollux n'a pas ce probleme. Mais je crois que son algo de rendu est sensiblement différent du mien, il faudrait que je regarde ses sources plus en détail.

L'algo de rendu est tt ce qu'il y a de plus bateau, je pense... (y a pas 36000 façons de faire)
En gros, ce que je faisais jusqu'à maintenant était d'avoir une map de groupes de tiles 8x8pix (la map au total fait 512x512 tiles pour l'instant), que je rends dans un buffer intermédiaire de l'ordre de 64x64, et après le traitement se fait à peu près comme celui de lionelA j'imagine... (bête tableau de pointeurs vers des tiles)
Mais bon, là le problème que je rencontre, c'est que j'ai 60000 cycles de copie à chaque frame, et ça commence à devenir plus du tout négligeable depuis que j'ai rajouté le zoom (le rendu mode7 lui-même fait dans les 200k cycles pour du 64x32, i.e. ça pourrait tourner à plus de 40 fps), donc il faudrait que je répartisse la copie sur plusieurs frames (et donc que je fasse du double-buffering pour le buffer de tiles ), mais bon #flemme#

Dechire le mode 7, tu pense mettre des enemies?

lionelA
: 2) Est-ce que tu gèrera des sprites externes (concurrents) ?

Nerick
: 2) oui, mais ce n'est pas ma priorite pour l'instant.

Lis le topic avant de poster. Il fait une page seulement...

si vous trouvez des bugs dans tetris ou minicave n'hesitez pas a les reporter dans ce topic (ils seront releases en version finale d'ici la fin de la semaine et je n'y toucherai plus apres)
Autre chose, quelqu'un pourrait m'expliquer les warnings du linker que j'obtiens systematiquement a la compilation de mode7, meme avec la derniere version de Tigcc? ("Impossible section arrangement rejeted at recursion depth 2/3/5/6/7/8")
sinon Kevin, les addressages du type x-y(an) avec x et y des labels exportes depuis un autre .o provoquent une "Relocatability error" (ou alors je m'y prend mal).

Pour le warning, je pense que tigcc doit tenter de réarranger les sections pour gagner quelques octets sur les branchements et que dans ton cas ça échoue. En décochant "reorder sections" dans les options du projet ça ne devrait plus le faire si mon hypothèse est la bonne.

voila c'etait bien ça merci

Nerick
: Autre chose, quelqu'un pourrait m'expliquer les warnings du linker que j'obtiens systematiquement a la compilation de mode7, meme avec la derniere version de Tigcc? ("Impossible section arrangement rejeted at recursion depth 2/3/5/6/7/8")

Il ne faut pas coder des branchements courts d'un fichier objet à un autre, et si ton programme fait plus de 32 KO, pas de références PC-relatives d'un fichier objet à un autre non plus, il faut laisser le linker optimiser là où c'est possible. Il y a des chances que --reorder-section ait trouvé une possibilité d'optimisation meilleure que celle que tu as faite s'il veut faire cet arrangement-là. Mais tu peux en effet désactiver le reordering des sections si tu es si sûr que ça que ton arrangement est optimal.

sinon Kevin, les addressages du type x-y(an) avec x et y des labels exportes depuis un autre .o provoquent une "Relocatability error" (ou alors je m'y prend mal).

C'est normal. Il n'y a pas de références négatives vers dessymboles externes dans le format AmigaOS de A68k. Utilise GNU as, il peut représenter ça.

versions finales de cave/tetris pour 89/89ti/92+/v200:
minicave_v1.0.zip
tetris_v1.0.zip
version 0.3 de mkart pour 89/89ti/92+/v200:
mkart_v0.3.zip
les details sont dans les readme.

Bon Nerick pour plus que tu soit degouter de la vie, je reply sur ton topic.
Mais alors seulement pour te faire plaisir.

v essayer tout ca

mkart n'a po l'air de fonctionner
sniff...

yop FlashZ

mkart n'a po l'air de fonctionner

tu as quelle calc?

Alors la nerick tu me decois.
Quand on t'envois un binaire, ce n'est pas pour que tu le desassembles pour ensuite pretendre l'avoir ecrit.
Faire un tuto en sous entendent que les idées viennent de toi, me font pensé que tu ne dois pas en avoir.
Reprendre les algos en remplacant deux add.w dx,dx par un lsl.w #2,dx n'est pas une grande inovation(gain 0), j'avais laissé ca en pensant qu'avec un pipeline ce serais plus rapide.
Mais ta version date, et il est possible d'augmenter la visibilité et la rapidité du moteur.
Ne prends pas le travail des autres, je n'ai pas lu dans ton read me,d'apres le moteur d'alexis benoit ou plagia du moteur d'alexis.
Tu me donnes envie de le finir rapidement, pour te montrer ce que l'on peu réellement faire.
Tu pompes meme tout le format du buffer et des sprites pour lesquels j'avais longtemps travaillé.
Jamais tu ne cites tes sources, trouve toi un proj, ne t'appropries pas le travail des autres.