Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (132)
games submitted by our members
Games in WIP (603)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2] 3 4 ... 6
  ignore  |  Print  
  Apple announces new graphics API: Metal  (Read 8841 times)
0 Members and 1 Guest are viewing this topic.
Offline Roquen
« Reply #30 - Posted 2014-06-03 12:14:17 »

"Dear JGO:  I'm working on a game and everything has been hunky-dorky until recently.  I've found that adding new features to my game is getting harder and more and more bugs are appearing.  What I'm I doing wrong???"
Here's my game:


And there's one class file that looks something like this:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
public class Game
{
  final static int MAX_ENTITY_ARGS = 5;
  final static int MAX_ENTITIES = 100000;
 
   static int[] activeEntity = new int[MAX_ENTITY_ARGS];
   static int currentError;
   static int[] entityX = new int[MAX_ENTITIES];
   static int[] entityY = new int[MAX_ENTITIES];
   
   final static int ERROR_SLOT = 0x0123123;
   
   public static int getError()
   {
     return currentError;
   }
   
   public static int getActiveEntity(int slot)
   {
     if (slot <MAX_ENTITY_ARGS)
       return activeEntity[slot];
     
     currentError = ERROR_SLOT;
     
     return -1;
   }
   
   public static void setActiveEntity(int entity, int slot)
   {
     if (slot < MAX_ENTITY_ARGS) {
       activeEntity[slot] = entity;
       return;
     }
     currentError = ERROR_SLOT;
   }
   
   public static void setActiveEntity0(int entity)
   {
     activeEntity[0] = entity;
   }
   
   public static void setActiveEntity1(int entity)
   {
     activeEntity[1] = entity;
   }

   public static boolean isLineOfSight()
   {
     int e0 = activeEntity[0];
     int e1 = activeEntity[1];
     int x0 = entityX[e0];
     int y0 = entityX[e0];
     int x1 = entityX[e1];
     int y1 = entityX[e1];
     
     // <snip>
   }
   
    public static boolean canEntitySeeEntity(int e0, int e1)
    {
     setActiveEntity0(e0);
     setActiveEntity1(e1);

     return isLineOfSight();  
    }
}


Quote
a subset of an API that works well, and generally, that's what we're getting, and using, successfully.
Sure.  Because there isn't another viable option.  Life would be alot easier with an API that does what you say and doesn't suck.  We could make the same argument for about anything.  We could program huge apps in C and if that was the only option we'd do it.  C is great, but it scales like crap.
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #31 - Posted 2014-06-03 13:04:06 »

@Roquen: http://www.opengl.org/registry/specs/EXT/direct_state_access.txt

Myomyomyo.
Offline Cero
« Reply #32 - Posted 2014-06-03 17:02:50 »

Every one in web is crying how openGL is broken/retarded/slow and when somebody is trying to give low level rendering API that potentially has market and actual need its suddenly bad thing? I personally used months for our last iOs game cpu optimizations and huge share of that went for fighting with driver overhead. It would have been so much faster to just use some different rendering API with direct control instead of just guessing fast paths.
Thats valid, but thats a very specific use-case Shocked

How normal 60fps game is spesific use-case? Gameplay needed 60fps with minimal input latency and absolute no stutter and we still wanted modern and clean 3d look. I happened to be only graphics programmer so my job was to deliver that.

Well programming to only one platform and then getting a specific lib for just that platform... thats specific.
would be the same deal if there was an android specific graphic lib.
The rest you say is super valid but only targeting one system, almost only one console - well sure in that case you can have a very powerful direct API. The point of opengl is that it works on so many platforms and hardware

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline ags1

JGO Wizard


Medals: 75
Projects: 3
Exp: 5 years


Make code not war!


« Reply #33 - Posted 2014-06-03 17:42:51 »

Didn't Apple originally create opengl?

Offline The Lion King
« Reply #34 - Posted 2014-06-03 17:59:23 »

Didn't Apple originally create opengl?

Nope but they were a big supporter of it and they have used it since practically the beginning, In fact at the time when hardware acceleration was a new thing, Apple jumped on it and made their windows hardware accelerated using OpenGL.

"You have to want it more than you want to breath, then you will be successful"
Offline TifantaWorld

Junior Devvie


Medals: 3



« Reply #35 - Posted 2014-06-04 01:38:12 »

Seriously, people. Apple is not going to drop support for OpenGL. Do you know how many games would instantly go kaput on the App Store if they did that? What Apple is doing is supporting a new API which they claim allows developers to access the power of the A7 chip on their mobile devices more easily and effectively. This is an iOS-centric thing, in other words. I'm not sure why every single announcement Apple makes has to be treated like this big travesty by many in the (largely non-Apple) programming community.

The bigger news at WWDC is that Apple is now using a new programming language. For those who argue that this is all part of Apple's big plan to make everything proprietary ... well, Objective-C was already a de facto proprietary language. It was, quite literally, only used for Apple development, and Apple was the only entity maintaining it. What Swift does is reassure Apple developers that they've made a good choice to stick with the platform, not only because the App Store ecosystem is far better than Android's, but because they now get a truly modern language to work with that isn't just some updated version of Objective-C with "modern features" chunked onto it. This is simply great for Apple developers, any which way you cut it. Oh, and you can include Objective-C and C code right alongside Swift, because they all use the same compiler. And the Swift development environment is absurdly cool.

Really not seeing the problem in any of this.
Offline Roquen
« Reply #36 - Posted 2014-06-04 05:39:20 »


Thanks..this is a massive improvement:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
   public static boolean isLineOfSightEXT(int e0, int e1)
   {
     if (isValidEntity(e0) && isValidEnity(e1)) {
       // <snip>
     }
     
     setError(ERROR_ENTITY_SLOT);
     return false;
   }
   
    public static boolean canEntitySeeEntity(int e0, int e1)
    {
     boolean r = isLineOfSight();
   
     if (getError() == ERROR_NONE) {
       //<snip>
     }
Offline theagentd

« JGO Bitwise Duke »


Medals: 366
Projects: 2
Exp: 8 years



« Reply #37 - Posted 2014-06-04 09:25:56 »

I can't tell if you're being sarcastic or not but... Yes. Yes, it is a huge improvement.

Myomyomyo.
Offline Roquen
« Reply #38 - Posted 2014-06-04 09:48:08 »

It depends on what point of view I'm taking.  Yes direct access to a given item is much better than to an implied item.  My joke example is intended to highlight how awful the API design is for today's world.  Ignoring the bigger picture it require minor inefficiencies everywhere and ones that aren't too nice to the limited branch prediction tables.

Seriously think about both sides, what's required to happen in the driver and application side.  If someone where to design a game engine in the same manner you'd tell them it's the stupidest idea on the planet.
Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #39 - Posted 2014-06-04 10:08:22 »

Evolution over revolution eh.

I suspect the issue they're dealing with is more to do with making it language agnostic and easier bindings to other things. As it is OpenGL is relatively easy to map to OOP languages in whatever style you'd like to do it, whereas an existing OOP style mandated by OpenGL would remove the choices.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TifantaWorld

Junior Devvie


Medals: 3



« Reply #40 - Posted 2014-06-04 11:19:53 »

All the OpenGL-related Core Graphics stuff in Objective-C was really just C dressed up in structs to look and act (somewhat) like objects. They're trying to make it so working with the graphics at a lower level isn't this entirely separate experience from the rest of Cocoa/Cocoa Touch APIs. None of this stuff was intuitive before. You had to learn Objective-C, then learn the Cocoa/Cocoa Touch APIs, and then learn the Core Graphics stuff, which also depended on having at least a decent amount of experience with C. It was a pain in the butt. Apple is trying to retain current developers and draw in new ones. That's their primary goal here.
Offline Roquen
« Reply #41 - Posted 2014-06-04 11:52:34 »

whereas an existing OOP style mandated by OpenGL would remove the choices.
You wouldn't have to go the DX route of low-level interfaces as C++.  You could stick to a C interface.  I don't see any choices that would be "removed" by going C++ though.  (Not that I would care one way or the other about this bit).
Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #42 - Posted 2014-06-04 12:36:00 »

Well not so much "removed" as just made more awkward.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #43 - Posted 2014-06-04 17:16:47 »

Seriously, people. Apple is not going to drop support for OpenGL.

People said the same thing about Flash.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Roquen
« Reply #44 - Posted 2014-06-04 17:20:11 »

That was a good call.
Offline ra4king

JGO Kernel


Medals: 356
Projects: 3
Exp: 5 years


I'm the King!


« Reply #45 - Posted 2014-06-04 17:30:17 »

Seriously, people. Apple is not going to drop support for OpenGL.

People said the same thing about Flash.
Apple never supported Flash in the first place. I highly doubt OpenGL support will get dropped anytime soon, as that would mean breaking almost all existing games.

Offline Cero
« Reply #46 - Posted 2014-06-04 18:29:20 »

Apple never supported Flash in the first place. I highly doubt OpenGL support will get dropped anytime soon, as that would mean breaking almost all existing games.
most ? currently that would be ... all, right ?

Offline pitbuller
« Reply #47 - Posted 2014-06-04 21:45:00 »

http://c0de517e.blogspot.fi/2014/06/rate-my-api.html
Offline TifantaWorld

Junior Devvie


Medals: 3



« Reply #48 - Posted 2014-06-04 22:40:43 »

People said the same thing about Flash.

Nice, pithy response, but it lacks rational analysis. Do you know why Apple "dropped" Flash? Because it ran like junk on their devices and Adobe never made it right. Heck, it took them 10 years--10 years!--to fully implement their Creative Suite, used heavily on Macs by design professionals, natively in Cocoa. You can, perhaps, forgive Apple for feeling like this particular 3rd party was taking them for granted and giving them the run-around. It's not Apple's fault that Adobe only claimed to see the light once the iPhone dropped, mobile suddenly boomed, and it actually *mattered* to lose Apple's support. Apple also saw HTML5 and hardware acceleration for browser graphics coming down the pipeline, and knew that Flash was soon going to be a thing of the past anyway. Worth noting, however, is that the "drop" only applied to iOS and the fact that Apple would no longer pre-bundle Flash in OSX. You can still download Flash on your own, or if you use Chrome, it will already be integrated into the browser for you. Not quite sure why anybody would want to proactively support Flash these days, though, unless they made Flash games or something like that. It's basically dead in the water.

Compare that to the OpenGL situation: This only applies to iOS and accessing the power of the A7 chip. They created an API which they've claimed allows developers to eke out better performance, more easily, from it. You can still use OpenGL, as usual, if you want. Why? Because Swift uses the same compiler as Objective-C, which means you can run your Objective-C and C code alongside it. Apple's contention is that you generally aren't going to want to, though, because Swift is not only more elegant to write, but also faster/more efficient than Objective-C, and you won't have to be well-versed in C just to manipulate the low-level graphics capabilities of the device.

You have to understand: if, once iOS8 comes out, Apple said, "Okay, OpenGL is now gone," that would effectively kill off a huge number of games in the App Store, needlessly. With the iOS update adoption rate being what it is, those games would enter the dustbin largely overnight, and Apple would lose a huge source of revenue. They have no reason to do this. They aren't going to do this. The paranoia is simply not justified.

The reality is that working with OpenGL in Objective-C was a big pain for most developers. It was designed to feel "integrated" into the experience through the use of C structs, but it just felt tacked-on and, well, wrong. Swift and Metal are not nefarious. They represent a real attempt, on Apple's part, to finally integrate all these aspects of iOS development, to make them feel like parts of a single, consistent process.

(I kind of hate how, as someone who also writes Java and Ruby code, I have to come off like a huge Apple fanboy here.  Cheesy)
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #49 - Posted 2014-06-08 20:56:10 »

Having a better designed API is always a sucky excuse if it means changing everything for developers to become more locked into some platform.
Why didn't they just implement their Metal stuff within OpenGL?

Offline TifantaWorld

Junior Devvie


Medals: 3



« Reply #50 - Posted 2014-06-09 02:20:47 »

Having a better designed API is always a sucky excuse if it means changing everything for developers to become more locked into some platform.
Why didn't they just implement their Metal stuff within OpenGL?

Because in terms of current iOS development, implementing this stuff in OpenGL means implementing it in C. Apple is trying to move away from C, not chain itself to C even further.
Offline Roquen
« Reply #51 - Posted 2014-06-09 05:23:36 »

I don't get all the interest in metal outside of Apple devs.  The only thing I find shocking about it is:  What the f**k took them so long?  This should have been in place before they shipped the first prototype to outside devs.  Low level access is the rule of the game for embedded device development.

Quote
Why didn't they just implement their Metal stuff within OpenGL?
That doesn't even make sense.  It would be purpose defeating.

Dev lock-in?  WTF?  How so?  All dev platforms have platform specific APIs.  Big deal.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #52 - Posted 2014-06-09 11:00:02 »

Quote
Why didn't they just implement their Metal stuff within OpenGL?
That doesn't even make sense.  It would be purpose defeating.

Dev lock-in?  WTF?  How so?  All dev platforms have platform specific APIs.  Big deal.

tbh I don't know any details about Metal; I was sort of referencing Carmack who stated that Mantle could have been done as OpenGL extensions and on surface it looked like Metal was going for something similar as Mantle.

And yes, all platforms have specific APIs, and that is a big deal as that was an important reason for Java to exist in the first place.
Maybe Apple intends to make Metal an open standard, but realistically that won't really make a difference. It's not like Google or Microsoft will be in any hurry to support it.

The big game engines like UE and Unity will probably support it if Metal becomes successful, but I can't imagine many developers being overjoyed with the idea of having to deal with yet another API that does the same thing.

Offline Roquen
« Reply #53 - Posted 2014-06-09 11:12:43 »

Quote
Microsoft
They don't care.  They're with the program of having a low-level versioned graphics API.

Quote
I can't imagine many developers being overjoyed
Those that aren't interested don't need to bother.  Those that are can't do the same thing with OpenGL.  Where's the problem?  Outside of embedded devices it would be great if OpenGL died.  I don't care if it were replaced with a newer non-backward compat low-level (versioned) thing called OpenGL.  Toss a backward compat version of top of that low level and everybody's happy.
Offline TifantaWorld

Junior Devvie


Medals: 3



« Reply #54 - Posted 2014-06-09 11:25:07 »

The big game engines like UE and Unity will probably support it if Metal becomes successful, but I can't imagine many developers being overjoyed with the idea of having to deal with yet another API that does the same thing.

Apple already demo'd it being used with Crytek and Unity engines.

Developers work with the best tools for the job that are available at the time. Developers don't pitch a fit just because there's a new API, as long as the new API means they can do better work.

And the bottom line is, if you still want to use OpenGL as is, you'll be able to do that on iOS. It's been said again and again: Apple is not getting rid of OpenGL. What they're trying to do, over the long-term, is offer a unified toolset for app development. Currently, developing with OpenGL is a fractured process, in which you're forced to bridge Objective-C and C. Apple wants to provide a way for developers to circumvent that mess, while getting the most out of the A7 chip as possible.
Offline princec

« JGO Spiffy Duke »


Medals: 435
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #55 - Posted 2014-06-09 11:39:45 »

My subtle prediction is that they will a) let OpenGL ES support on iOS (and possibly MacOS) stagnate and then b) quietly deprecate it completely a couple of years down the line. They will then provide OpenGL drivers as an optionally downloadable framework for end-users to run "legacy" applications. In the meantime developers, whilst not actually locked-in, begin to feel a little bit of drag when trying to swim slightly against the currents of Apple's whimsies, subtly backed by increasing numbers of whining customers.

They've done this before... they'll do it again.

Cas Smiley

Offline ags1

JGO Wizard


Medals: 75
Projects: 3
Exp: 5 years


Make code not war!


« Reply #56 - Posted 2014-06-09 11:50:41 »

The big game engines like UE and Unity will probably support it if Metal becomes successful, but I can't imagine many developers being overjoyed with the idea of having to deal with yet another API that does the same thing.

Apple already demo'd it being used with Crytek and Unity engines.

Yes, Game Engine Vendors LOVE all these new APIs mushrooming up at the moment. from their point of view there can't be enough of them. The more fractured the graphics world becomes, the more people are dependent on the game engine vendors to bridge the divides.

Offline Roquen
« Reply #57 - Posted 2014-06-09 12:33:39 »

Update to date (with respect to what hardware looks like) graphics APIs make your life easier...not harder.  They also  have a much lower learning curve.
Offline Rayvolution

« JGO Spiffy Duke »


Medals: 261
Projects: 2
Exp: 1 year


Resident Crazyman


« Reply #58 - Posted 2014-06-09 18:33:40 »

My subtle prediction is that they will a) let OpenGL ES support on iOS (and possibly MacOS) stagnate and then b) quietly deprecate it completely a couple of years down the line. They will then provide OpenGL drivers as an optionally downloadable framework for end-users to run "legacy" applications. In the meantime developers, whilst not actually locked-in, begin to feel a little bit of drag when trying to swim slightly against the currents of Apple's whimsies, subtly backed by increasing numbers of whining customers.

They've done this before... they'll do it again.

Cas Smiley

I'd bet money on it. This is what people don't understand about Apple, they've been doing this for the last decade. Their goal is to own everything connected to apple. The more locked in you are, the more power they have to strong arm people into using their overpriced machines.

I mean hell, take iOS development. There is absolutely no reason why you *have* to have a Mac to develop on iOS other than they just want it that way. I'm sure that an iOS IDE could exist on windows, but they can't sell those pretty $3000 Macbooks to Android devs who want to port over.

(EDIT: and the addition of Metal will make it more justified to make iOS development mac-only, hmm?) Wink

- Raymond "Rayvolution" Doerr.
Retro-Pixel Castles - Survival Sim/Builder/Roguelike!
LIVE-STREAMING DEVELOPMENT: http://www.twitch.tv/SG_Rayvolution
Offline TifantaWorld

Junior Devvie


Medals: 3



« Reply #59 - Posted 2014-06-10 04:25:15 »

My subtle prediction is that they will a) let OpenGL ES support on iOS (and possibly MacOS) stagnate and then b) quietly deprecate it completely a couple of years down the line. They will then provide OpenGL drivers as an optionally downloadable framework for end-users to run "legacy" applications. In the meantime developers, whilst not actually locked-in, begin to feel a little bit of drag when trying to swim slightly against the currents of Apple's whimsies, subtly backed by increasing numbers of whining customers.

They've done this before... they'll do it again.

Cas Smiley

Doesn't make sense. The Metal API only applies to the A7 chips in Apple's newest mobile devices. Ditching OpenGL would affect the OSX end of things, too.
Pages: 1 [2] 3 4 ... 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.

rwatson462 (36 views)
2014-12-15 09:26:44

Mr.CodeIt (29 views)
2014-12-14 19:50:38

BurntPizza (61 views)
2014-12-09 22:41:13

BurntPizza (98 views)
2014-12-08 04:46:31

JscottyBieshaar (58 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (76 views)
2014-11-29 21:32:03

toopeicgaming1999 (137 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (37 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!