I have been going over a number of books and examples that deal with GLSL. It's common after viewing the source code to have something like this...
Is this how a shader program should be used in real time applications? For example, if I have a particle class, for every particle that's created, do I want to compiling and linking a vertex, frag shader? It seems to a noob such as myself this might not be the best approach to real time applications.
If I am correct, what is the best work around?
Thanks so much for all the help,
I’m now working with Zugalu -- developer of an upcoming SHMUP named Technolites – as Community Manager.
In Technolites, you’ll take command of a fully customizable ship and dash across the universe to defeat an ancient alien threat. Deploy more than 500 weapons and utility upgrades – fighting by yourself or with a friend. The fate of humanity rests in your hands. We’re currently live on Kickstarter, and we’d love it if you could check out our page! Any feedback is greatly appreciated
Looking forward to seeing all of the great game projects being developed and launching this year!
I'm having some difficulty understanding how data would flow or get inserted into a multi-threaded opengl renderer where there is a thread pool and a render thread and an update thread (possibly main). My understanding is that the threadpool will continually execute jobs, assemble these and when done send them off to be rendered where I can further sort these and achieve some cheap form of statelessness. I don't want anything overly complicated or too fine grained, fibers, job stealing etc. My end goal is to simply have my renderer isolated in its own thread and only concerned with drawing and swapping buffers.
My questions are:
1. At what point in this pipeline are resources created?
Say I have a
borrowed from an existing post here. I would need to generate a VAO at some point and call glGenBuffers etc especially if I start with an empty scene. If my context lives on another thread, how do I call these commands if the command list is only supposed to be a collection of state and what command to use. I don't think that the render thread should do this and somehow add a task to the queue or am I wrong?
Or could I do some variation where I do the loading in a thread with shared context and from there generate a command that has the handle to the resources needed.
2. How do I know all my jobs are done.
I'm working with C++, is this as simple as knowing how many objects there are in the scene, for every task that gets added increment a counter and when it matches aforementioned count I signal the renderer that the command list is ready? I was thinking a condition_variable or something would suffice to alert the renderthread that work is ready.
3. Does all work come from a singular queue that the thread pool constantly cycles over?
With the notion of jobs, we are basically sending the same work repeatedly right? Do all jobs need to be added to a single persistent queue to be submitted over and over again?
4. Are resources destroyed with commands?
Likewise with initializing and assuming #3 is correct, removing an item from the scene would mean removing it from the job queue, no? Would I need to send a onetime command to the renderer to cleanup?
I am a CAM developer working with C++ and C# for the past 5 years. I started working on DirectX from past 6 months. I developed a touch screen control viewer using Direct2D. I am working on 3D viewer currently. I am very slow with working on Direct3D. I want to be a gaming developer. As i am new to this i want to know what are the possibilities to explore in this area. How to start developing gaming engines? Is it through tutorials? I heard suggestions from my friends that going for an MS helps. I am not sure on which path to choose. Is it better to go for higher studies and start exploring? I am currently working in India. I want to go to Canada and settle there. Are there any good universities there to learn about graphics programming? Sorry if I am asking too many questions but i want to know the options to choose to get ahead.