- Created: 14 August 2007
- Written by bositman
In our spare time, some of us do little things to amuse ourselves and others, generally involving the betatesters, the devs, or generally people who come in the IRC channel.
You may have previously seen CKemu's "Betatester Magazine" issues or his comic strips involving testers and developers. Well my "party piece" is making little songs, with the help of some of our IRC chatters of course!
Bositman is well known throughout the community, so we (being myself and GB_Away) decided a while ago to make a little song in his honor, it was catchy and fun to make but i wasn't totally happy with the sound. Recently i decided to remaster the song and redo the guitar, so for your listening pleasure i have placed it online for all to be amused!
The lyrics are simple but they say enough!
"Bositman, Bositman, ooooooooooooo, Bositman, Bositman, Bositman, Bositman, BOSITMAN!, Bositman, oooooooooooooooo, Bositman, Bositman, Bositman, Bositman"
And here in nice 320kbps 48khz MP3 format, is the song, enjoy!
Edit by bositman: Dude,I told you it's not pronounced as an "s" but "z"!!
Refraction Feat GB_Away - Bositman.mp3
- Created: 07 August 2007
- Written by ZeroFrog
It was apparent early on the project that the GS plugin was going to be a big bottleneck during 3D scenes. It isn't that the GS plugin itself does a lot of computation on the CPU, but the fact that it needs to communicate with the graphics card means that unnecessary stalls will occur in the graphics driver as the GPU and CPU are synchronized. During these stalls, the CPU basically goes to lunch until the GPU is ready. Graphics drivers and libraries are aware of this and try as little as possible to communicate with the graphics card. They usually cache render state changes, shader changes, and texture changes up until actual geometry is rendered. They also take advantage of FIFOs (first in first out buffers). The CPU just writes to the FIFO and the GPU just reads from it, this makes all the difference in terms of keeping the GPU active while the CPU isn't and vise versa.
The biggest challenge when designing games and hardcore applications that need to use the GPU to its full potential is to make sure that graphics driver stalls are minimal at all costs. What kills games isn't sending geometry down the graphics pipeline, but it is when render targets are switched, render targets are used as textures in the next draw call, textures are locked, and when render targets are transferred from GPU memory to CPU memory (in the last case, the CPU not only goes to lunch, but has dinner also). GPU optimization talks usually appear in every Game Developers Conference and there are many papers on them on the net, so there is a lot more to the story than written here.
All this means is that single-threaded applications really need to design their GPU algorithms well to see fast frame rates. This unfortunately is not possible with Pcsx2 and the GS plugin. The GS plugin has to draw geometry in the same order as it was received. This kills almost all caching techniques used by modern games because the GS and PC GPUs have very different performance bottlenecks. In modern GPUs, it is advantageous to group as much geometry as possible in one draw call. The GS doesn't suffer from such bottlenecks. The GS also has two different contexts which makes things twice as difficult. ZeroGS can only do a limited amount of work-arounds before compatibility starts dropping, so the only other option is to try to multithread the GS. Note that using graphics libraries from multiple threads is not a trivial task.
Fortunately, the GS plugin is very unique in its nature. 99% of the communication that happens between the GS plugin and the rest of the systems components happens in the direction to the GS. The only times the EE needs to synchronize with the GS is when it reads back the FINISH/SIGNAL registers and part of the 4Mb GS memory. Register readbacks are used frequently, so this suggests that tight synchronization will be needed with the GS. The GS memory readbacks aren't as frequent; however, they require some special considerations with Virtual Memory and DMAs. The rest of the 99% of communication that goes to the GS happens with a GS FIFO.
When first started, Pcsx2 creates a GS thread and reserves special memory for the GS FIFO. The GS plugin then creates the Direct3D device/GL context only for that thread. Then when the game runs, the EE copes all its GS packets to the FIFO and then notifies the GS thread. The GS thread then checks if the FIFO has data, and then sends it to the GS plugin. This sounds easier than it actually is because very tight synchronization needs to happen to make sure no overwriting occurs in the FIFO. The FINISH/SIGNAL register synchronization actually doesn't happen across the EE and GS thread boundaries. Instead the EE thread peeks at all the packets ahead of time and handles it in its own routines.
What makes the "Dual Core" option special is the notifies part of the last explanation. The GS thread can either sleep waiting for a notification from EE, which can be done by WaitForSingleObject and SetEvent functions. Or it can continually check if the GS FIFO is empty without ever stopping. The latter option kills single cores but goes much faster on dual cores. The results of clicking on the MTGS and DC options on dual cores are phenomenal. Usually frame rates go up or even surpass 2x.
Multithreading in games is going to be very big in the future. The times have passed when there is one CPU that does everything and one GPU that just renders. The biggest problem is which game processing to divide into which thread, and how these threads will communicate with each other. Many of these issues are still open and current game companies are struggling with the added complication of concurrent execution.
Moral of the blog - GPUs have become so powerful that people are staring to do tasks like stereo vision and general purpose computation with them. Learn how to use them. I recommend ShaderX3: Advanced Rendering with DirectX and OpenGL by Wolfgang Engel and GPU Gems 2: Programming Techniques for High-Performance Graphics and General-Purpose Computation by Matt Pharr, Randima Fernando, and the 20+ researchers that contributed to it.
- Created: 06 June 2007
- Written by CKemu
Testing can be a comical affair!
For instance Katamari Damacy, the poor little pint sized prince kept on falling through the universe, even better is the King would keep apologizing for a Royal Warp and return the prince to a new location, only for it to happen again.
Metal Gear Solid 3 suffers(ed) from a similar problem, Snake would suddenly drop though an invisible hole, causing the classic "Snake, are you alright? snake? SNAKE!!!"
Final Fantasy X still suffers from characters getting placed the wrong way around, so they run away from the monster, smite it and somehow return to the same position. WipeOut Fusion also suffers from things going backwards, every ship gets placed the wrong way around, and the AI along with you have to turn around before they can race!
Tekken Tag has Squishy Head Syndrome, you kick a character in the face and your head goes perfectly flat, suddenly "anything but the face!!" takes on an entire new meaning!
Over the course of testing for PCSX2 the team has encountered thousands upon thousands of bugs, but despite popular belief that all bugs are graphical, many of these bugs are much more bizarre. In fact the PCSX2 project may have released many a fine video demonstrating progress, we could have released an epic film trilogy of bloopers by now.
Now admittedly finding a bug requires the tester to try hundreds of program combinations (plugins, recompilers settings, debug options etc), make long debug logs and attempt to find the bug in the debugger or trace the origin of the bug if it's a regression, but sometimes just watching the bug makes it all worthwhile!
I fondly remember the linuz.naked_bug();, where characters in Street Fighter EX3 would be missing clothes - specifically the women missing skirts. Or how about every character in Final Fantasy X being Tidus, yes folks EVERY character, from enemies, to people walking around, nothing like hearing the pretty girl-boy with Yuna's voice!
Sometimes It's tempting to suggest we add an option to the emulator to "re-create" these bugs, from totally missing collision detection, AI going berserk, to people floating upside down, but alas we're here to emulate the PS2, not our goofs.
So next time you think of emulation bugs, do not assume they're always graphical, or some complex mind boggling bug that causes the game to do nothing - sometimes, just sometimes there's a poor unshaven tester in a darkened room, covered in coffee that they've just spat out because Lara Crofts boobs have just exploded, or Gran Turismo cars have just developed anti gravity drives!
So as a rare treat, and somewhat a prelude to current Work in Progress, here's a game with some of it's bugs intact!
Katamari Damacy - Status at time of writing: Ingame
List of testing notes:
- Floor Bug, seems the textures they use to do floor detail are layered? (zBuffer)
- Object clipping bugs (walls etc).
- Katamari Mask? (the circle around the katamari, perhaps used to cull objects under the outer layer of what you have collected?).
- Stuck on pillar, can't go anywhere bug! (Level 3).
- Created: 30 May 2007
- Written by CKemu
Emwearz has a really sexy sister. She's an up and coming model, and would like to do some promo shoots wearing a specially made PCSX2 t-shirt and her favorite white thong.
However we've run into a snag, emwearz doesn't want his sister doing such photo shoots, especially when they would be wet t-shirt and highly provocative (think FHM / Maxim style). Hence we need you the viewer!!!
Edit: Forgive CKemu,it's that time of the month again...(and don't edit my edits!)
PM EMWEARZ via the NGemu forums here with the subject "Hey emwearz, is your sister single?", if he receives enough of these PM's he has promised to let his sister do this photo shoot!
PS: This is a joke, to wind one of our good buddies up...feel free to PM him though (she is hot)
- Created: 04 May 2007
- Written by CKemu
PCSX2 is perhaps one of the few projects that releases a constant series of videos demonstrating development progress, and whilst I'm not 100% sure on this, I believe the only emulator to have had two "promo" videos demonstrating that yes indeed, PS2 emulation is possible!
These videos are delivered to you via Bit Torrent on our videos page, which for an emulation site is somewhat unique. In fact so "odd", I've had emails asking me if the use of Bit Torrent is legal, surprisingly Bit Torrent can and is used for legal distribution!
You might wonder why such "promo" videos are made, it's somewhat unorthodox, well aside from the fact they are good fun to make, they serve to demonstrate what this project is doing as many people still don't believe that this is even possible!
How are these videos made? Simple!
When using zeroGS you merely have to press F7 to start recording to your preferred codec, you then press F7 to stop recording, at this point you can just quit the emulator and marvel at your video, or you can keep playing! Press F7 again to add more footage to your video, and again press F7 to stop recording, this will produce one video based on where you stop/start recording.
zeroGS automatically speeds up footage to "normal" speeds, which causes issues if you want to record audio in sync with the video footage. P.E.Op.S SPU2 DSound Driver records at "emulated" speed and if the recording was muxed with the video recording, it would be significantly out of sync.
However, you can get around this issue by disabling MTGS / DC modes from the CPU settings dialog, and setting P.E.Op.S SPU2 DSound Driver to Thread Mode. To ensure sync with the video, set P.E.Op.S SPU2 DSound Driver to start recording before you confirm the codec you wish to record with.
You then can put the audio and video streams together in your preferred video editing software, for simple tasks like this I recommend VirtualDub.
The ability to record video directly from a PS2 game has significant benefits over camcorder or TV card recording as you can get fantastic quality at higher resolutions than the PS2 can natively output.
For the gaming enthusiast it lends itself nicely to demonstrating how kick-ass you are at a game, or lets you demonstrate secret areas, advanced combos.
YouTube obviously offers a space to share such videos, and many people from all over the world already show fantastic videos from PCSX2, even the team use YouTube as a low bandwidth option to our high quality torrented videos.
YouTube is also used by some testers to demonstrate intermediate work, and this videos are normally only shown on the official forums as a bonus to our forum browsers, an example of this would be the following video demonstrating Final Fantasy XII no longer suffering from vanishing text:
So go on! Search YouTube for "PCSX2" and check out what our users are posting! I personally get a great deal of pleasure from seeing this emulator being enjoyed and used.
If you feel inclined why not record your awesome combo powa's, or you defeating some insanely tough boss and then place them on YouTube.
If something catches our eye, you may just get a honorable mention here! We already place user made screenshots from the current release in our screenshots section!
Resident Evil 4 - Pervert (RPGWizard)
FFX-2 Secret Ending (NexXxus86)
PCSX2 Developers 0 - 1 Betatesters
Nothing to do with PCSX2, but testers RULE KTHX! HIHI