• Rage •

couilleshot a écrit :

c'est surtout que les environnements n'ont pas l'air variés, c'est genre "la colline a des yeux" teinté de stalker et madmax...pi c'est tout :sarcastic:

Cet univers me paraît un peu inhabituel pour un jeu ID également.

satrincha

Moi j'ai rien dit©
Transactions (1)

pourtant John Carmack à été claire ! les Quakes/Dooms like ça ne le motive plus du tout !

---------------
@ULTIMATE TopiK UniK JeuX GratuitS@

Sire Jeans

Jardin du son
Transactions (0)

Zeross a écrit :

C'est surtout que ce sont des images qui sont apparues à la base sur le site de Luxology, le développeur de Modo le modeleur utilisé par les artistes d'Id Software, donc c'est pas vraiment des screenshots destinés à la presse et mettant en valeur le jeu. Encore une fois JV.com confond tout, d'ailleurs dans le tas il y a surtout des images du niveau dans Modo (les 5 et 6), une image du rendu dans le renderer de Modo (donc sans Megatexture, la deuxième), le niveau final dans le moteur du jeu (la première) et les deux autres (garage et mouche) sont tirées du trailer.

Bref pour en voir plus sur Rage il faudra attendre l'E3 voire la QuakeCon en août.

Merci je cherchai justement le modeleur utilisé dans un des screen :jap:

Modder moi ce jeu pour en faire un VRAI Fallout 3 bourdel !! :fou:

---------------
( ͡° ͜ʖ ͡°) ( ͡⊙ ͜ʖ ͡⊙) ( ͡◉ ͜ʖ ͡◉)

nyxon

boo
Transactions (0)

site up !
http://www.aftertheimpact.com/

rapha3L

Benjamin Green, t'as l'air d'être dans la merde [:cerveau boidleau]

ANViL

yep...definitely ♫
Transactions (0)

Sire Jeans a écrit :

Modder moi ce jeu pour en faire un VRAI Fallout 3 bourdel !! :fou:

Ca poserait un petit problème - hors mod - si Rage se posait en concurrent de Fallout 3, vu qu'id Software appartient à Bethesda qui n'est autre que le développeur de Fallout [:prodigy]

---------------
Easy Ridin' ⎝⏠⏝⏠⎠

AnthonyD

»»───(knee)───►
Transactions (0)

C'est faux, id software appartient a la meme maison mere que Bethesda mais pas du tout directement a Bethesda, c'est plutot une relation soeur -soeur que mere-fille (en gros).

ANViL

yep...definitely ♫
Transactions (0)

petite preview chez NF :hello:

---------------
Easy Ridin' ⎝⏠⏝⏠⎠

rapha3L

[:gaga jap]

Publicité

biboulMRPN

ca fait envie, ça me fait penser a ce que Terminator Renaissance aurait du être.

dragonlore

A moins d'un miracle, l'idtech 5 sera le premier moteur 3d d'id qui ne sera plus un étalon technique sur PC.
bref la fin d'une époque.

Message cité 2 fois

theBride_

Strobist
Transactions (0)

dragonlore a écrit :

A moins d'un miracle, l'idtech 5 sera le premier moteur 3d d'id qui ne sera plus un étalon technique sur PC.
bref la fin d'une époque.

Ouaip, j'ai cru lire que carmack disait qu'à part le AA et l'AF on n'aura pas de gros changements graphiques entre les versions Xbox, ps3 et PC (et osx aussi !)

Ceci dit, si l'intérêt du jeu suit, pourquoi pas [:airforceone]

---------------
128DB - Instagram - Ventes

biboulMRPN

Preview Rage:

http://www.nofrag.com/2009/jul/19/31921/

XaTriX

86.4k€ - 99.6k€ eq.parisien
Transactions (1)

dragonlore a écrit :

A moins d'un miracle, l'idtech 5 sera le premier moteur 3d d'id qui ne sera plus un étalon technique sur PC.
bref la fin d'une époque.

Tant qu'ils arrivent à louer le moteur à tout plein de gens
Comparez l'id3 et l'id4 sur le sujet :pt1cable:

XaT

---------------
Proxytaf ? porn, xxx, hentai, camgirl, onlyfans, torrent, warez, crack, keygen, serials, darknet, tor, vpn, proxy, hacktool, metasploit, sql injection, password list, brute force, cp, gore, deepweb

AnthonyD

»»───(knee)───►
Transactions (0)

idTech4 n'est pas tres utilsé car c'est la merde a faire un portage console, l'idTech5 a été pensé pour etre portable avant tout dans l'optique d'etre adopté en masse comme l'est l'unreal engine 3 aujourd'hui

dragonlore

XaTriX a écrit :

Tant qu'ils arrivent à louer le moteur à tout plein de gens
Comparez l'id3 et l'id4 sur le sujet :pt1cable:

XaT

l'id3 s'est beaucoup mieux vendu que l'id4 et l'id3 était pourtant à la pointe quand il est sortit.

mais avec l'ue3 qui a pris énormément d'avance et le cryengine 3 pour les consoles, l'id5 va avoir plus de concurrence à l'époque et il va falloir qu'i lsoit bon pour être vendu.
l'ue3 était déjà vendu à beaucoup de développeurs avant que le premier jeu l'utilisant sorte. pour l'id5, il n'y a rien de visible pour l'instant.

dragonlore

theBride_ a écrit :

Ouaip, j'ai cru lire que carmack disait qu'à part le AA et l'AF on n'aura pas de gros changements graphiques entre les versions Xbox, ps3 et PC (et osx aussi !)

Ceci dit, si l'intérêt du jeu suit, pourquoi pas [:airforceone]

oui faudra voir l'intérêt mais c'est une constatation. Ils auraient pu faire un jeu multiplateforme et faire de la version Pc une version supérieure techniquement mais ça ne semble pas être le cas à part les sempiternelles choix de réso et aa et af en plus. on voit qu'ID est passé du pc comme lead platform à la console comme lead platform.

pour l'instant des jeux en monde ouvert beau et fluide sur console ça n'existe pas (surement du aux contraintes techniques de ces consoles) contrairement au pc (en monde fermé si ça existe sur console: voir uncharted par exemple). Comme ce rage semble se passer en monde ouvert, faudra voir si ID a surpassé tous les autres avec enfin une distance de vue très bonne sans se coltiner des textures SD, une absence de clipping des éléments et le reste au point.

Message édité par dragonlore le 20-07-2009 à 12:23:23

flav106

Vive la tartiflette !!!
Transactions (0)

Miam, ça s'annonce très bon tout ça ... [:huit]

---------------
PSN Flav106

bjone

Insert booze to continue
Transactions (0)

Apparemment ils ont repris les petits drones de Doom 3, la possibilité de construire des tourelles comme l'ingé de TF2.
C'est crair que d'un coup il redonne vachement envie ce petit Rage

ANViL

yep...definitely ♫
Transactions (0)

biboulMRPN a écrit :

Preview Rage:

http://www.nofrag.com/2009/jul/19/31921/

5 posts plus haut ..... [:fitterashes]

Sinon du reste, l'id tech 5 sera bien plus qu'un moteur tourné vers l'avenir et le multiplateforme : ce sera avant tout un outil permettant aux devs de s'afranchir des limitations techniques, toutes plateformes confondues. Le MegaTexture faisant déjà la joie des designer (cf le gars qui a été personnellement remercier Carmack pour le MT en lui disant que c'est l'outil dont tout artiste avait toujours rêvé pour pouvoir donner libre cours aux talents sans risques d'être limité :sol: )

Message édité par ANViL le 20-07-2009 à 17:32:07

---------------
Easy Ridin' ⎝⏠⏝⏠⎠

Profil supprimé

drap quoi

Hicks

Ya man!
Transactions (0)

Drapal

---------------
Il me reste un pays à connaître. Il me reste un pays à donner. Et le jour où ce pays naîtra, nul doute, je me souviendrai ---Gilles Vigneault---

XaTriX

86.4k€ - 99.6k€ eq.parisien
Transactions (1)

page sensationnelle

biboulMRPN

Teaser Comic-con

http://www.gamekult.com/video/8519903/

tfpsly

NoFrag citant Edge: Rage est deux fois moins fluide sur PS3

Citation :

Edge prétend que Rage tourne à 60FPS sur X360, mais seulement à 20-30FPS sur Playstation 3. Histoire de bien foutre la merde, ils n'ont pas jugé utile de préciser si ce "léger" problème sera corrigé avant la sortie du jeu. John Carmack explique les lenteurs actuelles en des termes imbittables que je ne m'aventurerai pas à traduire :

"The PS3 lags a little bit behind in terms of getting the performance out of it. The rasteriser is just a little bit slower - no two ways about that. The RSX is slower than what we have in the 360. The CPU is about the same, but the 360 makes it easier to split things off, and that's what a lot of the work has been, splitting it all into jobs on the PS3.

On peut supposer sans trop prendre de risque que "the PS3 lags a little behind in terms of getting the performance of it" signifie que Carmack estime que c'est juste une question de temps avant qu'ils réussissent à optimiser suffisamment le jeu pour obtenir la même fluidité sur les deux consoles.

À voir si ça se confirme... et si ça va être corrigé dans les versions finales.

Message édité par tfpsly le 31-07-2009 à 01:37:36

XaTriX

86.4k€ - 99.6k€ eq.parisien
Transactions (1)

Ca commence bien pour un moteur multiplateforme [:dawa]

Profil supprimé

tant qu'ils nous font pas un portage à la truelle xbox > pc ça va

ANViL

yep...definitely ♫
Transactions (0)

XaTriX a écrit :

Ca commence bien pour un moteur multiplateforme [:dawa]

Bon alors c'est là qu'on constate que certains n'ont absolument rien compris à la technologie de l'id tech 5 ... [:fitterashes]

- c'est justement parce que c'est un moteur multi-plateforme que les performances sont actuellement en deçà de celles de la X360 (c'est le même code exécuté sur 2 archis différentes dans ce cas-ci)
- le fait est qu'il n'y a justement aucun portage à réaliser vu que le code est identique pour toutes les plateformes, et la distinction s'opère à la compilation

Les améliorations de performances seront uniquement réalisées grâces à des techniques d'optimisation de routines (comme Q3 en son temps), et J-C l'avait déjà mentionné en 2008 lors d'une interview.

---------------
Easy Ridin' ⎝⏠⏝⏠⎠

tfpsly

ANViL a écrit :

- le fait est qu'il n'y a justement aucun portage à réaliser vu que le code est identique pour toutes les plateformes, et la distinction s'opère à la compilation

Oui à 80-90%.

ANViL a écrit :

- c'est justement parce que c'est un moteur multi-plateforme que les performances sont actuellement en deçà de celles de la X360 (c'est le même code exécuté sur 2 archis différentes dans ce cas-ci)

Non.

Profil supprimé

ben quand on sais que la ps3 est orientée SPU et la xbox/pc sont plus orienté sur le couple cpu/gpu quel est l'interêt d'avoir un code unique vuq eu ça ne fonctionne absolument pas pareil?

et avoir un moteur multiplateforme s'il ne tourne bien que sur une plateforme c'est étrange.

Je cherche pas a enflammer le débat, juste à comprendre.

Message cité 1 fois
Message édité par Profil supprimé le 31-07-2009 à 14:06:23

ANViL

yep...definitely ♫
Transactions (0)

Rayer de l'équation ce qui plombe les developpements multi-p depuis des années (plusieurs studios # travaillant sur des codes # avec des résultats finaux merdiques et des budget de prod astronomiques) [:prodigy]
Je gage d'ailleurs que l'id tech 5 sera un énorme succès commercial pour id, vu que c'est la première plateforme de dev à proposer une centralisation de dev aussi poussée [:cerveau meriadeck]

dixit ce qui a été dis ci-dessus : un code identique compilé pour des plateformes différentes et qui se comporte de manière similaire, c'est déjà énormément de travail. Si à cela tu rajoutes le fait de devoir tourner de manière similaire et à perfs équivalentes, c'est encore plus de travail (et sur ce plan, ça se jouera uniquement avec des optimisation hacks & co)

J-C à propos de ces optis :

Citation :

We’re doing a lot more of the traditional gaming hacks in the technology, because we’re a 60Hz game
[...]
This is one source tree and one environment, you build it and it works well on all these

Message édité par ANViL le 31-07-2009 à 14:36:00

---------------
Easy Ridin' ⎝⏠⏝⏠⎠

tfpsly

Ce qui pénalise le plus sur PS3 : tout code tournant sur SPU doit être écrit à la vieux-C : pas d'OOP, pas de structure, il faut bien mieux faire une structure de tableaux qu'un tableau de structures. Les SPU n'aiment qu'une seule chose : une boucle linéaire (sans test-branchement, sans if/else) sur plein de data ; et de préférence du code vectorisé le plus possible. Ce qui fait d'ailleurs que c'est assez difficile d'avoir du code gameplay tournant bien dessus. Du code orienté graphisme, touchant en boucle à plein de data (vertexes, pixels...) aura tendance à être plus adapté. Même si ça va à l'opposé d'un principe de base d'optimisation en 3D : ne jamais toucher sur le CPU les vertexes ou polygones individuellement, le GPU est en général plus adapté pour ce genre de job.

Je cite un post que j'ai fait sur le forum interne de ma boite :

Exemple simplifié de code sous-optimisé sur toutes les plateformes :

Code :

for(uint i=0; i<nbrParticles; ++i,++particle)
{
// branching on every single iteration - bad!
if( m_UseStandardSpeedUpdate)
{
particle->m_Speed += particle->accleration*deltaTime;
particle->m_Pos += particle->speed*deltaTime;
}
else
{
SpecialSpeedPosUpdate(particle);
}
particle->m_Lifetime -= deltaTime; // Not a vector, not optimal on SPU
[...]
}

Exemple simplifié de code un peu optimisé, mais toujours pas pour SPU :

Code :

if( m_UseStandardSpeedUpdate)
{
for(uint i=0; i<nbrParticles; ++i,++particle)
{
particle->m_Speed += particle->accleration*deltaTime;
particle->m_Pos += particle->speed*deltaTime;
particle->m_Lifetime -= deltaTime; // Not a vector, not optimal on SPU
[...]
}
}
else
{
for(uint i=0; i<nbrParticles; ++i,++particle)
{
SpecialSpeedPosUpdate(particle);
particle->m_Lifetime -= deltaTime; // Not a vector, not optimal on SPU
[...]
}
}
}

Exemple simplifié de code optimisé pour SPU :

Code :

if( m_UseStandardSpeedUpdate)
{
for(uint i=0; i<nbrParticles; ++i)
{
Vector4f speed = ma_Speed[i]; // Defeat memory aliasing
speed += ma_Accleration[i]*deltaTime;
ma_Speed[i] = speed;
ma_Pos[i] += speed*deltaTime;
}
}
else
{
for(uint i=0; i<nbrParticles; ++i)
{
SpecialSpeedPosUpdate(ma_Speed[i], ma_Pos[i]);
}
}
Vector4f *lifetime = (Vector4f*) m_aLifetimes;
const Vector4f vecDeltaTimes(deltaTime,deltaTime,deltaTime,deltaTime);
for(uint i=0; i<nbrParticles/4; ++i, ++lifetime)
{
// Use SIMD to update 4 particles' lifetime at once
lifetime -= vecDeltaTimes;
}

La version optimisée pour SPU (mais qui tournera aussi vite que la version précédente sur les autres plateformes) a un gros défaut : elle est méchamment plus crado. La structure Particle a complètement disparu, éclatée en plein d'éléments atomiques rangés à gauche et à droite dans différents tableaux.

Pour ceux que ça intéresse plus :

Message cité 1 fois
Message édité par tfpsly le 31-07-2009 à 16:04:06

Profil supprimé

montreal? t'es chez ubi? [:tinostar]

Profil supprimé

ah bne vu comme ça

CrowFix

Official Special Force
Transactions (0)

on est envahi par les Ubimen

---------------
Ma collec de jeux -

bjone

Insert booze to continue
Transactions (0)

tfpsly a écrit :

Je doute que l'Id-T5 soit plus "centralisé" que les autres gros moteurs. De fait, en général tout le code du game play, 99% du cœur de l'engin, et 90% du code de rendu est partagé entre les différentes plateformes, qui se ressemblent pas mal (plusieurs cores CPU + un GPU). Il y a certaines différences, notamment sur des post-fx que l'on fait tourner sur les SPU de la PS3 car le GPU est trop lent par exemple. Les SPUs sont pas mal pour aider le GPU, mais surtout pas pour le remplacer.

Ce qui pénalise le plus sur PS3 : tout code tournant sur SPU doit être écrit à la vieux-C : pas d'OOP, pas de structure, il faut bien mieux faire une structure de tableaux qu'un tableau de structures. Les SPU n'aiment qu'une seule chose : une boucle linéaire (sans test-branchement, sans if/else) sur plein de data ; et de préférence du code vectorisé le plus possible. Ce qui fait d'ailleurs que c'est assez difficile d'avoir du code gameplay tournant bien dessus. Du code orienté graphisme, touchant en boucle à plein de data (vertexes, pixels...) aura tendance à être plus adapté. Même si ça va à l'opposé d'un principe de base d'optimisation en 3D : ne jamais toucher sur le CPU les vertexes ou polygones individuellement, le GPU est en général plus adapté pour ce genre de job.

Je cite un post que j'ai fait sur le forum interne de ma boite :

Exemple simplifié de code sous-optimisé sur toutes les plateformes :

Code :

for(uint i=0; i<nbrParticles; ++i,++particle)
{
// branching on every single iteration - bad!
if( m_UseStandardSpeedUpdate)
{
particle->m_Speed += particle->accleration*deltaTime;
particle->m_Pos += particle->speed*deltaTime;
}
else
{
SpecialSpeedPosUpdate(particle);
}
particle->m_Lifetime -= deltaTime; // Not a vector, not optimal on SPU
[...]
}

Exemple simplifié de code un peu optimisé, mais toujours pas pour SPU :

Code :

if( m_UseStandardSpeedUpdate)
{
for(uint i=0; i<nbrParticles; ++i,++particle)
{
particle->m_Speed += particle->accleration*deltaTime;
particle->m_Pos += particle->speed*deltaTime;
particle->m_Lifetime -= deltaTime; // Not a vector, not optimal on SPU
[...]
}
}
else
{
for(uint i=0; i<nbrParticles; ++i,++particle)
{
SpecialSpeedPosUpdate(particle);
particle->m_Lifetime -= deltaTime; // Not a vector, not optimal on SPU
[...]
}
}
}

Exemple simplifié de code optimisé pour SPU :

Code :

if( m_UseStandardSpeedUpdate)
{
for(uint i=0; i<nbrParticles; ++i)
{
Vector4f speed = ma_Speed[i]; // Defeat memory aliasing
speed += ma_Accleration[i]*deltaTime;
ma_Speed[i] = speed;
ma_Pos[i] += speed*deltaTime;
}
}
else
{
for(uint i=0; i<nbrParticles; ++i)
{
SpecialSpeedPosUpdate(ma_Speed[i], ma_Pos[i]);
}
}
Vector4f *lifetime = (Vector4f*) m_aLifetimes;
const Vector4f vecDeltaTimes(deltaTime,deltaTime,deltaTime,deltaTime);
for(uint i=0; i<nbrParticles/4; ++i, ++lifetime)
{
// Use SIMD to update 4 particles' lifetime at once
lifetime -= vecDeltaTimes;
}

Exact, mais ça reste similaire au SSE/Altivec que l'on a sur nos x86 (enfin pour le SSE) à la maison ou sur le PPC d'une Xboite. Non ?
Le jeux d'instruction vectoriel des SPU est plus limité que le SSE ?
L'autre problème avec la PS3 c'est que le cell nécessite des transferts DMA pour alimenter ses SPU.
Pour un flow de donnée style DSP ça peut aller, mais quand tu est habitué à un système mémoire cohérent, ça doit faire un choc (et un gros sentiment de choses faites à moitié)

Message cité 1 fois
Message édité par bjone le 31-07-2009 à 17:21:52

tfpsly