Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Aug 2002
Offline Last Active Yesterday, 04:10 AM

Posts I've Made

In Topic: DirectX 12 Effect on the Game Development Industry

17 April 2014 - 12:25 AM

Based on my preliminary, incomplete understanding of D3D12.

I think there's chance the market will have to split, with non-performance critical apps staying D3D11 and therefore being not "up to snuff". Fortunately this isn't likely a problem for them.


I have personally been in love with display command lists since they were released on OpenGL 1.0 Direct3D 10 so I see some not-yet-quantifiable benefit in moving however with performance being not an issue for me this benefit is purely architectural. I'll need to see it released to understand if it's worth biting the bullet. I also build objects similar to Pipeline State Objects, as well as the saved bindings so there's some chance going D3D12 might result in smaller code for me or at least in moving it to more controllable sections.


I am wondering however how those "awesome" companies not understanding their trade will fare. You know, those who want the newest stickers (usually big proponents of GL since the API never changes). Those are going to have a nasty surprise! smile.png

In Topic: So this is how APIs get so messy?

17 April 2014 - 12:11 AM

Starting to understand why APIs get so messy.
Which API? Personally I found most APIs I worked relatively well designed, of course you have to consider the historical constraints but in general, I'm fine with them.

In Topic: My sockets are as fast as pipes..

17 April 2014 - 12:08 AM

When I have needed ultra-high bandwidth or ultra-low latency on Windows, I use shared memory, knowing the solution is not portable. In all other cases I use sockets because they are:
* Usually plenty fast
* Completely portable
I'd also add 

* can be put in select(), thus allowing to wake a IO thread. Windows can do that anyway using WaitForMultipleObjects() but I'm not aware of a *nix equivalent. Suggestions welcome!

In Topic: Fast GUID generator

17 April 2014 - 12:01 AM

I always considered GUIDs to be pretty overkill for runtime purposes in a gaming environments.

I find myself much more comfortable with [pool, slot] pairs which give up some control and require some more attention but are much, much easier to debug in my opinion, as well as intrinsically better defined.

In particular, generating GUIDs for objects in a hierarchy as OP wants to do is overkill by several orders of magnitude. I have a similar need and I just identify objects by their sequential creation index. I cannot see any problem in the foreseeable future so I would encourage in elaborating the specific needs.

In Topic: running flat, feeling burnt out...

14 April 2014 - 01:24 AM

To be honest BGB, since I noticed your posts, I have had many doubts about your ability to focus and I'm somewhat disappointed to have been proven right.

Your motivation didn't go away. You dissipated it. And you're still totally into the correct mindset to to this over and over. Just look at the nonsensical amount of irrelevant low-level detail you post even in this thread. I mean, just read this. Just read it.



like, while I could, for example, go and implement a newer scripting language and VM and maybe fix up some issues with my older one, this would be pretty solidly in "yeah, been there" territory, and the only real likely gain would be trying to make it more performance competitive with C, vs like 3x slower than C (in the JITted case), mostly because this slowdown largely keeps scripting code from being usable in performance-sensitive areas (such as in the renderer). (the planned scripting language would have been somewhat more C-like, vs my old one being at this point more of an AS3 clone).

Like anyone cares how fast/slow a game VM is. Epic had to go AAAAAA with their 3th engine iteration before seriously considering their internal VM slow. They are set up and sitting on hundreds of millions. Everyone using UnrealScript would tell you it was not suitable for performance, but it was suitable for its task.


My VM is not suitable for performance, but it is suitable for its task (1% frame time). It is orders of magnitude slower than C (like 1000x). Is it a problem? No. Will it be a problem in the future? Sure, if I end up having like 3/4 of worldwide engine licenses. I will be happy to scrap it.


rasterizer, basically written and tested, currently pulls 500-600 Mpix/sec for big/simple texture-mapped primitives, and around 800 for interpolated colors.
this was after fiddling with some of the arithmetic and similar.
but, it will require being fully implemented to see what the overall performance is like.

Here you go again.

I hope you realize the end users want you to speak their language, not yours.

If you wanted to do Quake+voxels, and your friends are on iOS games what did you expect they would tell you?


You need a higher level vision of what you need/want to do. Then you execute it. And never, ever assume your vision is going to be successful in the first place.

For the time being, just get off for a while and think at what you want to do to move forward. How can you transform what you have into value for your next step?