Venus Encore un shoot'em up ^^ - Page 1

Oui... Je sais bien que c'est pas original, y'en a déjà plein, mais j'en avais jamais codé, et comme ces quelques derniers jours j'avais pas grand chose à faire bah... Voilà



Vous remarquerez surement des points communs avec Platinum, c'est normal : pour moi c'est le shoot ultime sur Ti, donc j'ai essayé de m'en approcher le plus possible, même si c'est pas évident (vraiment, grand coup de chapeau à PatrickD, le gameplay de son jeu est excellent).

Coté features, le jeu est en niveaux de gris, y'a 40 armes (10 qui ont chacune 4 puissances de feu différentes), 3 upgrades pour le vaisseau (elles aussi avec 4 niveaux), le reste vous le verrez en jouant. L'éditeur de niveau (on-PC) est inclus, j'ai pas eu le temps de faire la doc, ça viendra (mais y'a moyen d'ouvrir le niveau de démo pour voir comment il est fait).
Attention, ce n'est qu'une beta, donc par exemple il est impossible d'avoir plusieurs niveaux sur la Ti : seul celui qui s'appelle "vnslevel" sera lancé (vous pouvez toujours en avoir plusieurs et les renommer au moment de jouer, ça ne pose pas de pb avec les sauvegardes). De plus, c'est Ti89-only pour le moment (désolé).

C'est aussi la 1ere fois que je distribue quelque chose sous license GPL, fallait bien que je tente au moins une fois ^^ Les sources du jeu et de l'éditeur sont dans le zip.

Dernière chose : ce n'est un petit jeu, et qui plus est réalisé en quelques jours. J'ai fait la release sur 3l33t y'a pas longtemps, donc il reste très probablement des bugs. Comme je m'en vais demain, je ne pourrais pas les corriger avant une semaine. Au pire, vous pouvez toujours recompiler le prog, mais si quelqun le fait envoyez moi les infos par mail si possible

Vala je pense que c'est à peu près tout... Ah si, le lien peut-être ?

[edit] Mis à jour les liens
Télecharger - Site

Tu commences à te faire une archive de jeux vraiment pas mal, quand même. Ce que j'aime bien c'est que les graphismes/interfaces sont toujours très bien fignolés, et ça fait plaisir Et le gameplay est agrèable, toujours rapide. Irais-je jusqu'à faire par ces constatations une comparaison avec FlashZ ? Pourquoi pas ?

Merci

Pour la comparaison avec FlashZ, il reste et restera encore probablement un moment, au-dessus de tout ce que je pourrais faire. Mais ça fait quand même plaisir, surtout venant de toi. Sincèrement

(à ds qq jours tlm ^^)

La diff c'est que FZ programmait en asm et faisait ses propres routines graphiques.. la diff est loin d'etre négligeable...

Ouaip, bravo Vertyos, surtout si "ce n'est un petit jeu, et qui plus est réalisé en quelques jours."
Vraiment bravo.

Euh... En recompilant le jeu avec Ti-GCC v.95 bêta 12, à la fin de la décompression sur Ti-89 AMS 2.09 (VTI), au lieu d'un beau menu Venus, il y a un pas beau "Protected memory violation" d'AMS qui se pointe... Et la calculatrice ne répond plus.

Enfin, la version compilée distribuée est impec

J'ai le même problème (avec TIGCC 0.95 b1).
Çe ne vient pas de la routine de traçage de ligne cette fois, je pense (j'ai recompilé avec la tienne et ça fait pareil).

Au fait pourquoi ne pas utiliser extgraphlib.a? si ya bien un truc qui m'enerve c'est la maniere d'inclure des lib comme ca:', ca me rappelle le temps du mode kernel ou ceux qui programmaient faisait des copier/coller des fonctions de graphlib etc... Comment fait on si il y a une modif de extgraphlib pour faire marcher ton jeu (en admettant que la modif soit essentiel pour un nouvel HW.).

Au fait ya quand meme des trucs qui me choquent:

unsigned short Even(unsigned short i)
{
	if (i & 1)
		return (i + 1);

	return i;
}

ca s'optimise:
#define Event(i) ((((i)+1)>>2)*2)
qui devrai donner en asm:
addq #1,d0;
lsr.w #1,d0;
add.w d0,d0; // le *2 c'est parce que je ne suis pas sur que tigcc optimise le <<1 en add dx,dx.

Je crois que ce genre de détail n'est pas franchement important...
Je doute que le fps augmente sensiblement avec ton optimisation.
Je pense que Vertyos avait juste envie de programmer un shoot'em up, sans essayer d'optimiser toutes ses lignes de C.

Excellent shoot em up pour le temps passé à le prog.

JM_
: Euh... En recompilant le jeu avec Ti-GCC v.95 bêta 12, à la fin de la décompression sur Ti-89 AMS 2.09 (VTI), au lieu d'un beau menu Venus, il y a un pas beau "Protected memory violation" d'AMS qui se pointe... Et la calculatrice ne répond plus.

Sasume
: J'ai le même problème (avec TIGCC 0.95 b1).

Et moi avec la Beta 13. (Avec les anciennes, ce serait encore normal, mais avec la Beta 13? Il y a visiblement un problème quelque part.)

JackosKing VNR :
Au fait pourquoi ne pas utiliser extgraphlib.a? si ya bien un truc qui m'enerve c'est la maniere d'inclure des lib comme ca:', ca me rappelle le temps du mode kernel ou ceux qui programmaient faisait des copier/coller des fonctions de graphlib etc... Comment fait on si il y a une modif de extgraphlib pour faire marcher ton jeu (en admettant que la modif soit essentiel pour un nouvel HW.).

On refait le copier-coller.

C'est quand même plus simple d'inclure extgraph.a au projet, non ?

Il y a des problèmes avec le pointeur world. La "Protected Memory Violation" est due à un pointeur world non valide. Je ne sais pas exactement d'où vient le problème.

À mon avis, au moins une des fonctions en assembleur (dans ExtGraph.c ou Factory.a) détruit des registres qu'elle n'a pas le droit de détruire.

Mais comment expliquer que la version compilée distribuée n'amène pas ce plantage ?

JackosKing VNR
: add.w d0,d0; // le *2 c'est parce que je ne suis pas sur que tigcc optimise le <<1 en add dx,dx.

TIGCC génère un and.w #32766,%d0

Ben, il fait la bonne chose! Il a optimisé votre séquence de 6 octets en une de 4 octets, ce que vous lui avez demandé (-Os).

EDIT: Euh, non, les 2 font 4 octets. Je vais voir ce qui se passe exactement...

Je voulais dire à la place du dernier add, les 2 autres instructions sont aussi gardées, et quelque soit le niveau de -O.

GCC fait la bonne chose.
lsr.w #1,%dn;lsl.w #1,%dn -> 4 octets, 16 cycles
lsr.w #1,%dn;add.w %dn,%dn -> 4 octets, 12 cycles
andi.w #-2,%dn -> 4 octets, 8 cycles

Au temps pour moi, c'est >>1 et pas >>2 dans la séquence de JackosKing VNR

Oui, sa séquence est mauvaise.

Vertyos
: Pour la comparaison avec FlashZ, il reste et restera encore probablement un moment, au-dessus de tout ce que je pourrais faire.

Bah Ti-Cave 2 est au moins aussi bien classé dans mes jeux préférés que l'est Ti-Pang. C'est à dire deuxième ex-aequo, juste derrière Platinum

ouai je me suis votré, mais l'idée etait là

On refait le copier-coller.

>> trop pratique.. c quoi l'avantage? ca optimise les sauts? je pense pas ... et puis bon si c pour ca ya quand meme d'autres optimisations avant de faire celle là.
D'ailleur tigcc optimise les sauts entre plusieurs *.c? ou il faut toujours mettre le code dans les .h a la barbar?

JackosKing VNR :
D'ailleur tigcc optimise les sauts entre plusieurs *.c?

Oui, le linker les optimise.

donc tigcc optimise aussi les sauts pour les *.a

Oui, à condition que le .a a été compilé en mode all-relocs (donc avec TIGCC 0.95, et en cas de compilation par étapes (tigcc -c), en passant aussi --optimize-code --cut-ranges à tigcc -c).

JM_ #5 / Sasume #6 / Kevin #11, #13, #14 > En effet, il semble y avoir un problème, et il a l'air d'être dans Factory. Je regarderais d'où ça peut venir, par chance la version compilée a l'air de ne pas avoir de problèmes.

JackosKing #7 > Si on veut changer, on copie-colle, j'ai pas trop envie d'inclure extgraph pour 3 fonctions et demie, et je ne pense pas que ça soit un travail insurmontable de les modifier. D'autant plus que, comme tu as pu le voir, je croyais qu'il y avait un problème dans le tracé de ligne d'Extgraph (ce qui n'est finalement pas le cas), donc j'ai pu temporairement remplacer facilement.

JackosKing #8 > Mouais... Bon bah tu peux te recompiler ta propre version qui devrait gagner au moins 10 fps grâce à cette optimisation

JM_ #5, Pim89 #10, Moumou #22 > Mici

Un copier coller est plus long qu'inserer un *.a (qui ne sera pas recompilé a chaque modification du *.h de tes prototypes).