Not all TopCoder programming contests select speed of implementation over everything else good.
One you are a rated member, you are eligable to participate in design or development competitions. These take place over a matter of weeks and emphasize all the goodness we all desire (sound design, clear code and comments, etc). AND first through third place get cash, just like the old days... *sigh*
You make an extremely good point. I suppose my argument was more about the entire process behind CG imagery. As technologies related to the engine improve, will they always be compatible with the old engine? Maybe there are leaps and bounds to be made in the realm of animation (and there are) which will call for a new interface to provide the engine. OO or CO programming could certainly preserve the old engine through this enhancement, but that would be too darn slow.
My bet is that when we're done rapidly advancing the engine, we will see a dramatic rate increase in the advancement of related technologies. Over time, these changes will in turn cause changes in the engine. No, the engine itself won't make any triumphant leaps forward, but it is quite possible we'll still be cranking them out at a decent speed.
Yes, some of those images are indeed very convincing. Especially those of landscape. My question though is, are those generated in real time? How long will it be before they are?
If John Carmack predicts that game engines might be tweaked in the future, having a longer life span, instead of being coded from scratch, I tend to disagree.
Even as computer graphics rapidly approach the quality of those we see on the big screen, CG movies are still a long ways from convincing me they are real. Turing said that a good way to test the quality of artificial intelligence would be to see if it could fool a human into thinking it was a real person. The same concept can be applied to computer generated graphics. We haven't really reached the finish line until CG can effectively fool us into thinking we are looking at a photograph.
As CG in games progresses, software and hardware will need to be increasingly effient (i.e. fast). This almost requires that game engines be written in fairly low level programming languages, ruling out heavy OO design and especially Component Oriented Design (which is the strongest candidate for long-life software).
With each passing year and each passing game, we will be trying harder to achieve the true feel of reality. If engines were component oriented in design, changing one feature such as lighting would not necessarily effect other parts of the engine. In this way it might be possible for a game engine to last more than a few years. However, the fact remains that this is too slow and is impractical for our uses.
Will we ever reach that finish line, fooling ourselves completely? Probably, but certainly not anytime soon.
I realize that the goal of this project was not to provide a versitle solution but rather to allow existing MIDP games to be played on the GBA. However, I think it would be fun to write a JVM for the GBA that would allow you to run any (okay not any, but with less limitation) java application or applet MIDP or not. Also, rather than having to buy a cartridge with its own processor, why shouldn't the program be run on the GBA's processor and loaded from a standard cartridge or even a multiboot cable. Slow? Yeah, it would be slow. There's no question about that. But it would certainly be more in the spirit of Java. I've started a sourceforge project to try and tackle this task. If you are interested in helping out, please inquire there.
Slashdot Mirror
Not to mention that non-invasive EEG would be one way. I don't want anyone hacking my brain.
Thumb a hundred bucks, will ya, and save the clock tower!
we're talking thousands of requests per day
Oh my gosh, that could almost be as many as one email every 8.5 seconds! How can their servers take it?!
Why do non-smokers urge smokers to quit?
They are actually a type of vegetable called a fruit vegetable. Like a pumpkin.
Not all TopCoder programming contests select speed of implementation over everything else good.
... *sigh*
One you are a rated member, you are eligable to participate in design or development competitions. These take place over a matter of weeks and emphasize all the goodness we all desire (sound design, clear code and comments, etc). AND first through third place get cash, just like the old days
My bet is that when we're done rapidly advancing the engine, we will see a dramatic rate increase in the advancement of related technologies. Over time, these changes will in turn cause changes in the engine. No, the engine itself won't make any triumphant leaps forward, but it is quite possible we'll still be cranking them out at a decent speed.
Yes, some of those images are indeed very convincing. Especially those of landscape. My question though is, are those generated in real time? How long will it be before they are?
Even as computer graphics rapidly approach the quality of those we see on the big screen, CG movies are still a long ways from convincing me they are real. Turing said that a good way to test the quality of artificial intelligence would be to see if it could fool a human into thinking it was a real person. The same concept can be applied to computer generated graphics. We haven't really reached the finish line until CG can effectively fool us into thinking we are looking at a photograph.
As CG in games progresses, software and hardware will need to be increasingly effient (i.e. fast). This almost requires that game engines be written in fairly low level programming languages, ruling out heavy OO design and especially Component Oriented Design (which is the strongest candidate for long-life software).
With each passing year and each passing game, we will be trying harder to achieve the true feel of reality. If engines were component oriented in design, changing one feature such as lighting would not necessarily effect other parts of the engine. In this way it might be possible for a game engine to last more than a few years. However, the fact remains that this is too slow and is impractical for our uses.
Will we ever reach that finish line, fooling ourselves completely? Probably, but certainly not anytime soon.
I realize that the goal of this project was not to provide a versitle solution but rather to allow existing MIDP games to be played on the GBA. However, I think it would be fun to write a JVM for the GBA that would allow you to run any (okay not any, but with less limitation) java application or applet MIDP or not. Also, rather than having to buy a cartridge with its own processor, why shouldn't the program be run on the GBA's processor and loaded from a standard cartridge or even a multiboot cable. Slow? Yeah, it would be slow. There's no question about that. But it would certainly be more in the spirit of Java. I've started a sourceforge project to try and tackle this task. If you are interested in helping out, please inquire there.