Jump to content

  • Log In with Google      Sign In   
  • Create Account


Krohm

Member Since 27 Aug 2002
Offline Last Active Sep 15 2014 11:35 AM

#5180386 BSP portal visibility

Posted by Krohm on 15 September 2014 - 12:11 AM


How does a BSP compiler decide which leafs make up a cluster or 'room' and which windings make a portal?
Nontrivial question.

ID software took three product iterations to get this right and that was still not enough.

 

I'd link to a message I wrote years ago but it seems I'm getting a virus positive (???).

 

I honestly don't know why you guys keep pulling this BSP thing. The simple fact we need to do splits was enough for me to look elsewhere and it's not like there are no alternatives. It's a boatload of work simply put. If you want to just have a lot of work, write your own Z-only rasterizer, it looks quite more promising!




#5178884 how to design a virtual world

Posted by Krohm on 08 September 2014 - 10:53 AM

Let's see if I got all the questions.

  1. How to load 3d world from file?
  2. How does that relate to underling containers of entities?
  3. What are standard map file formats ...
  4. ... what info do they include?
  5. Do i split the world in x,y,z cell grid, maybe use some other approach?
  6. How are the containers important in relation to client side/render engine?
  7. is it possible to export (lets say from some terrain generator program) a heighmap, textures and navigation meshes, collision detection rules, etc?
  8. How do I manage {a terrain scene}? As in, how do I get the size of the landscape (bounds of those 3 lists), so I can later place objects (trees, etc) to specific locations.
  9. Can I use any existing solution for this?

 

 

  1. First you figure out at high level what your game/app needs to do. Then you figure out what information you need to make that happen. Then you take this abstract information and sketch out a document specification where you describe how info x gets mapped to a certain set of bits and you get a file format out there. At that point you probably know already how to load it. I suggest writing your own format for engine use and go with standard formats for DCC tools.
  2. In general, there will be a special structure being "the world". The world might be solid or not or include "solidity" info. If the world is nonsolid then it's likely there will be another special entity being "the physical world". The rest of the structures might be for example put a light here, there and there. They usually have a very bland correlation with the world, both graphical and physical, at this stage of your app. I strongly suggest using a physics library.
  3. No standard.
  4. ID based engines basically include (3). Unreal based engines are fairly more advanced but if you cut a lot of corners they're basically the same thing and you can bet at this 10,000ft of abstraction everything looks pretty much the same.
  5. Splitting in fixed sized cells is relatively inflexible but some games go with it and they work fine. For a first iteration, I suggest to just reduce the batch count as much as you can and optimize your life by minimizing your efforts first. Then you figure out what you need with the experience you got from rigging up the prototype.
  6. What are you asking here?
  7. Yes... for some program... for some import filter... for some data. 
  8. Size of terrain is a 3D vector. Terrain has an origin which is a 3D vector. It might also have a orientation which is either a quaternion or a 3x3 matrix. Placing terrains is often not very different from placing entities, and entities are usually (but not always!) very loose on definition.
  9. Yes, a pre-made engine. You will also get a ready to go toolchain. Have a look at Unity or UDK.



#5170827 Collision Detection Issue

Posted by Krohm on 01 August 2014 - 02:46 AM

Since I have to explain it to you, I'll explain a more complex (but more powerful) way.

We want to see if the ball hits the odd shaped poly.

test.png

 

Then what we want is to take those two sprites and run a threshold of some kind.

Example: if alpha is >= 25 consider solid.

We mark "solid" pixels "white" to obtain two 1-bit per pixel masks.

ball.png poly.png

 

Now, we count the amount of stuff that could be colliding (this might be not trivial) and decide

- black pixels are "empty" and do not collide

- white pixels do.

But all masks are "white" so we decide to assign a bit of color to each sprite. So 32 bit color --> 32 collidable sprites.

Say we decide the ball gets red=128 while the poly gets blue=128.

 

Now the tricky stuff. You need to figure out where the ball sprite is located relatively to the poly sprite.

Then you "draw" them on top of each other by adding the values of the "colored masks" pixel-by-pixel.

What you get is (of course I moved the ball here, otherwise it would be very uninteresting):

hitting.png

 

So this tells you "sprite red hits sprite blue".

 

My previous approach with XOR is simplier as you don't need to choose colors (you can just XOR the original masks) but it doesn't tell you what collides with what. It's not even so reliable. You decide what's going to cut it for you.




#5170515 Profiling results, GPU or CPU bound?

Posted by Krohm on 30 July 2014 - 11:36 PM


This is because D3D drivers are generally lazy and only fully initialize things on first use.

As a side note: other drivers do this as well. Current AMD OpenCL sure does.




#5168095 In need of some architecture help

Posted by Krohm on 21 July 2014 - 02:28 AM


I might have missed something in there, but it seems to only really be useful on window creation, but doesn't really provide anything useful if I want to resize or move the window mid-session does it?
What it gives you is the ability to pass there a pointer to an object you can use to interface with your "real" object so even though the WndProc is static, it can forward calls to non-static functions through a object pointer.


#5168075 C++ avoiding pointers

Posted by Krohm on 20 July 2014 - 11:30 PM


The real proper use of these are all based on _lifetimes_. Who is responsible for creating the object? Who is responsible for destroying? Are users of the object just borrowing it for a while or do they need to take over responsibility of the lifetime? If they're just borrowing the object, how long do they need to borrow it for?
Quoted for emphasis.

I honestly find given proper design thinking about ownerships and lifetimes beats smart pointers at large.




#5168073 In need of some architecture help

Posted by Krohm on 20 July 2014 - 11:21 PM

On creation, the window gets its messages in a well defined order. In particular, CreateWindowExallows you to fetch an LPARAM to the WM_CREATE message. Pack there a pointer to your struct. You can also do something similar on the window class but I'd consider it a bit ugly.




#5168072 The next step?

Posted by Krohm on 20 July 2014 - 11:16 PM

I'm afraid you have to begin considering engineering your code. You have probably just wrote your game code so far. Now the next step is to make sure the code can scale. Engineering it to be "better fitting" your head is a thing. The other way is to reduce the code size.

It's not this XOR that. You have to acquire both tools. 

 

How are you with data-driven systems? Is that term new to you?

 

Writing your code to be data-driven means writing your code to be flexible, ultimately reducing the amount of code. It takes some more effort but scales up better. That's why you see so many people writing about "engines" in those forums. "Engines" are data-driven frameworks in the end.

 

Now, without going to that degree, what you need to find is a way so you code less and artwork more. Is that a verb? :P




#5168069 Funniest line of code ever ?

Posted by Krohm on 20 July 2014 - 11:05 PM


That seems desirable to me.
Not really. I have a scripting language where the only implicit casts allowed are: derived->base or pointer-compare-to-null. Notably, integers don't auto convert to bools. It stings me regularly every time I compile something with an if(integer) inside. It's not just a matter of being used to C/C++ autocasting feature. It's just more compact notation.


#5165943 Scaling on available memory

Posted by Krohm on 09 July 2014 - 11:13 PM

It is my understanding they do. This is the case especially for terrain related things such as in Frostbite. Perhaps ID megatexturing, in the case somebody still cares about them. Even games which are not streaming can still be more conservative before trashing old data.

 

There's of course the option of higher res assets.

 

My suggestion is to not mind those issues. It's a boatload of work and in the end, not required for market.




#5161467 Too large shaders - micro specializations.

Posted by Krohm on 19 June 2014 - 06:48 AM


- I am drawing about 58 type of different materials each frame!
It is a very affordable amount. What's about the '!' ?

Personally if I would still have to be stuck in D3D9 I'd drop all optimizations. It's not going anywhere.




#5160786 Build a render farm using DirectX and radiosity?

Posted by Krohm on 16 June 2014 - 02:05 AM

D3D11.1 can be used in session-0 processes in Win8 but googling I've read someone seemed to have issues with it.

OpenCL can definitely run without a monitor but I'm fairly sure it needs the drivers installed for AMD since it uses the internal AMD IL compiler.

 

Nonetheless, I wouldn't use D3D for long-running tasks. You need to set a flag to allow it to not timeout. The performance seemed to be considerably worse for large datasets in my case. I cannot tell if this is a driver problem by my side but it seems likely D3D11 Compute might have been optimized to work in a latency-sensitive context of small datasets used for realtime manipulation. 

 

OP:

never think about using FFP again. Not only you'll be shooting yourself in (at least) one foot, but you'll also have to go through ROPs instead of just streaming to memory and this can be a problem in modern architectures.




#5159191 Metal API .... whait what

Posted by Krohm on 08 June 2014 - 11:24 PM

Honestly I don't get the OpenGL is smart vibe in this thread at all.

To map a buffer you still have to bind it (p. 65 core spec 4.4). You bind it to target and then you map the target. You must be joking.

The best thing that could happen to OpenGL is to die instantly and be replaced by a set of built-in kernels in OpenCL. That's terrible.




#5159185 Bribes

Posted by Krohm on 08 June 2014 - 11:11 PM


The question is what is the purpose of these bribes.
For those who accept a bribe, the gain is always personal. Be it direct ("black" funds) or indirect (helping a friend of a friend I often go sailing with).

There's no other purpose than this.




#5157487 Memory allocator. Maintaining free list.

Posted by Krohm on 02 June 2014 - 12:31 AM

Now, to "free" a ByteBuffer slice, I'd need to find roughly its position inside the free block list.

You mean in the used block list. How do you plan to make things work roughly? I suspect I'm not getting the picture. I use a dual-list for my allocator.

 

 

The problem is that if the block I'm trying to free is between two free blocks, I'd need to merge all 3 (left free block, the block I'm freeing, and the right free block). That would mean, removing one of the adjacent free blocks, and expanding the remaining one to cover the block I removed and the block I'm freeing.

In my experience, found "forward merging" appeared to be sufficient. Keep in mind free memory is unreferenced, "useless" memory, so you can really do this every say 1024 free or every time an alloc fails. Making alloc performance nondeterministic doesn't sound like much of a big problem to me.






PARTNERS