Art shouldn’t have to be shared. The artist should be concerned about creation. Everything else is secundary.
If I want to create a painting on my bedroom wall, I won’t be inviting everybody.
Oh, did I mention I still vote for? (desperately trying to keep the thread at least remotely on-topic ;D)
art doesn’t need to be shared, some of the games (i don’t paint) i’ve made i’ve never shown them to anyone. But when art is shared those who experience IMHO can only benefit from it. Some art is only for certain people just as certain games arn’t for me, but in experiencing them i can only become a better developer both by its pros and cons even i don’t make those types of games. It isn’t from the artists point of view but from a societal point of view that it should be shared
Seeing as being off-topic is pretty much the norm in this thread, I’d just like to take this moment to say: “Modern art, eh? Tch.”. 
[quote]they could also make games nowadays that run twice as fast or are twice as smart, or pretty, etc. all they would have to do is write it all in assembly which would be too much effort, so they don’t do it and who would want too.
[/quote]
I’m not sure what you’re getting at here, but what you said isn’t true. It’s a common misconception, but the pertinent facts are:
Actually, the biggest reasons why computer games aren’t faster, prettier, or more complex are probably (who really knows?):
If you ask most professional game developers, they’ll probably cite the last problem. It’s often heard something like “Lots of people have great ideas for great games; actually completing just one single game is horrendously hard”. Bear in mind that in an extremely competitive industry, “two published titles” is often the main part of a job description - the common belief is that someone who has developed and seen published a title is so comparitively rare that you can use it to filter out most unwanted candidates.
i think you need to the read the posts before mine to understand what i was talking about. It was an example of an extreme that isn’t done because its impractical.
[quote]Assembly programs are NOT faster than compiled programs
[/quote]
This is not true, many commercial developers optimize their code in assembly to make it run faster. When I said that a would be faster if written entrirely in assembly I meant that if the entire program was optimized as much as possible, which is silly because it could take forever.
[quote]i think you need to the read the posts before mine to understand what i was talking about. It was an example of an extreme that isn’t done because its impractical.
[/quote]
OK, will have another go at understnading that :). Too little sleep the past few days, sorry.
OK, look, I’m sorry, but you don’t have the faintest idea what the hell you’re talking about. I wouldn’t mind you disagreeing - but you clearly know almost nothing about this.
If you’d like to learn, go find books with titles such as “Compiler Construction” or “Optimizing Compilers”. You probably only need to read about 1 or 2 chapters before you realise why what you are saying is completely wrong.
However, in order to spare you the hassle (most of those books are rather impenetrable unless you love mathematical theory), here’s a simple explanation: Except in a few special cases, there’s no human alive who can out-perform a really good modern compiler, when it comes to writing programs. On really simple programs, the best human programmer could equal the compiler. Compilers today have the collective equivalent knowledge and experience of about 100 years of human code-writing.
The special cases for writing assembly tend to be where you, as a human, are willing to deliberately do “stupid” things because you are guessing about how the program is going to be used. Even so, the days of such optimization are numbered (if not already over), because compilers are rapidly approaching the point where they can go one step further than that anyway.
…or where there are no decent compilers. Certain unusual programming languages, or languages which don’t get much attention from compiler experts, are still rather poor - just because they’re behind the times.
If you start looking at java, serious java VM/compiler pairs use feedback-directed optimization - e.g. they compile the same code multiple different ways, and run all of them to see which is fastest - and then continue to do this EVERY MINUTE OF EVERY DAY whilst the program is running. Find me a human programmer who can do that…
Not impossible at all - lots of compilers come very close to doing this. It’s one of the reasons for using a compiler. I’d be surprised if a typical program, compiled on a good compiler, was less than 99% of running at the fastest possible speed.
Theres a quote from John Carmack a while back which basically states that if you’re writing for a single, known hardware config (ie. a console) you can usually get twice the speed compared to ‘normal’ coding for a platform. Basically coding right to the metal, chucking out clean code in exchange for hardware hacks etc. etc.
Personally, I don’t care to program like that, and i doubt many other people would either. Now on a pc this is effectivly what you’re doing when you insert hand crafted asm into your code. So whats the alternative? Create the code as elegantly as possible, and let the compiler do the leg work - tedious, repetative tasks are what computers do best anyway 
If you really want code tailored to a specific architecture/chip, then either compile for a specific platform (C/C++) or hope the VM will do this kind of thing under the hood (like the use of SSE instructions mentioned in another thread 'round here).
On the other hand, there is a need for a gameplay/game programming forum. Theres plenty of topics that don’t sit easily in just the J2d, or just the lwjgl forums for example. But then again this place sufferes from too many forums as it is 
I know this is off-topic, but in the case of emulator programming, asm can still make make huge speed differences. Think about using native cpu flag behaviour instead of ‘manual’ flag emulation for example (z80 flags map perfectly on an x86 for example).
[quote]I know this is off-topic, but in the case of emulator programming, asm can still make make huge speed differences. Think about using native cpu flag behaviour instead of ‘manual’ flag emulation for example (z80 flags map perfectly on an x86 for example).
[/quote]
Interesting; any idea why your compiler is unable to see this?
[quote]Interesting; any idea why your compiler is unable to see this?
[/quote]
It just sees variables being masked and bits being fiddled with and I guess it would be highly unlikely it makes a connection like ‘hey that bit that’s being changed, is changed the same way my half-carry flag is being updated in those circumstances, and guess what, that bit has the same position in the byte as my half-carry flag in the flagregister’. And that for all flags.
I guess a compiler can’t know someone is trying to emulate flags or that compiler is even fully aware of how the flag register behaves exactly.
blahblahblahh:
Your points about compilers being superior are somewhat flawed. In theory you are correct… accept for the simple fact that the compilers you are talking about wither don’t exist yet or simply aren’t being used by the game developers.
There are actually VERY few compilers that will generate standard C++ into the fastest possible code in the case of several specific algorithm types.
The most common example is when coding SIMD instructions with an assembler. Any JPEG or MPEG codec that is halfway decent these days MUST use hand-coded assembly to get decent speed… I’m not saying that the hand-coded assembly routines wouldbe the fastest possible… I’m just saying there are any readily available C++ compilers that will come close. Image filtering and other similar operations that use SSE or Altivec etc. are all in the same boat. Usually the higher level language lacks the constructs to express the algorithm ina way such that the compiler can ‘see’ how to best use the SIMD instructions.
I’m not saying that all compilers aren’t up to the job, but certianly the GNU compilers and Visual C++ can’t come close. And they are quite popular.
For your standard if-then-else logic and simple expressions, sure a compiler will win most of the time… it’s when the ‘really clever’ expression can not be written in the higher level language in the first place that they tend to trip up…
Sorry to be so off topic :)…
Err… just so I contribute to the true purpose of this thread… I vote YES too. A forum on game play discussions (how to make games more playable, enjoyable, fun, immersive, addictive, etc.0 is a good idea.
This is “Java Gaming”.org and a forum for Gameplay has already been created, it’s called “Off Topic”.
Seriously though, maybe something more general because I think a forum devoted to gameplay alone wouldn’t get much traffic.
[quote]This is “Java Gaming”
[/quote]
Yeah, “Gaming” being half of it. Gameplay is a rather large and important aspect of that and hardly off topic.
I guess the ‘cheesy’ message icon wasn’t enough to indicate a hint of sarcasm.
Nah, that’s just me: I lack any sense of humour and I’m immune to sarcasm. :-*
It seems I didn’t make my meaning clear enough, but I was trying to make the point that for AN ENTIRE PROGRAM for the vast majority of cases it’s not just really hard, but it can take more time and skill than any team of humans realistically has available, just to get results as good as a good compiler. I was replying to:
[quote]they could also make games nowadays that run twice as fast or are twice as smart, or pretty, etc. all they would have to do is write it all in assembly which would be too much effort
[/quote]
…I would like to see, for example, someone writing entire non-trivial OO programs in fully optimized assembler, by hand.
Or see someone doing optimal register assignment for a whole PROGRAM, bearing in mind they have to write the entire program several times, trying different tradeoffs between e.g. reducing memory accesses vs making use of the cache.
If you read my post carefully, I’m basically objecting to the claims that you can write whole programs (and we’re talking computer games here, not simple stuff) in optimized assembler by hand - and that they’ll be “twice as fast” as the compiled C++ version. That’s just complete rubbish! In reality, a complete program is typically going to be very close in execution speed. TYPICALLY - i.e. I’m sure we could come up with another dozen particular programs, like your examples of (de)compressors, where the difference can be much greater - but these are special cases, and as you point out generally occur when the program is dominated by a particular kind of algorithm.
I wasn’t trying to say “no compiled code can ever be sped up”. I did say “Assembler programs are NOT faster than compiled programs”. You seem to have read that as “bits of code written in Assembler are NOT faster than the same bits of code output from a compiler” - the distinction (which obviously I didn’t make clear enough, sorry) is critical.
PS: there are also some crap compilers in common use, like the GNU ones last time I checked in detail, about 4 years ago (ducks and runs for cover!). Seeing GNU C++ compilers get thrashed on various benchmarks by Java 2 compilers is pretty unimpressive. Back then, the MS C++ compiler seemed about as good as I expected from a good compiler.
(at this point I’m so far off-topic, I’m actually back on topic again).
Ah, ok… I was going off on a tangent then…
I will just point out that these days it largely doesn’t matter at all if you choose assembler, C, C++, Pascal, etc… The slowdowns in Java aren’t related to generating bad code (mostly). They are caused by other ‘features’ of the language that the VM guys have to work around, and yet remain compatible with… like bounds checking, and garbage collection. Going between the Java heap and the native heap with data etc.
And of course fast code does not make a good game. (See how I dragged that back to being almost on topic )
Very nicely done :).
I vote yes for a gameplay forum, and then let’s let that forum blossom or stagnate on its own merits.