1

-

2

donc j'envoi ça a SetScreen avec -1 et -1 en parametre pour logic screen, et phys screen, comme ça le Xbios me les malloc tout seul

-1 a pour effet de garder la valeur courante. C'est 0 (zéro) qu'il faut utiliser pour forcer une réallocation. Bizarre, c'est pas précisé dans le Compendium pour la valeur zéro.

Pour le Pexec() et autres fonctions, il faut que ton programme ait libéré la RAM qui lui a été allouée, et dont une partie ne sert pas (utiliser Mshrink). Ya un petit exemple sur le wikipendium à stabylo (fo bien qu'il serve), 2e cadre:
http://removers.free.fr/wikipendium/wakka.php?wiki=BASEPAGE
Web: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

3

-

4

Fait juste attention car certaines configs sont impossibles (Pas de mode overscan en VGA, etc...)


GT Turbo octopus
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

5

Orion: pour être déjà passé par là il y a quelques années, je te conseille d'éviter d'utiliser les fonctions systèmes pour configurer tes modes vidéos. Tu verras sur la page de pmandin (voir sa signature) que certains "extendeur" de résolution comme la Screen Blaster ou la Blow Up ne réagissent plus quand tu veux changer de résol par les appels systèmes.
Essayes la lib DHS qui gère tout le hardware bien comme il faut et tout et tout : Voir sur la page http://dhs.nu/files_source.php dans "Misc sources and routines".
Codeur retraité coulant des jours paisibles...

Je raconte ma vie: http://blog.frosties.org/

6

-

7

Ah, pour le GEM il me semble qu'il vaut mieux éviter de changer de résol..
Codeur retraité coulant des jours paisibles...

Je raconte ma vie: http://blog.frosties.org/

8

En faisant le ménaches dans mes marques-ta-page, je suis retombé sur la page de WinDom.. Cette lib devrait t'intéresser wink
Codeur retraité coulant des jours paisibles...

Je raconte ma vie: http://blog.frosties.org/

9

frost :
Orion: pour être déjà passé par là il y a quelques années, je te conseille d'éviter d'utiliser les fonctions systèmes pour configurer tes modes vidéos. Tu verras sur la page de pmandin (voir sa signature) que certains "extendeur" de résolution comme la Screen Blaster ou la Blow Up ne réagissent plus quand tu veux changer de résol par les appels systèmes.

Justement, si les extenseurs désactivent certaines fonctions Xbios, ils ont en général leurs propres fonctions pour changer de mode vidéo, mais c'est tellement bien documenté que le désassemblage semble la seule solution (ce que j'ai fait pour la plupart avec ttdigger).
frost :
Essayes la lib DHS qui gère tout le hardware bien comme il faut et tout et tout : Voir sur la page http://dhs.nu/files_source.php dans "Misc sources and routines".

J'espère que tu ne parles pas de 'screenpain', tant vanté par certains sur les forums de dhs, le meilleur moyen d'avoir un mode video qui ne marche que sur le moniteur du codeur.
Web: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

10

Ah, y en a pas bon screenpain ?
Codeur retraité coulant des jours paisibles...

Je raconte ma vie: http://blog.frosties.org/

11

pmandin :
J'espère que tu ne parles pas de 'screenpain', tant vanté par certains sur les forums de dhs, le meilleur moyen d'avoir un mode video qui ne marche que sur le moniteur du codeur.


Pas tout a fait d'accord avec toi Patrice, car pour l'invitro de la JC2005 ( http://pouet.net/prod.php?which=16440 ), je l'ai utilisé pour les résols Falcon (Vga et RGB), pour l'instant personne ne m'a annoncé de soucis de compatibilité.


GT octopus
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

12

Euh, tu utilises screenpain juste pour initialiser un mode 320x200x16 couleurs? La fonction Setscreen(..,..,0) fait ca très bien depuis le ST.
Web: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

13

pmandin :
Euh, tu utilises screenpain juste pour initialiser un mode 320x200x16 couleurs? La fonction Setscreen(..,..,0) fait ca très bien depuis le ST.


Sincerement c'était une démo, et les trap ca me saoule, soit c'est 100% a la barbare (Demo, jeu) soit 100% propre Gem only.

Oui c'est un 320*200 en 16 couleurs, mais cette init me permet aussi en 'settant' un flag d'avoir un écran de 320*240 sur Falcon en mode normal et utiliser sur un ST, un overscan est automatiquement mis en place, voila pourquoi.


GT octopus
avatar
je sais pas depuis que Fadest nous mets de la zik partout dans ses jeux l'univers a été ebranlé (LordKraken)

14

ah, Setscreen() ! mon sujet de prédilection! magic
Orion_ :
merci pour pexec ça marche smile (enfin en multitos ça marche pas mais bon, je pense que ça doit etre compliqué a ce niveau ^^)
Au besoin, Pexec() est documenté là (avec les modes multitos) : http://removers.free.fr/wikipendium/wakka.php?wiki=Pexec() et si jamais il y a des choses qui marchent pas comme documenté, on peut mettre à jour la doc. pencil
Orion_ :
par contre pour l'ecran, j'ai remarqué que Vsetmode avec -1, me renvoyais -1 dans d0
attention Si jamais tu as NVDI 3, procure-toi un v4 ou une v5 smile La réallocation de la mémoire écran (paramètres d'adresse à 0), et de manière générale tout ce qui touche aux changements de résolution, marchent très mal avec la v3.
Orion_ :
ça me fait une erreur de bus, j'ai 2 puis 4 bombes :/
Avec NVDI, il faut que tu désactive l'affichage de la souris. Si t'es en GFA, fais un HIDEMOUSE (orthographe approximative). Explication : les paramètres de taille d'écran (ceux utilisés pour le clipping de la souris) sont correctement mis à jour avec Setscreen() sous TOS seul, mais pas quand NVDI est là (probablement un oubli dans NVDI). Résultat : l'affichage de la souris peut se faire en dehors de la mémoire écran, et comme cette dernière est tout à la fin de la mémoire du Falcon, le sprite de la souris peut atterrir en dehors de la mémoire, c'est des bombes assurées. fou3
pmandin :
Justement, si les extenseurs désactivent certaines fonctions Xbios, ils ont en général leurs propres fonctions pour changer de mode vidéo, mais c'est tellement bien documenté que le désassemblage semble la seule solution (ce que j'ai fait pour la plupart avec ttdigger).
Les extenseurs (Videl Inside, Centscreen, Videlity) c'est un peu un sujet en soi. livre Avec eux, il faut distinguer 2 besoins différents : leur demander de passer dans une résolutions qu'ils ont dans leur boîte à malice pour s'en servir dans ton appli, ou simplement avoir une résolution étendue en général pour bosser pénard et avoir besoin de passer dans un autre mode dans ton appli.

Le premier cas (dont patrice parle ci-dessus) dépend pas mal des réglages que chacun a fait dans son extenseur d'écran, donc c'est rigolo pour un petit truc que tu te fais pour toi, mais ça marchera pas forcément chez tout le monde ; pour le second cas, l'essentiel est de savoir que l'extenseur "détourne" généralement une seule des configs vidéo du Falcon tandis que toutes les autres fonctionnent comme sans extenseur.

Si on prend l'exemple de Videl Inside, chez moi ça donne un truc comme ça : "quand le mode 640x480x16 est demandé, alors l'extenseur prend la main pour mettre du 800x600x16, et quand n'importe quel autre mode est demandé, l'extenseur laisse faire sans intervenir". Donc si mon appli demande du 320x200x64k, elle aura bien ce qu'elle veut, et quand elle revient à ce qui lui semble être du 640x480x16, l'extenseur prend la main pour placer son 800x600x16.

Stabylo tout fou avec Setscreen() fou2 (n'hésitez pas à me signaler si je dis des bêtises!)
Stabylo/The Removers
http://removers.atari.org/

15

Boaf, moi, en dehors de mon 538*241*8bits de prédilection, de suis perdu. Surtout dans mes routines graphiques... Vive le 8 plans sur Atari !

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

16

stabylo
:
Orion_ :
ça me fait une erreur de bus, j'ai 2 puis 4 bombes :/
Avec NVDI, il faut que tu désactive l'affichage de la souris. Si t'es en GFA, fais un HIDEMOUSE (orthographe approximative). Explication : les paramètres de taille d'écran (ceux utilisés pour le clipping de la souris) sont correctement mis à jour avec Setscreen() sous TOS seul, mais pas quand NVDI est là (probablement un oubli dans NVDI). Résultat : l'affichage de la souris peut se faire en dehors de la mémoire écran, et comme cette dernière est tout à la fin de la mémoire du Falcon, le sprite de la souris peut atterrir en dehors de la mémoire, c'est des bombes assurées.

C'est pour cela qu'avec Setscreen(), il vaut mieux ne pas changer l'adresse de l'écran logique (où sont faits les dessins de la VDI, donc du GEM et la souris), et ne changer que l'adresse de l'écran physique, qui est la partie de la ram vidéo affichée par la puce vidéo, et dont on a donc besoin pour faire une démo/jeu.

Pour ce qui est des extenseurs d'écrans, toute aide est la bienvenue pour les documenter, pour pouvoir les utiliser proprement, ou au moins avoir des programmes qui ne plantent pas quand ils sont utilisés.
Web: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

17

je me disais bien que Stabylo craquerait en voyant un tel sujet boing

Seb

18

lol (et je savais bien ce que tu allais te dire en voyant ma réponse!) rotfl
Stabylo/The Removers
http://removers.atari.org/

19

pmandin :
Ya un petit exemple sur le wikipendium à stabylo (fo bien qu'il serve)
Ben oui, t'as bien raison Patrice wink
pmandin :
Bizarre, c'est pas précisé dans le Compendium pour la valeur zéro.
Sisi smile c'est dit comme ça :
If either log or phys is NULL, the XBIOS will allocate a new block of memory large enough for the current screen and reset the parameter accordingly.


Suite à mon post, je peux compléter quelques petits trucs:
stabylo :
Avec NVDI, il faut que tu désactive l'affichage de la souris.
Le HIDEMOUSE du GFA utilise la Line A ce qui est en dehors des bonnes pratiques. Pour ne pas utiliser le HIDEMOUSE de la Line A, il y a d'une part v_rmcur() (et son opposé v_dspcur()) disponible dans la VDI pour cacher le curseur, et encore mieux adapté à ton besoin de changement de résolution, il y a v_enter_cur() pour entrer en mode sans souris et son copain v_exit_cur() pour y revenir.

Et pour finir, j'ai documenté Setscreen() et compagnie dans WikiPendium, sachant que l'extention (avec le mode 3) s'appelle VsetScreen() : http://removers.free.fr/wikipendium/wakka.php?wiki=VsetScreen()

(bonne lecturesmile)
Stabylo/The Removers
http://removers.atari.org/

20

stabylo :
et encore mieux adapté à ton besoin de changement de résolution, il y a v_enter_cur() pour entrer en mode sans souris et son copain v_exit_cur() pour y revenir.


Et ya meme pas besoin d'appeler ces fonctions si tu renomme ton executable en .tos ou .ttp, puisque c'est le bureau qui s'en chargera.

D'ailleurs ca m'étonne que les gens nomment leurs exécutables en .prg alors que ce ne sont pas des applications gem (bon c'est le réglage par défaut des compilateurs ou assembleurs).
Web: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

21

pmandin :
Et ya meme pas besoin d'appeler ces fonctions si tu renomme ton executable en .tos ou .ttp, puisque c'est le bureau qui s'en chargera.
C'est à confirmer, mais je crois que pour faire du fullscreen en multitâche, un .TOS ouvrira une fenêtre console TOS et le redraw final ne sera pas fait sur la totalité de l'écran.
Avec un .TOS tu es aussi un peu limité ; il me semble que tu ne peux pas ouvrir une station VDI, passage obligé pour identifier (proprement) une éventuelle carte graphique, non?
Stabylo/The Removers
http://removers.atari.org/

22

stabylo
: C'est à confirmer, mais je crois que pour faire du fullscreen en multitâche, un .TOS ouvrira une fenêtre console TOS et le redraw final ne sera pas fait sur la totalité de l'écran.

Je ne parlais pas d'utilisation dans un OS multitache. Au début la VDI et le GEM tournaient en monotache, et sur PC, où les cartes graphiques ont des modes vidéos séparés pour le texte et le graphisme, d'où ces fonctions dans la VDI pour passer d'un mode à l'autre.
Ce que je voulais dire, c'est qu'un programme qui n'utilise pas l'AES ou la VDI devrait avoir l'extension tos/ttp au lieu de prg/app/gtp, c'est tout.

Avec un .TOS tu es aussi un peu limité ; il me semble que tu ne peux pas ouvrir une station VDI, passage obligé pour identifier (proprement) une éventuelle carte graphique, non?

Il faut vérifier, mais je pense qu'en passant en mode texte, la station VDI utilisée par l'AES doit etre fermée, ainsi que la station physique. Ensuite tu fait ce que tu veux. Mais effectivement, si tu veux faire un prog qui utilise la VDI, bin il faut un prg/app/gtp.
Web: http://pmandin.atari.org/
Programmeur Linux, Atari
Spécialité: Développement, jeux

23

pmandin :
Je ne parlais pas d'utilisation dans un OS multitache.
Exact, c'est juste que j'ai toujours en tête ce que je pourrais améliorer dans ce vieil Animator que j'avais bien du mal à faire fonctionner sous les OS multitâches hehe
Cela dit, cette discussion me fait du bien car ça me plonge dans les docs et j'ai pu découvrir dans l'article v_exit_cur() du Compendium comment gérer le redraw avec form_dial(), chose que je savais pas faire jusqu'ici happy
Il faut vérifier, mais je pense qu'en passant en mode texte, la station VDI utilisée par l'AES doit etre fermée, ainsi que la station physique. Ensuite tu fait ce que tu veux. Mais effectivement, si tu veux faire un prog qui utilise la VDI, bin il faut un prg/app/gtp.
Après un petit tour dans le Compendium, il ne semble pas nécessaire de fermer la workstation. Ils disent que v_enter_cur() sert à préparer le lancement d'un appli TOS.

Mais j'ai quand même dit des bêtises parce qu'avec un .TOS, ça doit juste être l'AES qui n'est pas dispo. Animator est un TTP et ça ne l'empèche pas de (tenter deroll) gérer les cartes graphiques en faisant (avec un cookie EdDI de version suffisante) un graf_handle(), puis un v_opnvwk() pour avoir les infos.

Donc effectivement, quand on change de résolution, on devrait utiliser des extensions TTP et TOS car rien ne l'empèche! wink
Stabylo/The Removers
http://removers.atari.org/

24

TTP ou TOS ont accès à l'AES/VDI, mais seulement sur des stations virtuelles (genre une station destinée à l'impression) mais pas physique (écran) puisque le mode vidéo du TTP/TOS est en texte...

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/

25

Kochise :
TTP ou TOS ont accès à l'AES/VDI, mais seulement sur des stations virtuelles (genre une station destinée à l'impression) mais pas physique (écran) puisque le mode vidéo du TTP/TOS est en texte...
merci pour cette précision David! top et pour compléter, ces programmes ont accès à l'écran, mais c'est un accès "limité" : ils peuvent ouvrir une station virtuelle sur l'écran, mais celle-ci ne leur accorde qu'un accès aux fonctions de l'émulateur VT52 de la VDI.
(il semble aussi qu'on n'ouvre jamais de station physique sur l'écran car ces stations servent juste pour certains drivers GDOS, non?)

Et si un programme TOS ou TTP exécute un v_exit_cur(), je sais pas ce qui se passe... Peut-être que c'est possible et qu'il gagne alors un accès aux fonctions graphiques de la VDI?
Stabylo/The Removers
http://removers.atari.org/

26

Oui, oh, tu sais, j'ai commencé à taper plus sérieusement dans l'ASE/VDI pendant que je programmait SSAVCALL, avant de passer à autre chose (l'IUT essentiellement)... Tout ça, ça date un peu pour mes pauvres neurones smile

Kochise
avatar
Si Dieu m'a de nouveau fait homme, cette fois il m'a pas raté : marcher sur l'eau et dupliquer les pains, ça marche p'us :/