Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2001
Online Last Active Today, 07:47 PM

#5161403 What are the process to become Indie Dev?

Posted by Promit on 18 June 2014 - 08:54 PM

You've got it backwards and upside down. Make your game first, then deal with these things at the end of the process. You don't need a name, company, copyright, trademark, fees, domain -- none of it. Your planned name is not special, and besides you're not allowed to arbitrarily reserve a name forever. Doesn't even help you without a lawyer. It would be equally as effective to go to Kinkos and print off a gigantic sign with your imagined company name on it.


Make your damn game first.

#5161386 Too large shaders - micro specializations.

Posted by Promit on 18 June 2014 - 05:56 PM

Have you profiled your application to see if the CPU is the bottleneck?  If it isn't the bottleneck, then reducing draw calls probably won't help much - so you should start there. 
That depends on his batch sizes, doesn't it? If he's submitting large blocks of polygons then sure, but if we're talking about small batches and frequent effect changes, then he's going to see GPU side inefficiency stemming from that too.

#5160711 OpenGL and SVG rendering in C++

Posted by Promit on 15 June 2014 - 04:05 PM

Last time I had to port something from ES to desktop OpenGL, I think it took half an hour. Maybe less. I don't think you should consider that a deal breaker. But if you just need something to offline render it, I think Cairo might be able to do it?

#5160653 Build a render farm using DirectX and radiosity?

Posted by Promit on 15 June 2014 - 10:51 AM

Direct3D always runs in the context of a particular window. However, you don't need a monitor in order to create a window, and the window doesn't need to be visible anywhere.

#5159540 Contacting press

Posted by Promit on 10 June 2014 - 10:53 AM

Personally I also appreciate the talk by Ben Kuchera (formerly of Ars Technica, now of Polygon) about how things look, from the journalist side of things.

#5158833 CG or GLSL ?

Posted by Promit on 06 June 2014 - 08:02 PM

Cg has been discontinued, so I wouldn't go with that one.

#5158779 Metal API .... whait what

Posted by Promit on 06 June 2014 - 02:41 PM

Also the AZDO presentation has a problem which tends to show up in NVIDIA presentations, which is that it's only applicable to NVIDIA hardware and follows a lot of custom built fast paths. Nevermind that the features are unavailable, inconsistent, or just plain implode on competing vendors' drivers. (And sometimes this is explicitly stated IN the NV presentations O_O) And then they act like everyone is crazy to be building these other APIs because their custom fast path and extensions supposedly do the same thing.


None of which even begins to cover the total failure to support even basic advances in graphics on the ES side.

#5158569 Metal API .... whait what

Posted by Promit on 05 June 2014 - 05:24 PM

Very interesting comments, Hodgman. If only the mobile world were as simple as the desktop chips... dead serious. So much more variation in how the mobile platforms work, much more poorly documented, and the drivers... dear god the drivers.

#5158448 Why do large engines use their own string class

Posted by Promit on 05 June 2014 - 11:18 AM

It also uses a custom allocator (presumably without the psychosis of std allocator) and supports misc things like being constructed on top of an existing char*. When I see stuff like this, I'm reminded of a comment that appears in the Fluid Studios mmgr code: "Kids, please don't try this at home. We're trained professionals here." :)

#5158272 Metal API .... whait what

Posted by Promit on 04 June 2014 - 09:31 PM

I suspect the difference in performance between Metal and ES is going to be gigantic, considerably overshadowing PC API advances. Major engines gain the functionality, which means most of the devs get it, and pretty much the whole ecosystem wins. Plus we're talking about a serious competitive advantage against Android and Windows Phone.

#5158017 glGetUniformLocation Failing on uniform

Posted by Promit on 03 June 2014 - 11:32 PM

It's worth noting that you're allowed to pass a uniform location of -1 into the glUniform* functions, so in practice you don't really have to worry about whether the uniform exists or not. Just pass the location you got in and all will be well.

#5158015 Overhead of GL_DYNAMIC_STORAGE_BIT​ or GL_MAP_WRITE_BIT​ when there's no...

Posted by Promit on 03 June 2014 - 11:25 PM

Personally I think you're making things needlessly difficult. Vectors aren't supposed to support this usage. Just block out your own memory (array/vector/whatever) and give the meshes a pointer and an offset. As far as the interleaving thing, just keep in mind that on-chip GPU bandwidth is gigantic and vertices are few. Interleaving unused attributes just means a bit of extra copy bandwidth. On the other hand, some hardware (all NV chips circa 2008, not sure what the situation is these days) can't use separated streams, so the driver has to go in and interleave the streams into spare memory before the draw is executed. I also suspect that using mismatched vertex formats between the vertex buffer and the shader will cause a few internal recompiles, though that's relatively minor.

#5157974 Metal API .... whait what

Posted by Promit on 03 June 2014 - 06:37 PM

Given the course this conversation has taken, I'm booting it out of Horrors and into Graphics.


As far as the Metal API design, there's no real surprises (apart from the C++ shading language thing). I'm a little dismayed that command buffers are transient-only objects, as I'd much prefer to build them once and just reissue. Anything to fix the moronic way GL handles pipeline state is good. Anything to get away from the moronic way GLSL handles everything is good. Everything to [...] threading is good. The list just goes on.


In the meantime we're seeing multiple vendors clearly draw out battle lines on APIs, to the point that being dependent on GL may well become a significant competitive disadvantage. Most people aren't drinking the MultiDrawIndirect kool-aid (and it wasn't even in the cards for ES). The interesting questions are, just how much fragmentation are we going to see before things pull back together? Does GL have legs? Or will we get some new standard that is reliable across platforms and vendors?

#5157971 Overhead of GL_DYNAMIC_STORAGE_BIT​ or GL_MAP_WRITE_BIT​ when there's no...

Posted by Promit on 03 June 2014 - 06:28 PM

As with anything in OpenGL, maybe. If the driver decides to take your flag at face value, then yes, there are implications for internal memory allocation that will create overhead. This may or may not have actual consequences in practice, especially depending on the driver involved. Keep in mind that until recently, pretty much everything had WRITE set anyway because that was the only way to get data into buffers in the first place.


That said, i don't understand what the problem is which is leading you to this question in the first place. But it sounds like you're abusing std::vector in a way you shouldn't be. It's also worth noting that drivers and hardware HATE when you keep separate vertex streams like that. Interleaved = good. Separate = bad. I'd deal with that mistake first.

#5157547 Is working in terminal/console really a waste of time?

Posted by Promit on 02 June 2014 - 10:06 AM

I love when the "UNIX" (because let's face it, you are all using Linux anyway and Linux isn't a UNIX) guys pop up to explain that all they need is a text editor and not a fancy IDE. As if emacs or vi are simple text editors -- for most practical purposes, they are IDEs in their own right.