Slashdot Mirror

I played with the Novint Falcon at the GDC two weeks ago. It's a neat concept, but the problem is that you have to constantly hold your hand in midair to use it. It's tiring, and not really useful for anything more than a quick demo. This controller, and controllers like the spaceball, make a lot more sense as far as being able to relax your arm while you use it.

they have a graph that very clearly shows raytracing at a performance advantage as complexity increases.

No, they have a graph that very clearly shows that raytracing while using a binary tree to cull non-visible surfaces has a performance advantage over rasterizing while using nothing to cull non-visible surfaces. Perhaps someday a raster engine will regain that advantage by using these "BSP Trees" as well.

Hey, I couldn't find a PM option, so I'm hoping you get e-mail notification of comments to you, Yartrebo: I ran across an old post of yours at the Game Dev forums in which you spoke of ripping models via AdriPSX in 2002: http://www.gamedev.net/community/forums/topic.asp?topic_id=93782 The post's links are dead (not surprising since it's 5 years old). At the Chrono Compendium, a bunch of us are obsessively pulling out all the stops to map Cross's file structure and rip its assets, but the community isn't the most active one and so we're not getting much expert help. If you remember any details, could you provide any advice? http://www.chronocompendium.com/Forums/index.php/topic,3684.0 Huge thanks for considering.

Sigh. Not this tired old argument again!

Look, if little game companies like id software, Epic Games, Splash Damage, and S2 Games with developer counts measured in the single and double digits can deliver their Linux version of their product on the same CD as the Windows one (or available as a download shortly thereafter) and do so consistently year after year, version after version, then /anyone/ can do it. If they can continue to deliver their product as a cross platform offering and make money at it, then /anyone/ can. It's just not that tough!

If you're serious about developing a cross platform application, quit your whining, dig in, and learn how to do it. Here, I've even did a little Googling so you don't have to: Linux Game Development. While this series of articles are focussed on game development, the basic principles they cover can be used for any market niche.

Otherwise, quit your bellyaching. You're not adding anything useful to the conversation.

It's a genuine how-to book, and a pretty good one at that. That, plus NeHe, are excellent ways to get started.

The API may not depend on the underlying driver capabilities, but the implementation certainly does. MS would have had to support two completely different implementations to make it run on XP. That would have been expensive as well as difficult. It's understandable that they chose not to. While there may have been some conniving against the customers as many have supposed, I would say the primary motive for not supporting XP was simply cost and effort. They were expecting Vista to take off quickly. It is Vista's slow uptake that is hampering DX10 moreso than the lack of support in XP. (At least from MS point of view. They planed well enough. The rest of the world just didn't cooperate. ;-) )

My own experience concerning games and D3D is this: Some games take over the screen and don't give up. I can't alt-tab out. Or maybe the game locks up and I can't get back to the desktop and I can't kill it other than reboot. Such cases are sometimes laziness on the programmers part to make the game share and cooperate on the display hardware or save state to allow the OS to come back in. In D3D 10, the game cannot own the screen in this manner. The OS is always capable of taking the desktop back and preserving the game virtually in the background. It's the difference between can share and will share. D3D9 games can share if they want to. Some do, some don't. D3D 10 games will share no matter what.

No, not marketing nuts. Programmers. Its a 'free' as in beer API. I've programmed in it on and off over the past two years or so, and if you hang out at the usual places (gamasutra, gamedev.net, the official mailing list, etc.) you will find lots of users, most hobbyists and garage type programmers, who love the stuff and are digging deep into the API's and gladly help out the new comers. Just go look at the width and breadth of tutorials, sample code, etc. generated by non-Microsoft employees out there. It really is a community, in the truest sense.

If OpenGL could drum up the kind of community, you could generate some kind of seague into open source. But what do they have, really, beyond NeHe? a few college classes, really. Try comparing Riemers XNA Tutorial to say NeHe. IMO, Riemer is more in-depth, he goes over the derivations more than NeHe does (no offense to NeHe, I've drawn a lot from his work too learning OGL). And at the end you have a simple, functional game. Stuff like that, I think, is all the difference.

This is a great thread. There are so many 3D alternatives out it will be great to see what this thread comes up with. I am only disappointed this topic didn't get rated as a major story on Slashdot.

Not to downplay the benefits of programming in C++, I think it is better to focus game development using scripting language rather than for C++. When I started writing games on the Apple II+ I wrote everything in 6502 assembly but with lores B&W graphics. Today the successful game developer no longer has that luxury. ;-)

Game development now requires imagination, creativity, artistic talent and often times story telling ability in addition to programming talent. IMHO it is better to balance your time developing all the different parts of a game than to waste cycles on the ins and outs of C++ (or assembly). I believe this is why the LUA (open source) scripting language has seen so much success in the development of video games. Games such as Grim Fandango and Escape from Monkey Island published by Lucasarts and Neverwinter Nights and MDK2 developed by Bioware were written in LUA. More information about LUA can be found here: http://www.lua.org/ and here: http://www.gamedev.net/reference/programming/featu res/lua.

There are no less than five (and probably more) major 3D engines tied to LUA: Ogre3D (using Emma3D http://emma3d.sourceforge.net/, Irrlicht http://irrlicht.sourceforge.net/ (using https://sourceforge.net/projects/irrlua/, Apocalyx http://apocalyx.sourceforge.net/, Luxina http://www.luxinia.de/, and Electro http://www.evl.uic.edu/rlk/electro/index.html

I am just getting started learning LUA (for a 2D game - another advantage of learning LUA - the ability to grow) so I make no claims to know which 3D engine is the best. There may be other 3D engines integrated to LUA out there and I would love to hear from other people who have experience developing games using LUA and from people developing 3D games using LUA.

Probably should add that Wild Magic is now the excellent Geometric Tools.

And here's a thread where David mentions him writing NetImmerse for those interested...
http://www.gamedev.net/community/forums/topic.asp? topic_id=310637

Hey, guess what, all narratives can be classified if you abstract it enough; there's the 36 Dramatic Situations, and a lot of games follow the Monomyth to some extent. Should all games go away? Maybe. To say that there's a lack of originality in storywriting for games is an unfortunate truth, but it by no means is limited to the Final Fantasy series. In fact, the situation you described applies to a whole host of console RPG's, churned out because a lot of people love it and (more importantly) will pay for it. The Final Fantasy series, however, has at least made strides towards improving (or at least varying) their gameplay mechanics--just look at Final Fantasy XII.

In my opinion, better storywriting is the future of games. Chris Crawford talks about this in a somewhat old Gamasutra interview. *Shameless plug alert* I'm also involved in a project that aims to tailor stories to the player.

1. "Eh? Fallout and Fallout2 run fine under WinXP, dontchaknow?"

Here is a rather good quote from our recruitment post @ gamedev.net: (check: http://www.gamedev.net/community/forums/topic.asp? topic_id=430811&PageSize=25&WhichPage=1)
"Just like the name of our project suggests we work on a new open source engine for isometric RPGs. The engine started as a Fallout-related project but we recognized very fast that it offers the potential to be used as a general 2D isometric engine for the development of cross platform RPGs. The engine supports the assets of the original Fallout games but it is meant to be suitable for the creation of all kind of 2D RPGs. We are focusing on the programming of the engine itself but will bundle it with an example mod. This way modders have a starting point to create their own games based on our engine.

Since we do not focus on the creation of a complete game we will be working on comfortable and easy-to-use editing tools. Engine and editor are planned to run on all flavours of Linux, Win32 and MacOSX."

I hope that helps to clear up things :-)

We could prolly make it even easier for you by giving the project a new abbreviation: e.g. FIFE - FIFE ISN'T (A) FALLOUT EMULATOR.

And a little visual help: this is a screenshot of the content of the upcoming demo map for FIFE, looks _very_ Falloutish, doesn't it?
http://wiki.fifengine.de/images/1/15/2007.1.004.jp g

Ohh that post made my day :-)

At first I need to say that I'm the current project manager of FIFE so I thought it would be worth replying to this message eventhough it seems that the original writer hides behind his anonymity.

1. "It's ran by people who can't code"
So I guess you actually didn't take a look at our code, did you? It's pretty strange that we get quite positive feedback about our code, engine design, project organization and progress from rather professional developers (check e.g. http://www.gamedev.net/community/forums/topic.asp? topic_id=430811) while you are able to draw a conclusion without actually looking at the code. If you took a look at the code your statement seems even more strange to me.

How about raising some valid points = constructive critizism? E.g. "You guys got way too many singletons in the code, how about refactoring them to ..." or "Your engine doesn't look bad but the lack of an editor after such a rather long development time is a definite drawback from using your framework for my planned game project."

2. "they only know Lua"
So maybe you can answer where the 25000 LOC C++ come from? (check: http://www.ohloh.net/projects/3313) Maybe a wizard and an elf wrote them? Following your logic the developers of Monkey Island 3, FarCry and Stalker can't code either, they're using Lua for scripting purposes ... A well, I hope you see where that leads to.

3. "This project has been stale for years"
I'm curious how a project can be stale for years, when it has been just founded 19 months ago. Our SVN changelog also says something different:
Engine SVN: https://mirror1.cvsdude.com/trac/fife/engine/timel ine
Content SVN: https://mirror1.cvsdude.com/trac/fife/content/time line

4. "And the project leader needs to move on"
Didn't get that one :-/ Maybe it's because I'm no native speaker.

So drawing my final conclusion: I know that it's hard to use arguments in discussions if your mother dropped you on your head by accident a few too many times. I know that it hards to understand the spirit of such a project if you think that HALOO IST HE MOST AWSOMEEE RpG MADE EVARRRRRR!!!!! (and according your post you clearly belong to this target audience).

But how about actually trying to activate your brain before writing these kind of posts. All your raised points (you can't call that arguments, can you?) could have been disproved with 5 minutes of google search. Maybe they didn't told you how to properly use a search engine in your 3rd class PC school course?

Radiosity is definitely used in games, because while the straight-forward algorithm is slower than raytracing, you can do some fancy tricks with precalculating certain characteristics of the scene, that makes it possible to do in realtime. Here is an article that explains it in detail. Don't know what Black & White was using.

It's not my field, but I've picked up a few hints and tips by hanging around at http://www.gamedev.net/ which is a good place for amateurs and pros.

http://en.wikipedia.org/wiki/OpenGL_vs._Direct3D

http://www.gamedev.net/reference/articles/article1 775.asp

http://www.xmission.com/~legalize/d3d-vs-opengl.ht ml [(this one is a bit out of date and only covers OpenGL 1.2 and DirectX 8

http://en.wikipedia.org/wiki/OpenGL_vs._Direct3D

http://www.gamedev.net/reference/articles/article1 775.asp

http://www.xmission.com/~legalize/d3d-vs-opengl.ht ml (this one is a bit out of date and only covers OpenGL 1.2 and DirectX 8

No, we just see the usual split between engineering ("get it working") and science ("how does it work?").

And to be honest, the engineering aspect has a long way to travel. Software quality is horrible and worse yet: Random. Very few development groups even have a process for the development itself, much less quality control. Writing a spec and starting to code isn't a process. UML isn't a process. Pseudo-code specification isn't a process. Throwing fancy buzzwords around to cover your lack of process isn't, either.

Zero-Defect Software Developmentor NASA's shuttle software group are beginnings. What they do is try to understand and improve the actual development process.

mp3beatingcompression?

One of the largest benefits of many of these programs is that they bring a student through the entire development process, from concept to polishing.

Take De Blob, created by nine Dutch students for (I believe) the city government of Utrecht, in The Netherlands. I think it's a fine game; not perfect, but well-polished and (most importantly) complete. This means that the team has seen both the great and nasty aspects:

* "Let's create a great concept! This is going to be so rad!"
* "Prototype's done. Let's kick the tires."
* "I know we have the same machine. I'm saying it's not working on my machine."
* "That prototype sucked. We need to re-design our core game mechanic."
* "What do you mean we created our art assets too early and have to discard them?"
* "Time for the alpha. Our programming lead just left to become a nun?"
* "This game is so much fun that we play it for hours on end instead of working."
* "We have a bug where the game crashes if you move the mouse too much."
* "Why does everyone outside the dev team not like our game? We love it."
* "I want to quit. I want to quit. I want to quit. Rrrrr!"
* "Okay, now more artwork. Someone tell the artist to stop using 4096x4096 textures."
* "Everything's running smoothly. Beta time! This should be cake."
* "What do you mean, 'nobody can run the beta'?"
* "It's finally done! Hahaha!"
* "Wait, what do you mean it's not done?"
* "I'm so freakin' tired. Damnit, if I quit, I'll fail the course. Can't quit. Gotta keep going."
* "Finishing the final 10% should only take us 10% of our total dev time, right?"
* "Our playtesters are smashing their controllers against the walls."
* "Okay, our playtesters are finally happy."
* "Time to ship. That wasn't so bad. What's that yellow thing in the sky called, again?"
* "I need a drink."

Presumably, folks who have been through a project of any reasonable size have some idea of how development goes, and can recognize some not-so-obvious mistakes. And the ability to stick with it through a grungy project (and they're all grungy at one point or another) is a plus.

While that's not enough to recommend these programs outright (and there many be many other points that make them not worthwhile), I view it as a big benefit.
________________________________________
Dejobaan Games - Bringing you quality video games for over 75 years
Indie Superstar - Indie games news in an exciting video webcast. Woo!

Please more consoles with contacts that wear out in a few years! (Actually, I think that's Sony's department now.)
Don't forget that it is Microsoft's department as well!

No, NURBS aren't supported in hardware, but bezier patches are. It would be great if OpenGL supported them as well as some chipsets do. You can't do everything with bezier curves that you can do with NURBS, but you can get pretty darn close.

The latest version of the DirectX 9 SDK (April 2005) pisses me off. You can no longer use Visual Studio 6.0 with it, Microsoft forces you to upgrade to a newer version of Visual Studio. I downloaded the free Visual Studio 2005 Express Edition which is actually pretty good, but it still pisses me off that I can no longer use my legit copy of Visual Studio 6.0. The free express version doesn't come with a resource editor.

It is possible to get the latest DirectX SDK working with Visual Studio 6.0, but it's a pain in the ass. Here is a website that goes into detail on howto get it working.

Here are some of the steps you have to go through (involves installing/uninstalling multiple different DirectX SDK versions):

1. Download the April 2005 DirectX SDK (scroll down the page to the "Older SDK Releases" section
2. Download the April 2005 MS Platform SDK (scroll down the page and download PSDK-x86.exe)
3. Go to Keith's site and download the April or June DirectX 9.0c D3DX Only Installer Download
4. Assuming that you are using the Summer or October 2004 DirectX SDK, go to the Lib folder and copy the Dxerr9.lib and Dinput8.lib files to a temp folder.
5. Uninstall the current DirectX SDK.
6. Install the MS Platform SDK (assuming you don't already have the latest version installed)
7. Install the April 2005 DirectX SDK
8. Install the D3DX runtime files you downloaded from Keith's site
9. Reboot
10. Go to the Lib\x86\ folder where you installed the April 2005 SDK and backup the Dxerr9.lib and dinput8.lib files
11. Copy the Dxerr9.lib and dinput8.lib files from your previous Summer 2004 or October 2004 into the \Lib\x86 folder.

And here is the reason why DirectX is now broken with Visual Studio 6.0

In the case of the Dxerr9.lib file, the reason for this is that MS compiled that library (don't ask me why they did this with only this file) with buffer overrun/security checking (as they do with all their .Net libs now, hence the reason VS6 no longer works with DX) and any library function which makes calls to that library (e.g. to DXGetErrorString9) will cause linker errors

Also:

In the case of the dinput8.lib file, you will get this error when compiling a debug app. For some unGodly reason, this file seems to contain corrupt and/or incorrect debugging information. So you will see something like this if you don't use the older version. Incidentally, when comparing these legacy files, in April 2005 SDK, MS decided to include versions that are older than those in the October 2004 Update. Don't ask.

They broke Visual Studio 6 on purpose to force developers to upgrade to a more recent version of Visual Studio (with .net no doubt).. Luckily for a poor person (student) like myself, Microsoft offers free Visual Studio versions (Express Edition), which you can download here.

Before you can develop games for consoles you need to apply to the particular console company to become an approved developer. The exact process varies but it generally means proving that you are an experienced game developer with a financially stable company. The console companies won't approve hobby/inexperienced teams to work on their consoles.

Before you can develop games for consoles you need to apply to the particular console company to become an approved developer. The exact process varies but it generally means proving that you are an experienced game developer with a financially stable company. The console companies won't approve hobby/inexperienced teams to work on their consoles.

I don't quite understand the prizes - looking at the previous year: http://www.gamedev.net/community/contest/4e4/

The top winner didn't get much in the way of prizes. Softimage XSI, yeah I know it's expensive - but if the developer is already making games without it, it's questionable whether he needs it or not. The rest of the prizes are fairly small.

So does winning this contest gain you a considerable amount of notoriety or am I missing something?

some good general sites:
http://www.xmission.com/~nate/tutors.html basic's
http://www.gamedev.net/ Game programming
http://nehe.gamedev.net/ OpenGL programming/game site

some good general sites:
http://www.xmission.com/~nate/tutors.html basic's
http://www.gamedev.net/ Game programming
http://nehe.gamedev.net/ OpenGL programming/game site

That's a lot more reply than my post deserved!

Perhaps you could look at some sites like...

http://www.gamedev.net/community/forums/forum.asp? forum_id=12
(good place to ask questions about graphics programming)

http://www.vterrain.org/
(very interesting stuff here, lots of theory in the rendering section)

I hope you get some better answers than I can give. My own terrain engine is much simpler in scope, although possibly wider (rendering planet-sized maps for an RPG in real-time) and I'm yet to come to this problem. When I get there, maybe I'll read how you solved it!

As an aside, after reviewing ROAM and all sorts of CLOD algorithms, I've decided to go for a completely GPU-based approach. Split my world map (about 5000km squared at 1m resolution) into chunks of 1025m squared, which can be low-res (33x33 vertices, good for distant scenery) or high-res (1025x1025 vertices, with a low-res version as well). Each high-res chunk is then split into patches of 33x33 vertices. I keep nearly all of my patches and low-res chunks on the GPU, and create a list of ones I want to render using the CPU (frustrum cull, simple horizon occlusion). I then just step through the remaining patches and render each.

CPU load is as close to zero as makes no difference, leaving more time for AI and world management. The GPU needs a good bit of memory, but rendering is very fast using VBOs and static geometry. Also, every patch and low-res chunk shares the same triangle design, so I re-use the vertex index list, saving some memory.

It's early stages yet, but it's looking good.

Again - best of luck with your efforts.

I don't think it is really worth doing 3d programming in terms of a learning experience until you know the fundimentals. If there were a tool that one could use to write graphics stuff without understanding matrix maths one would probably come out of the experience still not understanding matrix maths since one would not need it with that tool. Go to a university book shop, you should be able to find a decent mathamatics text book that covers vector spaces and linear maps, read that. Then check out the NeHe OpenGL tutorials and learn OpenGL. Now you will know the fundimentals of 3d graphics and you can just practice until you are good.

• The NeHe tutorials are a good place to start, if you want to start with code...
  
• From a theory perspective, books are good, like 3D Math Primer for Graphics and Game Development, and some community sites too, like GameDev's Graphics Theory section.
  
• Realtime Rendering - the website associated with the book of the same name. I never really made it through the book, but the web page has an excellent collection of links to other sources of information....
  
• Forums like GameDev.net and Devmaster are another approach.
  

• The NeHe tutorials are a good place to start, if you want to start with code...
  
• From a theory perspective, books are good, like 3D Math Primer for Graphics and Game Development, and some community sites too, like GameDev's Graphics Theory section.
  
• Realtime Rendering - the website associated with the book of the same name. I never really made it through the book, but the web page has an excellent collection of links to other sources of information....
  
• Forums like GameDev.net and Devmaster are another approach.
  

• The NeHe tutorials are a good place to start, if you want to start with code...
  
• From a theory perspective, books are good, like 3D Math Primer for Graphics and Game Development, and some community sites too, like GameDev's Graphics Theory section.
  
• Realtime Rendering - the website associated with the book of the same name. I never really made it through the book, but the web page has an excellent collection of links to other sources of information....
  
• Forums like GameDev.net and Devmaster are another approach.
  

I agree wholeheartedly with the parent. This is a hobby project, right? The point is to have fun, and to learn something? In that case, I think you'll have more fun if you don't start with a premade "game engine."

Start from scratch. It sounds intimidating, but that's just because you haven't tried it: You will be amazed at what you can do.

You don't need to spend any money. Compilers are freely-available. Between that, the web as a reference, and your own intelligence and creativity, that's all you need!

Do you know a programming language? If not: You say you can write scripts. If you can learn to write scripts, you can learn to write code. If you need to choose a language, I'd recommend C++ or Java; C++ is probably the most commonly-used language in game development. This site was an important reference for me when I was getting started. Go through all the tutorials. Don't rush to get out of the console: It's a great place to focus on your logic and your algorithms without worrying about interfacing with graphics APIs. It's where you learn how to think about programming.

Then, graphics! I'd suggest you start with some OpenGL programming. That's for a number of reasons. It's not just that OpenGL code is widely portable: Compared to Direct3D code, it's a breeze to write. Carmack himself wrote a piece about how OpenGL programming is a straightforward, enjoyable experience.

Where to start? Try NeHe's tutorials, and its parent site, gamedev.net. That's how I started writing OpenGL code, and I had a lot of fun doing it.

Then, think about what sorts of worlds you want to represent. Landscapes? Indoors? Look up the relevant algorithms and data structures. You care about spatial partitioning schemes, occlusion culling, and LOD. This is where it starts to get advanced. Here, you'll learn more than just to code; you'll learn some actual Computer Science.

You don't need to worry about this now, but when you get to the point where you're ready for it, there's stuff you can google. Spatial partitioning: BSP (older algorithm, computationally beautiful, generally used for indoors), Octtrees (more modern approach, conceptually simpler, lets you efficiently throw stuff at the graphics card), Quadtrees (variant for outdoor environments where the map extends mainly in two dimensions), K-D trees (special case of BSP which behaves more like Oct or Quad-trees). LOD: For outdoor scenes in particular: ROAM, geomipmapping. Occlusion culling and visibility: Portals, precomputed PVS, image-space techniques with occluders.

Just explore, experiment, and have fun. You'll learn a lot.

I agree wholeheartedly with the parent. This is a hobby project, right? The point is to have fun, and to learn something? In that case, I think you'll have more fun if you don't start with a premade "game engine."

Start from scratch. It sounds intimidating, but that's just because you haven't tried it: You will be amazed at what you can do.

You don't need to spend any money. Compilers are freely-available. Between that, the web as a reference, and your own intelligence and creativity, that's all you need!

Do you know a programming language? If not: You say you can write scripts. If you can learn to write scripts, you can learn to write code. If you need to choose a language, I'd recommend C++ or Java; C++ is probably the most commonly-used language in game development. This site was an important reference for me when I was getting started. Go through all the tutorials. Don't rush to get out of the console: It's a great place to focus on your logic and your algorithms without worrying about interfacing with graphics APIs. It's where you learn how to think about programming.

Then, graphics! I'd suggest you start with some OpenGL programming. That's for a number of reasons. It's not just that OpenGL code is widely portable: Compared to Direct3D code, it's a breeze to write. Carmack himself wrote a piece about how OpenGL programming is a straightforward, enjoyable experience.

Where to start? Try NeHe's tutorials, and its parent site, gamedev.net. That's how I started writing OpenGL code, and I had a lot of fun doing it.

Then, think about what sorts of worlds you want to represent. Landscapes? Indoors? Look up the relevant algorithms and data structures. You care about spatial partitioning schemes, occlusion culling, and LOD. This is where it starts to get advanced. Here, you'll learn more than just to code; you'll learn some actual Computer Science.

You don't need to worry about this now, but when you get to the point where you're ready for it, there's stuff you can google. Spatial partitioning: BSP (older algorithm, computationally beautiful, generally used for indoors), Octtrees (more modern approach, conceptually simpler, lets you efficiently throw stuff at the graphics card), Quadtrees (variant for outdoor environments where the map extends mainly in two dimensions), K-D trees (special case of BSP which behaves more like Oct or Quad-trees). LOD: For outdoor scenes in particular: ROAM, geomipmapping. Occlusion culling and visibility: Portals, precomputed PVS, image-space techniques with occluders.

Just explore, experiment, and have fun. You'll learn a lot.

In fact, over at NeHe Productions there are a ton of OpenGL demo tutorials (and a CD available), mostly written in C/C++. Some of these (the "beginner" ones, mainly) have been converted over to Python (and, IIRC, PyOpenGL - that, or some other wrapper), and are very easy to read, well commented, well documented, etc.

Once I had Python and PyOpenGL set up properly on my Linux box, I was able to get the demos working well, and modifying them was easy. Eventually, I took the "simple room walkthrough" demo, and had modded it to allow me to walk around while being able to look whereever I wanted (that is, I could look independently of movement). I eventually modded the code to use the mouse for "lookaround", and the arrow keys were for walking. Now, this isn't too special - what was interesting, though, was getting X to recognize and be able to use two different mice on my system (one was serial, the other PS/2) - I did this 1) to see if I could and if it was possible, and 2) because my "second" mouse was an "off-table" ring-mouse trackball device I had bought specifically for virtual environment navigation, and I didn't want to be constantly swapping the devices out. It was cool while I had it working - a great experiment, and it really showed the power of Python and OpenGL.

I am pretty certain a full 3D engine could be built using Python and PyOpenGL (of course, OpenGL is doing all the "heavy" lifting - though who knows if Python would be up to task of doing everything else a real 3D engine needs - perhaps at that point you move to CrystalSpace or something)...

When I was a 2nd year student we weren't this sort of stuff, makes me wish I went to Stanford.

You really don't need to go to some high-ranked CS university to do cool projects. I hear a lot of people on Slashdot griping about how they couldn't go to MIT/CMU/Stanford/CalTech/whatever. Okay, maybe you get some good lectures and have some bright people handy to work with, but that's really a drop in the bucket compared to what you choose to do yourself. If you read about the things you're interested in, work on some projects, you *will* know far more than the people that went to Ivy League U and didn't do anything themselves -- just went to class and read enough content to get their grades. You have powerful, inexpensive computers easily available. You have free high-quality development software (if you don't have Valgrind and gcc on your computer, you're really missing out). You have an Internet's worth of excellent resources available, along with research papers on every neat thing you can think of free for the downloading. You don't need a professor or a boss to say "okay, write me a Foobar" to write a Foobar -- as a matter of fact, if you're writing a Foobar for yourself, it's probably going to be a better Foobar than if you're writing it because someone else is making you do so. Same goes for reading an algorithms book or a research paper.

Plus, if you don't want to tackle a whole game, choose something that you *do* like doing -- AI, graphics, sound engine, networking -- and pick a random existing open-source project and put your ideas into it. Then you have a nice end result that you can show off to people ("That game you're playing? Yeah, I'm one of the authors"), you have encouragement to keep going (because it isn't just a lone you -- you get feedback when you do something cool), and if you want a good practical excuse, you have a resume item that shows that not only do you have the ability to work with people to produce neat things -- but you've done so simply because you like making neat things. Also, it's *fun* to add a new feature to a game and then play using said feature with the rest of the dev team.

Remember that Woz never got his college degree (well, until a few years ago, when he decided to go back and get it). He built cool things because he liked making cool things, not because someone in a suit told him to make something cool. The same's true of an awful lot of techie folks out there -- school is a convenient tool, but it's much less important than going out and actively learning about things, and the fact that your uni has "State" in its name doesn't have a heck of a lot to do with what you learn. Sure, your professor will assign a bunch of books to read, but you can write that final paper without learning all that much, and certainly with big gaps in what you know. On the other hand, you can read all you want about just about anything I can think of on that Internet-connected computer in front of you.

Universities enforce a lower bound on your knowledge at graduation. They have nothing to do with setting a ceiling.

I have some friends who are working with developing Java games. So far the big money is not in developing titles for phone companies portals (or even worse trying to sell them to the end user yourself) but to develop ad games for companies who make them available for free downloads, usually as a part of a competition.

From what I understand, the best part of the job is that since graphics on mobile phones and other limited devices are so cruddy development focus tends to be on addictive gameplay rather than eyecandy. It is also still possible to be a small independent game studio, no need for a big art studio to render hours of CGI, etc.

Worst part is that just about all phone developers are very sloppy when it comes to implementing the J2ME standards and all models tend to have their own quirks. Sony Ericsson and Nokia are probably the best, but that is not saying much. So in this case, it really is "write once, debug everywhere" type java.

Mobile gaming is really taking off, I read on GameDev for instance that mobile game developers Gameloft increased their workforce from 432 to 1375 employees.

... it will interpolate the data to give an effective 44khz (or less, depending on how many active voices) sample. This means that an 8khz sample will sound better on the GUS than most other cards, since the GUS will play it at 44khz!

Time to bust out the holy wars.

I like the 68000 because it has so many registers but I think all in all in the 80386 is the better CPU.

For reference, consider:

http://www.freescale.com/files/32bit/doc/reports_p resentations/MC680X0OPTAPP.txt

http://www.df.lth.se/~john_e/gems/gem0028.html

http://linux.cis.monroeccc.edu/~paulrsm/doc/trick6 8k.htm

http://www.csua.berkeley.edu/~muchandr/m68k

Right off the wheel, we notice that the 68000 did not support 32 bit multiplecation at all. Doesn't sound too much like a 32 bit chip to me. Compare that to Intels quirky IMUL, which I believe puts the result into EAX, EDX to get a real 64 bit result.

Integer math was faster clock for clock on the 386. Compare things like 68K register addition to Intel register addition. There's no comparison.

Compare

http://www.gamedev.net/reference/articles/article2 14.asp#ADC

to

http://www.df.lth.se/~john_e/gems/gem0028.html

Whenever you did any 32 bit pointer math on a 68k, you paid a huge, huge performance penalty. It was always more efficient to do things in 16 bit PC relative addressing.

The 68K had no concept of isolated memory or tasks. So systems like the Amiga and the Macintosh would run without any isolation between processes. I was an Amiga fan boy and I used to get that GURU meditation error so much that it was not even comical.

The tragedy of the 386 architecture was actually Microsoft and not Intel. DOS and Windows did not use even the 386 chip to its fullest capability for memory management. MS users would have to wait until Sept 1995, almost 10 years after the 386, for a true 32 bit operating system.

I don't know if this is totally redundant now, but there's a little article on this on http://www.gamedev.net/community/forums/topic.asp? topic_id=349817 too. Since I don't have the time to play games nowadays, I'm hoping this movie might give me a hint what the big deal about Halo is heh.

I would be curious to know how the newer edition stands up to the old edition. OpenGL programming is very math ("maths" for the UK) intensive (canonical view volumes, vectors, etc). Of course, game mechanics are complicated enough.

If you are trying to learn OpenGL, Neon Helium is more useful (I have an older edition of the red book).

Looks like from this thread", that with the current plan, windowed OpenGL implimentations will have to either not be truly hardware accellerated, or else have to shut down the Windows desktop hardware accelleration. That makes for a really bad choice to give the user when developing a cross-platform 3-d application, because we don't know what trouble that might cause for a user yet to force them back to a 2-d desktop.

Shame - I'm starting to develop some nice casual window-only games in my spare time (for people tired of minesweeper, pinball and card games) using SDL and OpenGL, and I'd like windowed users to be able to use them. I'll still keep going - it's too much fun working with OpenGL to stop for some boneheaded MS decision - just don't like having to tell people their SOL for using a certain OS in certain situations.

Ryan Fenton

Read this post for an explanation of why this problem is NOT as bad as people are making it out to be.

http://www.gamedev.net/

Here's a good place to start if you're interested http://www.gamedev.net/reference/ Looks like it would takes years of dedication, but the payoff would be ... low wages long hours?

mov eax, 1 ;We want to use the value 1 as our argument
cpuid ;call the cpuid instruction
shr edx, 23 ;shift right 23 times
and edx, 1 ;'and' out the 1st bit
cmp edx, 0 ;compare the result with 0
je err ;If it's zero this feature's not supported
;Other wise continue
mov eax, 1
ret

Start Here. Go there, read and do what it says.

And FYI, I'm resisting the urge to make snide remarks about the naivety of your comments. You state that you're ernestly going to try "making some games" (if you manage ONE coherent game I'll be impressed), and that you enthusiastically want to make 3D games (but appear to be scared of C++).

In the words of Yoda: Try not. Do. Or in this case, "after asking on Slashdot, try some of the suggestions".

Learn from games you play. You've obviously played a computer game before. Take one that's similar to the game you think you want to make. Write down all the things that you do in that game and what you think the game has to do to support that action.

(ie: you click "new game", the board re-initializes and sets up the game state. You try and move a piece, the game checks to see if it's a valid move. You win the game, the game somehow detected that condition. You've got a high score, the game knows this and stores it somewhere).

Write this down for a game that you know, then try to change it into the game that you want to make. Then expand each section with detail and keep adding more and more game features while keeping everything coherent. You'll soon figure out how complex (or simple) your game will probably be.

Great program design begins on paper. A great implementation can come later when you've got the broad strokes figured out. (Unless it's an organic design (which is often unavoidable in live projects where you can't afford to break something) - in which case, welcome to hell).

One of the first things that is beaten into 1st year computer science college students is that you should not cling to any one language. You should grow to the point where you can easily pick up any language thrown at you (the specific advanced knowledge later coming with experience).

FYI, there are decent free C++ tools and libraries available for Windows, you don't have to use whatever Microsoft tries to push on you.

With your Java background you might want to try messing around with Proce55ing (a very good prototyping tool) to solidify some of your ideas.

And of course, break the rules when it suits you.

Possibly the best way to get started with OpenGL is the NeHe Tutorials. The articles are often written in a C or C++ style but most of them have been ported to tons of other languages and platforms. Check the ends of the articles for links to source for whatever platform you want to work with.

Forget Google. In Medieval times we made do with mystic rhymes.