editeur de texte formaté(qques questions) - Page 1

voila, j'ai presque fini mon algo
avant de coder l'editeur j'aurais besoin de conseils:

1/options à coder:
1.1/tableaux complets avec images comprises, cellules variables et edition wysiwyg
(la gestion actuelle est lamentable: taille des cellules fixes,...)
ou supprimer les tableaux inline
1.2/niveaux de gris(4)
ça serait lent car ça relentirait pas mal le moteur et ça repousserait la sortie
mais ça pourrait être cool:
-images de fond en gris clair,
-surlignage,...
1.3/multifontes (fichiers externes)
ça c'est plus facile à faire, je peux même faire vitef un convertisseur fontes win->TI en java
mais ~1.5ko par fonte en compressé=>taille sur la caltosse+loading+ça bouffe de la ram
(mais c'est très bo)

2/fichiers:
2.1/liens externe (necessité d'avoir les images (ou autre) sur la calto)
tout integré (pratique mais on ne peut pas reutiliser un fichier dans plusieurs docs)
fonction d'extraction de ressources (là ausi, fauda un moment) ou prog externe de decompilation
2.2/compression ziplib (comme ça je me ferai pas chier et ça buggera pas)
compression speciale (meilleure qualité mais plus lente) , je peux étudier le format de hibou

3/format de l'exe:
3.1/kernel ou _nostub (j'interdis à kevin kofler, TiMad, pen² et PhHd de repondre au 3.1)
sachant que je vais faire une api complète que je reutiliserai pour d'autres progs
avec menus, compression,...
ou format mixte avec une lib statique qui comprend toutes les fonctions en .a et ue dynamique
et on choisit à la compilation mais la ça repporte encore la sortie
3.2/maximum de taille: 10,20,30,40,50,60 ko (en tout avec des fontes) ?
donc:
asm?C?
tigcclib? je recode tout en asm?

voila
pour des screenshots, le topic sur le prototype que j'avais codé se trouve dans les archives du forum
si tout va bien, première version pour noël sauf si vous me demandez toutes les fonctions
(ce que je comprendrais néanmoins volontiers)

les grays, mis à part le surlignage, je voie pas trop d'intéret : on voit plus mal, et ça rame plus...

Les fontes (en externe), c clair que ça peut faire joli
cela dit, en usage réel, ça reste à prouver que c utile

fichiers> je dirai bien liens externes...

exe> ma fois, nostub ou kernel, pour moi, je m'en fou : j'ai toujours un kernel installé
cela dit, voie en fonction des librairies que tu peux être emené a utiliser (ziplib, par compatibilité avec TxtRider ?)
Pour faire une API complète, est-ce que tu ne pourrai pas voir par rapport à api92 (la lib utilisée par PCT), qui est pas mal complète, il me semble...

maximum de taille : sans les fontes (en n'utilisant que celle du TIOS), dans les 35 ko max. (nn compressé).

point de vue RAM... bof, tu peux en utiliser 150ko tout compris
(suffit de rien avoir d'autre en RAM )

1.1 : les tableaux sont interressants : personnellement, leur utilisation serait essentiellemnt pour des tableau de valeurs, et non une gestion de tableaux à la manière html
1.2 : les niveaux de gris sont utiles pour les images, et encore...
1.3 : les multifontes sont interressantes pour avoir acces à des caractères spéciaux qui n'existant peas sur Ti (mais tu as peut-être déjà programmer ça, je ne sais plus...)

2.2 : si tu veux tu peux reprendre l'ago que j'ai trouvé : comme je l'explique dans mon topic, je n'y toucherai pas avant 1 mois. telle que l'ago est à l'origine, y'a juste quelques petites modifs à faire et ca marche, mais avec les var en static . je ne suis pas aller plus loin (je n'ai pas eu le temps...). Donc tu peux reprendre le projet, y'a pas de pb : l'adresse de la source est dans mon topic.

3.1 : je préfère nostub, mais bon, tu lance ici un débat dont la conclusion n'existe probablement pas. C'est à TOI de faire le choix

si tu veux, je susi en train de faire une lib graphiques pour les applications (prend pas bcp de place et plus rapide que extrgraph)

je compte y ajouter menu/dialogues/compression/creation de varaibles/getion de texte/gestion de clavier

hibou> je vais regarder ça
(et peut-être la coder en asm)

nEUrOne>si tu veux je peux t'aider à la faire cette lib(kernel?)

jan²2> elle est pas kernel pour l'instant mais je la passerais surement en kernel

featuring (pour l'instant):
- drawstr 7* plus rapide que tios (~ 1.5* les nvelles fct de TN pour ebkreader)
- texte structuré
- ligne,cercle,ellipse,sprite,bitmap

il me faut les caractères en 16x16
(j'ai fait un ripper de fontes en java mais je me suis rendu compte qu'il faut 10 de large au min pour bien voir les polices "décor")

je peux pas le foutre: yaRo faudrait que tu rajoute le smiley applet

nEUrOne a écrit :
jan²2> elle est pas kernel pour l'instant mais je la passerais surement en kernel

featuring (pour l'instant):
- drawstr 7* plus rapide que tios (~ 1.5* les nvelles fct de TN pour ebkreader)
- texte structuré - ligne,cercle,ellipse,sprite,bitmap

Résumé: une librairie kernel contenant presque exclusivement des fonctions graphiques qui ne sont que des réécritures de celles qui sont déjà dans AMS. Où est l'utilité? On a déjà des librairies inutiles comme ça: par exemple, graphlib, à part les fonctions de niveaux de gris, est entièrement ça. Résultat: plus personne n'utilise graphlib.

sauf que cette lib serait plus rapide que le TIOS
(c pas dur, je sais)

Kevin Kofler a écrit :
Résumé: une librairie kernel contenant presque exclusivement des fonctions graphiques qui ne sont que des réécritures de celles qui sont déjà dans AMS. Où est l'utilité? On a déjà des librairies inutiles comme ça: par exemple, graphlib, à part les fonctions de niveaux de gris, est entièrement ça. Résultat: plus personne n'utilise graphlib.

ah me pourris pas mon topic sinon je vais arrêter d'être poli, et je t'interdit de répliquer
en foutnt tes conneries d'anti-kernel là ou je pose des questions pour mon programme

KK> utilises DrawStr pour faire un Editeur de texte bien fluide .. enfin, essaie ! ca necessite des routines assez rapide, en ce mmt je suis à 8*tios pour un DrawStr ...

C'est clair que DrawStr est lent: pour mon hibtext, j'ai commencé par ca.
Quand je suis passé à la méthode qu'utilise TICT : je suis passé du noir et blanc à la couleur !!!

c'est quoi, cette méthode ?
(j'ai un peu regardé les sources, mais pas trop compris)

bufferisation de la fonte,
mais plize repondez à mes questions...

c'est-à-dire, bufferisation ?

Bon, je vais répondre à tes question, même si je ne me sens pas trop concerné :
1.1 c'est mieux avec des tableaux (avec taille des cellules variable), mais bon, j'ai bien peur que sur notre petit écran ça ne ressemble pas à grand chose, un tableau.
1.2 Ce serait bien, si ça ne ralentit pas trop. Pour du surlignage, par ex, ou bien un effet d'ombrage...
1.3 Moui, pkoi pas.... enfin, c'est pas non plus la peine d'avoir plein de fontes, du moment qu'on en a au moins une bien... Donc c'est pas vraiment la peine, je pense.

2.1 C'est le même pb que les lib (statiques ou dynamique), je ne sais pas. Vraiment pas. D'un côté, c'est plus cool si on n'a qu'un seul fichier avaec tout dedans, mais bon, ça peut être pratique de n'utiliser que des liens externes pour les images, comme ça on peut les réutiliser. Moi, je pencherai quand même pour la technique "statique" (tout dans un seul fichier).
2.2 ché pas. m'en fous

3.1 Le mieux pour l'utilisateur est évidemment la solution mixte, sinon, je préfère en _nostub.
3.2 max taille, je m'en fous. Le moins que tu puisse faire et c'est tout.

bufferisation => tu affiche ne boucle tous les caracteres dans un buffer puis apres, tu les reprends en utilisant une fonction de sprite

pour la compression, je reprends le truc de hibou,
donc ça risque d'être un peu pu long que prévu...


tiens, je t'ai dépioté ebook.c:

short* charwidth = 0; // will be used to speedup length calculation
unsigned char* charset = NULL; // buffer for "grabbed" 4x6 font

//=============================================================================
// setup charset
//=============================================================================
static inline void SetupCharSet(void) {
short i;

FontSetSys(F_4x6);
memset(charset,0,256*5);
PortSet(charset,7,5*256-1);

// now draw all characters into the buffer so that we can use it later
for (i=0;i<256;i++) {
charwidth[i] = FontCharWidth(i);
DrawChar(0,i*5,i,A_REPLACE);
}
PortRestore();
FontSetSys(F_6x8); // used in the rest of the program
}

//=============================================================================
// draws string using own sprites (about 4 times faster than DrawStrXY)
//=============================================================================
void FastStringXY(short x,short y,const unsigned char* s) {
unsigned char* sprite;
long addr;
unsigned short cnt;
short ytemp;

while (*s) {
sprite = &charset[(short)(*s)*5];
ytemp = y;
if ((*s) == 0x67) ytemp++; // move letter 'g' one pixel down

addr = ((long)screenbuffer)+(ytemp<<5)-(ytemp<<1)+((x>>3)&0x1e);
cnt = 24-(x&15);

// unrolled loop for more speed ....
// NOTE: We are using XOR here, so this function can also be used
// for the "white on black" strings
*(long*)addr^=(long)(*sprite++)<<cnt;addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt;addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt;addr+=30;
*(long*)addr^=(long)(*sprite++)<<cnt;addr+=30;
*(long*)addr^=(long)(*sprite)<<cnt;

x+=charwidth[*s++];
}
}

comment elle est lente la fct FastStringXY % tX_DrawStr

(je plaisante, la différence n'est pas trop importante ...)

Au fait: nEUrOne, n'as-tu pas toujours été plutôt pour les librairies statiques? Si c'est bien le cas, pourquoi as-tu changé d'avis?

c'est pas une lib kernel:
tu as une lib statique, une dynamique,
et le header choisit les protos en fonction de USE_KERNEL

Ah, c'est un bon compromis, ça.
Même si personnellement je trouve que la version statique toute seule suffirait.

personnellement je trouve que la version dynamique toute seule suffirait.
donc tout le monde est content

mais pr l'instant, c'est que du statique

Kevin> j'ai quand même un peu changer d'avis rien que sur _nostub vs. kernel ... je ne suis plus totalement contre la programmation sur kernel car je trouve ca en fait, plus interessant pour le programmeur; faut voir maintenant si qq veut bien patcher sa rom pour avec le kernel auto-installé

nEUrOne
a écrit : Kevin> j'ai quand même un peu changer d'avis rien que sur _nostub vs. kernel ... je ne suis plus totalement contre la programmation sur kernel car je trouve ca en fait, plus interessant pour le programmeur;

En quoi est-ce "plus intéressant pour le programmeur"??? Je ne suis pas du tout d'accord avec cette affirmation en tout cas.

faut voir maintenant si qq veut bien patcher sa rom pour avec le kernel auto-installé

Moi non. Auto-installer un programme est trop dangereux. S'il y a un bogue dans le programme, c'est le reflash obligatoire...

Kevin Kofler
a écrit : En quoi est-ce "plus intéressant pour le programmeur"??? Je ne suis pas du tout d'accord avec cette affirmation en tout cas.

Chacun sont point de vue mais par exemple, les librairies c'est très bien ca pke le statique ca lourde a force d'avoir des exe trop gonflés et d'avoir 50 fois les mm routines dans les progs alors que ce serait dasn une lib ....

Moi non. Auto-installer un programme est trop dangereux. S'il y a un bogue dans le programme, c'est le reflash obligatoire...

ouép, mais on a le mm type probleme avec Maxmem et pourtant pas trop de probs ... mais c'est sûr que ce n'est pas moi qui pourrait programmer ca pour l'instant (appel à JM ou PphD )