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!


phantom

Member Since 15 Dec 2001
Online Last Active Today, 05:06 AM

#5219552 Google Play Alpha Testing

Posted by phantom on 27 March 2015 - 03:30 AM

OK, so just to keep this topic updated for any future reference smile.png

Got someone to create a private Google Community with at least my account in it.
Having joined that community I added it to the Alpha Testers group.
Upon visiting the url you get to let you become an alpha tester I was able to see a page to let me join the test.

At this point I'm waiting for Something to happen so that I can in fact download the app - apparently this can take a few hours? (wut?)

Account in group remains the same account the app was published with - the fact that it doesn't "just work" remains frankly insane.


#5219266 Why didn't somebody tell me?

Posted by phantom on 26 March 2015 - 03:45 AM

Better than trying to throw Kosh to the wind...
B5_kosh01b.jpg


#5219042 Google Play Alpha Testing

Posted by phantom on 25 March 2015 - 06:15 AM

After many a google search and even a brief twitter exchange I wanted to confirm something here if possible.

I have an app I want to Alpha test.
I have a google play account which will publish this app.
I have a phone which is logged into the same account.

If I publish the app as alpha can I just access it via the account?
OR
Do I have to be part of a google group/g+ group in order to test it?

In short, is my only option here to create a group, of which I'll be the only member, in order to test this app?


#5218597 Vulkan is Next-Gen OpenGL

Posted by phantom on 23 March 2015 - 02:42 PM

Multidraw is implicit rather than explicit: there is no "grCmdMultidraw"; I assume that in order to get multidraw you will push multiple grCmdDraw calls onto a command buffer, then submit the command buffer.  A variant way of looking at this is that every draw call is also a multidraw call.


Multi-draw is largely a CPU optimisation which is why you don't see it going forward; in the client-server days it would have minimised network traffic and these days it means the driver can trivially expand without having to do any checks after the first call that invariants haven't changed and without requiring a round trip into the driver just to do draw operations with the same parameters.

With 'direct' command buffer writing and a much lower overhead and the ability to submit your own command batches multidraw becomes redundant as an API concept.


#5218013 Doge Indirection

Posted by phantom on 21 March 2015 - 02:58 AM

unsee.jpg


#5217304 Transition From Unity To Unreal Engine 4

Posted by phantom on 18 March 2015 - 03:20 AM

Its largely going to be a case of 'try things and see', certainly where UI changes are involved.

The Unreal Engine youtube channel (here) which I assume you've been using does have some old videos but the more recent ones should be using a closer UI. Things like the Blueprint Jump Starts should be pretty up to date.

With regards to the reliance on Blueprints; this is effectively the language for UE4 much like C# is the language for Unity. The idea is to present a (reasonably, some changes are going on still) consistent UI and experience between the different parts of the engine be it Material Graphs (which you call out) to Animation and AI.

With regards to your specific thing about terrain; what you've created is a Material, which can indeed have slots to place different textures in difference instance of it, which should be on a par with what Unity does but in a different way.

Material Blueprints are just describing how the material works, and I assume Unity has a similar system to describe a material without having textures and the like defined directly in the material.

For specific help on things you'd want to check out the Unreal Engine Forums where people are likely to be able to help out with issues and indeed coming from Unity to UE4.


#5216034 Vulkan is Next-Gen OpenGL

Posted by phantom on 12 March 2015 - 05:25 AM

Yes, instancing and indirect calls are here to stay; the former might break down to a few draw calls in the driver/command processor but are useful still for expressing intent.. the latter is a different class of call as instead of embedding the draw information (counts, offsets, etc) in the command buffer that information is sourced from a location in GPU memory.

So in command stream terms it is the difference between;
[draw][mode][first][count][primcount]
and
[fetch][location][draw_indirect]

Where the 'draw_indirect' command knows to look at a certain register in the command processor for the details.


#5215000 What are your opinions on DX12/Vulkan/Mantle?

Posted by phantom on 06 March 2015 - 01:13 PM

Depending on how you have designed things the time to port should be pretty low and, importantly, the per-API level of code for the new Vulkan and DX12 paths will be very thin as they look very much the same in terms of API space and functionality.

Older APIs might be a problem, however again this depends on your abstraction levels; if you have coupled to D3D11 or OpenGL's style of doing things too closely at the front end then yes, it'll cause you pain - if your abstraction was light enough then you could possibly treat D3D11 and OpenGL as if they are D3D12 and Vulkan from the outside and do the fiddling internally.

At this point however it depends on where you are with things; if you want to release Soon then you'd be better off forgetting the new APIs and getting finished before going back, gutting your rendering backend and doing it again for another project/product.

In fact I'd probably argue 'releasing soon' is the only reason to stick with the current APIs; if you are just learning then by all means continue however I would advocating switching to the newer stuff as soon as you can. That might mean waiting for lib to abstract things a bit of you don't feel like fiddling but the new APIs look much cleaner and much simpler to learn - a few tricky concepts are wrapped in them but they aren't that hard to deal with and, with Vulkan at least, it looks like you'll have solid debugging tools and layers built in to help.

I guess if you are a hobbyist you could keep on with the old stuff; but I'd honestly say that if you are looking to be a gfx programmer in the industry switching sooner rather than later will help you out as you'll be useful in the future when you join up.


#5214313 Vulkan is Next-Gen OpenGL

Posted by phantom on 03 March 2015 - 04:06 PM

Asserting rights to IP is not sabotage; if it was then the same claim can be levelled at others in the group too over their various IP claims over the years. Hell, S3 caused issues with their texture compression IP claims.

Btw, MS left the ARB in March of the following year; it has taken 12 years for the rest of them to stop messing up with the following years being series of mistakes, missteps, bad choices and back tracking.
(Years, btw, that I lived as an OpenGL programmer, one time moderator of this sub-form, vocal GL advocate vs DX9, and GLSL chapter author for More OpenGL Game Programming... so, I know a thing or two about the history ;))

All of this is of course horribly off topic so should probably stop...


#5214295 Vulkan is Next-Gen OpenGL

Posted by phantom on 03 March 2015 - 02:47 PM

I was trying to bring up the fact that some people believe that Microsoft sabotaged the OpenGL implementation on Windows to increase DirectX adoption.


Yes, people do enjoy painting MS as the 'big bad' in all of this when, truth be told, 99% of OpenGL's problems were caused by ARB infighting and incompetence (see GL2.0 and Longs Peak/GL3.0) - the worst MS ever did was fix their software version back on GL1.1 and not ship GL drivers/dlls via Windows update for updated graphics drivers (which is a pain, but given they don't test that component I can see why), but they never actively sabotaged things.
(btw, if your source for this was the Wolfire blog from some time back then... well, forget you read it, it was trash frankly.)

The biggest tell in all of this is the utter amazement which has been expressed by many long time graphics programmers that Valkan seems, well, sane and well thought out.. I think many of us are still waiting for the other shoe to drop and won't be 100% convinced until we have working drivers in our hands to play with/test.


#5214170 Vulkan is Next-Gen OpenGL

Posted by phantom on 03 March 2015 - 05:07 AM

Yeah, as I said in the other thread, it seems sane... a Khronos take on the Mantle API.

Interested to see the complete model; do we get separate command queues for graphics and compute? (based on the ImgTec blog this looks to be the case!) how does it deal with multiple gpu machine? what about upload/download control?

But on the face of it things look sane... which I still find confusing... biggrin.png


#5213913 Next-Gen OpenGL To Be Shown Off Next Month

Posted by phantom on 02 March 2015 - 08:30 AM

Meh.. names... they could call the thing Wigglebum Fart Goblin for all I care; It could have the coolest name in the world but it's the API that matters.


#5212733 Is it time to upgrade to Dx11?

Posted by phantom on 24 February 2015 - 11:21 AM

Whatever the case, I apologize to the original poster because of my 'raving paranoia'. (thank you for the smart words phantom)


If you are going to make up bullshit then I'm going to call you on the aforementioned bullshit, simple as.
If in response to this you wish to resort to childish down voting of reasonable posts then carry on, your ire at being called out amuses me and underscores the kind of person you apparently are. smile.png


#5212482 Is it time to upgrade to Dx11?

Posted by phantom on 23 February 2015 - 11:20 AM

hmmm...I don't know. Seems like a real nice dangling carrot that precursors an OS subscription based pay system. Not the cool Epic deal you all know and love but more of a 'able to pull the plug' when you don't pay relationship. Personally, I think it's a trap and your OS will actually cost more in the long run.


Wait... wut?
How can a free OS cost you more in the long run?
You are going to have to explain this because right now it looks like raving paranoia...
 

I'd hold off as well but for different reasons. What I'm waiting for is glNext because I feel the giant is about to pull another fast one.


Your paranoia aside if anyone is going to drop the ball this time it'll be the ARB as they have a history of ball dropping which is frankly excellent.


#5212420 Is it time to upgrade to Dx11?

Posted by phantom on 23 February 2015 - 04:14 AM

Might want to hold off a bit if it isn't a major issue yet; DX12 will bring another major API shift and with Win10 going 'free' for anyone with Win7 or Win8 it could well get a lot of traction.




PARTNERS