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!

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Jan 26 2015 08:13 PM

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

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

Its "Intersection of two lines", I already posted it here,


it actually appears to be intersection of two vectors in 2d space, using parametric expressions.


a good book on vector math seems to be called for.   don't have mine anymore unfortunately...

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

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

So as the title suggest, do you copy code from the internet and put it in your game/engine without fully understanding it?


never, or only in the distant past.


so today I gave up and just copied the code from the internet and put it in my engine.


i may have done that once or twice in my early days.


just do good black box testing to make sure you can depend on it - even if you don't fully understand its internal workings.


even better - as suggested above - use the gamdev.net, community to help you figure out the code!  : )

#5199878 Stuck with which approach to take (architecture)

Posted by Norman Barrows on 24 December 2014 - 01:29 PM

How do you guys typically architect a rendering engine?


custom rolled for the game its designed for.  the custom render engine in turn calls the Direct3D api.


how to render is a function of what to render, which is a function of game type.

#5199876 Visual studio 2013 (exe release) runs slower compare to VS2010

Posted by Norman Barrows on 24 December 2014 - 01:16 PM

Hello, I convert a project that was in VS 2010 to VS2013, everything went smoothly, but the performance (for the release exe, with same exact code, and optimization settings) drop almost in half compared to VS2010.


Is this comparison fair? By that I mean same CPU, same GPU and same drivers?


for a fair test, only the compiler/linker/ide can change, and you must replicate compiler and linker settings as best as possible. no hardware or drivers on the PC used for speed  tests can change.


is this the case? if so, the difference is of interest, but probably due to some difference in compiler or linker settings etc that you didn't notice yet.


if not, then comparisons are meaningless. apples and oranges.

#5199465 How can I create an installer for my game?

Posted by Norman Barrows on 21 December 2014 - 07:42 PM

i found inno setup to be an excellent turnkey solution for windows games

#5198767 first person camera rotations to 2d sprite rotation

Posted by Norman Barrows on 17 December 2014 - 08:39 AM

it depends on how you store the camera's rotation.


what you want is the camera's y rotation (Euler angle). that's the rotation to apply to the sprite, assuming you want to draw the player from a top down view in the middle of the radar facing in the direction of the camera.


if you store the camera's rotation as Euler angles (Xrot, Yrot, Zrot), just use Yrot.


if you use a matrix, use the "matrix to Eulers" algo to get Yrot.


if you use forward (look at), up, and right vectors, you already have the first step of "matrix to Eulers" done, just use the rest of it to get Yrot.


if you use quats, convert to matrix, then use "matrix to Eulers" to get Yrot.


been a while, off the top of my head, the "matrix to Eulers" algo is:


start with a vector 0,0,1.


rotate it by the matrix. this gets you your forward or look-at vector.


project the forward vector onto the X-Z plane. 


the angle between the z axis and the projection is  Yrot. how you handle the degenerative cases of forward / look-at vectors of 0,1,0 and 0,-1,0 is up to you.


now, unrotate the forward vector by Yrot, so it lies in the X-Y plane.


at this point, the angle between the forward vector and the Z axis is Xrot


but the algo does not give you Zrot. just an Xrot and Yrot that points a vector 0,0,1 in the same direction as the matrix.


odds are you could do the same sort of thing with up or right vectors to get Zrot.


note that nested rotations are not commutative, so the above assumes a rotation order of Xrot, then Yrot, Then Zrot for transform, and -Zrot, then -Yrot, then -Xrot for untransform. That's why you unrotate by Yrot before you project to get Xrot. If your rotation order is different, you'll need to adjust accordingly.


a couple calls to rotate point by matrix, and a little trig, and you've got it.


the projection of a vector onto an axis (the i,j,or k component) is a vector along the axis with a magnitude equal to the the magnitude of the original vector times the cosine of the angle between the vector and the axis.


as i recall, atan is used to compute the angles between the vectors and the axes.


note that this is just one way to do it. there may be some slick way to do it with vectors or something as well.

#5198449 Do i have to make basic games again after break in gamedev?

Posted by Norman Barrows on 15 December 2014 - 06:39 PM

Tl ; DR
I took long break from gamedev but not programming in general.
So I am wondering if I need to recreate these simple games or I can start with more advanced concepts like AI, side scrolling, more physics etc.?


i've taken multiple breaks of multiple years in the 25 years i've been doing games. its just like riding a bike, you never forget. sure you get rusty, but you pick it up again pretty quick. just pick up again where you last left off, and you'll be back up to speed in no time.

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

Posted by Norman Barrows on 11 December 2014 - 03:46 PM

but it could be done in realtime to create the incredible shrinking (or growing) man.


but its not the best way to it - forgot to mention that. for real time user scaling of a skinned mesh you can just use the scale part of your transform matrix and add in the user correction factor.


in my case i was dealing with multi-mesh rigid body models that you couldn't simply scale using just the scale part of the model's transformation matrix.

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

Posted by Norman Barrows on 11 December 2014 - 03:40 PM

It is far better from a correctness viewpoint to simply model everything at the same scale.
Very often games use a 1-meter scale.


agreed. defining the time and distance scales used in the simulation, as well as what visible object distances will be, and how to store world coordinates is one of the first steps i take, then i do everything to scale. in Caveman 1.0 once i got my male and female models done, i found they were a bit too big or small, so i wrote some fixup code to do a one time scale at load time, instead of having to use a correction factor in each scaling transform during gameplay, or go back into the 3d modeler and scale each rigid body limb, then use the in-game modeler to modify the limb attachment points in the model for the new sized limbs. the performance hit was negligible, and just one time at program start when everything else got loaded anyway so you never noticed. the code took less than an hour, and i could have spent days on getting all 14 or so meshes of a model scaled and attached just right so they all added up to exactly the correct overall height. a kludgey fix that cost maybe 1 second of runtime and saved about a weeks dev time. but definitely comes under the category of a cheating hack.

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

Posted by Norman Barrows on 10 December 2014 - 09:14 PM

Scaling things in exact dimensions in the game editor is a good idea, but one problem I encounter with this is
I have to allow the user to tweak the sizes of the agents to their likings, rather than I do it myself.


i used a custom coded realtime model scaling routine that actually scaled the data in a d3dxmesh object. i just did it once at load time as a fixup to get things the correct size in the game (scale male by 1.2, female by 0.9, that sort of thing), but it could be done in realtime to create the incredible shrinking (or growing) man.

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

Posted by Norman Barrows on 09 December 2014 - 01:39 PM

in one game i did, i did a one time scaling of some models at load time to get them the correct size. it was lazy of me, but easier than using the 3d modeling software to get them the right size in the first place.

#5197236 Renderqueues

Posted by Norman Barrows on 09 December 2014 - 01:27 PM

I feel like maybe this could get optimized in some way. Any suggestions?


like Buckeye says, plop it in a game, and check your framerate. if its acceptable, you're done!


if its not, fire up the profiler (or use timers if you don't have a profiler) and see where the bottleneck is. 


if the bottleneck is the render queue, post a screenshot, the render queue code, and a description of what you're drawing, and from there folks should be able to suggest what directions to take in optimization.  

#5197018 is there a name for this type of data structure?

Posted by Norman Barrows on 08 December 2014 - 02:15 PM

is there a name for this type of data structure?


i've been considering commonalities in some titles i'm working on and have been playing recently, and i realized that all the games in question have static scenes, and then they have various types of objects with similar render and / or update methods, such as clouds, dropped objects, swaying vegetation, entities. projectiles etc.


this leads to an abstract data type (a  data structure + methods)  such as a list, along with the render and update methods to operate on objects in the list and / or on the entire list.


so, is there a name for this type of data structure?


it often ends up that its easiest to keep multiple entity lists based on type, such as players, targets, dropped objects, etc.


its also often easiest to implement particle systems as stand alone lists with their own render and update methods.


so is there a name for a "list with render and update" ?


it seems that this type of data structure / API could be used for most everything in a game.


so a game would be a collection of these modules, some being object lists, and others being particle systems, and render_all and update_all would call the render and update methods of these modules.









#5195702 Improving component system

Posted by Norman Barrows on 01 December 2014 - 08:49 AM

Though if there was a clean way to retain that functionality and switch to a plain array of objects then I'd probably at least try it out since it would simplify things quite a bit.


one possibility:

use an array[max_object] of objects.

each object has a parent_ID.

each object has a num_childeren (where max_children = 10 or whatever)

each object has an array[max_children] of child_IDs.


parent ID lets you traverse up the hierarchy.

child ID lets you traverse down the hierarchy.

a parent id of -1 means no parent.

num_children=0 means no children.



pros: fast arrays, can be iterated quickly. can be a static data structure.

cons: limited to max_objects, max_children.


this is a flat array implementation of a tree, a variation on the flat array implementation of a doubly linked list (IE one that has multiple "next" pointers).


i like the idea of object hierarchies for movement. i only use that type of thing in one place - moving entities and dropped objects aboard moving rafts. i render equipment using hierarchies, but don't consider them objects, simply inventory items.


converting my non-hierarchy entity list to this style would be straightforward. add the parent and child variables, and modify update to additionally apply results to any offspring. when an entity boards or disembarks from a raft, set parent and child variables for the entity and raft. max_children could be a problem if they want to drop 100 objects on the deck! <g>.

#5195700 fully motivated to make a video game since could not find right one

Posted by Norman Barrows on 01 December 2014 - 08:25 AM

but I have difficulty choosing which one to use, I have started scratch projects in all of C, C++, Java, C# and PHP but never fully completed one, because I then switch to another language and recode the algorithm again, I am just not sure which one to use.


whatever will get the job done with the least development time. so the language has to be capable of doing what's required, and running fast enough on the target platform. all the tools and libraries required must be compatible with the compiler and language used. what language and library specifically is totally irrelevant. all that matter is that it works, and its the fastest way for YOU to complete the game, including learning time. tools should be selected based on productivity.


so make a list of all the tools that could do the job. for each tool, estimate how long it would take you to learn the tool and then use it to make the game.

whatever set of tools adds up to the l;east amount of total learning and development time is the correct choice for you.


note that this makes tool selection a very personal thing. its based on the dev's current knowledge level, and what tools they have access to. for a given game, the correct answer might be different for two different dev's based on previous knowledge, existiing in-house code, and budget constraints.


i personally have experience with c++ and the dx9 fixed function API, along with an in-house game development library of low level stuff. so unless i need graphics beyond the capabilities of dx9, the answer for me for just about any game is c++, dx9, and my Z game library. they can do anything that dx9 can do, and i already know them, so learning time is zero. 


but the real message to take away here is that its how PRODUCTIVE a tool makes YOU that should drive tool selection. and that is measured in estimated learning time + estimated  development time to complete the game. and obviously the tool must be capable of the job in the first place. other than having the basic needed capability, and how productive a tool makes you, no other factors should really be considered, except perhaps tool price vs budget constraints.