Forums GAMERGEN

portugal508 Wrote:ou puis je acheter ces lunnetes 3d old school?
et est -que ca marche avec nimporte quel lunnetes 3d frouge et bleu?
merci
et bonne continuation aux dev

Ce n'est pas rouge et bleu mais rouge - cyan et Geecko vient d'indiquer les couleurs possibles

Salut,

Certains commentaires me font rire
Le principe des anaglyphes est certainement bien plus vieux que nous tous ici.


La performance est sans doute l'un des facteurs responsables de l'absence de jeux 3D stéréoscopiques sur les PSP actuelles.

Avoir un nombre de frames par seconde qui monte à 60 n'est pas significatif quand il s'agit de formes primitives non texturées, jetées dans le vide. Et puis ensuite, faire de la 3D pour des jeux 2D y'a pas grand intérêt. Sony : c'est vrai.

Concernant la stéréoscopie par anaglyphes (lunettes classiques), le rendu serait bien trop médiocre pour des jeux officiels. Et s'attarder à mettre en place une version dolby serait à mon avis trop couteux pour peu rentable. Mouai

Gecko a dit que le premier HB de ce type sur psp était de lui.
Certes, mais techniquement ou est l'exploit ?

Toboss45 Wrote:BON ALLER VOUS SAVEZ TRES BIEN QUE WASSGHA A RAISON DONC STOP ^^
ALLER WASSGHA SORT NOUS TON PLUGIN QUIL FERME LEUR ****** une bonne fois pour toute :=)

Je pensais que wassgha codait en Lua ?
Quoi qu'il en soit, même en C il rencontrera des problème de performance.
Vous pourrez peut-être profitez de la 3D, mais à quelle allure ?

Je suis ni contre vous ni avec vous.
Bon courage pour la suite à toi Gecko et à Wassgha.
Merci de faire bouger la scène

A+!

Techniquement il n'y a pas vraiment d'exploit, vu que n'importe que développeur confirmé aurait pu le faire...
Par contre, c'est bien le premier homebrew utilisant cette technique sur un rendu 3d temps réel qui a été releasé publiquement
D'ailleurs je trouve les performances très satisfaisantes, vu que les fps baissent à 60%, et avec un peu d'optimisation (réduction des calculs doublons) on pourrait peut-être passer à 70%.
Du moment que ça fait bouger les choses, je trouve ça bon à prendre.

Edit : Les formes primitives sont texturées

Geecko Wrote:Du moment que ça fait bouger les choses, je trouve ça bon à prendre.

Je suis d'accord avec ça.

Geecko Wrote:D'ailleurs je trouve les performances très satisfaisantes, vu que les fps baissent à 60%, et avec un peu d'optimisation (réduction des calculs doublons) on pourrait peut-être passer à 70%.
Edit : Les formes primitives sont texturées

Je voulais dire, qu'une scène complexe demanderait bien plus de ressources.
Que les primitives soient texturées ou non, change peu.
Ici 60% c'est déjà énorme, pour une scène contenant des primitives texturées.

Ce que tu fais gecko, c'est bien et personnellement ça me fait plaisir de voir des développeurs de la scène taper dans l'originalité.

Mais les jeux officiels ne peuvent pas se permettre d'être limités à l'affichage de cubes.
D'autant plus que les routines d'affichage ne sont pas les seules à tirer sur le CPU.

EDIT:
Ceci pour tenter de répondre à ceux qui demandent pourquoi les mecs de sony, (ou autre) ne sortent pas de jeux utilisant ce principe.

Je comprends, que cette scène est relativement simple, donc que ça ne reflète pas les performances d'un jeu normal
Tu as testé cette technique sur un de tes homebrews 3D pour voir l'impact ?

Geecko Wrote:Je comprends, que cette scène est relativement simple, donc que ça ne reflète pas les performances d'un jeu normal
Tu as testé cette technique sur un de tes homebrews 3D pour voir l'impact ?

Non pas celle ci et pas sur psp, mais il n'est pas difficile de comprendre qu'on prendrait moins de ressources avec un 1 seul et unique appel à la routine de rendu pour une frame.

EDIT:
Tu pourrais éventuellement alterner les 2 rendus. de cette manière tu restera certainement proche de 60 fps, mais en dessous de 50 fps, l'œil risque de se rendre compte de l'arnaque.
En terme d'illusion, tu sera à, ou en dessous de 25 images/seconde pour chaque rendu.
Mais tu gagnera en performance. et tes scène 3D pourront garder une certaine fluidité.

C'est une bonne idée, je peux essayer ça.
Dans ce cas-là le rendu ne perdra tout simplement pas en performances.
Il y aura par contre un problème de clignotement...
Merci

Même si au premier abord cet homebrew est inutile j'ai passé 15 min à regardé c'est vraiment prometteur et bien vivement un jeu comme ça !

Respect, trop balèze ^^

Moi je serai absent pour 13 jours à partir du 16...

Salut,

Geecko Wrote:C'est une bonne idée, je peux essayer ça.
Dans ce cas-là le rendu ne perdra tout simplement pas en performances.
Il y aura par contre un problème de clignotement...
Merci

En fait si tu fait appel à ton swap uniquement au moment ou tu rends la seconde partie et ton clear à la premiere , alors tu n'aura pas de problème de clignotement.
Avec ça Il faudrait éventuellement revoir la syncro au niveau de ta direct list.

La boucle principale sollicitera moins le proc.
Il resterait peut-être un inconvénient du coté du wait Vblank.

Si tu fais appel à lui, à chaque passage les mouvements paraitront moins fluides , (on rate une frame)

il faudrait peut-être jouer sur les translations et rotations des cubes,
ou encore avoir des transformations 3D sur t pour la partie 1 et t + 1 pour la partie 2.

En plaçant le wait uniquement à la seconde partie, toutes les 2 frames réels, alors les 2 frames en question n'auront pas la même durée.

A voir... ^^

pire que du chinois respect les dev