Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 15 Dec 2001
Online Last Active Today, 09:42 AM

#5195659 OpenGL 5 - Release?

Posted by phantom on 01 December 2014 - 03:23 AM

The reason for a new API, ground up ditch all the shite version, can be surmised quite simply;

Currently OpenGL, OpenGL|ES and D3D11 are the only 3 major APIs in the wild which do not support 'going wide' on their command buffer building or do not see any speed up from doing so. (3 of 9 it should be added.)

Next year OpenGL and OpenGL|ES will be the only APIs not to support this.

CPU archs are wide.
Graphics setup is naturally wide.

So, from just an ease of writing and compatibility mindset OpenGL will require a bunch of hoop jumping just to use sanely; maintaining this going forward is not helpful.

#5195191 OpenGL 5 - Release?

Posted by phantom on 28 November 2014 - 08:24 AM

Wow, for a moderator you are a real ******* (I know I am risking getting banned here, who cares with such a community).

Yep, and I'm ok with it...
(and judging a whole community on one person? really? drama much?)

Also that reply wasn't direct just at you, however I missed an 's' which is why you could take it as such.

Either way I stand by it because frankly I'm bored of the constant 'MS are evil/bad/whatever' narrative which continues to run rampant (in general, not just with GL) and if someone is willing to buy into that without either doing the research or asking a question before putting forward a strong opinion then, well, you'll get such a reply from me.

And as you are apparently new around here; there is an unofficial agreement in place that if a moderator takes part in a thread they will not moderate in that thread, certainly not for things involving them, which is something I've stuck by - if you have a problem with that post, or indeed any post, feel free to report it I won't stop you or act on it and if anyone else in the mod team has a problem with my conduct then they will say something and if needs be I'll give up the position.

#5195145 OpenGL 5 - Release?

Posted by phantom on 28 November 2014 - 05:25 AM

Oh for the love of pete...

Dear Microsoft Conspiracy Theorists,

This is not the 90s or early 200s.
Microsoft have had nothing do with OpenGL since they left the ARB in March 2003 - 11 years ago.
Since then NV, ATI, AMD, Intel and others managed to successfully blunder the development of OpenGL on the desktop platform on their own.
MS don't need to sabotage OpenGL because the ARB and the Khronos board made up of ARB members managed to royally screw that up on their own - D3D won the battle some time ago.

The ONLY thing MS are involved in is their recent sign up to the WebGL group because they are implementing it (as everyone asked them to do...).

Please... just... learn some history and update your mental model... because... well... ugh...

#5195131 OpenGL 5 - Release?

Posted by phantom on 28 November 2014 - 03:03 AM

The more realistic scenario is something more like another bunch of extensions to add to the current mess, and we end up waiting 2/3/4/5 years for Intel and AMD to fully implement them in their drivers.

I guess it all comes down to how serious they were about 'brand new API' in the slides.

My bet on the path would be that next year you get a shiny spec for OpenGL|NG and maybe some implementation but likely not until Siggraph (as that tends to be when OpenGL stuff is announced) along side an OpenGL4.6 spec which adds a bunch of new extensions for many of the things but not all of them.

The thing is the worry about 'backwards compatibility' isn't really a big one; every time DX changes tools get rewritten, games get rewritten, people are willing to take the pain IFF the gains are worth it (thus lack of D3D10 adoption) - game devs have spent some time yelling about this and when Mantle appeared went 'yes... this!' and where heavily critical of the OpenGL approach of 'look, these extensions mean we don't need a new API!' hand waving we got for about a year (until suddenly a new API was a good idea..).

If they haven't learnt from it then OpenGL will remain the ugly child left out in the cold once more, only used when we are forced to.

(And while everyone loves to yell about cross platform compatibility lets not forget that Mobile is the only place OpenGL, in the form of OpenGL|ES, has any real weight. D3D gets you Windows, Windows Phone and Xbox, PS4 uses it's own API, iOS has Metal, WiiU has it's own API and Linux and OSX are still showing very low market shares still for desktop - and OpenGL|ES also suffers the overhead problem (along with general Android cluster-fuckery) - so if they screw up it'll be a screw up which will be largely ignored in the AAA space in favour of the better APIs anyway until we are forced to deal with it, and I personally wouldn't count on seeing OpenGL|NG in whatever form it takes on Android until maybe 2016 or 2017 anyway so...)

#5195015 OpenGL 5 - Release?

Posted by phantom on 27 November 2014 - 12:35 PM

Take in mind it is most likely GL NG will be just GL4.5 without any legacy cruft, with a unified shader compiler or IL, plus some ideas taken from the Mantle API like being multithread friendly, explicit access of DMA engines, and being multi-GPU and multi-monitor aware.

I don't think it will... or rather if it is then I'll slap a bit Failed sign on the API and move on with my life.
OpenGL, as it stands, does not reflect the GPU and just 'dropping the cruft' does not get you the performance you need.

Mantle is a simple API, from someone doing a dump of the entry points it has around 40 entry points, that is it.

OpenGL NG needs to look more like the proposed Mantle/D3D12 model than the current OpenGL model; 'cutting the cruft' isn't going to cut it this time around.

#5195013 UDK 4 vs Unity - Which is better and easier to use to make a first person act...

Posted by phantom on 27 November 2014 - 12:23 PM

*puts on Epic Employee hat*

The last few % in graphical glitz might cost you some $, but as long as you shop smart, its below 100$.... which you also will have to pay over the lifetime of your UE4 usage for upgrades.

Of course those upgrades includes a LOT of stuff; as I said before every 6 weeks or so we are kicking out updates which include performance fixes and new features (a some sizable list of them at that, via community feedback) not just graphical glitz - as to if people think this is worth while or not is another matter but trying to say that a 'few asset store things' is the same as 4 or 5 months of updates is a little misleading imo (more so considering the higher base set you get for your $20 - which can be a one off payment - than the free unity stuff).

#5194822 UDK 4 vs Unity - Which is better and easier to use to make a first person act...

Posted by phantom on 26 November 2014 - 02:04 PM

*puts on Epic Employee hat*

Unreal still requires 5% royalties on gross sales, but the price per seat for developers (considering the feature set) is bound to attract some attention from the indie scene.

Just to clear up A Thing.
The royalties are on a per-quarter amount and you only pay after the first $3,000 (gross) made in that quarter.
In theory this means that you could make $2,999/quarter and not have to pay Epic a dime. If you factor in the 30% cut many places take then you can make $2099.30/quarter before the 5% kicks in and then it is only 5% over the $3,000.

Reading the FAQ it seems to imply that it is per-product, so in theory you could have 4 games out, all pulling in less than $3,000/quarter each so you end up with just over $10K/quarter net income and don't have to pay Epic a dime.
(I'd double check that of course but that's what I read when it says 'per product')

For $20.

(Although personally I'd say if you can afford to keep the subscription do so; we push out updates pretty quickly with release 4.6 due soon and release 4.7 work well under way and there are hot fixes which go out too - plus who doesn't want to follow master and see every live commit? ;))

#5193426 is there a better way top refer to assets in a game?

Posted by phantom on 18 November 2014 - 07:30 AM

if i'm drawing 16,000 non-instanced meshes, i don't want to be looking up the array index for the mesh filename of each one.

Well, no... even if you weren't doing 'data driven' you'd still pre-cache the index on creation because doing it every draw would be dumb dumb dumb - if you are looking up data which can not change every frame on every frame then you are Doing It Wrong regardless of if you are doing the look up via text, id or lasers bounced off the moon.

Also 16,000 draw calls is going to crash your framerate so you've already got problems...

#5192959 is there a better way top refer to assets in a game?

Posted by phantom on 15 November 2014 - 03:30 AM

In any case, you shouldn't have code like playwav("some_sound.wav"); though -- more like:
Sound* some_sound = loadwav("some_sound.wav"); //filename processing paid once, pointer obtained
playwav(some_sound); // no details of filesystem involved per frame

1000x this.

Load sound once; obtain handle to sound; play via handle either playwav(handle) or soundObj->play().

At BEST I might have a playprecached("some_sound"); which would do the name hashing and lookup from the resource container there and then but still no disk I/O at that point.

#5192476 Why don't you use GCC on windows?

Posted by phantom on 12 November 2014 - 01:33 PM

And as of today, with the offering of a Community Visual Studio 2013 which gets you plugin support I'd say there is even less reason to use anything but VS on Windows.

And the 2015 stuff which is coming is just added gravy on top... (see link).

#5191847 Assets reloading and streaming

Posted by phantom on 08 November 2014 - 03:39 PM

I've worked on a system which used a mixture of the two things you mention.

When a resource is loaded it can request a handle to other resources (so a material might say "give me a handle to a texture with the name 'grass'") and in the process it is registered as 'interested' in that resource.

When a resource is loaded, or unloaded, anyone interested in it is sent a message and can react accordingly to the message - so in the case a material it could swap for a 'default' texture or just flag itself as 'unrenderable' which would then ripple upwards, so the mesh using the material would know it couldn't render and thus would prevent itself from doing so.

When something was loaded in anyone interested in it could do whatever 'bind' work was needed on the loaded message - so in the case of the material it would grab the texture handle (for the 3D device being used, this system was cross platform) and cache it for a later draw call.

This meant that we could remove ANY rendering resource and with the correct call backs in place handle it gracefully - which in our environment meant that an artist could make a chance to a texture, save it and with one press of a button it would be cooked to a game ready format, the game would be told to unload the old one (which would stop it rendering whatever it was on but only those things), load the new one and rebind with no hitch at all - the system was so good we could unload the whole scene description for the render (what passes) and reload it as if nothing had happened.

The key point being the bind/unbind caching should only be done once; so there should be zero overhead when compared to a normal system.

#5189830 Current state of custom and commercial game engines as of 2014

Posted by phantom on 28 October 2014 - 06:28 PM

Either way, I still believe there are more Unity programmers being "produced" than hardcore ones, and that happens because of this engine monopoly.

However I don't think we've lost anything in this regard; people interested in low level will go low level because they'll have a desire to find out more - Unity and UE4 just open up the game dev world to those who don't care about the details and just want to make games.

OR to put it another way;
Lets say pre-Unity there were 100,000 programmers and 50,000 of them were low level.
Now we might have 400,000 programmers and 60,000 low level - the proportion of low level might have dropped but the over all pool has increased.

Before today people the people doing low level hardcore stuff where the ones who wanted to learn; in my case I looked at a BBC and wondered 'how does that work...' and went from there. You'll still have those people, you'll always have them, they just make up a lower percentage of the programmers over all and that's ok.

In the end we get more cool games to play and the demands of those games feed back into the tech - people who know the tech will always be needed to build and maintain it but it'll be the games which drive it forward.

As to what you should do, well, follow your passion.
If your thing is tech then go make the coolest tech you can.
If you want to make a game then make a game - pick an engine, make your own, but do it because you want to.

That is what has build this business after all.

#5188790 Is optimization for performance bad or is optimizating too early bad?

Posted by phantom on 23 October 2014 - 12:49 PM

To quote more than a few different tech leaders, the mentality that "premature optimization is evil" is why Word takes 10x longer to open today than it did on significantly weaker hardware over a decade ago. (I'm not in 100% agreement with that, but not in complete disagreement either.)

Honestly, I would disagree with it completely if that's the full extent of their usage of the quote; the whole point of the 'premature optimisation' thing isn't "don't optimise until you need to" but "don't try to optimise until you have profiled" with the rider "but don't write dumb code to start with either..".

People who throw quotes away in a lazy manner annoy the fuck out of me because they mangle the message to serve their own agenda...

#5188508 Why not use UE4?

Posted by phantom on 22 October 2014 - 06:41 AM

This was just a rendering error in a test scene; G2 looked fine, Nexus 5 was missing some textures as I recall - I've not cycled back around to that problem in a few days.

As for shaders, currently we just on demand compile them on the device; I don't think that will change any time soon as we have an init step which basically throws a pixel shader at the hardware to figure out what it can and can't deal with and then patches shaders on load to work around issues.

(FYI: don't trust this either - I'm pretty sure the spec says "if a device can not support a precision requested compile or link will fail" but I've seen Mali-400 devices silently convert code from highp to mediump, with just a note in the log, which then causes fun errors because Mali-400 only has 10 bits of precision at medium so you end up with problems such as artefacts in sky domes...)

#5187627 Why not use UE4?

Posted by phantom on 17 October 2014 - 04:48 AM

nowadays there are lots of platforms to target...

And in the case of Android that is basically 'one platform per phone per chipset per driver' as Android isn't one platform it's a utter fuck tonne of them all broken in various ways and lying to you in others.

Case and point; Nexus 5 is, hardware wise, an LG G2 - the former has rendering issues the latter doesn't have... well played Android, well played.