Discussion :

[maeiky]

Bonjours, je me demande de la possibilité de la chose, j'ai créer un langage de programmation Nx2 semblable au Java qui convertie le tout en C++.

J'ai également développer le moteur derrière, qui ne requière aucune dépendance. La partie graphique 3d/2d, peut être rendu soit par OGL ou par CPU. Pour un affichage CPU c'est un traitement sur un tableau de pixels, il suffit simplement de pouvoir afficher celui-ci.

Évidement c'est compiler en natif, donc excellent pour les performances.

J'ai pensé que ça pourrait ajouter de nouveaux horizons à cet OS

Est-ce possible de lancer un .exe, peut-il accéder au Kernel CPCDOS?
Supporte t-il OpenGL?

[cpcdos]

Bonjour maeiky,

j'ai jeté un coup d’œil sur ton projet, et cela semble plutôt intéressant à mettre en place C'est d’ailleurs un bon projet! Félicitation à toi!
Seule bémol, le noyau Cpcdos est en re-construction, depuis février 2015, réécriture complète du noyau. Hors mis le langage CpcdosC+, le support du rendu graphique HTML, CSS à été voté pour les développeurs souhaitant créer leur propres navigateurs internet après la stabilité du prochain noyau.
Il sortira en 2016.
L'innovation et la mise en place du 3D dans Cpcdos serai prévu beaucoup plus tard, donc je ne me suis pas intéressé plus que ça, mais ton projet me semble plutôt mal pas pour avancer, ce qui change ce que je pensais

Concernant les exécutables .exe, malheureusement Cpcdos ne supporte pas la lecture d'entête MZ, même s'il est doté d'un stub DPMI, il sera dépendant seulement de cette routine basé sous FreeDos et non a Cpcdos en interne/instance. Le projet futur et bien évidement le support des exécutable WIN32 mais... futur futur

Et l'OpenGL n'est pas inclut mais possible!. J'ai trouvé une "variante", j'ai testé un exécutable déjà compilé que j'ai soumis à un DPMI sous FreeDos, et il se débrouille plutôt bien pour afficher un simple cube animé en 3D (OpenGL) sous DOS, manque de temps, je n'es pas mis mon nez dans les sources, et cette "variante" est mesa3D
Si d'ailleurs tu trouves une solution pour compiler en GCC 4.7 (C/C++) / DJGPP une version d'OpenGL, mesa3D ou je ne sais quoi, ça avancera pas mal l'intégration/support de Nx2 sur Cpcdos et les milliers de développeurs d'OS sur Cpcdos qui pourront profiter de ton système sur leur propres OS.

Pour conclure, un peut de boulo et il sera possible
Qu'en penses-tu ?

[maeiky]

Salut, pour la partie OpenGL, mon moteur peu facilement s'en passer, il donne le même rendu CPU au pixel près, donc ça peut attendre. Faire un rendu CPU étant dans un but de compatibilité, c'est exactement pour ce genre de cas. Je supporte également les fenêtres avec pixel-semi transparent, ce qui pourrait être un feature très intéressant pour ton OS. Mais je ne comprend pas vraiment le système de fenêtrage en cpcdos, il faudrait pouvoir blitter les pixels dans une fenêtre, j'avoue ne pas savoir comment procéder.

Pour les exécutable Win32, ça va fonctionner avec la gestion des fenêtres? Je ne m'y connais pas trop en Dos et en entête MZ, est-ce difficile à implémenter? Y a t-il d'autre solutions? Dll par exemple?
Avec quoi est programmer CpcDos? Comment as-tu créer ton interface graphique?

[cpcdos]

Salut,

D'accord, donc on oublie l'OpenGL. Effectivement par CPU c'est bien ce j'ai pu comprendre dans tes écrits, c'est effectivement un bonne chose pour cpcdos sachant que j'ai des problèmes de drivers GPU!
(Attention Cpcdos est le noyau, l'OS c'est ce que vont faire les développeurs)

Maintenant concernant l'interface graphique de Cpcdos, les version disponibles en ligne (<= Apha 3.9.5) le blitting n'est pas possible en CpcdosC+,
Aujourd'hui il est très obsolète, il s'agissait seulement de simples algorithmes pour remplir des formes de couleurs, de t-elle couleur, des opérations binaires XOR, AND etc.. pour gérer les transparences, le canal alpha pour le png, magenta color replacement pour les bmp etc.. BREF Le tout était géré dans Cpcdos et non l'utilisateur mais tout ça, ça va changer.

Pour les exécutable Win32 / Dll c'est un boulo colossale, j'ai toutes les sources de Japteth (le createur du hdpmi) et ça va me prendre un temps fou à "essayer" d'implémenter la lecture des Win32 sachant que c'est très limité. Je prendrai un temps mais pas cette année. Donc oublions les Win32, j'ai une autre méthode qui peut être intéressante.

Donc oublie ce qu'es ce Cpcdos aujourd'hui, mais intéressons nous à la prochaine version où on pourra implémenter Nx2.



--> Ce qu'il faudra faire pour la prochaine version, c'est une sorte d'agrégation, une instance de ton moteur directement/nativement dans Cpcdos. Je m'explique,

Je ne sais pas comment est organisé ton code, mais il faudrait que tu puisses créer sois une librairie .a (si tu veux garder ton code source pour toi, ce que je comprendrai avec le boulo colossale que tu as fais) ou un code c++ compatible avec le compilateur GNU GCC 4.7, que je puisse compiler nativement dans CPinti core.
(CPinti core codé en C/C++/asm est un nouveau composant important de Cpcdos multi-threading, http, tcp, task manager etc.. dont j'en suis l'auteur)

Pour implémenter ton moteur, j'ai 2 solutions (si tu en a d'autres hésites pas)
Solution 1 : Si c'est bien-sure possible
Cpcdos (qui va créer des thread pour ton moteur) puisse se nourrir des méthodes publiques de ton moteur du style :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
void* INIT_NX2(TailleX, TailleY)
void* DRAW_LINE(blabla, .., .., ..)
void* LOAD_PNG(blabla, blbla)
void*  .....
.....

et que chacune de ces méthodes renvoie un pointeur vers la nouvelle bitmap/image travaillé par ton moteur graphique
et Cpcdos s'occupera simplement de placer directement ce bitmap sur l'écran par rapport à la position X et Y de la fenêtre.

Solution 2 :
C'est quasi la même que la première, sauf que c'est ton moteur qui affiche directement le flux d'images sur l'écran à une positon + taille définit par rapport à une fenêtre

Qu'en penses-tu ? Ou as-tu une autre solution ?

[maeiky]

Ça me ferais super plaisir que mon moteur sois intégrer directement
Il compile sous GNU GCC 4.7, les sources sont déjà disponible. Par contre il me reste à le mettre a jours, et plusieurs corrections s'impose.

Le moteur serait parfait pour faire la gestion des fenêtres, le tout est basé sur les coordonnées écrans, excellent pour la 2d, mais n'empêche aucunement la 3d.

Pour les solutions proposées les deux sont bonnes, ça dépend surtout de toi.
Ce qui est intéressant c’est que s'il gère entièrement l'UI, il ne sera pas limiter avec la semi-transparence des fenêtres, très pratique pour faire des widgets.
Il faudrait créer un gestionnaire de fenêtre, le texte commence à être gérer aussi par le moteur.
Peut-être aimerai tu apprendre le Nx2?
Sinon c'est utilisable en c++, mais c'est pas mal moins évident. Je travaille aussi en ce moment sur un IDE avec auto-complétion et compilation live du Nx2, ce qui va simplifier le tout. Si tu connais le Java, c'est très similaire.

[BlackoOSX]

Salut!
Cela va demander beaucoup de boulot de la part Seb et de toi mais ce projet serait variment une très grande avancée et un grand avantage sur CPCDOS!
Bravo à toi maeiky pour ton travail génial et quand à toi Seb, continue comme cela pour le développement du Noyau.

[cpcdos]

Et bien c'est parfait!

Pour la gestion des fenêtres j'y ai beaucoup réfléchi il y a quelque minutes, après de bons temps de réflexion, je ferai deux types d'affichages.
Comme sur Windows phone avec WPF et Sliverlight. Avec Windows GDI/WinForms et Net.Framework. Et bien là ça pourrai être Cpcdos's GUI et Nx2 Forms ou je sais quoi

Je serai surtout très impressionné de voir de la 3D sous Cpcdos, à partir de là, ça serai une grande avancée!

Un petit entretient sur Skype ne sera pas de refus ! Je t'enverrai une invitation en MP. Je travaille actuellement sur le TCP et Serveur TCP multi-client de CPinti core. Dés que j'aurai finis, on attaque ;-)

[cpcdos]

Merci BlackOSx

[BlackoOSX]

Derien !

[maeiky]

Good,

Pour un système de fenêtre c'est un peu complexe, en théorie ça pourrait être entièrement géré pas GZE (Le moteur graphique) sans avoir à passer par un buffer pour chacune des fenêtres.

Les buffer obligeant de faire un second traitement sur tout les pixels, ça joue donc sur les performances.

Mais ceci limite le fait de pouvoir afficher d'autre interface comme Cpcdos's GUI, mais surtout des éventuelles applications (Win32?), ou bien un PBO d'OpenGL, où l'on récupérerais le tableau de pixel.

Un buffer permet également d'effectuer de la transparence uniformément sur la fenêtre, dans le cas contraire la transparence est par objets, ce qui donne un effet étrange.

Donc la combinaison des fenêtre pourrait être géré pas GZE avec effet 3d ou pas, leur contenue serait un buffer pouvant provenir de n'importe quel source, tout comme le DWM

[cpcdos]

Le gestionnaire des fenêtres je n'aurai pas de problèmes, j'ai su le faire, ça serai "quasiment la même" que les version précédentes, à la différence c'est que je vais le retaper de zéro avec mes idées précis et propre! l’organisation des instances et du buffer qui va changer.
Et le rendu graphique entre Cpcdos's GUI et Nx2 ou GZE pourrait être le choix du développeur

• Si l'utilisateur à une vielle carte VGA, il utilisera Cpcdos's GUI
• Si par exemple il veut une application avec un pétage de couleurs, de la 3D pour faire un menu de jeu vidéo/intro, un thème gamer, il utilisera Nx2
• Si veut simplement faire une simple application, une barre des tâches type flat banale peut de couleurs (aussi pour débuter).. il utilisera Cpcdos's GUI
• Si son PC n'es malheureusement pas Chuck Norris pour X raisons (il peut avoir 10 serveur http, ftp lancé en même temps et très gourmandant) et se voit limité par sa rapidité, il prendra Cpcdos GUI's
• Si le développeur veut des animations dans son OS à t-elle endroit, il utilisera Nx2 à t-elle endroit et pas l'autre etc...
• ...

Mais encore....

[maeiky]

Oui, bon c'est toujours au stade d'idée, l'idéal serait peut-être de ne pas avoir à travailler en double. Le projet me semble déjà de très grande ampleur.

Pour ce qui est des performances c’est surtout d’arriver à redessiner que les zone qui change.
C'est la partie difficile, en même temps une fois bien optimisé, l'utilisateur pourrait tout de même faire un affichage avec ou sans animations, avec ou sans 3d. Je pense qu'il est possible de faire autant un affichage basique que riche.

Serait ont mieux de se concentrer sur un seul GUI, ou bien Cpcdos's GUI apporte t'il certains avantages?
Par contre je ne garantie rien pour les performances, à grande résolutions pour des animations 3d, ça peut s'avérer lourd. Bien entendu, normalement ce n'est qu'une partie de l'écran qui est actualisé.
Comment procède-tu pour l'affichage, tu peux blliter un buffer sur le drivers?

[cpcdos]

Je pense que les deux pourrai élargir les choix du développeur, par ce que justement l'avantage de Cpcdos's GUI c'est qu'il utilise le CRT0 du compilateur FreeBasic pour dessiner, ce qui porte un petit + pour du dessin optimisé car à l'assemblage, il est très proche du driver générique pré-inclus dans le compilateur. Je ne m'amuse donc plus à bidouiller l'interruption 13h avec une apparence typique d'un setup Après dés qu'on arrive sur des PC du style Pentium, i3, i5 ... la différence ne se fait plus ressentir

Donc Cpcdos's GUI étant très proche du CRT0 de FreeBasic / driver vidéo, il serai plutôt réservé pour gagner des performances pour des petites machines, ou pour les machines exécutant des serveurs ou autre. ( Je pense aux carte graphique de certain serveur HP et DELL qui ne supporte pas du tout les grandes résolutions du pilote générique SVGA et se voir afficher en 16bits et en 800x600 ou aussi aux vielles cartes EGA, MGA &| VGA. Là je parle de GPU juste pour l'affichage en général) )

Si tu es d'accord, mieux être prévoyant on ne sera jamais sur quel PC le développeur, ou l'utilisateur final va utiliser, cela ne différenciera pas le gestionnaires de fenêtres mais uniquement le rendu qui sera plus riche ou pas. (Je par qu'aux niveau des fenêtres ..)

Après les animations 3D, si l'utilisateur est en 1080p effectivement il se peut que cela s'avère lourd. Travailler sur la zone qui à changé va être un bon boulo mais j'ai plusieurs pistes qui peut porter avantageux
J'utilise un driver SVGA générique inclus nativement dans Cpcdos/FreeBasic et oui je peux blitter un buffer, même sur plusieurs pages vidéos

[maeiky]

Parfait,

C'est bien que le moteur graphique soit inclue directement au core, mais il faudrait tout de même pouvoir lancer des applications et que son contenue soit affichable dans une fenêtre. Évidement ce sera possible avec ton langage interprété CpcDosC+, mais le mieux serait d’étendre le tout à des applications qui roule nativement.

Bon les exécutable Win32 était un exemple (leur implémentation semble difficile), mais j'ai pensé à quelque chose qui pourrait en quelque sorte être révolutionnaire pour un OS.

Ce qu'il faudrait ce serait d'arriver à intégrer LLVM au core et qu'il puisse lire le LLVM IR, plus d'info ici : https://pauladamsmith.com/blog/2015/...lvm-c-api.html

Les fichier LLVM IR est l'intermédiaire de la compilation de C++ à Assembleur. Je dis C++ ici, car c'est ce qui me semble le plus intéressant, mais il supporte d'autres langages.
Ce LLVM IR peut être compilé en langage machine, mais encore plus intéressant, il peut être exécuter live (JIT -> Just In Time)
Cette compilation à la volé peu être encore plus performante qu'une compilation en langage machine standard, pour la simple et bonne raison qu'elle est compiler sur la plateforme cible et que celle-ci peut apporter les optimisations approprié, par exemple si ta machine supporte tel type d'instructions SSE, il peut l'activer.

Ceci ouvre la voie à plein d'applications portable sur ton OS, mais surtout le Nx2 que je pourrais concevoir spécialement pour ça
Tu aurais un OS unique, même Microsoft serait jaloux

[cpcdos]

Pour le LLVM, ça alaire plutôt intéressant! Je regarderai une autre fois quand j'aurai déjà terminé les bases

On fera un entretient sur Skype, tu seras tenu au courant d'ici peu

[MINEOSX]

Salut,

Bravo maikey pour ton travail et pour toi Sébastien, je te souhaite un très bon courage pour le développement du noyau, continue comme ça!


Cordialement.

MINEOSX, Le créateur de MINEOSX.