Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!

Norman Barrows

Member Since 04 Apr 2012
Online Last Active Today, 05:38 PM

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

Posted by Norman Barrows on Today, 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.

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

Posted by Norman Barrows on Today, 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 Today, 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.

#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.

#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.

#5195510 Improving component system

Posted by Norman Barrows on 30 November 2014 - 11:28 AM

out of curiosity, why the tree of entities?   what types of entities have child entities?  its seems a bit unusual:


"the simple objects making up the majority of most scenes are probably going to be self contained static meshes with no hierarchy anyways."


have you actually identified objects in the game that have hierarchies? or is this just a capability you anticipate needing?


so what type of objects have a hierarchy? i've heard of using tree hierarchies for renderables: "horse - rider - sword" type thing, but i've never heard of it used for entities.

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

Posted by Norman Barrows on 30 November 2014 - 11:12 AM

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


"I have started in a small secret MMO RTS project that is unique last year"


if its truly the case that you've discovered a game type you want to play that isn't already out there, and you want to make it, then you are most fortunate. if this is indeed the case, then i'd recommend pursuing it, despite its complexity. 


start with the simplest possible rapid prototype - no networking (if possible), no audio, and just enough graphics to tell whats going on. get that working, playable, and at least semi-balanced. then add the next step - networking, then graphics, then audio.


do you research first. determine the target user and the target platform. figure out the COMPLETE suite of tools to do it all: compiler, network lib, graphics lib, audio lib, low level stuff like timers and math, paint programs, 3d modelers, audio file editors, etc. make sure you can convert asset file formats between all the tools. select the tools that will get the job done fastest - including learning time. 


much of your time will be spent in learning. by thinking first, and not rushing into things until you're sure what you're doing, and with a lot of patience, and a couple of years, you'll have your game.


a complex game as your first project simply means much more to learn and do before you get results. most folks don't have the stick-to-it-ivness to see such a project through to completion. that's why its not usually recommended. i'd only recommend it if you've found a game that meets the magic criteria of what to build: "what do you want to play, that's not already out there?". if you have found a game like that, then develop the concept incrementally in small baby steps and rapid prototypes, basic gameplay, networking, AI, graphics, audio, etc. and keep the design as simple as possible to start. you can get fancy in later versions, once its proven itself worthy of a new version. the real trick is to select and test your tools in advance so you know you'll be able to do the entire thing without having to change tools mid-stream. then you can proceed with relative confidence that you will reach the end of the tunnel if you keep on trudging. and avoid the temptation to switch to newer more advanced tools as time goes on. if you fall into this trap, you'll spend all your time learning the newest API's and porting the game to them, and never make any actual progress on completing the codebase, just updating portions thereof. continuous graphics improvements alone could probably be a full time job if take to the extreme.