Comment by anthk

Comment by anthk a day ago

With the PS2 you are right. With the PSX... so-so. Yes, it could match maybe a Pentium 90 almost 100, but a MMX pentium with 3DFX would stomp it and be on par of the N64 if not better.

MIPS CPU's are amazing, they can do wonders at low cicles. Just look at the PSP, or the SGI Irix.

Also, the PS2 "GPU" is not the same as the R4k CPU. BTW, on the PS2... the Deus Ex port sucked balls against the PC port, it couldn't fully handle the Unreal engine.

Yes, the PS2 did crazy FX, but with really small levels for the mentioned port; bear in mind DX was almost 'open word' for a huge chunk of the game.

rasz a day ago

> With the PSX... so-so. Yes, it could match maybe a Pentium 90 almost 100, but a MMX pentium with 3DFX would stomp it

Pentium much faster than MIPS CPU for game logic, 3dfx 50 MPixels/s fillrate matches Playstations 60 MPixels/s, Pentium FPU tho is no match for Playstation GTE 90-300K triangles per second meaning you would have to rely on CPU power alone for geometry processing (like contemporary Bleem) resulting in 166-233MHz Pentium minimum requirements. MMX would be of no help here, it was barely used in few games for audio effects.

Reply View 2 replies

anthk 14 hours ago

Bleem it's an emulator; it emulates the architecture, is not a virtualizer. 233 MHZ to emulate the 33 MHZ PSX seems reasonable, Windows 95/98 take up a good chunk of the CPU themselves. But, you forgot something.
The PSX "GPU" just worked with integers and that's it. Any decent compiler such as GCC and flags like -ffast-math would emulate the both dead simple MIPS CPU and the fixed point GPU where no floats are used at all while taking tons of shortcuts. MMX? Ahem, MPEG decoding from videos. If you did things right you could even bypass the BIOS decodings and just call the OS MPEG decoding DLL's (as PPSSPP does with FFMPEG) and drop the emulation CPU usage to a halt and let your media player framework do the work for you.

Reply View | 1 reply
- rasz an hour ago
  
  Bleem didnt need 233MHz Pentium to emulate 33MHz MIPS CPU, it needed it for the geometry (rotation, scaling). GTE 90-300K triangles per second is a LOT LOT. Geometry was the bottleneck of PC games in mid nineties. For example contemporary Quake was heavily optimized to operate on as little geometry as possible (BSP), rendering up to ~1000 triangles per second while only ever touching up to maybe 10K? triangles (I dont want to research this down to instrumenting quake code/looking at map data, Google results suggest PVS leaves are as small as hundreds of triangles) in active Potentially Visible Sets (PVS) at any given time. Playstation 1 on the other hand DGAF and could rotate/scale/light whole levels on every frame with raw power of GTE.
  MMX was meant for anything you would normally use traditional DSP (also fixed point). Intel envisioned software modems and audio processing, in reality it was criminally underused and fell into 'too much effort for little gain' hole. Intels big marketing win was paying Ubi Soft cool $1mil for POD "Designed for MMX" ad right no the box https://www.mobygames.com/game/644/pod/cover/group-3790/cove... while game implements _one audio filter_ using MMX. Microsoft also didnt like Intel's Native Signal Processing (NSP) initiative and killed it https://www.theregister.com/1998/11/11/microsoft_said_drop_n...
  MP3 - you could decode on Pentium ~100 so why bother, MPEG Pentium ~150 will play it flawlessly as long as graphic card can scale it in hardware. I would love to see the speed difference decoding MPEG with ffmpeg between Pentium 166 with and without MMX. Contemporary study shows up to 2x speedup in critical sections of image processing algorithms but only marginal gains for mp3/mpeg cases https://www.cs.cmu.edu/~barbic/cs-740/mmx_project.html
  >drop the emulation CPU usage to a halt
  Playstation 1 doesnt support MPEG.
  Now could you implement GTE with MMX? Certainly yes, but again why bother when already 166-233MHz CPU is enough to accomplish same thing with integer unit alone.
  
  Reply View | 0 replies