Forum TI-Planet.org

Un nouveau venu dans la communauté TI-68k, Ralf "rwill" Willenbacher, présente aujourd'hui un nouveau moteur FPS, nommé Delsgolf.
Outre le fait que les projets TI-68k sont rares de nos jours, une autre bonne raison de faire connaître ce programme à un plus large public est que contrairement à la plupart des moteurs FPS sur TI-Z80 et TI-68k, ce moteur gère une caméra à hauteur variable
La caméra à hauteur fixe simplifie et donc accélère certains calculs. La caméra à hauteur variable, par nature, offre quelques variantes de scénario par rapport à la large enveloppe déjà accessible avec les excellents jeux basés sur (entre autres) le FAT-Engine de TICT, par exemple ceux d'AaroneusTheGreat.

Le moteur est utilisé comme base d'un jeu tout à fait jouable où il y a des couloirs, des ennemis, deux armes, des trousses de médicaments, des caisses de munitions, plusieurs niveaux de difficulté... bref, les principaux ingrédients attendus dans tout jeu de ce genre



Signalons que:
* c'est le premier jeu pour calculatrice de rwill (bien qu'il possède une certaine expérience de la programmation en général, comme le montre le code source qu'il fournit)... et que c'est une excellente entrée en matière
* rwill cherche pour l'instant à limiter la taille du programme à 24 KB, de manière à ce que le programme ne nécessite, sur AMS versions 2.04 et ultérieures, aucun des nombreux contournements de la restriction artificielle stupide mise par TI sur la taille des programmes ASM. Très peu de gens font ce choix, surtout de nos jours, car l'utilisation de tels contournements (PreOS, KerNO, SuperStart, tiosmod+amspatch, etc.) est extrêmement répandue en pratique. Ceci dit, tant qu'elle n'interfère pas avec l'ajout de fonctionnalités, passe encore pour un tel effort.

Encourageons-le à poursuivre ses travaux, même s'il est très occupé, car je pense que c'est mérité
D'ailleurs, même s'il n'insiste pas sur cet aspect dans le README - il y a peut-être une raison - le fait est que le code source comporte une partie éditeur et une partie convertisseur de textures, à compiler soi-même (pour Windows, avec GCC, sous MinGW ou Cygwin, une des deux parties nécessite GTK+). La création de niveaux par des tiers serait théoriquement possible. Je n'ai pas écrit "est facile", je n'ai simplement pas essayé ^^
Le code source est sous licence permissive (mais peu protectrice) BSD 2 clauses.

Téléchargement: archives_voir.php?id=23307
Source de l'info: http://www.ticalc.org/archives/news/art ... 48434.html
(vu que c'est une news page principale sur ticalc.org, s'il y a un vote pour le POTY en catégorie TI-68k cette année, Delsgolf devrait en faire partie)

Genial ca c'est une news enorme !!!!!! zpres en raycasting pour en avoir fait, faire varier la hauteur de la camera n'est pas compliqué du tout.... le plus dure c'est de faire pencher la camera selon un angle ! je pense que c'est ce qu'il a fait !

Alors là ... Quelle performance ! Manque plus qu'un émulateur 68k sur Nspire pour que je puisse le tester, et ça va être génial !
En tout cas, un de mes amis en est tombé fan !

C'est vraiment génial comme concept. Mais ça donne vraiment envie de le faire sur nspire

Si j'ai bien compris, c'est de l'asm, alors :
- L'asm 68k est-il beaucoup plus rapide que le Lua sur Nspire ?
- Est-ce que c'est des images pour les graphismes ? Si oui, sous quelle forme est le format d'image en ASM 68 k ?
- Est-ce que c'est possible de faire un moteur Raycasting en Lua ?

Antox :
-Je pense que l'ams 68k est plus rapide que le lua mais je peux pas etre sur...
-les graphisme sont des prite afficher en raycasting je peux t'expliquer comment ca ùarche sir tu veux (chat ti planet)
-possible mais tres lourd a faire, il vaut mieux faire directe un moteur 3D

Le code natif sur TI-68k va être nettement plus rapide que le Lua sur Nspire pour un raycaster, oui. Le FAT-Engine peut tourner jusqu'aux environs de 10-12 FPS avec son scaler code natif généré / optimisé. D'une manière générale, les langages interprétés sont souvent 10 à 1000 fois plus lents que le code natif.

En Million Instructions Per Second, le 68000 à 12 MHz est en-dessous de 3 MIPS (les instructions prennent au moins 4 clocks) alors que l'ARM926EJ-S à 150 MHz est entre 75 et 150 MIPS (les instructions prennent habituellement 1 ou 2 clocks). Certaines instructions de l'ARM9 sont moins puissantes, donc il faut plus d'instructions pour faire la même chose - mais d'autres instructions se passent bien sur ARM (shifts et rotates généralisés, par exemple). Bref, une estimation précise de la puissance comparée est un vrai bazar - mais le scaling du FAT-Engine n'est pas possible en Lua à ce framerate-là, oh non.

Certains des tutorials S1Px et S2Px sur http://tict.ticalc.org (écrits par Thomas Nussbaumer, pas par moi, comme le FAT-Engine qui en est dérivé) sont excellents pour l'explication du raycasting.

Bon, je me disais bien aussi
Sinon, en C/C++ c'est plus ou moins rapide ?

Dn fait, il n'y a pas de C++ sur TI-68k, même si on peut largement en faire sur 68000. C'est pour 68000 qu'une version plus ancienne de bFLT a été faite.
Un bon code ASM sera toujours plus rapide qu'un code C - mais moins portable, moins réutilisable, moins maintenable, plus lent à écrire et à debugger, etc. (en génie logiciel: l'optimisation entre en conflit avec nombre d'autres axes de maintenabilité)
FAT-Engine et Delsgolf sont tous les deux des hybrides: le gros du code est en C (pour la facilité d'écriture / maintenabilité / etc.) mais certaines parties critiques en vitesse sont en ASM, selon la règle du pouce des 80/20 (dans la grande majorité des programmes, 70 à 90% du temps est passé dans 30 à 10% du programme).

Si matref a réussi à porter un moteur raycasting en C sur nspire, c'est donc possible de porter de tels jeux ?

AnToX98 a écrit:Si matref a réussi à porter un moteur raycasting en C sur nspire, c'est donc possible de porter de tels jeux ?

Oui, comme nDoom