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, 04:04 PM

#5222992 Alternatives to global variables / passing down references through deep "...

Posted by phantom on 13 April 2015 - 01:15 PM

One thing that I think it is worth pointing out is that, in practice, with a well designed system I've never once encountered the 'deep call tree' problem with regards to passing things around. That's not to say I haven't seen people get 'bothered' by having to pass things down two levels, instead butchering designs to add a g_Renderer because they didn't want to do it.. but frankly I put that down to lazy thinking.

I would argue that Cozzie has hit the nail on the head with the mentioning of the SRP with regards to what the classes are doing.

Take the 'player' example given. It is controlling the thing it renders, when it renders, the sound it makes and even has some idea about 'shooting' - maybe fine for a simple application but very quickly things like this become and interconnected nightmare.

Many things can be solved by decoupling and abstraction.
Take rendering, for example, instead of the 'player' telling the renderer 'draw this', as things are created a 'renderable' is created and handed off to the renderer. The higher logic never talks to the renderer again but might touch the handle to the renderable to flip internal state which the render can act upon.

Sound it a similar thing; you might have a handle to a sound but instead of instructing the sound system directly to 'play a sound' instead a message might be broadcast to say 'play this handle' via the message system. This decouples you from knowing if the sound system even exists AND allows other things to 'hook in' to listen for events.

Shooting is another decoupled area; instead of the player 'shooting' the player might well have a weapon to which the 'shoot' logic is handed off to. That in turn could have some effect handles which is sends a message out to say 'hey, do this'.

At best the 'player' in these situations acts as a container and coordinator, it might not even have the logic internally to do things like listen to input; instead an 'input controller' might be assigned which could be a local input, an AI input or even a remote player driving the same logic and actions.

The point I'm trying to drive at is that, in many cases, when people think they 'need everything everywhere' or 'have to pass it down loads of layers' the truth of the matter is the design is often at fault. Be that down to a lack of experience or not is another matter, but across a number of (AAA) games now and a few engines which have avoided globals in favour of locally passed in parameters I've never experienced either of those situations play out with a good design. (And in one case the removal of a 'global' system for one locally passed down even simplified the codebase and made life easier for all concerned. )


#5221583 Looking for step my step guide for visual studio

Posted by phantom on 06 April 2015 - 03:31 AM

I think you need to look at existing engines again; UE4 doesn't mandate that (heck, if it did how do you think you'd have AI opponents in games?) and I dare say Unity and CryEngine don't either - all of the major engines would let you assign an AI component to things you've spawned and let them control the movement, you just have to hook it up.

Just because a bunch of games have taken the select-unit-and-click method doesn't mean engines don't have the ability to do what you want; hell, I dare say if you had access to the source for SC2 or Grey Goo you could modify them to do just what you want.


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

Posted by phantom on 04 April 2015 - 02:38 AM

But then I don't have a 1:1 mapping with old and new API.


And this is a good thing; you can't take a system you designed to get around the problems of an old API and map it to a new API where the problems no longer exist and expect it to be optimal.

Sure, you can make Vulkan/DX12 work like DX11/GL3/4 era APIs but you'll start reproducing driver work and generally make things less than optimal. (Ran into this problem a while back; designing new renderer layer, based too closely on DX11 so the PS4 version was a nightmare. If we had waited a bit to see the new hardware then chances are it would have been more towards the PS4 way of doing things and DX11 made to emulate that in some way.)

Right now it is like you've worked out a great way to cook burgers, and you can cook burgers really well, but now people want beer and you are trying to work out how to apply your grill to serve them beer without doing any extra work.

This is also a great argument against close API abstraction layers as they don't react well to massive API changes.

Honestly, if you can, I'd take some time to strip your abstraction layers and rebuild so that the Vulkan/DX12 way of doing things is your primary abstraction and make OpenGL work with that instead. If nothing else the old way of doing things IS going away, even if it takes a little while, so getting on top of it sooner rather than later is probably a good move.

If you can't do that, because you have a game to ship or something, then I'd forget DX12 support for now, finish what you need to finish and then go back and rebuild.

End of the day an abstraction which is based around the current DX11/OpenGL limitations and functionality will be broken and slow going forward, you are probably better off redesigning with the new method in mind.


#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


#5219138 Google Play Alpha Testing

Posted by phantom on 25 March 2015 - 01:46 PM

Yeah, it looks like having some kind of group is the only way; I'd rant about how dumb it is but frankly I'm tired of moaning about how bad Android is...


#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




PARTNERS