Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 3 4 [5] 6
  ignore  |  Print  
  Apple announces new graphics API: Metal  (Read 7698 times)
0 Members and 1 Guest are viewing this topic.
Offline TifantaWorld

Junior Member


Medals: 2



« Reply #120 - Posted 2014-06-18 06:17:59 »

The features, screen sizes, and default programs vary from phone to phone. Android has to overcome this, and its market value will explode.

This x1,000. The biggest weakness of Android is that its open nature puts the onus on a bunch of third-parties to decide how they want to implement the platform, and most crucially, how it will be disseminated to end users. If a telecom has created its own customized version of Android, it has to redo those customizations every time the latest Android version drops. They inevitably drag their feet, because hey, they're getting customers' monthly service payments regardless. This is what has always driven me away from Android, both as a user and from a development perspective. It's oddly ironic that being open-source actually ends up restricting the activities of many Android end-users, unless they have certain phones, and certain service plans.

If Google rectified this problem, Android would decimate all. Unfortunately, Android is, in its very DNA, allergic to becoming proprietary in any way. It's one of the big problems, in my view, with the whole "open source at all costs" movement.

Quote
With Metal, Apple can decide that they just will stop supporting OpenGL and deprecate it overtime. Microsoft did it with DirectX. Google tried doing it when it split Java with Dalvik. This is normal practice for companies, and it has nothing to do with any sort of fandom. It is literally business as usual for these companies...

Okay, but what you fail to explain is why this is likely to happen. I don't think it's enough to just say "Well, it's an inevitable outcome, just business as usual."
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #121 - Posted 2014-06-18 07:57:02 »

I wouldn't say that it was "likely" to happen, just that it is an actual possibility, based on past events and actions taken by Apple and most of the other big players over the last 30 years. And if I were Apple I'd be seriously thinking about doing it at some point in the future, because it's a good idea for Apple to do so.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #122 - Posted 2014-06-18 08:11:18 »

Regardless of the apparently evil business side of Metal and Mantle, I think it's clear that both Apple and AMD are not so happy with OpenGL (and Khronos) anymore.

The wild growth of extensions (whether they are in core or not) means that the OpenGL state machine is one of the most complex on the planet, seriously. The investment to support yet another extension, creating a few dozen of new 'fast paths' on hardware architectures spanning a decade, while supporting all fast paths existing games and applications rely on, is getting harder and harder. Starting from scratch, with an entire library that is vastly more performant from day one, suddenly is not as hard and time-consuming as working on the latest and greatest OpenGL 4.x driver.

To give you an idea of the amount of validation drivers have to perform for even the simplest VBO: for small batches of triangles (up to a few hundred), glBegin()/glEnd() is still the fastest path - even glMapBufferRange(..., GL_UNSYNCHRONIZED) and persistent buffers don't come close.

OpenGL drivers in its current shape are exceptionally hard to develop and maintain. We might be better off with a DirectX-like approach where there is no backwards compatibility whatsoever when the major version is bumped, allowing driver developers to start from scratch every few years.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TifantaWorld

Junior Member


Medals: 2



« Reply #123 - Posted 2014-06-18 08:29:45 »

And if I were Apple I'd be seriously thinking about doing it at some point in the future, because it's a good idea for Apple to do so.

Why? Eliminating OpenGL would break thousands upon thousands of existing apps, essentially throwing away potential revenue.
Offline Roquen
« Reply #124 - Posted 2014-06-18 08:32:12 »

Direct X has had some real stinker versions.  And it doesn't matter for the long haul.  Consider this OpenGL feature:  You provide shaders as source code.  Neat huh?  It nice for rapid prototyping and having a minimally easier "build time process".  All is good.  Except all OpenGL drivers have to contain a full compiler chain from the tokenizer down to the backend generation.  (And yeah I'm aware of that mediocre extension for loading from binaries)  If you're not using the extension you pay the very high cost of performing a full compile every time.  And guess what?  This isn't a fast process and the memory footprint isn't small.  And you're dependent on the quality of the drivers compiler. And guess what...a fair number suck.  So folks have AOT GLSL compilers that compile optimize and emit source, no help for build time and are still paying the price of the runtime compiler.  No gain.  It was a nice idea that should DIE! DIE! DIE!  Put this kinda crap in a higher level optional API and declare it a failed experiment for the low-level.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #125 - Posted 2014-06-18 08:43:53 »

Regardless of the apparently evil business side of Metal and Mantle, I think it's clear that both Apple and AMD are not so happy with OpenGL (and Khronos) anymore.
...
OpenGL drivers in its current shape are exceptionally hard to develop and maintain. We might be better off with a DirectX-like approach where there is no backwards compatibility whatsoever when the major version is bumped, allowing driver developers to start from scratch every few years.
Absolutely. I suspect this might be where Khronos want to head in the next major rev. of the API - clean break and moving a bunch of common functions out into a separate layer eg. the much-maligned GLSL compiler parts.

There is actually a method to the ARB's madness I think, and it's to do with the "Open" part of OpenGL. What it means is that hardware manufacturers can sprout all kinds of crazy ideas and release them into the wild to see how they fare; some of them eventually become EXTs, then ARBs, and finally, if they are where everyone thinks the API should be headed, they're folded in to the core APIs. It's actually been working really well for the last decade. As far as development is concerned, for us developers, OpenGL does not actually have to be any trickier than DX development: you can pick a core API level and use just that - there is absolutely no need to use any extension mechanism from our PoV.

Cas Smiley

Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #126 - Posted 2014-06-18 08:50:24 »

And if I were Apple I'd be seriously thinking about doing it at some point in the future, because it's a good idea for Apple to do so.

Why? Eliminating OpenGL would break thousands upon thousands of existing apps, essentially throwing away potential revenue.
A careful re-read of some of my previous posts might enlighten you, but as they are lengthy and some way back, I will recap: they do not need to eliminate OpenGL, at least, not immediately. They can first freeze the API level, providing only bugfixes for a while. Then they can announce to nobody's surprise that the OpenGL framework has been deprecated and all rendering should be done by the new Metal API* Then they can, after a reasonable period, remove the OpenGL driver framework as a standard feature of iOS and OSX, and at least on OSX it'll probably be available as an optional downloadable framework for quite some while, albeit stuck at whatever version they left it at, whilst Metal forges ahead. By this time a couple of years have passed; a few developers will be affected, still fewer will moan, but at the end of the day the vast majority of consumers won't be any the wiser. In the meantime developers face increasing irritation attempting to make cross-platform applications, particularly on iOS, and are likely to either focus their efforts on iOS or abandon the platform and lose a huge chunk of revenue. (OSX not so important - market share is tiny)

Cas Smiley

* I don't for one minute imagine that Metal is exclusively designed for the A7. It's almost certainly using techniques that are broadly useful across a large range of chipsets. And consider what might occur when Apple start thinking about putting iOS GPUs inside low-end Mac parts.

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #127 - Posted 2014-06-18 08:57:17 »

There is actually a method to the ARB's madness I think, and it's to do with the "Open" part of OpenGL. What it means is that hardware manufacturers can sprout all kinds of crazy ideas and release them into the wild to see how they fare; some of them eventually become EXTs, then ARBs, and finally, if they are where everyone thinks the API should be headed, they're folded in to the core APIs.

The issue is that extensions that one day where incorporated into the core, shouldn't be any longer. With advances in hardware architecture, the point where the API should be headed is actually a moving target, involving a lot of redesigns. Case in point: anybody calling glMapBuffer these days should be taken out and tickled to death, eventhough it's part of the core. One day our new-fangled, jaw-dropping glMultiDrawElementsIndirect call will be frowned upon too.

Clean breaks solve this, the current way of API call deprecation doesn't work, because as long as some compatibility-profile exists, the driver has to support it, and it will affect the performance of the core-profile, as these profiles do not have a fully separate implementation.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #128 - Posted 2014-06-18 09:25:12 »

Yes, a clean break would be great. So many things about OpenGL are just baffling these days.

Cas Smiley

Offline TifantaWorld

Junior Member


Medals: 2



« Reply #129 - Posted 2014-06-18 11:02:06 »

They can first freeze the API level, providing only bugfixes for a while. Then they can announce to nobody's surprise that the OpenGL framework has been deprecated and all rendering should be done by the new Metal API* Then they can, after a reasonable period, remove the OpenGL driver framework as a standard feature of iOS and OSX, and at least on OSX it'll probably be available as an optional downloadable framework for quite some while, albeit stuck at whatever version they left it at, whilst Metal forges ahead.

So SceneKit, the high-level game development API that Apple only very recently introduced, and which is built on top of OpenGL, is going to be sabotaged almost right out the gate? That makes sense, I guess (if Apple is operating on comic book villain logic and has only chaotic-to-the-point-of-self-destruction evil as its driving motive, that is).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #130 - Posted 2014-06-18 11:27:45 »

I think that it is well within Apple's powers to retarget SceneKit to another, faster rendering API. Unless they did it wrong. Mind you it's a bit of a pointless API for most developers. I wonder if Apple engineers are getting a bit bored and tinkering for tinkering's sake. Reminds me of Google and Microsoft.

Cas Smiley

Offline TifantaWorld

Junior Member


Medals: 2



« Reply #131 - Posted 2014-06-18 11:44:18 »

I think that it is well within Apple's powers to retarget SceneKit to another, faster rendering API. Unless they did it wrong. Mind you it's a bit of a pointless API for most developers. I wonder if Apple engineers are getting a bit bored and tinkering for tinkering's sake. Reminds me of Google and Microsoft.

Cas Smiley

I've worked with SpriteKit and the API makes direct use of all the happy little C structs prancing around as glorified "types" in the Core Graphics API. Apple designed these APIs to be accessible to developers, something that will persist through OS updates without breaking. Are you trying to tell me that Apple is going to pull a fast one and make people learn SpriteKit and SceneKit all over again? I can only see this being the case if they're in comic book villain mode. They don't gain anything by ditching OpenGL.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #132 - Posted 2014-06-18 12:00:21 »

I can't imagine many professionals using those API seriously tbh. If I thought that Metal was vendor-lock in then I really can't imagine the sense in using an entirely OSX-only framework in this manner. Excepting perhaps to adhere to specific OSX-only requirements. The pros will have their own systems. For the rest of us there's Unity. Oh, and libgdx.

Cas Smiley

Offline TifantaWorld

Junior Member


Medals: 2



« Reply #133 - Posted 2014-06-18 12:42:48 »

I can't imagine many professionals using those API seriously tbh. If I thought that Metal was vendor-lock in then I really can't imagine the sense in using an entirely OSX-only framework in this manner. Excepting perhaps to adhere to specific OSX-only requirements. The pros will have their own systems. For the rest of us there's Unity. Oh, and libgdx.

Are you talking about SceneKit and SpriteKit? SpriteKit is essentially Cocos2d, except guaranteed not to break when iOS gets an update. Lots of iOS developers use Cocos2d, and SpriteKit is easy to pick up if you're experienced with it. SceneKit is kind of a 3D counterpart to SpriteKit's 2D-centric scope. Both of these are built on OpenGL.

I'm really not understanding how you can even pretend to maintain your point now. Apple wouldn't gain anything by carrying out such a silly action.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #134 - Posted 2014-06-18 12:53:17 »

Not sure what you're arguing about here. Why would they even develop Metal then? That's the odd part. It's not making any sense to developers to have all these crazy different ways of doing the same thing... unless they're trying to push people in a particular direction and then deprecate the redundant methods.

Cas Smiley

Offline TifantaWorld

Junior Member


Medals: 2



« Reply #135 - Posted 2014-06-18 13:18:32 »

Not sure what you're arguing about here. Why would they even develop Metal then? That's the odd part. It's not making any sense to developers to have all these crazy different ways of doing the same thing... unless they're trying to push people in a particular direction and then deprecate the redundant methods.

They developed Metal because they have a proprietary mobile chip and they want developers to be able to wring the best performance possible out of it. Metal is only part of the iOS 8 SDK. It's an alternative, not a replacement. A lot of people are suggesting that the main audience for it really is middleware/engine developers. The ordinary developer won't use it directly, but will benefit as Metal is built into Unity or whatever else.
Offline theagentd
« Reply #136 - Posted 2014-06-18 13:53:53 »

Tifanta, a discussion is supposed to involve listening as well. Otherwise it's called a monologue... Here people are speculating about what Apple's ultimate goal with Metal is, based on what Apple has done before. Most of your questions have already been answered.

Myomyomyo.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #137 - Posted 2014-06-18 14:11:41 »

Not sure what you're arguing about here. Why would they even develop Metal then? That's the odd part. It's not making any sense to developers to have all these crazy different ways of doing the same thing... unless they're trying to push people in a particular direction and then deprecate the redundant methods.

They developed Metal because they have a proprietary mobile chip and they want developers to be able to wring the best performance possible out of it. Metal is only part of the iOS 8 SDK. It's an alternative, not a replacement. A lot of people are suggesting that the main audience for it really is middleware/engine developers. The ordinary developer won't use it directly, but will benefit as Metal is built into Unity or whatever else.
I suspect that increasingly only middleware vendors are going to care about it all in the end. Hitting the rendering API directly is getting increasingly fiddly. I could do without it now I think.

Cas Smiley

Offline Roquen
« Reply #138 - Posted 2014-06-18 18:47:36 »

...are speculating about what Apple's ultimate goal with Metal is...
Any speculation is silly.  Sell more units.  This helps because you have an advantage if you can go low-level on an embedded fixed-hardware device vs. any generic API (regardless of how well written it is).

Quote
based on what Apple has done before.
Like what?
Offline TifantaWorld

Junior Member


Medals: 2



« Reply #139 - Posted 2014-06-18 21:45:12 »

Tifanta, a discussion is supposed to involve listening as well. Otherwise it's called a monologue... Here people are speculating about what Apple's ultimate goal with Metal is, based on what Apple has done before. Most of your questions have already been answered.

I have listened to the speculation, and I've refuted most of it directly, in detail.
Offline theagentd
« Reply #140 - Posted 2014-06-18 22:02:57 »

...are speculating about what Apple's ultimate goal with Metal is...
Any speculation is silly.  Sell more units.  This helps because you have an advantage if you can go low-level on an embedded fixed-hardware device vs. any generic API (regardless of how well written it is).

Quote
based on what Apple has done before.
Like what?
If you think this whole thread is pointless, then why post in it? See Cas' posts for examples of similar moves by both Apple and other companies.

Tifanta, a discussion is supposed to involve listening as well. Otherwise it's called a monologue... Here people are speculating about what Apple's ultimate goal with Metal is, based on what Apple has done before. Most of your questions have already been answered.

I have listened to the speculation, and I've refuted most of it directly, in detail.
Good for you. Sorry for not giving you the attention you think that you deserve.

Myomyomyo.
Offline TifantaWorld

Junior Member


Medals: 2



« Reply #141 - Posted 2014-06-19 00:32:33 »

Any speculation is silly.  Sell more units.  This helps because you have an advantage if you can go low-level on an embedded fixed-hardware device vs. any generic API (regardless of how well written it is).

This. Apple has no reason to get rid of OpenGL. Metal will filter down through third-party engines while SpriteKit and SceneKit, which basically compete with simpler third-party engines (like Cocos2d, Corona, JMonkey, etc) will continue to benefit from OpenGL's continued existence. Large-scale developers creating graphically-intensive games may use Metal directly, but most game developers will use it with Unity, and other popular engines, as the interlocutor. Generally speaking, Apple just wants people to be able to make the best games possible on the devices, because games make a lot of money for Apple. If Apple wanted to gain OS market share, there would be far more effective ways to do it than "locking" people to a low-level graphics API (which most people would never use directly anyway).
Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #142 - Posted 2014-06-19 04:45:12 »

This thread is almost literally wrung dry, however...

Quote
If Apple wanted to gain OS market share, there would be far more effective ways to do it than "locking" people to a low-level graphics API (which most people would never use directly anyway).

I'm curious, what would Apple have to do?

Offline TifantaWorld

Junior Member


Medals: 2



« Reply #143 - Posted 2014-06-19 05:02:22 »

I'm curious, what would Apple have to do?

Make iOS available for use on third-party devices.
Offline HeroesGraveDev

JGO Kernel


Medals: 253
Projects: 11
Exp: 2 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #144 - Posted 2014-06-19 05:08:29 »

Not sure how that would go down.

I'd rather have Android on an iPhone than iOS on an Android Phone.

Offline TifantaWorld

Junior Member


Medals: 2



« Reply #145 - Posted 2014-06-19 07:26:26 »

Not sure how that would go down.

I'd rather have Android on an iPhone than iOS on an Android Phone.

But I'm sure that it would get picked up at least on some basis. Better shot at increasing market share, anyway, than trying to lock the tiny subset of people who'd even use a low-level graphics API to the platform. I mean, seriously. How many small-time developers do you imagine that would apply to? Not many, in my estimation. Any development outfit with people experienced enough to use Metal directly (i.e. not through an engine like Unity) is likely too big to get "locked in" in the first place. They'd have teams working on iOS and Android releases already.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #146 - Posted 2014-06-19 07:50:33 »

An idea that could never fly I think... Apple tried that in the 90s with the CHRP and Mac clones. I think the lesson they learned there was, "Don't!". They've got a lucrative hardware business, the most lucrative one in the world by all accounts, so there's nothing needs changing in that respect. If we want to find answers to our speculations of the future we only have to look at the past to get a good idea of how things might turn out.

Cas Smiley

Offline Roquen
« Reply #147 - Posted 2014-06-19 08:02:46 »

See Cas' posts for examples of similar moves by both Apple and other companies.
I've re-skimmed.  I'm not seeing any examples.  He's repeating "They've done it before and they'll do it again." like a mantra but isn't giving any "bad" examples of what exactly "it" is.  I'm translating this into: "I don't feel like learning anything new".  And that's fine.  I'm sure a high percentage of Cobol programmers felt like that way too.  And I've very glad I don't need to program in Cobol on a monolithic OS using round-robin scheduling.  Personally I think the big players don't "shake things up" enough and we (as programmers) are stuck with antiquated tech.  So it goes.

Support for OpenGL in it's current form isn't going going anywhere for quite awhile.  Too much investment in too many sectors to kill it off.  No margin in it.  Microsoft hasn't tried because it would be terrible idea.  They just don't pour much money into it either.  No margin in that either (at least as long as nvidia and AMD don't totally drop the ball.)  Good business.  Let someone else do your work (or the lion's share) for you and spend your resources elsewhere.  Oh yeah, I don't think it's been mentioned but iOS 8 now has WebGL support by default...oh and wasn't Apple actually pushing HTML5?  I'm not confused am I?

On metal.  This isn't even the same playground as OpenGL or DirectX so let's not pretend like it is.  The only impact on OpenGL should be it's yet another example (in many coming out) that all isn't hunky-dork in GPU land.  Real "threats" to OpenGL are probably in the general purpose GPU techs that are being developed by pretty much everybody.  Well actually OpenGL is OpenGL's biggest enemy.

On swift: I can't say if it's a good idea or not...I don't know enough about it.  I can't say why they even created it in the first place.  It could exists for the exact same reason as why we have Java.  Some Sun employees were bored and they hated C++ and its tooling.  So rather than have them jumping ship, Sun tossed them a bone to chew on and out pops Java.  Swift was created by the LLVM creator.  Maybe he needed a bone.  Whatever the reason, it's about time they tried to killing of "industry standard" Objective-C thank you very much.  Maybe it's an awful idea.  So what?  Like I said: I like it when people try to shake the tree.  Would C++ been an better idea?  Or one of the dynamically typed languages?

LATE BREAKING NEWS!
Quote
..speculations of the future we only have to look at the past to get a good idea of how things might turn out.
Yeah yeah:  examples would be good.  Stuff that Apple did for awhile after kicking-out Jobs isn't very interesting...they were just doing stupid shit right and left and didn't have any reasonable direction.   Pro-tip: Don't choose marketing people clueless in tech to head-up a tech company.  Insured fail.
Offline TifantaWorld

Junior Member


Medals: 2



« Reply #148 - Posted 2014-06-19 08:23:03 »

On swift: I can't say if it's a good idea or not...I don't know enough about it.  I can't say why they even created it in the first place.  It could exists for the exact same reason as why we have Java.  Some Sun employees were bored and they hated C++ and its tooling.  So rather than have them jumping ship, Sun tossed them a bone to chew on and out pops Java.  Swift was created by the LLVM creator.  Maybe he needed a bone.  Whatever the reason, it's about time they tried to killing of "industry standard" Objective-C thank you very much.  Maybe it's an awful idea.  So what?  Like I said: I like it when people try to shake the tree.  Would C++ been an better idea?  Or one of the dynamically typed languages?

I'm in the developer program now, so I've been able to use the Xcode 6 beta and work with Swift. It's pretty excellent thus far, even if the IDE itself, in beta form, is still sort of buggy. Code completion in Playgrounds, for example, is not currently that helpful. But the Swift language itself is a major improvement in many ways over Objective-C. Inferred types are quite nice, and the way the language prefers that you use actual constants as much as possible (and not just for global data, for example) is refreshing. The syntactic sugar with ranges (instead of Objective-C's clunky insistence on having to initialize an NSRange object, and then pass that object to a method as a parameter), and so on, is also great. Oh, and the fact that pointer arithmetic is not going to be a thing anymore, that's great too. String interpolation, and generally getting rid of the whole mutable/immutable class thing is excellent.

Apple's main motive in developing Swift and moving away from Objective-C was, I think, to make Mac development more welcoming for people who are used to working with more modern languages like Python, Ruby, and so on. The language gives you all the OO perks, but also embraces functional programming. Methods can take functions as parameters and return functions as well. Methods are actually denoted with the keyword "func" now.

A lot of people claim it will be easier for programmers to learn, but in a way, I think Objective-C was actually easier, if only because it had far fewer things to learn, like optionals, tuples, generics, and so on. Objective-C is, in many ways, a far more stripped-down language. But it's also clunkier, and its dependence on its C underpinnings leads to inconsistencies that really start to gnaw away at you after a while if you ever end up using both in the same project.
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #149 - Posted 2014-06-19 08:49:11 »

See Cas' posts for examples of similar moves by both Apple and other companies.
I've re-skimmed.  I'm not seeing any examples.  He's repeating "They've done it before and they'll do it again." like a mantra but isn't giving any "bad" examples of what exactly "it" is.  I'm translating this into: "I don't feel like learning anything new".  And that's fine.

Well... Java on OSX, for one. Deprecated, then moved to optional download, not even sure if it's available at all from Apple in 10.9. It's not like Java isn't available any more, but it broke everyone's Java stuff at around the time of 10.6 and we're still suffering from that now which is irritating.

Microsoft and OpenGL is another example. Sidelined, Direct3D appears, investment ploughed into D3D.

Internet Explorer's mid-term strategy appeared to be to try and dominate by effectively changing the framework that the whole web worked on. Fortunately didn't prevail and they've embraced open standards.

Actually Microsoft zap tech far quicker than most. .net, WPF, GDI+, etc... all strange offshoots that lasted just a short time. Their current flavour of the month is the deadly shit trio of HTML5/CSS3/JS.

It's not like I think that it's weird or unusual or anything... just something that happens, and usually for entirely sensible pragmatic reasons. The way I see it right now is that OpenGL is up against a bit of a dead end because of limitations with the design of the API and so various OEMs are coming up with all sorts of closed proprietary APIs to deal with the shortcomings, which solves just two problems (easier programming on one particular platform, and performance on that platform) and creates loads of other problems (all centred around porting friction). As Riven says, a clean break OpenGL 5.0 that looks at these new APIs would get things back on track. Without such a new OpenGL API though we're in an annoying wilderness of non-portable APIs and code and it's more or less back to the dark ages.

For the record, I do hate learning new ways to do the same old f**king thing Smiley I'm only really interested in new ways to do new things. Right now where things are currently interesting to me are the areas of multithreaded design and the gradual elimination of runtime exceptions. I see many solutions sprouting off in all sorts of directions but many of them make fundamental mistakes in lexical design or syntactical design that almost look like "trying to be different for the sake of it". One of Java's best secret weapons was its sheer lexical simplicity and consistency, along with its superficial similarity to C++.

Cas Smiley

Pages: 1 ... 3 4 [5] 6
  ignore  |  Print  
 
 

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (24 views)
2014-09-19 03:14:18

Dwinin (39 views)
2014-09-12 09:08:26

Norakomi (68 views)
2014-09-10 13:57:51

TehJavaDev (93 views)
2014-09-10 06:39:09

Tekkerue (47 views)
2014-09-09 02:24:56

mitcheeb (68 views)
2014-09-08 06:06:29

BurntPizza (51 views)
2014-09-07 01:13:42

Longarmx (38 views)
2014-09-07 01:12:14

Longarmx (44 views)
2014-09-07 01:11:22

Longarmx (40 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!