BryanMcPhail.com

Professional software development, amateur BMW tinkering, old arcade game stuff

By

Lost game – Fear Factor Unleashed

Fear Factor Unleashed was a project for PC, Xbox and PS2 based on the Fear Factor tv show.  The time scale for the project was very short and the company had no existing cross-platform tech so the decision was taken to use the Renderware middleware.  At the time Renderware had a good reputation as it had been used in GTA 3 and Burnout.  It soon became clear though that GTA 3 and Burnout must have had a lot of programmers working on the engine, because what was in the base Renderware was not very impressive at all.  It’s no exaggeration to say we could have built our own PS2/Xbox/PC tech in the time taken working around Renderware problems or unimplemented features.

ff3 ff2 ff1

Regardless the game featured a mix of 3rd person platforming levels, vehicle based levels and special button press ‘eating’ levels to match the TV show.  It certainly wasn’t a triple A game, but was certainly competitive with other mid-range PS2 titles from around that time.  The game was never released as the publisher went bankrupt and although a few other publishers were interested nothing came of it.

ff6 ff5 ff4

There was some nice graphics tech in the game, such as heat hazes, render to texture effects, projected lights, reflective water on Xbox/PC and blur/disorient post-fx for when your ‘fear meter’ got too high!  I was the lead on the Xbox platform, but as it was only a small team (5 programmers total, later 4) I done a lot of work on PS2 and PC as well.  In particular I remember working on character collision detection – using a swept ellipsoid representing the character against the landscape triangle mesh.  Swept means you are colliding over time as well as 3d space – so you find out what position in the timestep a potential collision would occur.  There is a neat trick to swept ellipsoid detection – imagine transforming the world triangles by the inverse of the ellipsoid – so that if the ellipsoid was a perfect sphere the world is now ‘squashed’.  Then transform the triangles around the direction you are sweeping in (imagine looking down the movement direction defined and seeing the triangles in front you – essentially a barycentric space).  So now your ellipsoid is just really a 2d sphere looking at oncoming triangles – simply solve triangle versus sphere for every triangle and you have all your collision points!  (Testing vertex to be inside or outside of sphere, then line versus circle for each edge of the triangle).  The ‘depth’ in this space essentially gives the ‘time’ of collision, and you can just transform the results back to world space position & time step proportion when done.

ff10 ff8 ff9

 

 

By

Fighters History protection chip

I found an interesting project on a backup harddrive from 2002 which was the ‘Trojan horse’ software I wrote to analyse the software protection device on the Data East Fighters History arcade pcb game.

I doubt the code itself is very useful anymore but the process it used may still be interesting.  You can download the files >here

fh2fh3

FH used an ARM cpu – ARM cpus are everywhere these days but were still quite rare in 1993!  Coupled to this was a copy protection chip that essentially had a range of input ports the CPU could write to and modified results could be read back.  By writing game code variables to the chip and the code that read them back ‘knowing’ the permutation that would be applied the copy protection was quite effective.  Unless you knew all the hardware permutations game code would at worst crash and at best behave incorrectly – drawing wrong graphics, game moves not working correctly, etc.  Because it was close to impossible to guess what the protection chip did just by examining the software the only solution is to run special software on the board that deliberately probes the protection device by writing known values and examining the results returned.  Hence ‘Trojan horse’.

Unlike earlier 8 and 16 bit games it was actually feasible to use a modern C compiler to write code to run on this device, so the official ARM c compiler was used (circa 2000) and the flow was C program -> .o ASM file -> patch ASM into original ROM image -> split ROM image into 2 16 bit images -> burn ROMs to EEPROM -> install EEPROMs on board -> get results!

The main components on the pcb board below are A – the ARM cpu (not marked as ARM – they only licensed the design so the chip was fabricated for Data East and is marked as such).  B – two 16 bit program EEPROMs – the 16 bit data buses are interleaved to provide a 32 bit stream for the CPU.  C – the protection chip itself.  The fact it’s mounted on a daughterboard suggests it was added to the hardware design fairly late.

fh

 

Recently I noticed Charles Macdonald had furthered the work I done on this – http://cgfm2.emuviews.com/new/detech.txt

 

 

By

Crypt Talker

Around 1995-1998 I worked on a telnet style chat server for Unix and Windows NT.  Any trace of it has long disappeared from the web except I found someone that forked it and added it to Sourceforge around 2005!

http://sourceforge.net/p/crypttalker/news/

There’s some vintage old school C code in that project for sure – who remembers declaring C functions like this?

 

main(argc,argv)
int argc;
char *argv[];
{

 

It had some nice features for internet in the 90′s.. the server opened a port for HTTP as well as chat, so web pages could be generated on the fly from the data associated with the logged in users, so names, descriptions, login times, could be mirrored to a web page.

I found one of the last source code zips and placed it here for download.

By

VCMame

VCMame archive project has been added – this allowed the use of Visual Studio 6 and Visual Studio .NET to build and debug the MAME project as opposed to the standard GCC/GDB/makefile command line setup.

http://www.bryanmcphail.com/vcmame/