Question pour le créateur de Purebasic (Fred)

[Filax]

Je crois rever Un développeur qui demande de l'aide à ses clients pour
améliorer son produit Excellent J'adore !!!

Non sans déconer ? Bin ecoutez je serais heureux d'apporter mon aide
en terme de conseils sans problème !

Alors a chaud comme ça, je vais essayer de développer ce que j'aime
bien dans blitz en terme de 3D.

1) J'aime beaucoup le principe des entités blitz, et c'est un bon point pour
purebasic qui a une syntaxe a peut pret similaire. Par contre la ou le bat
blesse c'est qu'il manque pas mal de commandes (ou alors je n'ai pas très
bien lut la doc) mais bon, si je me trompe, ne me reprenez pas, ce n'est
pas le but du truc. Je citerais en vrac la doc de blitz3D.


------------------------------------------------------

EntityPitch# ( entity[,global] )
EntityRoll# ( entity[,global] )
EntityYaw# ( entity[,global] )

Returns the pitch, yaw, roll angle of an entity.
The roll angle is also the z angle of an entity.

------------------------------------------------------

CountChildren ( entity )
Returns the number of children of an entity.

------------------------------------------------------

EntityClass$( entity )

Returns a string containing the class of the specified entity.
Possible return values are:

Pivot
Light
Camera
Mirror
Listener
Sprite
Terrain
Plane
Mesh
MD2
BSP

------------------------------------------------------

EntityName$ ( entity )
Returns the name of an entity. An entity's name may be set in a modelling program, or manually set using NameEntity.

See also: NameEntity.

------------------------------------------------------

NameEntity entity,name$

Description
Sets an entity's name.

See also: EntityName.

------------------------------------------------------

Mais bon comme a mon sens il en manque un bon paquet peut etre
que si je t'envoyais la doc de blitz fred sa te mettrais un peu sur la
voie ? Car a vue d'oeil il manque une bonne trentaines de commandes
et ce soir j'ai pas trop la frite pour du copier coller

Mais tout cela pour dire qu'une gestion par entité de la 3D c'est ce qui a
contribué au succé de blitz donc sa parler de plagia, je pense que des
idées sont a reprendre.

------------------------------------------------------

2) Le principe identique par ID pour les textures est sympa aussi
en blitz je fais :

MonObjet=LoadMesh("Machin.3ds"
MaTexture=LoadTexture("Machin.bmp",Des parametres)
ENtityTexture MonObjet,MaTexture

Et opla, en pure je n'ai toujours pas compris comment faire Le
'Des paramètres' dans la ligne de commande du loadtexture sous blitz
permettent de par exemple, pre charger la texture en mode DOT3,
et donc sur le meme principe on pourrait parametrer du vrai bump
ou du paralax mapping

------------------------------------------------------

3) de manière identique le principe des entités pourrait amener lui aussi
a une simplification pour les shaders je m'explique.

En blitz il existe une commande : EntityFX

Cette commande permet d'activer certain paramettres graphique sur
une entité du style du blend, une surbrillance, le dot3 etc... Je pense
que l'idée serait bonne pour purebasic et en ce qui concerne les shaders
pourquoi pas une commandes du style :

EntityShader(monobjet,"monpoint.fx")

En gros je pense qu'un travail poussé sur le principe des entités attirerait
du monde et surtout permettrait a beaucoup de gens d'enfin comprendre
comment comment faire de la 3D facile sous pure et de plus, une pierre
deux coup, vous permettriez aux blitziens (non non je ne pense pas a
moi de faire des portage de leur applications blitz beaucoup plus
rapidement:) en gros Fred vous y etes presque

Donc je suis désolé, mais a part donner des idée je ne pourrais pas faire
grand chose de plus techniquement Ou alors peut être pondre une
ou deux démos pour agrémenter le pack de la future version

[Polo]

Ah !!
Quelqu'un qui, comme moi, apprécie la logique du Blitz
Evidemment, je n'utilise pas Blitz3d (dx7, plus mis à jour, interprété, exe énormes), mais il faut reconnaître que le langage est extrémement bien pensé
Mais bon, Sibly nous fait un remake du C++, alors bon....

Mon moteur 3d en Purebasic avance un peu, en fait je me contente de recréer les commandes 3d de Blitz3d
Mais je fait ça à ma sauce, en d3d9, et quand j'aurai fini de "porter" toutes les commandes du blitz j'en rajouterai
Mais bon, c'est la galère de faire ça

[Fred]

Ok, bon je vais me faire une liste et voir ce qui est implementable/deja present dans OGRE. Pour les Entity, t'inquiètes pas, le Blitz n'a rien inventé et c'est présent dans OGRE depuis le tout début: http://www.ogre3d.org/docs/api/html/cla ... ntity.html

Avant de me lancer la dedans, je vais deja finir les v4, et attendre que la v1.2 finale de OGRE sorte.

PS: à propos de la taille, il ne faut pas se leurrer, si c'est aussi imposant c'est qu'il y a une bonne raison: un moteur 3d actuel, ca fait pas 3 lignes de code. Evidemment, tu peux afficher 3 polygones en 4 kos, mais bon l'interet est plutot limite.

[Filax]

Et bien si il a rien inventé alors hesite pas ! c'est ce
qui fera décoller ton langage, car moi j'en ai plein le cul
d'attendre un gars (mark sibbly) qui repond jamais
à mes questions, alors que mes démos ont contribués
sevèrement à lui faire vendre des tas de licences ....

Donc fatigué d'attendre en permanence que dieu me
parle, je cherche d'autres langages et le seul qui pour
le moment me tenterait bien c'est pure, pour tout un
tas de raisons citées plus en amont. Mais pour cela il
m'en faut plus en 3D, car j'ai besoin d'un moteur
qui en a sous le pied pour enfin délirer.

Donc si tu as besoin de mes services pour du test
ou autre n'hesite pas... Je me ferais un plaisir
de t'apporter un soutient avec mes maigres
compétences aux regards des tiennes.

[Progi1984]

Pour info, la RC2 de Ogre1.0.2 est sortie : http://ogre3d.org/index.php?option=com_ ... 5&Itemid=2

Concernant Ogre, la liste des caractéristiques est ici : http://www.ogre3d.org/wiki/index.php/Cu ... reFeatures

De plus, je voudrais ajouter un point aux divers concepts abordés par Filax : la physique et les collisions.

Tu as commencé dans la V4 à aborder les collisions et la physique, mais hélas, tu n'as fait que l'effleurer.

Par exemple pour la gestion des collisions, il serait intéressant de pouvoir choisir la réponse à la collision :
- collision ss réponse
- collision glissante
-etc...

pour la physique, c'est de même. Il serait intéressant de pouvoir accéder via accesseurs aux forces, gravité appliqués aux objets. Je te conseille de regarder des tutos faits par Filax afin de voir les différents commandes d'interaction entre les objets/monde blitz et le moteur physique :
http://www.blitz3dfr.com/phpfrench/e107 ... php?fid=44

PS : Merci de nous demander de t'"aider" ! Ca fait plaisir !

[Polo]

j'en ai plein le cul
d'attendre un gars (mark sibbly) qui repond jamais
à mes questions, alors que mes démos ont contribués
sevèrement à lui faire vendre des tas de licences ...

Je suis la scène Blitz vaguement de loin, et faut avouer que t'as pas tout à fait tord
T'as fait des trucs drôlements sympas !!

à propos de la taille, il ne faut pas se leurrer,

Oui, c'est vrai, mais je trouve que ça fait beaucoup tout de même, plus gros encore que le runtime de blitz3d (qui contient les fonctions 2d, 3d, etc...).
Le fait qu'une dll soit nécessaire fait, justement, qu'il y a "un fichier en +", que tout est inclus même quand on ne se sert que d'1/10 du moteur, etc... Bref, je trouve que par rappport à tout ton boulot sur Purebasic quant à l'optimisation de la taille des exe, c'est dommage

Je sais, je suis vraiment lourd et têtu

[Progi1984]

Avant de me lancer la dedans, je vais deja finir les v4, et attendre que la v1.2 finale de OGRE sorte.

Fred, la v1.2 finale de Ogre est sortie

Manque plus que les V4 à finir

[Guimauve]

Et maintenant , la version 1.2.1 vient de sortir. Avec la correction de bogues bien sur. Rien de nouveau il me semble.

A+
Guimauve

[Progi1984]

La version 1.2.3 vient de sortir ...

Code : Tout sélectionner

Changes since v1.2.2:

    * D3D9:
          o Respect displayFrequency option if specified
          o Use D3DFMT_UNKNOWN instead of D3DFMT_FROM_FILE for DDS loading routines, allow more fallbacks
          o Make sure DestroyWindow is called in all cases on destruction in D3D9 when using OGRE-created window
          o Don't try to update RTT/MRT when D3D device is lost
          o Fix device lost recovery for secondary windows
          o

    * GL:
          o Make sure fixed-function LBX_ADD_SMOOTH implemented, even though no direct equivalent for arbitrary GL_COMBINE in GL. GL_INTERPOLATE is the closest
          o Fix a problem with the model (world) matrix being incorrectly taken into account when using fixed-function cubic reflection in GL
    * TerrainSceneManager:
          o Explicitly shut down page source before DLL shutdown, identified by tuan as a cause of shutdown problems in TSM under certain conditions
          o Fix terrain pages not using custom assigned render queue
    * Resource system:
          o Move firing of resource start / end outside the isLoaded() check to ensure that the callback count is correct even if resource state changes
          o Fix a bug with ResourceGroupManager::loadResourceGroup - if any resource in the group at the start changed group (because of a resource found in another location not in the group being loaded), iterators are invalidated which caused a nasty crash. Really people should sort out their group locations but detect this condition and deal with it nicely
          o

    * XSI Exporter:
          o Fix exporting of tangents
          o Fix bug with scaling in keyframes should be relative to original bone scale (previously assumed bind scale of UNIT_SCALE)
    * Linux:
          o Fix compilation of OgreSDLConfig_gtk.cpp with recent libsigc
          o Ogre::SDLWindow::isFullScreen implementation
          o gcc deprecated warning fixes
          o Provide -DOGRE_DOUBLE_PRECISION and -DEXT_HASH through pkg-config
    * OSX:
          o Universal binaries support
          o Dependencies update
          o Updated the Ogre Config Dialog to look more like it's windows counterpart
          o NOTE: Using Frame Buffer Objects (FBOs) on OSX can cause some visual artefacts, choose "PBuffer" as the "RTT Preferred Mode" when configuring the GL rendersystem until Leopard is released which should fix this problem.
    * Code::Blocks:
          o project format updated
          o STLport no longer required, but special build of MinGW needed for correct DLL handling of std::string
    * Node changes:
          o If node already attached to a parent, addChild now throws an exception instead of just asserting, helpful to track down this type of bug in release build
          o removeChild(Node*) now uses node name to find whether/where to erasing the child (still keep same behavior as previous), increases performance 
          o Bugfix for node weighted transform scale blend: should interpolate between old and new scale rather than scaling old scale with factored new scale
    * Compositors:
          o Eliminate constant recompilation when compositors enabled on more than one viewport at once
          o Eliminate extra memory consumption each time CompositorChain is recompiled
    * ManualObject:
          o Fix crash in ManualObject when silly people call begin() and end() with no data in between
          o If ManualObject is already attached to a node when new geometry is added, tell parent to update so potentially new bounds are updated too
    * BillboardChain:  
          o changing number of elements and chains, enabling/disabling vertex colour and texture coords usage should mark index buffer dirty and rebuild later
          o update render queue should take render queue into account
    * Tangent calculations:
          o Correct bug with shared geometry where each submesh covered only some of the vertices
          o Orthogonalise tangent vectors with the vertex normal when generating
    * Ensure the correct texture format / num mips is used if texture loaded through declareResource / loadResourceGroup instead of TextureManager::load
    * Fixed stencil shadow bug when enabling a custom near clip plane, which in some case missing generate light/dark caps that required by zfail algorithm
    * Viewport clear buffers defaults to FBT_COLOUR|FBT_DEPTH, the same as the value defaulted in Viewport::setClearEveryFrame, not 0xFF. More consistent, small speedup and resolves some compositor issues
    * Overlay bugfix - when a parent container was using pixel metrics, and the child was using non-left or non-top alignment, the pixel metrics were being used as relative metrics to calculate the childs position in error
    * Mesh::clone - fix pose list being empty after mesh cloning
    * DeferredShading Demo now compiles under OGRE_DOUBLE_PRECISION mode
    * Fix incorrect override on AnimableValue::applyDeltaValue(Real)
    * Bugfixes for skeleton unloading
    * Fix use of depth bias with CEGui renderer
    * Tolerate compile errors in shaders, just log the errors and mark the technique as unsupported instead of requiring app to catch exception
    * StaticGeometry was getting the wrong material technique which caused material LOD not to work, and for potentially unsupported techniques to be picked - fixed.
    * Fix a bug in vertex morph animation where if the same keyframe was passed as both parameters for the morph (because only one keyframe in a track, or because the time exactly matched a keyframe), the same buffer was locked twice
    * Root::addFrameListener now deals with the case where a listener with a given address is removed and re-added before the deferred removal is processed
    * Entity::refreshAvailableAnimationState should refresh vertex animation too. Refreshing the animation state should update length if it has changed
    * Virtualise a few SceneNode methods so they can be overridden
    * Copy pass should copy hash value too. On demand illumination pass compiles should calculate new pass hash value immediately.
    * BillboardSet: unreference main buffer when destroying buffers, so the hardware vertex buffer will release back to driver as early as possible
    * Fix Ocean demo crashing if there are no supported material techniques
    * Safely handle null camera in all cases in Viewport
    * Fix a bug in the Milkshape exporter when exporting models imported from other formats which have less position keyframes than rotation keyframes (Milkshape never creates these)
    * Fix and enhance BitmapFontBuilderTool
    * Miscellaneous detail-level performance improvements
    * Documentation updates

[jerexgrz]

Voila !!!!

Avec toutes vos demandes, vous venez de tuer Fred !
Il a disparu ! Plus de traces de lui sur le forum francais comme anglais.
...




Non, je deconne la !

[Guimauve]

Sujet sur le forum anglais

http://www.purebasic.fr/english/viewtop ... c&start=75

Fred parle qu'il s'est trouvée un nouvel emploi à temps plein et que le dévellopement est au ralenti depuis.

Et donc la sortie de PBV4.00 pour linux et Mac OS sera forcément retardée et du même coup la mise à jour tant attendue du moteur 3D.

C'est comment dire ...

A+
Guimauve

[Thyphoon]

Sujet sur le forum anglais

http://www.purebasic.fr/english/viewtop ... c&start=75

Fred parle qu'il s'est trouvée un nouvel emploi à temps plein et que le dévellopement est au ralenti depuis.

Et donc la sortie de PBV4.00 pour linux et Mac OS sera forcément retardée et du même coup la mise à jour tant attendue du moteur 3D.

C'est comment dire ...

A+
Guimauve

C'est un peu ce que je pensais... on ne peut pas vivre correctement d'un programme comme le Purebasic. surtout lorsque les mise à jours sont gratuite...il aurait fallu payé un petit abonnement par an/ pour les mise à jour genre 20€, pour permettre a son auteur d'en vivre.

En tout cas si je gagne au loto le gros lot ! Je monte une boite et J'embauche Fred pour s'occuper du purebasic a plein temps. Quitte a payer d'autre developpeur pour l'aider
Bon bien entendu ...si je gagne au loto

[comtois]

je ne comprends pas très bien l'anglais, je peux lire de travers, mais il me semble que Fred dit qu'il avait besoin de changer d'air, que développer tous les jours chez soi ce n'est pas sain, et que depuis quelques mois il n'avançait plus trop dans le développement de PureBasic, bien qu'il n'avait pas encore un emploi plein temps.

C'est sa vie, il la mène comme il veut, on attendra bien quelques mois de plus pour la mise à jour de la 3D

[Thyphoon]

je ne comprends pas très bien l'anglais, je peux lire de travers, mais il me semble que Fred dit qu'il avait besoin de changer d'air, que développer tous les jours chez soi ce n'est pas sain, et que depuis quelques mois il n'avançait plus trop dans le développement de PureBasic, bien qu'il n'avait pas encore un emploi plein temps.

C'est sa vie, il la mène comme il veut, on attendra bien quelques mois de plus pour la mise à jour de la 3D

Oui tout a fait raison ...

[djes]

Je connais ça. J'avais monté une petite boîte il y a quelques années, en famille. Non seulement c'était très stressant car on n'osait pas se dire les vérités en face, mais on avait parfois du mal à se mettre à travailler, car il fallait s'automotiver car nous n'arrivions pas à tenir nos rôles de chefs de projets.

Aujourd'hui la boîte tourne toujours, mais cette expérience m'a été utile. J'espère que pour Fred aussi, et qu'il trouvera un "truc" pour continuer à aussi bien bosser sans se lasser En tout cas il a des supporters