Jump to content

  • Log In with Google      Sign In   
  • Create Account

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Jan 23 2015 10:04 PM

#5206290 Question about local axes conventions

Posted by Norman Barrows on 23 January 2015 - 06:05 PM


I am living in a right-handed world, if that makes a difference.

 

very much so! <g>

 

i live in a left handed world (so to speak), and there, positive Z (your negative Z) is the desired direction for "forward" for the static pose of an object model in object space. its desirable for just the reasons you intuitively suspect. IE it makes life a bit easier. So in your case, a right hand world, facing in the negative Z direction is probably the best option. I can't think of any reason why it wouldn't be. i've been doing it that way (the left hand version thereof ) since i started 3d coding, which would have been when microsoft bought rendermophics (1995) and turned reality lab into directx 1.0, which was released in 1996. i was about to license reality lab for SIMSapce when MS pulled it off the market. I was forced to write my own 3D perspective correct texture mapped poly engine from scratch, since directx 1.0 was yet to be released.




#5206083 a better fix your timestep?

Posted by Norman Barrows on 22 January 2015 - 06:06 PM


I can only assume you completely misunderstand the [Gaffer] article.

 

perhaps i don' t understand - or more accurately - can't relate to it.

 

PLAYBACK:

unlike many folks, i specifically design my games to be as non-deterministic as possible. The whole idea is that even i as developer shouldn't know what will happen next (so i can play it! <g>).

 

PHYSICS:

i've always used a frame rate limiter to guarantee a constant physics update speed. since the update speed is known in advance, i don't pass in an ET to update, so wacky ET values can't blow up the physics. in fact, physics that blow up strikes me as bad engineering. i hand code all my own physics, so i don't know what kind of BS you all have to deal with out there in the real world. <g>. but physics that blows up is something i've never heard of (or had to deal with to be more precise) and therefore simply cannot relate to.

 

NETWORK:

I like to build hard core simulations. the type of thing where the delays of network lag are unacceptable, and "prediction" is the most evil thing in the world ever. So on the rare occasions when i do networked games, they're lock stepped to maintain perfect sync. I've gone so far as to write my own protocalls so robust you could unplug the phone line, plug it back in, and not lose sync. but in the end, you can only "ACK" so may "ACKs", and then you have to take it on faith the last one got through.

 

so the idea is you decouple render so it doesn't interfere with the speed update runs at?   but in a framerate limited basic loop it only interferes when render times go long. and the f-y-t approach deals with this by dropping frames - a potentially bad thing.

 

also note that i haven't been considering the impact of multi-player on all this. i've only been thinking in terms of single player games. i can see how in multiplayer you'd need to maintain some consistent communications rate in order to have any hope of maintaining sync if you were not running lockstep (IE like most games do).

 

perhaps some of my reservations stem from the fact that as a player i've fallen victim to f-y-t's frame dropping, and its ruined more than one evening's worth of gaming over the years.

 

i guess as long as i don't need deterministic playback, don't use physics that can blow up, and stick with single player, f-y-t is just overkill for me.




#5206068 Open world RPG - how to efficiently simulate the whole world?

Posted by Norman Barrows on 22 January 2015 - 04:58 PM


the events need to be happening even when the player isn't around, like in Skyrim.

 

i don't think skyrim does this.

 

can you give an example of what you mean? I'm pretty familiar with skyrim - odds are its faking what you think its doing. give me an example, and i might be able to tell you how they do it (or fake it).




#5205995 Getting World Matrix (Mesh Space)

Posted by Norman Barrows on 22 January 2015 - 09:23 AM


loaded .obj file model for rendering in DX11, then I read vertices, UV, normal, etc.. from the file.
 
Sometimes, the mesh position in the 3D modeling software is not 0.0f, 0.0f, 0.0f

 

load it into the modeler, center it, save it. job done. get a beer! <g>.




#5205066 AI Interface

Posted by Norman Barrows on 18 January 2015 - 08:39 AM


I guess the first attempt using the UI would result in a lot of computations as I had to calculate first what to do and how I achieve it by using the player UI, however I would get an AI behavour like an actual player. For example the UI limits the player not be able to shoot while running, the AI would be limited to the same.

On the other hand just calculating directly what to do and simulating then the limits by the player ui might be way more straight forward but maybe result in errors as the player for example can't turn the hero in a certain situation while the ai behaviour was never adjusted to simulate the same behaviour which might led then to the ai cheating and frustration of the players.

 

things like:

"can't shoot while running" 

"can't turn under certain conditions"

 

are the RULES of the game.   folks often loose sight of the fact that we're making games - and games of all kinds: computer, tabletop, card, etc - have things like rules and objectives / goals / victory conditions.

 

right now, you enforce the rules in the UI. you'll need to do the same in the AI. and no, you don't want to send the AI input thru the UI interface.  the AI should decide what to do -WITHIN THE RULES OF THE GAME - then do it. UI is not used. its just another place you must enforce the rules of the game. this of course leads to the possible creation of some sort of generic move_is_legal() checker used by both input and AI - IE code sharing.




#5204716 Rendering .obj Model in DirectX 11

Posted by Norman Barrows on 16 January 2015 - 08:56 AM

indices are definitely wrong. from the image above, you can see that the triangle in the foreground is actually the lower left triangle of the front face of the cube, except that its bottom left vertex has been moved to the back corner of the cube. other tri's aren't showing due to back face culling - very common when indices are wrong. draw a 3d sketch of a cube on paper and number the corners (zero based). that will tell you what tri uses which indices.




#5201324 C graphics gaming program

Posted by Norman Barrows on 02 January 2015 - 10:11 AM

in games (or science , or engineering), when you want to model something (like the projectile hitting the ellipse), its usually best to start with the simplest model, and get fancier if needed.

 

in your case, the simplest model would probably be:

 

if the BBox distance from the projectile head to the center of the ellipse is "close enough", they hit the ellipse.

 

BBox distance is defined by:

 

given two points: x1,y1, and x2,y2

 

dx= abs(x2-x1)

dy=abs(y2-y1)

 

BBox distance = greater of dx or dy.

 

"close enough" might mean <=2, ,<=5, zero exactly, etc.




#5201286 do most games do a lot of dynamic memory allocation?

Posted by Norman Barrows on 02 January 2015 - 08:43 AM


Problem one: I now have to recompile my game to make any data changes. There goes my iteration time...

 

any data structure can be data driven. whether its stored on the heap or in the data segment is irrelevant. heap just adds the overhead of allocations and de-allocations, and a bit of extra de-referencing on access, and you trade heap type de-reference errors for static array type range errors. with static, you only recompile when you change the max capabilities of the engine, which is almost never. in fact you'd only have to do it twice. once at project start to set everything to more than enough (the american way - as they say), then once at program completion to right-size resize everything to "just big enough" for the game you finally ship.

 


Problem two: I can't make DLC, addons, or support user modding cause all my data is in my EXE.

 

in my case data is not stored in the exe.

 

meshes, textures, models, animations, and wavs are loaded from disk.

 

meshes, textures and wavs are stored in static arrays of structs, with struct members which are pointers to vb's, ib's, textures or wavs on the heap. vb, ib, textures and wavs are variable size data that's most easily dealt with using the heap. models and animations are of known constant size, and are stored in static arrays.

 


Problem three: You still have to allocate unless you're storing all your textures, models, audio, and other assets in your exe.

 

indeed. one alloc at asset load, and one dealloc at asset unload. neat, clean, and simple, one time per program execution only (no asset paging, everything is loaded all at once at program start)

 


Problem four: You've now made a bunch of global state which is generally bad architecturally.

 

unfortunately, it seems that games tend to have global states.

 

the problem isn't necessarily global states, its MISUSE of global access.   this is where things like coder discipline and coding convention can be used to make life easier.  or you can refactor stuff so nothing is global, and stupid programmers CAN'T shoot themselves (and the entire team) in the foot.

 

 


Problem five: You can't free up memory by unloading data that isn't needed at the current time

 

i load and unload textures a number of textures for opening animations and such before loading all game assets before the main title screen appears.

 

i'm only using maybe 700 meg on a PC with 3 gig. so freeing up memory is not required.

 


Problem six: You haven't actually fixed anything. You still need to point to the data somehow, so you have indirection costs, and you're even less protected against buffer overruns or other programmer mistakes then if you used something like std::vector which can perform runtime checks.

 

well, you only need to design the code so you don't get range errors (trivial), and you avoid the lack of re-alloc control of std:vector, and any additional unnecessary type checking it might do. i'm a performance nut, so i don't like unnecessary de-references, allocs, de-allocs, or runtime type checks. given the choice of fast syntax where i can shoot myself in the foot if i'm stupid, and slower syntax that i can't shoot myself in the foot with, i'll take the faster syntax every time. when i started coding games, "safe code" stuff didn't exist, so i "learned how to handle a gun properly without shooting myself in the foot" so to speak. so much of this later day kid glove safe code stuff just strikes me as hand holding for programmers who are careless with non-idiot proof code.

 


"Coder discipline" is fancy talk for those who refuse to use the right tool for the job because they like tracking down memory corruption bugs at 3am ;)

 

code discipline is fancy talk for understanding how things work and not doing stupid stuff in the first place that can cause things like tracking down memory corruption bugs at 3am. and if you don't do stupid stuff with the heap, you really can't  corrupt (heap) memory in the first place.




#5200804 Am I overengineering

Posted by Norman Barrows on 30 December 2014 - 08:47 AM


Here is one of the design mantras I always try to follow:  By only adding the code that you need right now, you make it easier to change direction later.  This is hard, only adding the code you need and keeping everything as simple as possible.  

 

THIS!

 

it becomes easier as you develop more coding discipline.

 

 

 

more sprigs of gamedev wisdom:

 

 

 


Time spent moving things around without any positive gains is also wasted time.

 

 

 


If you just add the dumbest code you can, eventually the design will appear.

 

 

 


Eventually you'll have your game, and it will look nothing like your designs from the beginning. 



#5200703 do most games do a lot of dynamic memory allocation?

Posted by Norman Barrows on 29 December 2014 - 07:33 PM


I spent most of the video wondering why he was considering extending a language to have native support for raw pointer based ownership in 2014. I just don't get where he is coming from.

 

...

I guess you also have a lot of global state lying around with no restrictions on where you can access it from. I wouldn't like that.

With custom allocators and modern approaches to management, I see solutions to problems that don't really exist around this whole topic. It was an interesting talk from Mr Blow, who I respect enormously, but I was left feeling like he wanted to add to a core language things that are already well solved by libraries.

 

i get the impression he is of the old school bare bones down to the metal kind of programmer.  take a look at the code he shows for invaders, and how the game is written, and you'll understand better why he wants what he wants in a game language. while its not what i'd want in a game language, my experience with the productivity increase from switching to Cscript makes me understand his enthusiasm.

 

its not so much the language he's making that impressed me so much as some of the observations, such as "the solution should define the program structure, the program structure should not be mandated a priori". also the fact that Carmack is in-lining a bunch of stuff. etc. but then again, those guys at ID never did give a hoot about all that "high falutin' architecture stuff", all they care about is "does it work? and is it fast?"     might be a lesson to be learned there.  ; )




#5200256 How to model and program in the correct scales?

Posted by Norman Barrows on 27 December 2014 - 09:14 AM


only for rigid body models. for skinned meshes, you typically just have one rigged mesh scaled correctly in max, then exported for loading into the game.

 

that is, unless you're doing multi-part skinned meshes, where for example the head is a separate skinned mesh from the body.




#5200255 How to model and program in the correct scales?

Posted by Norman Barrows on 27 December 2014 - 09:09 AM


Do I first merge the NPC models into the main scene, and export them as a whole to the game engine.

 

probably the hard way to do it.

 


And do we usually use a game editor so that we model each piece individually and put them together in the game editor
and export them to the game engine later?

 

only for rigid body models. for skinned meshes, you typically just have one rigged mesh scaled correctly in max, then exported for loading into the game.

 


Do we first merge the NPC models into the scene, then make the correct scales and delete them in turn

 

by "scene" i assume you mean the static world geometry (ground mesh, buildings, etc).  the method you describe is one way to make sure you get the models scaled correctly.

 

another is to define a scale, such as 1 unit in max = 1 d3d unit in the game = 1 meter.   you know the size of the desired vehicle: 2.5m wide, 3.5m long, 2m tall let's say. so you just scale it in max until its about that size, then save and export. this is really the way to do it. no code fix ups required. model everything to scale this way, and all you have to do is load and go! everything is already the right size.




#5200140 When is it okay for a player to get "stuck"?

Posted by Norman Barrows on 26 December 2014 - 03:49 PM


With this mechanic, a player could be at a point where they would have to "restart" the level in order to retry if they don't do things in the right order before going through the "one way door".

 

requiring a specific order of task completion without making the player aware of it (other than by trial and error) is usually considered bad design that leads to player frustration. but this does not necessarily hold true for puzzles, where proper order can be part of the puzzle to be figured out. and indeed, the fact that some specific order is required might also be part of the puzzle to be figured out. so as long as you use it as part of the puzzles, id' say its fine. just don't be TOO cruel! <g>.




#5200094 Warcraft 3 style Collision avoidance

Posted by Norman Barrows on 26 December 2014 - 11:46 AM


I found many answers that refer to pathfinding (it is typically said that clearance based pathfinding HAA* is used) but none of those referring to collision avoidance.

 

http://aigamedev.com/open/tutorials/clearance-based-pathfinding/

 

by finding a clear path, you avoid obstacles, thus collisions are avoided.

 

a game that uses some form of A* will typically re-calculate paths from time to such as when a path is deemed no longer valid. other approaches include only doing A* out to a limited range instead of the entire map, and re-calculating from time to time - used for lots of units and large maps where full blown A* of everything is too slow.

 

generally speaking, A* is known to be processor intensive, so you want to calculate path only when required.

 

note that heuristic approaches can also yield good results in your case (many units, not complex environment, no concave obstacles).




#5200087 Do you put code in your engine/game you don't fully understand?

Posted by Norman Barrows on 26 December 2014 - 10:59 AM

from a quick glance  at the code you linked to, it appears they express the two vectors as follows:

 

a start point, and a unit vector in the desired direction, times a constant magnitude.

 

they then assume the two vectors intersect, and solve for the two constants when the resulting endpoints are the same:

 

unit_vector_1 * constant_1 = unit_vector_2 * constant_2

 

i'd find a book on vector math, use a different better documented algo, black box test thoroughly, or find a math nut who memorizes this kind of stuff.






PARTNERS