The development system costs $10,000 and requires signing an NDA. Also, SCEA generally want to see a business plan or some indication that you're going to release product.
It's very complex hardware to work with in any significant way. Very powerful, but when you have 6 functional units (EE, VU0, VU1, GS, IOP and SPU) all operating in parallel and synchronised (generally) by DMA commands, it's going to be tough to program. At least C++ and STL do work pretty well, there are plenty of companies relying on them for their games. Be thankful for small mercies:-)
In all honesty I would not recommend you look to straight PS2 development for your project. I have some alternate recommendations:
PS2 Linux kit - may not be released in the USA, or not in time for your needs. Runs on the consumer PS2 (with the HDD addon) and has more library support.
Gameboy Advance - has some of the PS2 issues, namely expensive development hardware and NDAs, but much easier for a single programmer to produce something credible on with.
XBox - you can do most of your work on a regular PC under DX8. Easiest programming environment of the 3. But if you do this, maybe you would be better just on a PC with a GeForce 3?
The Nintendo64 used a R3400 and the PSX used a R3300 (I think, unsure about that one) so you might consider this synergy to have already taken place:-)
Personally I think it's a good thing for consoles to use the same CPU architecture because it makes the compiler vendors' lives easier, which means their tools are better, which means game programmers' lives are easier, which hopefully means better games.
Ok, here's a summary of the various PS1 and PS2 development hardware.
You start work on a development kit - this is the expensive PCI card for PS1, or the big black tower (the T10000) for PS2. This hardware supports source-level debugging, has more memory, etc and is what you do your main development on.
Once your game is well on the way to completion (eg. it can fit in the memory of the consumer hardware, it doesn't crash too often) you start to make bootable discs that run on what are called debug stations. The blue PS1 was the debug station. For PS2 the debug looks like the consumer unit except it says 'TEST' on the top instead of 'PS2'. The debug stations can operate from CD-R and DVD-R media (no copy protection). These are primarily so your testers can run the game before you submit it to Sony.
The black PS1 (the Net Yaroze) wasn't even as full-featured as a debug station - it couldn't boot from CD-Rs. Plus, you could only download your own code to it after booting from a special black CD. Given that this PS2 hobbyist kit is for the consumer PS2, there won't be CD-R support there either.
You're right that the serial link between controller and console is probably not sufficient for real time video and you're also right that it's probably an undesirable user interface choice.
However, you could do a rear view on the GBA if you wanted. Who says you have to treat it as a dumb terminal and pour full-frame video to it? I'd write essentially the guts of a simple driving game on it, download that and the sprite data at the start of the race, and then just send the relatively small amount of info indicating position and so on each frame.
That said, I'd use it to indicate things like tyre pressures, distance to next/previous car, fuel level, overhead track view with green/yellow/red flag status, instructions from the pit and so on and so on.
Incidentally although I believe NFL2K does have VMU play calling, a screen as small and as low-contrast (partly because of the thick plastic frame on the Dreamcast controller, in my opinion) as the VMU is of limited use for that. You need enough pixels and colours to give some indicator of what the play actually does.
As for analog, I have no idea if Nintendo has done this, but the D-pad could be pressure-sensitive like the PS2 Dualshock2 controller's D-pad, face buttons and shoulder buttons. Personally I was also hoping for 4 front buttons on the GBA, too, but it's still a great piece of hardware even with 2 buttons and a (likely) digital-only D-pad.
I not only own a Playstation2, but I program for the hardware. You're wrong. Games, as part of their initialisation, have to tell the graphics chip whether to go into PAL mode (50Hz) or NTSC mode (60Hz).
This has numerous consequences. The amount of video memory used for the framebuffer changes, because you can show more scanlines at 50Hz. This impacts texture uploads, drawing rate and many other areas of your rendering pipeline's timing. A well-programmed game (hopefully) won't count the passing of time in terms of vsyncs (PS2 has a CPU cycle counter and other high-resolution interrupt timers), but it also has to ensure framerate doesn't drop, and so you might move the camera on a PAL system or make some other change. There's also the issue that colour balance is different between PAL and NTSC (PAL copes better with saturated red, in particular) so you might want to process your artwork slightly differently as part of your build process. All these things make the 'bit identical' assumption invalid.
By the way, game consoles are still programmed 'to the metal'. No matter how complex or powerful they get, they always will be, because that's how you get the most performance for your specific requirements. PS2 is designed very heavily around that concept.
For the original Playstation there were "anti-piracy" mod chips which allowed the console to play imports but NOT CD-Rs. The copy protection on that system worked by checking for a character stream coming from sideband data on the disc.
The "anti-piracy" version was done by only rewriting part of the data stream coming from the CD rather than generating the whole stream in the mod chip, thus you needed a black disc to generate the rest of the stream.
Just a nitpick. I'd expect the Australian law prohibits both intents equally, however.
Ok, the story is light on details and nobody else here seems to have any understanding so here is the real skinny. This is an expanded version of the GS (Graphic Synthesiser) chip in the PS2. I expect even the same clock speed, from the 75 million poly number. By the way, that number is a theoretical peak based on it taking 2 cycles to do triangle setup of a flat-shaded untextured polygon.
Your comment about triangles having 3 verts thus cutting the performance in half is wrong though. Tristrips get you pretty close to 1 vert/poly. Each time you kick a vert you use the previous two kicked verts to form your poly. Thus, a 20 poly strip only needs 22 verts. You are correct that texturing and shading require more setup time, however. Generally you're at 5 cycles of setup time and thus 30 million polys/sec.
2560 bit bus is because you have 16 functional units in parallel, thus 160 bits per unit. 32 bits framebuffer read, 32 bits framebuffer write, 32 bits Z buffer read, 32 bits z buffer write, 32 bits texture read giving 5x32 = 160 bits total. Note you need all these accesses to happen concurrently to fully render a pixel in 1 clock cycle. This is all internal to the chip, too. The external bus interface is 128 bits.
The advantage of having 32 megabytes of on-die memory is that you can generate many full-screen buffers in 32 bit and use them as texture sources for high-quality image processing effects like motion blur or depth of field or environment mapping. Think of that 32 megabytes as a big cache. You could store many more megabytes of texture in system memory and DMA them up to the GS for rendering as needed.
This latter fact is also true for PS2. I generally suggest that people think of the PS2's graphics chip (NOT the cpu core) as 16 Voodoo1s in SLI, overclocked to 150mhz, on a 32x AGP bus. To be sure, PS2 has some developer issues but lack of texture memory is not that high on the list.
The 'router' comment surely refers to the Emotion Engine itself. Sony developed that chip in a joint venture with Toshiba and it is manufactured in a fab owned by the Sony/Toshiba JV. It's essentially a 300MHz MIPS core with the ability to do lots of floating-point math in parallel.
I am surprised that this chip is only news now, Sony demonstrated this concept at the last SIGGRAPH (the GSCube machine). It's intended purpose is to replace render farms. Put 16 of these chips together and you could do semi-close-to-pixar rendering quality in semi-realtime. Good enough to preview animations and lighting and so on.
As one of the Pinball 2000 programmers, maybe I can shed some light.
Pin2000 uses PC-Xinu as the basis of its core OS although we added a lot of functionality to it. This was the decision of Tom Uban who was the chief software engineer on the project and all-round hardcore superstar programmer in general. PC-Xinu already includes a TCP/IP stack, and he had already written a packet driver for one kind of Ethernet card because we did all our code and image downloads via ethernet during development. A really simple web server wasn't too hard to write on top of that - all the statistics it reports are already collected by the game and displayed on-screen in the administration menus.
We demoed another use of the TCP/IP stack at Pinball Expo in 1999, where we had a tournament automatically running. We produced barcode badges for entrants, they walked up to a game, swiped the badge in a barcode reader, played, and their score was recorded. We also took their picture with a webcam and printed it on the badge, and the games showed the current high score list including their digitised pictures on all the games during their attract mode (ie. while they weren't being played).
Since I work for a company that makes arcade games and since I did video programming for such a system, maybe I can help:-)
Arcade monitors come in two kinds (mostly). Low res and medium res. Low res will only do 240 scanlines at 60hz, medium res is normally 384 scanlines at 60hz. The biggest problem you'll face is that these days everything is 480 scanlines minimum, with the low-level video hardware line doubling for 'old' modes.
The system I worked on, Pinball 2000, used a Cyrix MediaGX for CPU and video and we could happily drive a low-res monitor at 640x240 at 60hz but we were not using a VGA mode. On that hardware VGA is _emulated_ so we threw that away and set all the timings up ourselves at the register level. It was a pain to get right, requiring an oscilloscope to provide sanity checks that we were getting the correct frequencies.
So, sure, you can hook a coin-op monitor up to your PC but it will likely require more work and be less useful than most would want to deal with.
We used a MediaGX board for Pinball 2000. We used the standard BIOS on the board too, since it knows how to do all the chip initialisation and also things like how to configure the memory controller for the specific type of memory you have installed so you get the best performance.
You can use either the video BIOS or network BIOS extension areas in the memory map. If there is valid data in them the system BIOS will call out to them at various points in its boot sequence. Now, these windows are very small (32k I think), but of course if your EEPROM is on a PCI card and memory-mapped, your 32k boot ROM can download code into system RAM for execution once the BIOS finishes doing its stuff.
The value you place on your privacy is exactly that; a personal value judgement. Your assessment is fine, for you. The key issue is that you get to make that choice rather than someone else making it for you.
I don't work for Epic, but maybe I can answer your question.
How about pixel and vertex shaders? Under DirectX 8 there's a standard microcode language for designing these and all the upcoming video cards will support this. Write your shaders once and they'll work on whatever next-generation video card your Windows gamer owns. Under OpenGL support will be vendor-specific (via extensions).
Shaders will be tremendously important for next-generation games. They allow lots of advanced surface effects (furriness/hairiness, all the various uses of bump mapping like beads of sweat on a person's skin or water dripping down walls to name but two) you just can't get with conventional multitexture or multipass because you'd need so many passes even 8 bits per channel is not enough to avoid enormous quantisation error. John Carmack was talking about this just recently in his.plan in fact.
DirectX also has texture memory management more suited to games, especially games which algorithmically generate textures (like the lava, fire and water in Unreal). OpenGL takes a very high level approach to this which makes texture management nicer to program for but less efficient both in RAM and CPU terms (converting textures from one format to another and storing multiple versions in memory). Remember, performance also ties to features. If something only runs 15fps on a P3-800 with 256megs of RAM, it's not going to go in the game because it will make the game play badly on most people's systems.
I used to work for Williams and now I work for Midway.
Williams no longer makes pinball - that operation was terminated last October 25th (and was the reason for my job change).
Midway owns all the rights to the games. When Midway and Williams were a single entity they were transferred to Midway.
If I understand things correctly (this isn't something I personally worked on) you're actually playing the real game code on an emulator made as a Shockwave plugin. Digital Eclipse's logo is there and they are the people who did all the emulators for the arcade classics compilations Midway sells for PC and Playstation and Nintendo 64.
Bear in mind that there is a thing called subsidiary rights, which means that the original people who worked on these awesome arcade games (not I, being only 26:-) ) still get paid if you buy the games.
1) You could also just get the EE core specs and write a gcc backend. I believe Toshiba makes this information available (the base CPU core is designed for more than 'just' PS2).
2) This won't work. PSX CDs use ISO 9660 but they have extra data on them too and without a way to put that data on the disc you can't make a bootable disc for a regular PSX. That's why people use mod chips. PS2 is the same way both for CD and for DVD media.
3) They are using DVD but not UDF. You'd need to write authoring software for their custom file system. There's the issue in point 2, also.
4) You're assuming that you'll be able to get a USB/PCMCIA/1394 interface running quickly. My guess is register-level access to these ports will be difficult. Sure, once you've figured that out, porting code for a USB client to your USB server driver will be easy enough.
5) See point 4.
6) I covered the ee-gcc code issue in another post:-)
The GPL doesn't say that you are required to give source to anyone who doesn't have it but asks you for it. It says that if you give a binary to someone you must give them the source code too. Important difference.
Sony's agreement with 3rd party developers says we can't give anything to anyone. If you ask me for the ee-gcc source OR binary I'll just say 'no' even though I have both.
N64 in no way 'rocks' Japan. Kirby has indeed sold well but that's just because there's been no decent game for the system for so long. The total sales figures of N64 in Japan are very low, almost as low as Europe in fact. The USA is the only place where the system was even a moderate success.
For reference, before PS2 came out (not seen any figures since), PSX sold about 35k a week, DC 30k, N64 4k.
Also, PS2 does indeed have hardware transform and lighting. That's what the two vector units are for. In fact they give you _programmable_ T&L which lets you effectively implement vertex shaders and do all kinds of other interesting things you can't do on any other platform yet. Upcoming PC video cards will have this - check gamasutra.com for a nice article about DirectX 8.0's support for them.
Right now it's _much_ too early to say which of the four consoles will be the top dog and which will be eliminated. I don't think you can even say whether the market will bear 2 systems, or 3, or maybe even all 4.
Your argument would be valid if the game could be played without needing to use your palm to rotate the stick. Problem is, some of the minigames you just can't do without using this method because you can't rotate the thing as fast with your thumb. Pedalling the exercise bike to light the lightbulb before Boo catches you is one example of this.
There already is one. It comes as part of the PSX2 development environment. It's not real-time of course and it doesn't emulate the graphics chip either. Its primary use was before people had real silicon although running code on an emulator can be useful to analyse what's going on cycle by cycle, especially when dealing with multiple function units.
Firstly, I work for WMS Industries, which is a supplier of casino gaming equipment. I do pinball now, but I did some gaming stuff in the past.
Secondly, this is my PERSONAL opinion. I am a programmer, NOT a spokesman. Got it?
This isn't the main point of my post, but you use the term 'gambling establishment' and I'd like to clarify this matter. Offshore Internet casinos have nothing whatsoever to do with the state-legal, regulated 'gambling establishment'. There is an enormous quantity of federal and state legislation covering that entity and it's almost all designed to protect gamblers. There's a reason that the Offshore casinos are illegal to do business with.
As for this specific case, well, Visa lent this woman money (and it is definitely a loan, funds advanced against future payment with interest) by authorising a transaction with XYZ corporation offshore (Cayman islands most likely) for an unspecified purpose.
It's later brought to their attention that the purpose in question is illegal gambling. Now they have a problem. If this woman were in Florida they would actually have been party to a crime, for reference. Since they don't want to see California enact a similar law, they do what they did.
I'm personally undecided whether I think such laws are a good thing or a bad thing. It's an instance of the general case of how much society should use legal force to protect its members from situations where they may be hidden, disadvantageous, circumstances.
Actually the unreal tech page update was made by Brandon Reinhart, not Tim Sweeney.
A Linux client for the Unreal engine is very cool because it makes it more likely that upcoming games (eg. Deus Ex, Rune and Duke Nukem Forever) will have Linux versions. The modularity and flexibility of the engine means that other games developed using it have more localised changes and so a code merge is less painful than it might be.
Also, Klingon Honor Guard in theory will also work on Linux since it made no engine-level changes (it's just new maps, textures and unrealscript code).
This seems to me like a disturbing thing. If all it does is show pictures, that's not too big a deal. The Intel motherboard in this PC defaults to showing an Intel Ad at bootup (you can turn that off and see the 'normal' bootup sequence instead) but it doesn't get in the way of things.
However, once you have the idea that Ads or other content can be sold into the BIOS, how long will it be before Microsoft comes along and buys the right to put code in there to refuse to boot the machine if certain criteria aren't met.
That would be a perfect gun to hold to users' heads to make them pay a yearly subscription and to prevent other OSes from gaining any place in the market.
Sure, this is a pretty paranoid thing, but if it occurs to little old me, why shouldn't a multi-billion dollar corporation have had the same idea?
In fact, what's to say they don't write their own BIOS (okay, that's a BIG undertaking but they could do it) and couple it with Windows fees to leverage it into the marketplace? Use their BIOS and get $20 off your Windows license. Then, they could do exactly as they please.
I've pre-ordered Bleem! for a few reasons. It does indeed look better than the real PlayStation because it supports hardware acceleration. Filtered textures at 1024x768 beats the non-filtered 320x224 of the PlayStation. Also, games can run at higher frame rates thanks to the greater fill rate of PC 3D accelerators. Having virtual memory cards is nice too; having to swap cards in and out or shuffle data around can be a pain.
This certainly isn't a PlayStation replacement though. It by no means runs all the games, and some that do run have flaws of one kind or another. Anyway, the whole experience of sitting with the PlayStation controller in hand in front of the TV is lost.
The biggest reason I'm buying Bleem! is just because it's a very cool technical achievement and I think the people concerned deserve some payback for their hard work. Randy Linden is an extremely nice guy and a talented programmer.
By the way, the whole thing is written in x86 assembly. That, coupled with its use of DirectX for sound and graphics likely make it tough to port to Linux.
If you're interested in Bleem!'s compatibility, here's a shameless plug for my little webpage listing the games I've tried. I have another 11 games to add to the page (been busy with work and Rollercoaster Tycoon:-) ).
Look at it this way. If you were a school principal and you DIDN'T run filtering software, what would you do when a lawsuit lands on your desk courtesy of a parent claiming their child accessed 'harmful' content through your school's computers?
It's a business decision. Even if the risk of losing such a lawsuit is small, the cost of losing would be so enormous that it offsets the reward.
I don't pretend to like any part of that situation, but I don't think I could take such a risk, especially somewhere like Utah.
Slashdot Mirror
That would be me, too :-)
:-)
The development system costs $10,000 and requires signing an NDA. Also, SCEA generally want to see a business plan or some indication that you're going to release product.
It's very complex hardware to work with in any significant way. Very powerful, but when you have 6 functional units (EE, VU0, VU1, GS, IOP and SPU) all operating in parallel and synchronised (generally) by DMA commands, it's going to be tough to program. At least C++ and STL do work pretty well, there are plenty of companies relying on them for their games. Be thankful for small mercies
In all honesty I would not recommend you look to straight PS2 development for your project. I have some alternate recommendations:
PS2 Linux kit - may not be released in the USA, or not in time for your needs. Runs on the consumer PS2 (with the HDD addon) and has more library support.
Gameboy Advance - has some of the PS2 issues, namely expensive development hardware and NDAs, but much easier for a single programmer to produce something credible on with.
XBox - you can do most of your work on a regular PC under DX8. Easiest programming environment of the 3. But if you do this, maybe you would be better just on a PC with a GeForce 3?
The Nintendo64 used a R3400 and the PSX used a R3300 (I think, unsure about that one) so you might consider this synergy to have already taken place :-)
Personally I think it's a good thing for consoles to use the same CPU architecture because it makes the compiler vendors' lives easier, which means their tools are better, which means game programmers' lives are easier, which hopefully means better games.
Ok, here's a summary of the various PS1 and PS2 development hardware.
You start work on a development kit - this is the expensive PCI card for PS1, or the big black tower (the T10000) for PS2. This hardware supports source-level debugging, has more memory, etc and is what you do your main development on.
Once your game is well on the way to completion (eg. it can fit in the memory of the consumer hardware, it doesn't crash too often) you start to make bootable discs that run on what are called debug stations. The blue PS1 was the debug station. For PS2 the debug looks like the consumer unit except it says 'TEST' on the top instead of 'PS2'. The debug stations can operate from CD-R and DVD-R media (no copy protection). These are primarily so your testers can run the game before you submit it to Sony.
The black PS1 (the Net Yaroze) wasn't even as full-featured as a debug station - it couldn't boot from CD-Rs. Plus, you could only download your own code to it after booting from a special black CD. Given that this PS2 hobbyist kit is for the consumer PS2, there won't be CD-R support there either.
You're right that the serial link between controller and console is probably not sufficient for real time video and you're also right that it's probably an undesirable user interface choice.
However, you could do a rear view on the GBA if you wanted. Who says you have to treat it as a dumb terminal and pour full-frame video to it? I'd write essentially the guts of a simple driving game on it, download that and the sprite data at the start of the race, and then just send the relatively small amount of info indicating position and so on each frame.
That said, I'd use it to indicate things like tyre pressures, distance to next/previous car, fuel level, overhead track view with green/yellow/red flag status, instructions from the pit and so on and so on.
Incidentally although I believe NFL2K does have VMU play calling, a screen as small and as low-contrast (partly because of the thick plastic frame on the Dreamcast controller, in my opinion) as the VMU is of limited use for that. You need enough pixels and colours to give some indicator of what the play actually does.
As for analog, I have no idea if Nintendo has done this, but the D-pad could be pressure-sensitive like the PS2 Dualshock2 controller's D-pad, face buttons and shoulder buttons. Personally I was also hoping for 4 front buttons on the GBA, too, but it's still a great piece of hardware even with 2 buttons and a (likely) digital-only D-pad.
I not only own a Playstation2, but I program for the hardware. You're wrong. Games, as part of their initialisation, have to tell the graphics chip whether to go into PAL mode (50Hz) or NTSC mode (60Hz).
This has numerous consequences. The amount of video memory used for the framebuffer changes, because you can show more scanlines at 50Hz. This impacts texture uploads, drawing rate and many other areas of your rendering pipeline's timing. A well-programmed game (hopefully) won't count the passing of time in terms of vsyncs (PS2 has a CPU cycle counter and other high-resolution interrupt timers), but it also has to ensure framerate doesn't drop, and so you might move the camera on a PAL system or make some other change. There's also the issue that colour balance is different between PAL and NTSC (PAL copes better with saturated red, in particular) so you might want to process your artwork slightly differently as part of your build process. All these things make the 'bit identical' assumption invalid.
By the way, game consoles are still programmed 'to the metal'. No matter how complex or powerful they get, they always will be, because that's how you get the most performance for your specific requirements. PS2 is designed very heavily around that concept.
For the original Playstation there were "anti-piracy" mod chips which allowed the console to play imports but NOT CD-Rs. The copy protection on that system worked by checking for a character stream coming from sideband data on the disc.
The "anti-piracy" version was done by only rewriting part of the data stream coming from the CD rather than generating the whole stream in the mod chip, thus you needed a black disc to generate the rest of the stream.
Just a nitpick. I'd expect the Australian law prohibits both intents equally, however.
Ok, the story is light on details and nobody else here seems to have any understanding so here is the real skinny. This is an expanded version of the GS (Graphic Synthesiser) chip in the PS2. I expect even the same clock speed, from the 75 million poly number. By the way, that number is a theoretical peak based on it taking 2 cycles to do triangle setup of a flat-shaded untextured polygon.
Your comment about triangles having 3 verts thus cutting the performance in half is wrong though. Tristrips get you pretty close to 1 vert/poly. Each time you kick a vert you use the previous two kicked verts to form your poly. Thus, a 20 poly strip only needs 22 verts. You are correct that texturing and shading require more setup time, however. Generally you're at 5 cycles of setup time and thus 30 million polys/sec.
2560 bit bus is because you have 16 functional units in parallel, thus 160 bits per unit. 32 bits framebuffer read, 32 bits framebuffer write, 32 bits Z buffer read, 32 bits z buffer write, 32 bits texture read giving 5x32 = 160 bits total. Note you need all these accesses to happen concurrently to fully render a pixel in 1 clock cycle. This is all internal to the chip, too. The external bus interface is 128 bits.
The advantage of having 32 megabytes of on-die memory is that you can generate many full-screen buffers in 32 bit and use them as texture sources for high-quality image processing effects like motion blur or depth of field or environment mapping. Think of that 32 megabytes as a big cache. You could store many more megabytes of texture in system memory and DMA them up to the GS for rendering as needed.
This latter fact is also true for PS2. I generally suggest that people think of the PS2's graphics chip (NOT the cpu core) as 16 Voodoo1s in SLI, overclocked to 150mhz, on a 32x AGP bus. To be sure, PS2 has some developer issues but lack of texture memory is not that high on the list.
The 'router' comment surely refers to the Emotion Engine itself. Sony developed that chip in a joint venture with Toshiba and it is manufactured in a fab owned by the Sony/Toshiba JV. It's essentially a 300MHz MIPS core with the ability to do lots of floating-point math in parallel.
I am surprised that this chip is only news now, Sony demonstrated this concept at the last SIGGRAPH (the GSCube machine). It's intended purpose is to replace render farms. Put 16 of these chips together and you could do semi-close-to-pixar rendering quality in semi-realtime. Good enough to preview animations and lighting and so on.
As one of the Pinball 2000 programmers, maybe I can shed some light.
Pin2000 uses PC-Xinu as the basis of its core OS although we added a lot of functionality to it. This was the decision of Tom Uban who was the chief software engineer on the project and all-round hardcore superstar programmer in general. PC-Xinu already includes a TCP/IP stack, and he had already written a packet driver for one kind of Ethernet card because we did all our code and image downloads via ethernet during development. A really simple web server wasn't too hard to write on top of that - all the statistics it reports are already collected by the game and displayed on-screen in the administration menus.
We demoed another use of the TCP/IP stack at Pinball Expo in 1999, where we had a tournament automatically running. We produced barcode badges for entrants, they walked up to a game, swiped the badge in a barcode reader, played, and their score was recorded. We also took their picture with a webcam and printed it on the badge, and the games showed the current high score list including their digitised pictures on all the games during their attract mode (ie. while they weren't being played).
Hi there,
:-)
Since I work for a company that makes arcade games and since I did video programming for such a system, maybe I can help
Arcade monitors come in two kinds (mostly). Low res and medium res. Low res will only do 240 scanlines at 60hz, medium res is normally 384 scanlines at 60hz. The biggest problem you'll face is that these days everything is 480 scanlines minimum, with the low-level video hardware line doubling for 'old' modes.
The system I worked on, Pinball 2000, used a Cyrix MediaGX for CPU and video and we could happily drive a low-res monitor at 640x240 at 60hz but we were not using a VGA mode. On that hardware VGA is _emulated_ so we threw that away and set all the timings up ourselves at the register level. It was a pain to get right, requiring an oscilloscope to provide sanity checks that we were getting the correct frequencies.
So, sure, you can hook a coin-op monitor up to your PC but it will likely require more work and be less useful than most would want to deal with.
We used a MediaGX board for Pinball 2000. We used the standard BIOS on the board too, since it knows how to do all the chip initialisation and also things like how to configure the memory controller for the specific type of memory you have installed so you get the best performance.
You can use either the video BIOS or network BIOS extension areas in the memory map. If there is valid data in them the system BIOS will call out to them at various points in its boot sequence. Now, these windows are very small (32k I think), but of course if your EEPROM is on a PCI card and memory-mapped, your 32k boot ROM can download code into system RAM for execution once the BIOS finishes doing its stuff.
The value you place on your privacy is exactly that; a personal value judgement. Your assessment is fine, for you. The key issue is that you get to make that choice rather than someone else making it for you.
I don't work for Epic, but maybe I can answer your question.
.plan in fact.
How about pixel and vertex shaders? Under DirectX 8 there's a standard microcode language for designing these and all the upcoming video cards will support this. Write your shaders once and they'll work on whatever next-generation video card your Windows gamer owns. Under OpenGL support will be vendor-specific (via extensions).
Shaders will be tremendously important for next-generation games. They allow lots of advanced surface effects (furriness/hairiness, all the various uses of bump mapping like beads of sweat on a person's skin or water dripping down walls to name but two) you just can't get with conventional multitexture or multipass because you'd need so many passes even 8 bits per channel is not enough to avoid enormous quantisation error. John Carmack was talking about this just recently in his
DirectX also has texture memory management more suited to games, especially games which algorithmically generate textures (like the lava, fire and water in Unreal). OpenGL takes a very high level approach to this which makes texture management nicer to program for but less efficient both in RAM and CPU terms (converting textures from one format to another and storing multiple versions in memory). Remember, performance also ties to features. If something only runs 15fps on a P3-800 with 256megs of RAM, it's not going to go in the game because it will make the game play badly on most people's systems.
I used to work for Williams and now I work for Midway.
:-) ) still get paid if you buy the games.
Williams no longer makes pinball - that operation was terminated last October 25th (and was the reason for my job change).
Midway owns all the rights to the games. When Midway and Williams were a single entity they were transferred to Midway.
If I understand things correctly (this isn't something I personally worked on) you're actually playing the real game code on an emulator made as a Shockwave plugin. Digital Eclipse's logo is there and they are the people who did all the emulators for the arcade classics compilations Midway sells for PC and Playstation and Nintendo 64.
Bear in mind that there is a thing called subsidiary rights, which means that the original people who worked on these awesome arcade games (not I, being only 26
1) You could also just get the EE core specs and write a gcc backend. I believe Toshiba makes this information available (the base CPU core is designed for more than 'just' PS2).
:-)
2) This won't work. PSX CDs use ISO 9660 but they have extra data on them too and without a way to put that data on the disc you can't make a bootable disc for a regular PSX. That's why people use mod chips. PS2 is the same way both for CD and for DVD media.
3) They are using DVD but not UDF. You'd need to write authoring software for their custom file system. There's the issue in point 2, also.
4) You're assuming that you'll be able to get a USB/PCMCIA/1394 interface running quickly. My guess is register-level access to these ports will be difficult. Sure, once you've figured that out, porting code for a USB client to your USB server driver will be easy enough.
5) See point 4.
6) I covered the ee-gcc code issue in another post
The GPL doesn't say that you are required to give source to anyone who doesn't have it but asks you for it. It says that if you give a binary to someone you must give them the source code too. Important difference.
Sony's agreement with 3rd party developers says we can't give anything to anyone. If you ask me for the ee-gcc source OR binary I'll just say 'no' even though I have both.
N64 in no way 'rocks' Japan. Kirby has indeed sold well but that's just because there's been no decent game for the system for so long. The total sales figures of N64 in Japan are very low, almost as low as Europe in fact. The USA is the only place where the system was even a moderate success.
For reference, before PS2 came out (not seen any figures since), PSX sold about 35k a week, DC 30k, N64 4k.
Also, PS2 does indeed have hardware transform and lighting. That's what the two vector units are for. In fact they give you _programmable_ T&L which lets you effectively implement vertex shaders and do all kinds of other interesting things you can't do on any other platform yet. Upcoming PC video cards will have this - check gamasutra.com for a nice article about DirectX 8.0's support for them.
Right now it's _much_ too early to say which of the four consoles will be the top dog and which will be eliminated. I don't think you can even say whether the market will bear 2 systems, or 3, or maybe even all 4.
Your argument would be valid if the game could be played without needing to use your palm to rotate the stick. Problem is, some of the minigames you just can't do without using this method because you can't rotate the thing as fast with your thumb. Pedalling the exercise bike to light the lightbulb before Boo catches you is one example of this.
There already is one. It comes as part of the PSX2 development environment. It's not real-time of course and it doesn't emulate the graphics chip either. Its primary use was before people had real silicon although running code on an emulator can be useful to analyse what's going on cycle by cycle, especially when dealing with multiple function units.
Firstly, I work for WMS Industries, which is a supplier of casino gaming equipment. I do pinball now, but I did some gaming stuff in the past.
Secondly, this is my PERSONAL opinion. I am a programmer, NOT a spokesman. Got it?
This isn't the main point of my post, but you use the term 'gambling establishment' and I'd like to clarify this matter. Offshore Internet casinos have nothing whatsoever to do with the state-legal, regulated 'gambling establishment'. There is an enormous quantity of federal and state legislation covering that entity and it's almost all designed to protect gamblers. There's a reason that the Offshore casinos are illegal to do business with.
As for this specific case, well, Visa lent this woman money (and it is definitely a loan, funds advanced against future payment with interest) by authorising a transaction with XYZ corporation offshore (Cayman islands most likely) for an unspecified purpose.
It's later brought to their attention that the purpose in question is illegal gambling. Now they have a problem. If this woman were in Florida they would actually have been party to a crime, for reference. Since they don't want to see California enact a similar law, they do what they did.
I'm personally undecided whether I think such laws are a good thing or a bad thing. It's an instance of the general case of how much society should use legal force to protect its members from situations where they may be hidden, disadvantageous, circumstances.
Actually the unreal tech page update was made by Brandon Reinhart, not Tim Sweeney.
A Linux client for the Unreal engine is very cool because it makes it more likely that upcoming games (eg. Deus Ex, Rune and Duke Nukem Forever) will have Linux versions. The modularity and flexibility of the engine means that other games developed using it have more localised changes and so a code merge is less painful than it might be.
Also, Klingon Honor Guard in theory will also work on Linux since it made no engine-level changes (it's just new maps, textures and unrealscript code).
This seems to me like a disturbing thing. If all it does is show pictures, that's not too big a deal. The Intel motherboard in this PC defaults to showing an Intel Ad at bootup (you can turn that off and see the 'normal' bootup sequence instead) but it doesn't get in the way of things.
However, once you have the idea that Ads or other content can be sold into the BIOS, how long will it be before Microsoft comes along and buys the right to put code in there to refuse to boot the machine if certain criteria aren't met.
That would be a perfect gun to hold to users' heads to make them pay a yearly subscription and to prevent other OSes from gaining any place in the market.
Sure, this is a pretty paranoid thing, but if it occurs to little old me, why shouldn't a multi-billion dollar corporation have had the same idea?
In fact, what's to say they don't write their own BIOS (okay, that's a BIG undertaking but they could do it) and couple it with Windows fees to leverage it into the marketplace? Use their BIOS and get $20 off your Windows license. Then, they could do exactly as they please.
Graham
I've pre-ordered Bleem! for a few reasons. It does indeed look better than the real PlayStation because it supports hardware acceleration. Filtered textures at 1024x768 beats the non-filtered 320x224 of the PlayStation. Also, games can run at higher frame rates thanks to the greater fill rate of PC 3D accelerators. Having virtual memory cards is nice too; having to swap cards in and out or shuffle data around can be a pain.
:-) ).
This certainly isn't a PlayStation replacement though. It by no means runs all the games, and some that do run have flaws of one kind or another. Anyway, the whole experience of sitting with the PlayStation controller in hand in front of the TV is lost.
The biggest reason I'm buying Bleem! is just because it's a very cool technical achievement and I think the people concerned deserve some payback for their hard work. Randy Linden is an extremely nice guy and a talented programmer.
By the way, the whole thing is written in x86 assembly. That, coupled with its use of DirectX for sound and graphics likely make it tough to port to Linux.
If you're interested in Bleem!'s compatibility, here's a shameless plug for my little webpage listing the games I've tried. I have another 11 games to add to the page (been busy with work and Rollercoaster Tycoon
http://members.tripod.com/bleemgraham/
Look at it this way. If you were a school principal and you DIDN'T run filtering software, what would you do when a lawsuit lands on your desk courtesy of a parent claiming their child accessed 'harmful' content through your school's computers?
It's a business decision. Even if the risk of losing such a lawsuit is small, the cost of losing would be so enormous that it offsets the reward.
I don't pretend to like any part of that situation, but I don't think I could take such a risk, especially somewhere like Utah.