J’aimerais m’y mettre mais j’ai besoin d’aide. - Page 7

Le MAKELIBR.BAT dans le sous-répertoire OBJ génère normalement le .olb à partir des divers .obj (il faut le modifier en fonction des .obj à inclure)

Edit : lance le 1 fois à chaque fois que tu modifies un .obj ou que tu en rajoutes (ou supprimes)

Fadest (./181) :
Le MAKELIBR.BAT dans le sous-répertoire OBJ génère normalement le .olb à partir des divers .obj (il faut le modifier en fonction des .obj à inclure)

Edit : lance le 1 fois à chaque fois que tu modifies un .obj ou que tu en rajoutes (ou supprimes)

bien, j'ai décidé de rajouter un fichier sprite.obj dans le dossier OBJ

del test.olb
libr65 a test.olb fond.obj
libr65 a test.olb sprite.obj
move test.olb ..

MS_DOS, toujours le même message d'erreur:
Impossible de trouver C:\lynx\Projet_1\test\OBJ\test.olb
Et bien sûr, libr65 n'est pas reconnu...

D'ailleurs, je trouve assez curieux de demander d'effacer un fichier (del test.olb) alors qu'il n'existe pas ! Je veux sortir de la quatrième dimension, aaaah !

Pour faire dans l'ordre :

>>D'ailleurs, je trouve assez curieux de demander d'effacer un fichier (del test.olb) alors qu'il n'existe pas
C'est juste au cas ou il existerait, vu qu'il est regénéré en entier (et en mode "libr65 a" pour ajouter, je crois me souvenir que ça plante si on ajoute un fichier qui existe déjà).
Rien n'empêche de faire bien mieux, surtout que ça peut être un peu long à généré quand il y a quelques dizaines ou centaines de sprites mais en général, je fais tout à l'avance et je génère 1 fois (ou je fais plusieurs librairies thématiques mais là, c'était pour faire un truc qui marche au plus vite)

>>Et bien sûr, libr65 n'est pas reconnu...
Il est bien dans ton répertoire c:\lynx\newcc65\bin
Vu qu'il n'y a pas de set PATH dans MAKELIBR, MS-DOS ne sait pas ou trouver LIBR65
3 solutions :
- la hardcore, copier LIBR65 dans le répertoire OBJ
- la soft : ajouter le set PATH dans MAKELIBR.BAT
- la comme je faisais, une fois que tu as fais "c test" une fois, même avec des erreurs, la PATH de ta session MSDOS est bien configurée et donc MEKLIBR va fonctionner
- utiliser un make qui va bien avec un makefile aux petits oignons si tu préfères

Oui, il y a plus de 3 solutions, mais tant qu'à être dans la 4° dimension, autant en profiter...

Merci pour vos réponse et votre grande patience

Fadest (./183) :
Pour faire dans l'ordre :

>>D'ailleurs, je trouve assez curieux de demander d'effacer un fichier (del test.olb) alors qu'il n'existe pas
C'est juste au cas ou il existerait, vu qu'il est regénéré en entier (et en mode "libr65 a" pour ajouter, je crois me souvenir que ça plante si on ajoute un fichier qui existe déjà).
Rien n'empêche de faire bien mieux, surtout que ça peut être un peu long à généré quand il y a quelques dizaines ou centaines de sprites mais en général, je fais tout à l'avance et je génère 1 fois (ou je fais plusieurs librairies thématiques mais là, c'était pour faire un truc qui marche au plus vite)

>>Et bien sûr, libr65 n'est pas reconnu...
Il est bien dans ton répertoire c:\lynx\newcc65\bin
Vu qu'il n'y a pas de set PATH dans MAKELIBR, MS-DOS ne sait pas ou trouver LIBR65
3 solutions :
- la hardcore, copier LIBR65 dans le répertoire OBJ
- la soft : ajouter le set PATH dans MAKELIBR.BAT
- la comme je faisais, une fois que tu as fais "c test" une fois, même avec des erreurs, la PATH de ta session MSDOS est bien configurée et donc MEKLIBR va fonctionner
- utiliser un make qui va bien avec un makefile aux petits oignons si tu préfères

Oui, il y a plus de 3 solutions, mais tant qu'à être dans la 4° dimension, autant en profiter...

J'ai opté pour la solution hardcore, en copiant LIBR65 dans le répertoire OBJ, et je viens de créer un beau test.olb, joie ! La logique reprend ses droits !

D'ailleurs, pour lancer makelibr.bat, je viens de faire un autre batch file, à double cliquer pour gagner du temps (que j'ai nommé go_makelibr):
call C:\lynx\Projet_1\test\OBJ\makelibr.bat
cmd

Encore merci

Pas de problèmes...
Mais là, j'ai normalement coupure d'accès au net pour 2 jours... donc il faudra attendre jeudi pour des réponses de ma part à d'éventuelles questions

beauregard (./180) :
pour obtenir test.o, la présence du fichier test.olb est indispensable, sinon il y a un message d'erreur sous MS_DOS : Can't open 'test.olb'

Tu aurais dit dès le début que tu avais une première erreur à l'exécution de libr65, il aurait été plus facile de t'aider...

Tu n'avais jamais développé quoi que ce soit nécessitant une ligne de commande pour la compilation ? Je croyais pourtant t'avoir aperçu sur le forum jagware, tu avais pourtant l'air de dire que tu maitrisais, non ?

vince (./186) :

beauregard (./180) :
pour obtenir test.o, la présence du fichier test.olb est indispensable, sinon il y a un message d'erreur sous MS_DOS : Can't open 'test.olb'

Tu aurais dit dès le début que tu avais une première erreur à l'exécution de libr65, il aurait été plus facile de t'aider...

Tu n'avais jamais développé quoi que ce soit nécessitant une ligne de commande pour la compilation ? Je croyais pourtant t'avoir aperçu sur le forum jagware, tu avais pourtant l'air de dire que tu maitrisais, non ?

Pour le jeu Glob shoot, je l'ai fait avec The Game Factory, donc bon. Et avec pure basic tout est configuré (ide), mais lui ce n'est pas un freeware (je l'ai acheté pour 79 euros), donc point besoin de passer par MS_DOS. Je ne suis pas ingénieur, mais électrotechnicien, donc même si j'ai programmé en assembleur certain automate programmable, sur PC je suis une quiche dès qu'il s'agit de faire autre chose que du basic. Je me débrouille assez bien en graphisme aussi.

Je suis entrain de m'arracher les cheveux sur un pb.
Déjà voila mon besoin, j'affiche durant 500 unités de temps mon image de fond et un sprite puis je déplace ce sprite jusqu’à un point donné et je laisse l'image de fond et le sprite arrivé à sa nouvelle position durant les 500 udt suivante . Ma boucle principale est fini et je redémarre à udt 0.
Mon problème c'est si cela fonctionne bien la première fois dés la 2eme boucle le déplacement du sprite ne marche plus

Voici mon code :

"""""
d=201;

for( ; ; )
{
for(i=0; 500 > i; i++)
{
SCBX(SCBfond) = 0;
SCBY(SCBfond) = 0;
DrawSprite(SCBfond);

SCBX(SCBs) = 38;
SCBY(SCBs) = 75;
DrawSprite(SCBs);

Vsync();
SwapBuffers();
}

for(i=500; 1000 > i; i++)
{
SCBX(SCBfond) = 0;
SCBY(SCBfond) = 0;
DrawSprite(SCBfond);

d=d+dir_d;
if (d>200) {d=75; dir_d=-1;}
if (d<20) {d=20; }
SCBX(SCBs) = 100;
SCBY(SCBs) = d;
DrawSprite(SCBs);

Vsync();
SwapBuffers(); }

}

J'ai tout essayé (enfin tout ce à quoi je pensais, déclaré le "D=201;" apres le for( ; ; )
{
ecrire un truc du genre if (d<19) {d=201; } que je place juste apres for(i=500; 1000 > i; i++)
{
Mais rien ne marche et je ne comprend vraiment pas pourquoi

tu ne réinitialises jamais "dir_d" en positif, donc à la prochaine boucle le d=d+dir_d fera passer systématiquement ton code dans le cas if (d<20)
donc le sprite ne bougera plus.

Oh putain ! Oh putain !!!
Deux jours que je galère la dessus !!!!

Merci SCPCD

Coucou, j'ai eu beau chercher partout sur le net, je n'ai pas trouvé un seul lien vivant pour télécharger lyxass (les sources pour le compiler, pas le binaire), quelqu'un a-t-il ça sous le coude ?

Regarde si ce n'est pas là-dedans : http://www.monlynx.de/download/lynx/old-stuff/newcc65src.zip

Malheureusement non.. Quelqu'un aurait ça qui dort sur son disque dur ?

Pour une raison qui m'échappe en utilisant le nom de domaine geocities.ws et non .com on arrive au vieux site de Bastian, où les liens vers les sources de lyxass sont toujours là :
http://www.geocities.ws/SiliconValley/Byte/4242/download/index.html

Et c'est bien ce que tu voulais ?

Oui, et ça compile sans trop de problème sur ma Ubuntu.
Personne n'utilise plus lyxass et le kit BLL ici ?

je préfère le C puor ma part

Ma question sur le code du Nyancat de vince m'a rappelé cette chose qui me dérange depuis pas ma de temps.

J’ai un petit problème avec la gestion de la “Pause”, ci dessous un petit morceau de programme qui me permet d’afficher à l’écran un sprite lorsque l’on appuie sur un bouton ou une direction de la croix.
Aucun souci avec les directions, aucun souci avec OPT1 et OPT2, pas de souci non plus avec le B (Inner) par contre la ou ca bug c’est que quand j’appuie sur le bouton pause mon sprite n’apparait pas et quand j’appuie sur A (outer) cela m’affiche à la fois le sprite alloué à la Pause et celui alloué à A et je ne comprends pas pourquoi….

#define JOY_RIGHT 0x10
#define JOY_LEFT 0x20
#define JOY_DOWN 0x40
#define JOY_UP 0x80
#define BUTTON_OPTION1 0x08
#define BUTTON_OPTION2 0x04
#define BUTTON_INNER 0x02
#define BUTTON_OUTER 0x01
#define BUTTON_PAUSE 0x01

{
if (joystick & JOY_RIGHT)
DrawSprite(SCBt1); }
{
if (joystick & JOY_LEFT)
DrawSprite(SCBt2); }
{
if (joystick & JOY_UP)
DrawSprite(SCBt3); }
{
if (joystick & JOY_DOWN)
DrawSprite(SCBt4); }
{
if (joystick & BUTTON_OPTION2)
DrawSprite(SCBt5); }
{
if (joystick & BUTTON_OPTION1)
DrawSprite(SCBt6); }
{
if (joystick & BUTTON_OUTER)
DrawSprite(SCBt7); }
{
if (joystick & BUTTON_INNER)
DrawSprite(SCBt8); }
{
if (joystick & BUTTON_PAUSE)
DrawSprite(SCBt9); }

C'est normal, c'est pas if (joystick & BUTTON_PAUSE) qu'il faut tester mais if (switches & BUTTON_PAUSE)

Pré S. Vince merci pour le code de détection du type de Lynx.
Pré S. J'ai voté oui la question du 28/10/2012 j’espère que tu as vu


Bon maintenant mon problème du jour :

Je préparais une petite rom avec principalement du texte donc je faisais un truc de ce genre :
for(a=0; 1 > a; a++) { DrawFBox(0,0,160,102,0); POKE(0xFDA1, 0); TextOut(45, 25, 1, 0, "bla bla bla"); TextOut(57, 45, 1, 0, "bla bla bla"); TextOut(53, 65, 1, 0, "bla bla bla"); SwapBuffers(); for(j=0; 150 > j; j++) Vsync(); for(i=0; 16 > i; i++) { POKE(0xFDA1, i); for(j=0; 10 > j; j++) Vsync(); } for(j=0; 255 > j; j++) Vsync(); }for(a=0; 1 > a; a++) { DrawFBox(0,0,160,102,0); POKE(0xFDA1, 0); TextOut(45, 25, 1, 0, "bli bli bli"); TextOut(57, 45, 1, 0, "bli bli bli"); TextOut(53, 65, 1, 0, "bli bli bli"); SwapBuffers(); for(j=0; 150 > j; j++) Vsync(); for(i=0; 16 > i; i++) { POKE(0xFDA1, i); for(j=0; 10 > j; j++) Vsync(); } for(j=0; 255 > j; j++) Vsync(); }

Des blocs comme ça j'en ai environ 30 le tout me fait un fichier test.c d'environ 20ko donc apriori pas de souci sauf que lorsque je compil mon programme une fatal error surgi.
string space exhausted"
ligne : Textout (37. 10. 1. 0. "blo blo blo");

Si je retire le bloc de texte blo blo blo et que je re-compile la même erreur ce produira en m'indiquant que le probleme est sur le bloc qui arrivais juste apres blo blo blo, c'est donc apparemment bien un problème de mémoire ou de je ne sais quoi qui est plein.

Question pourquoi ? Et y a t-il une solution qui consisterait à vidanger les textout au fur et à mesure pour ne pas saturer je ne sais quoi ?


EDIT(vince) : j'ai ajouté la balise source pour le code

Le problème vient du fait que tu utilises trop de chaines statiques. Si en plus ce sont souvent les mêmes, tu devrais les remplacer par des constantes ou des variables mémoire...

Hum hum disons que ma méthode est à ma porté et dans mon idée j'étais parti sur l'emploi du texteout justement car je pensais cela ultra économe en mémoire finalement j'aurais meilleur compte de faire 26 sprites de chaque lettres ça sera plus long mais apparemment moins bouffeur de mémoire.

surtout pas, c'est déjà ce que fait textout, sauf que dans ton cas, c'est la chaine qui prend de la place avoir 500 fois "bla bla bla" va créer 500 statiques, le compilateur ne réalise pas que c'est la même chose à chaque fois.

Bah merde alors j'aurais jamais cru que texout équivalait à des sprites
N’empêche que je ne comprend toujours pas pourquoi cela bloque alors que mon test.c ne fait que 20ko.surtout que j'ai déjà compilé des code qui faisaient 100ko et ça passe très bien ok cela plante si on veux tester mais ça ce compil.

Bon je vais aller voir ce que sont des statiques des constantes et des variables maintenant

RYGAR (./204) :
Hum hum disons que ma méthode est à ma porté et dans mon idée j'étais parti sur l'emploi du texteout justement car je pensais cela ultra économe en mémoire finalement j'aurais meilleur compte de faire 26 sprites de chaque lettres ça sera plus long mais apparemment moins bouffeur de mémoire.

C'est ce que je fait, et ça marche bien. Mais je n'ai pas testé sur de nombreuse phrases.
up: Je peux te donner mon code, précise moi le nombre maximal de lettre par ligne, et la taille des lettres (exemple 8x8).

RYGAR (./206) :
N’empêche que je ne comprend toujours pas pourquoi cela bloque alors que mon test.c ne fait que 20ko.surtout que j'ai déjà compilé des code qui faisaient 100ko et ça passe très bien ok cela plante si on veux tester mais ça ce compil.

En fait, il faut considérer qu'il y a une taille limite pour le texte inclus dans ton programme. Chaque fois que tu mets une chaine "tototo" ou "bloblo", ça consomme de cet espace réservé, si tu dépasses, ton programme ne marchera pas.
Cette limite est peut-être modifiable par une option de compilation...

J'avais eu le même souci en développant Merlain, au début, je ne me basais pas sur un fichier externe, tout était inclus dans le code. Finalement, j'ai du me résoudre à externaliser les textes, ce qui est pas plus mal, car ça permet des jeux plus gros, et ça m'a permis de proposer un version anglaise digne des traductions VF des jeux des années 80 (niark, vengeance )

Comme le dit Vince, si tu as plusieurs fois le même texte à afficher, soit tu déclares tes chaines dans des variables et tu utilises la variable au lieu de la chaine, soit tu utilises des procédures par exemple (suivant la quantité de texte semblable).

En fait, je ne sais pas trop ce que tu veux faire, mais tu dois pouvoir regarder le source du kit aventure tiré de Merlain pour l'adapter à tes besoins (virer la partie gestion d'inventaire, choix multiples & co mais conserver ton texte dans le fichier externe)

attente provisoire

Bonne idée Fadest, je vais me pencher sur ton programme aventure pour essayer de palier à ce pb.

Une conversation sur un topic avait dévié sur la création d'un tamagochi pour Lynx et je voulais voir si c'était possible de faire qqchose avec cette idée.

Mon but premier aurais été de raconter la petite histoire de l’œuf qui allait bientôt éclore avec une dizaine d'écrans de texte qui ce seraient succédé.

Comme le textout est limité J'ai aussi essayé de faire mon histoire sous forme d'un gros sprite de 160*999 pixel qui défile mais là ça me bouffe déjà 30ko sur le 38/40 disponible

Ce qui me fais halluciner en voyant les contraintes c'est quand je repense au générique de Lemmings, un générique qui dure presque 5 min et qui doit comporter pas moins de 1000 lignes de texte !