Raspberry Pi3 ou ODROID C2
-
@voljega said in Raspberry Pi3 ou ODROID C2:
@kevin-geyer la PSX est nickel sur Pi3 et la N64 est pourrie partout.
Bref tu veux absolument un C2 ? Va l'acheter.
Parce que sinon on s'arrête là on va passer des jours à te dire que c'est pas un bon choix non plus.
Pas la peine de s'énerver, je me renseigne parce que je peux récupérer un ODROID c2 pour 20 € chez un ami.
Pourquoi la N64 est pourri partout ? Pourtant si le Pi3 arrivea faire tourne la PSX pourquoi pas la N64 ?
-
@kevin-geyer si la N64 tourne moyennement même sur des machines performantes c'est à cause de ses emulateurs. Ils sont moins optimisés que pour d'autres systèmes, du coup il y a de moins bon résultat en jeux.
J'ajoute que pour 15€ de plus que le C2 de ton ami, tu peux avoir un pi3 B ou B+ qui sont soutenu par une grande communauté et qui te donneront des résultats très satisfaisant
-
@Kevin-geyer
Le RPI3B est tres stable. Le XU4 est peu capricieux (Bluethooth, bruit du ventilo etc ...) -
@kevin-geyer said in Raspberry Pi3 ou ODROID C2:
Pourquoi la N64 est pourri partout ? Pourtant si le Pi3 arrivea faire tourne la PSX pourquoi pas la N64 ?
Parce que la N64 avait un hardware obscur et mal branlé, qui est encore très mal émulé aujourd'hui
-
-
@gaetan Ben c'est vrai, hein example : http://digitalfantasy.angelfire.com/n64-hardware-specifications.html
The Nintendo 64 had some glaring weaknesses that were caused by a combination of oversight on the part of the hardware designers, limitations on 3D technology of the time, and manufacturing capabilities. One major flaw was the limited texture cache of 4KB. This made it extremely difficult to load large textures into the rendering engine, especially textures with high color depth. This was the primary cause of Nintendo 64's blurry texturing, secondary to the blurring caused by the bilinear filtering and limited ROM storage. To make matters worse, because of how the renderer was designed, if mipmapping was used the texture cache was effectively halved to 2KB. To put this in perspective, this cache could be quickly filled with even small textures (a 64x64 4-bit/pixel texture is 2KB and a 128x64 4-bit/pixel texture is 4KB). Creative developers towards the end of Nintendo 64's lifetime managed to use tricks such as multi-layered texturing and heavily clamped small texture pieces to simulate larger textures. Conker's Bad Fur Day is possibly the best example of this ingenuity.
There were other challenges for developers to work around. Z-Buffering significantly crippled the RDP's fillrate so managing the Z-depth of objects, so things would appear in the right order and not on top of each other, was put on the programmer instead of the hardware to get maximum speed. Most Nintendo 64 games were actually fillrate limited, not geometry limited, which is ironic considering the great concern for Nintendo 64's low ~100,000 polygon per second rating during its time. In fact, World Driver Championship was one of the most polygon-loaded Nintendo 64 games and frequently would push past Sony PlayStation's typical in-game polygon counts. This game also used custom microcode to improve the RSP's capabilities.
The unified memory subsystem of Nintendo 64 was another critical weakness for the machine. The RDRAM used was incredibly high latency memory (640 ns read) and this mostly cancelled out its high bandwidth advantage. A high latency memory subsystem creates delays in how fast the processors can get the data they need, and how fast they can alter this data. Game developers also said that the Nintendo 64's memory controller setup was fairly poor, and this magnified the situation somewhat. The R4300 CPU was the worst off component because it had to go through the RCP to access main memory, and could not use DMA (the RCP could) to do so, so its RAM access performance was quite poor. There was no memory prefetch or read under write functionality either.
Despite these drawbacks, the Nintendo 64 hardware was architecturally superior to the PlayStation. It was, however, more challenging to program for and to reach peak performance/quality.
-
Finalement j'ai acheté l'Odroid C2 de mon ami à 20 € parce que cela comprenez la carte mère, le boîtier, micro SD de 16 Go et l'alimentation.
J'avais déjà un raspberry pi3 celui-ci je l'ai mis avec Recabox et l'Odroid C2 avec Libreelec vu qu'il c'est déchiffrer le H265 matériellement jusqu'en 4k
-
C'est vrai que le H265 n'est pas le fort du RPI3.
Mais pour les jeux, il couvre une énorme partie des consoles, donc génial pour recalbox. -
@voljega said in Raspberry Pi3 ou ODROID C2:
La PSX marche parfaitement sur Pi3...
A quelques exceptions près (je pense à certains jeux non-compatibles ou étrangement gourmands, souvent des jeux squaresoft : Parasite Eve 2, Tobal 2, iS - internal section, ...), mais je doute que le XU4 fasse mieux de toute façon.
-
@barbudreadmon Tobal 2 j'ai pas de problème ?
Mais oui sinon c'est plutôt des problèmes au niveau de l'émulateur, Dynasty Warriors rame à mort aussi -
@voljega said in Raspberry Pi3 ou ODROID C2:
Tobal 2 j'ai pas de problème ?
Ah ? Dernière fois que je l'ai testé, j'avais des gros ralentissements et des glitchs graphiques sur l'écran titre, remarque c'était sûrement sur mon mini pc car je me souviens avoir testé sur mednafen derrière et avoir eu exactement les mêmes problèmes. Bizarre que celui-là marche bien sur un rpi3 et pas sur un x86_64 @ 2.56Ghz .
-
@barbudreadmon je confirme ce que @voljega dit, Tobal 2 fonctionne bien sur pi3
-
oui le C2 est parfait pour libreelec, mais pas pour recalbox, vaut mieux rester sur un pi3, car je sais pas combien de fois faudra le dire, la N64 sous linux c'est bon pour un aveugle manchot, et avec un seul doigt sur l'autre main.....
la N64 fonctionne assez bien sous windows, mais ABSOLUMENT PAS sous linux, quelque soit le materiel.