Programmation Falcon Clean pour jeu & demo - Page 1

-

Te fais pas chier, sauve les 32 premiers et derniers KiB à l'init ($0000.w-$7FFF.w et $8000.w-$FFFF) que tu restaureras à la sortie...

Désactive la souris si tu n'en à pas besoin, les routines d'affichage du TOS sont très très lentes...

Kochise

Orion regarde donc tes operations de copie, il y a un petit soucis, le dbra ne marche que sur 16 bits, donc mefie toi. J'ai pas regardé mais je penses pas que le 060 change la donne.


GT En 16 bits !!

Pour la souris, si c'est comme sur ST, tu peux la désactiver proprement avec la fonction Ikbdws du XBIOS.

Orion_ (./1) :
bref pour le moment j'ai ce code la, je voudrais savoir pourquoi ça plante quand j'essaye de remettre le mode vidéo d'origine (ligne Vsetscreen dans FalconExit)

	// Restore Resolution
	VsetMode(FV_screenrez);
	//Vsetscreen(FV_screenadrsL, FV_screenadrsP, SCR_NOCHANGE, SCR_NOCHANGE);
	VsetRGB(0, 256, FV_savepal);
}

Peut-être faut-il ajouter un appel à Vsync après ceux-là. En effet, le système ne change le mode vidéo, les adresses écran, la palette qu'au moment de la VBL suivante. Sinon, bin, c'est que t'a un BUG dans ton code .

-

Orion_ (./6) :
ah, bon ben je vais regarder ça alors.
pour info j'utilise NVDI5 et PicDesk, je sais pas si ça peut jouer

juste pour préciser, faudrait un Vsync genre apres vsetmode ?

Je le mettrais après tous les appels, histoire que tout soit fait en même temps (après ton VsetRGB).

Sinon, il est bien possible que NVDI et/ou PicDesk fassent quelque chose dans ton dos.

La seule subtilité que je connaisse avec NVDI c'est qu'utiliser Setscreen() pour changer les adresses et le mode vidéo simultanément réinitialise la palette, alors je fait un Setscreen() pour les adresses, et un Vsetmode() pour le mode vidéo.

Si j'ai le temps, après l'AC j'écrirais un petit prog d'exemple.

-

Dans ce cas, tu n'as plus qu'à vérifier que le contenu de tes pointeurs, où tu stocke les adresses originelles, n'ont pas été corrompues pendant l'exécution de ton programme.

Orion_ as-tu regardé du côté des routines de DHS ? Ici : http://dhs.nu/files.php?t=democreation
Ils ont écrit des librairies en asm pour gérer les inits/restauration mais aussi la vidéo, le son, etc.
Je sais pas si ça peut être utile ?

-

Euh, tu détournes bien la VBL et le Timer C dans ta lib...

-

Détourner les interruptions, c'est pas assez clean pour toi ?

Orion_ (./13) :
ouiiiiii mais bon, je parlais du videl quoi
en fait je crois que je doit avoir des problèmes de débordement mémoire.
et ensuite il aime pas du tout que je détourne le timerC, car après retour au Tos, le click souris déconne complétement.

Et le clavier part pas en live aussi ?


GT

-

Il vaut mieux taper dans les registres du Videl. Dès lors que tu mets NVDI, voire que tu pousses le vice à ajouter une Screenblaster, VSetMode ne se comporte plus correctement. Autant mettre le système en sommeil le temps de ta démo, et tant pis pour le reste. Garde quand même le Timer C pour les accès disque (me semble que c'est celui-là).
Et sur certaines combinaisons Falcon/écran, tu as aussi un bug hardware auquel il faut faire attention: la double VBL...

Pense aussi à flusher le buffer clavier (en lisant $fffffc00 me semble) pour éviter d'avoir le son d'une touche qui se répète à la sortie.

frost (./17) :
Il vaut mieux taper dans les registres du Videl. Dès lors que tu mets NVDI, voire que tu pousses le vice à ajouter une Screenblaster, VSetMode ne se comporte plus correctement. Autant mettre le système en sommeil le temps de ta démo, et tant pis pour le reste. Garde quand même le Timer C pour les accès disque (me semble que c'est celui-là).
Et sur certaines combinaisons Falcon/écran, tu as aussi un bug hardware auquel il faut faire attention: la double VBL...

Pense aussi à flusher le buffer clavier (en lisant $fffffc00 me semble) pour éviter d'avoir le son d'une touche qui se répète à la sortie.

J'y crois pas un Sector One qui ose parle code !!! Ahah !!

GT a pas pu se retenir

regarde éventuellement dans les sources d'Animator, je crois que Stabylo avait trouvé la façon propre de faire des changements de réso sous Falcon, compatible avec NVDI...

Réutilisant mon falcon depuis qu'il a une CT63 (ca pootre grave !), ca m'intéresserait de faire quelques programmes dessus.
Sachant que j'ai pas forcement énormément de temps et que je veux pouvoir utiliser le 060 :
- qu'est ce qui est le plus simple ? C ou ASM ? (sachant que ca fait 12ans que j'ai pas programmé sur un atari autre que la jag)
- y a-t-il des librairies pour noob ?
- y a-t-il des tutoriaux /exemples ?

Tout dépend ce que tu comptes faire : du direct hardware ? Du Gem ? L'assembleur est bien supporté en général, sauf 68060. Coté C c'est pas la joie, le Coldfire attire tous les espoirs et y'a deux compilos plus ou moins récents, sinon du C optimisé 68060, t'oublies direct. Reservoir Gods avaient libérés leurs routines C super bien faites pour de l'accès direct, tu trouveras tout ça plus un compilo sur DHS...

Kochise

-

Oui ca m'interesse

-

Merci,

Je vais tester ça

Je viens d'essayer, voici mes remarques :

dans l'ordre des événements :
- j'ai utilisé STZip pour de-zipper sur l'atari et j'ai eu un soucis au niveau des fichiers readme : ils ont les noms long avec espace et je me suis retrouvé avec ces 2 fichiers inaccessibles (j'ai pu les renommer avec Mint)
- en changeant les chemins j'ai pu recompiler l'exemple fourni à partir de l'acc. (je suis étonné du temps que ca met pour compiler par contre : assez long alors que je l'ai fait en CT63 )
- quand je lance le prog de demo, il se lance bien, par contre en quittant j'ai la palette du bureau qui part en live : texte gris très foncé sur fond noir donc illisible.


voilà pour mes premiers essais

SCPCD (./26) :
(je suis étonné du temps que ca met pour compiler par contre : assez long alors que je l'ai fait en CT63 )

La compilation c'est le mal, l'assemblage c'est le bien


GT Fanatique de l'asm !!

-

Je suis en VGA 640*480 16couleurs.

Je ne serais pas dire les applications que j'ai de lancé en même temps que NVDI.
Je te dirais ca ce soir.

-