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!


TheChubu

Member Since 13 Sep 2012
Online Last Active Today, 05:33 PM

#5226708 How 3D engines manage so many textures without running out of VRAM?

Posted by TheChubu on 01 May 2015 - 08:35 AM


ooh wow. I haven't heard of texture streaming or DXT1/BC1 compression before. That's really interesting.
They're the tiny .dds files you see in desktop games (usually that is, DDS is a container, it could hold either DXT compressed data or raw data). Mobile devices have their own formats too (PVRTC, ETC2, etc). And there is ASTC although its starting to get support only recently AFAIK.

 

Its not often you send uncompressed data to the GPU since, as you mentioned, its simply too much data. Then again, in 2D games if you do some sort of pixel art kinda thing, DXT compression might screw up the look.




#5226613 Modern OpenGL Tutorials

Posted by TheChubu on 30 April 2015 - 06:57 PM

While the site arcsynthesis.org expired, the tutorial/online book is still up in the repository https://bitbucket.org/alfonse/gltut/downloads




#5226397 How to learn advanced CryEngine type graphics technologies

Posted by TheChubu on 29 April 2015 - 07:07 PM


Ambiguous slides are great because then you need to think about the problem a bit.

Eh, sometimes you can clearly see the author just doesn't wants to spill his precious beans. When I see that I don't see it like "Oooh, learning opportunity!" I see it more as "Oh, what an asshole!". If you do research and you publish it, you explain it properly, otherwise don't publish at all since it becomes just a matter of showing off at that point.

 

On the other hand, plenty of material is oriented for people "in the know" which is different from trying to obfuscate the content. Just don't expect introductory coursers from things that aren't introductory courses.




#5226027 Steam's compensated modding policy

Posted by TheChubu on 28 April 2015 - 03:00 AM


According to Bethesda, Valve is taking their 30% standard cut. After that, the publisher decides the split of the remaining 70% (in this case, Bethesda chose a 45/25 split).
Hm, I read the other figures from Robin aka Dark0ne aka NexusMods owner IIRC. "Standard" 30% cut for Valve makes more sense too, and 45/25 does sounds kinda crappy.

 

In any case its done. Didn't lasted long though. They'll probably reintroduce the scheme when FO4/TES6/something comes out methinks...




#5226022 So, what happened to god games ?

Posted by TheChubu on 28 April 2015 - 02:49 AM

I'd say Molyneux ran them to the ground by "overpromising" (aka, lying) for two decades.

 

 Black and White in particular had the odd situation where I was playing as a super powerful god, but I seemed to spend all my time being a child minder to stupid minions

 

And I loved it that way :3 Specially when your creature went and randomly took a poop on top of the villagers because I WORK IN MYSTERIOUS WAYS.




#5225966 Periodic Perlin Noise GLSL Shader

Posted by TheChubu on 27 April 2015 - 06:11 PM

Hausziege_04.jpg




#5225945 Steam's compensated modding policy

Posted by TheChubu on 27 April 2015 - 04:09 PM

I think that 25% is fair,
Its 25% for the mod's author, 40% for Bethesda and 35% for Valve. From that 35% Valve gets, 5% can be distributed to "service providers" the mod's author think they helped to create the mod (think NifScope for models, SKSE for scripts, NexusMods for the community, etc).

 

The mod's author can select from a list which "service providers" they think helped to create the mod in any way and they get a cut of the sales, "service providers" don't need to do anything else.

 

It seems like a fair deal. And that 5% Valve gives out from their cut is a very friendly gesture.




#5224281 Vulkan is Next-Gen OpenGL

Posted by TheChubu on 19 April 2015 - 04:22 AM

I'm starting to get annoyed by people commenting "Oh now graphics programming will be exclusive to the elite programmers who can understand the API!". Seen comments like that in a few places.

 

Bitch, useless abstractions add to complexity, they don't reduce it, OpenGL is already fucking annoyingly complexUnless you're doing very shitty fixed function OpenGL, in which case you might as well just use an engine and stop coding with a 20 year old API.

 

Moreover while doing graphics programming you inevitably end up with constructions that, oh big surprise, look much like how Vulkan/Mantle/D3D12 handle things! I expected people complaining "Khronos can't be trusted with this! It will fail!" but I never thought I'd hear someone imply coding with OpenGL is "simpler" of all things, ugh...

 

I'm afraid Promit post didn't helped though, as it was written it sort of implied that only professional engineers working on big name engines will be able to use the API, when it actually was just a side point on why Khronos would be keen to rebooting the API right now.  It wouldn't be surprising if people just took that statement at face value and are just rolling with it.




#5222471 Can Python be used for 3D programming?

Posted by TheChubu on 10 April 2015 - 12:25 PM

Blender is written in Python, it's as 3D as you can get.
http://www.blender.org/

Actually no, it exposes Python as scripting language but the core isn't written in Python: https://github.com/dfelinto/blender-git/ Hell, there it seems to be quite the amount of plain C there.

 

In any case, that Blender isn't written in Python has nothing to do with this, all you need is a GPU API binding (like PyOpenGL) and you're good to go. PyOpenGL is a binding for raw OpenGL, PyOgre seems to be a binding for Ogre rendering engine, which is a completely different thing.




#5222169 Multithreaded mesh loading and 0xcc returned from glGenVertexArrays

Posted by TheChubu on 08 April 2015 - 10:40 PM

You could always load the mesh data into main memory from different threads, then hand the pointers to the OpenGL context owner thread and let that one do the GPU uploading.




#5222115 curious case of integer overflow?

Posted by TheChubu on 08 April 2015 - 01:54 PM


If it makes any difference, the code is in Java not c++ 
Yes, it does. In Java all of this is defined, overflow will wrap around, integer variables get auto initialized to 0, you don't have unsinged types (except for 'char' technically, but whatever), and so on.


#5222106 Using named POSIX mutexes?

Posted by TheChubu on 08 April 2015 - 12:29 PM


sometimes when it takes a minute or two for your game to load/start, the user might get impatient and just start clicking away thinking "why won't you start?",
Show a splash screen first that says something along of "Loading the game, please wait.", then init the game.


#5221468 Is it realistic to expect to make money in Unity Asset Store/UE4 Marketplace?

Posted by TheChubu on 05 April 2015 - 07:54 AM


Okay, thank you again, frob. It seems that as a beginner, I have months, or even years of work ahead of me, before I even get the chance to earn some small amounts of money. Not very encouraging
Such is life when you expect to make money in very specialized areas.


#5220872 Trouble with uniform matrices

Posted by TheChubu on 02 April 2015 - 02:34 AM


ByteBuffer matrix_buffer = ByteBuffer.allocateDirect(64).order(ByteOrder.nativeOrder()); //JAVA DIRECT NIO BUFFER, for use with LWJGL

 

and

 

matrix_buffer.asFloatBuffer().put(m).flip(); //Write to buffer and set its capacity

 

Be careful with what you're doing there. You'll be uploading data to the GPU all the time, you should strive for it to be a garbageless process. There you're creating two new objects each call is made. Moreover, timely deallocation of direct buffers isnt guaranteed, and you're doing a new direct buffer alloc each time.

 

You can very easily just create one instance of a big enough buffer and pass that all around the renderer, with LWJGL 3 you dont even have to create FloatBuffer view objects since most calls have a version that receives pure ByteBuffers.

 

EDIT: I misread, you might not be creating a new direct buffer each call. You're still creating a new view each call though, you can (and should) hold onto that reference too instead of re creating it all the time.

 

Also this line here:

 

matrix_buffer.asFloatBuffer().put(m).flip(); //Write to buffer and set its capacity

 

It might not be doing what you think its doing. asFloatBuffer returns a new FloatBuffer object that basically points to the same region of memory as the ByteBuffer (well, address + current position exactly). Thing is, its a whole different object, if you call 'flip' on that view, it wont do anything to the position/limit/etc of the original ByteBuffer. 'ByteBuffer#asFloatBuffer' javadoc explains it in detail.




#5220464 GDC videos?

Posted by TheChubu on 31 March 2015 - 06:21 AM

Actually, all the GDC 2015 free talks are online right now: http://gdcvault.com/free/gdc-15

 

Too bad Vulkan's has very, very low volume.






PARTNERS