Jump to content

  • Log In with Google      Sign In   
  • Create Account

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Jun 22 2016 05:38 AM

#5295218 How can i create a Cockpit as first person view

Posted by Norman Barrows on 06 June 2016 - 02:16 AM

do you want a slewable cockpit camera view? IE you you want to be able to look around inside the cockpit?


for a slewable view, you need a 3 model of the cockpit interior as part of the scene. for a non-slewable view, a 2d UI is sufficient. the 2d UI can be a pre-renderd cockpit view, or just a HUD, or whatever you want.


if you don't need slewable but want the stick to move etc, use a combo of 2D UI for the static parts and 3d meshes for the parts that move.

#5295213 skin mesh design need advice

Posted by Norman Barrows on 06 June 2016 - 01:41 AM

for static meshes i use a mesh memory pool, an array of structs with VB pointer, IB pointer, numverts, numtris, and is_active variables.


for skinned meshes i use D3DXMeshes. i turned tiny.cpp, the multiple animations demos, and parts of DXGI DXUT from the june2010 dx sdk into a stand alone turnkey skinned mesh library for dx9. i posted the code to one of my dev blogs here.




but its very common to roll-your-own solution for skinned meshes.  for example, D3DXMeshes have no easy way to share animations. You more or less end up with a copy of each animation in every controller that uses it.


when rolling your-own, you can do things like memory pools and sharing of assets, and reducing models and animations to just the data you need in your custom file format and data structures.


as for what that format should be, its up to you.  you might take a look at custom formats used in games or engines whose source is available online. or perhaps someone here might share their custom format layout and why they chose that format - what they need may not be what you need.


you could also use D3DXMeshes and AnimationControllers as a guideline. just add the capabilities you want (like animation sharing and binary file loading), and omit the stuff you don't need. note that D3DXMeshes support both text and binary files, but many tools don't support binary, just text, which loads sloooow....

#5294942 Peer-to-peer Massive Multiplayer Game

Posted by Norman Barrows on 04 June 2016 - 07:11 AM

peerless data sharing is one thing


distributed computing is something different.


for distributed computing you're going to need some sort of host / master / server to coordinate things, especially if you have nodes dropping into and off the network during runtime.


so you should probably be looking at models for distributed computing, not peerless networking. peerless networking is just the hardware architecture your distributed computing system will run on.  peerless is the lower layer of code, and distributed computing is the upper layer of code built on the lower layer.


i think you'll find that in distributed computing they always have some sort of host / master / controller computer, or some node(s) on the network that perform this function.

#5294939 Do I need to know Algorithms and Data Structures?

Posted by Norman Barrows on 04 June 2016 - 06:53 AM

>> Data structures and algorithms are the bread and butter of computer software.


this can not be overstated.


Data structures and algorithms are the bread and butter of computer software.


Data structures and algorithms are the bread and butter of computer software.


Data structures and algorithms are the bread and butter of computer software.


Data structures and algorithms are the bread and butter of computer software.


Data structures and algorithms are the bread and butter of computer software.


the more data structures and algo's you're familiar with, the bigger your "bag of tricks" to handle any programming task you encounter.


platforms, OS's, languages, libraries, engines, etc come and go. data structures and algorithms are eternal.

#5294938 Best approach for a demo game in short time?

Posted by Norman Barrows on 04 June 2016 - 06:46 AM

>> In 2 months, if you are a fast learner, something like Snake or Asteroids is possible. 


zero game dev experience -  zero UE4 experience - in two months i'd say "pong" - but 'roids might be doable.


>> For 2 months, I would say don't go there, drop anything with a network in it.


i'd have to second that.

#5294789 responsiveness of main game loop designs

Posted by Norman Barrows on 03 June 2016 - 08:46 AM

>>  input->photon latency


yes, this is the thing to be measured - and reduced, if necessary. which leads to the question, how much is too much? my testing that came up with 15hz minimum for a standard loop did no tests to determine if it was render rate, poll rate, or input -> photon latency that was the core cause for 15Hz minimum. so it might be the 15Hz refresh rate, the 15Hz polling rate, or the input -> photon latency of a 15Hz std loop - whatever that crunches out to be.


>> By simply ensuring that your game runs at 60Hz, that goes down to 50 to 67ms.


you mean with a std loop at 60Hz - correct?   those are the correct numbers for a std loop at 60Hz w/ 60Hz screen refresh rate lag.  or are you referring to a decoupled multi-thread design? or both?


>> If you increase the simulation rate even higher than 60Hz, you can reduce input->photon latency below 50ms. 


without changing poll rate, poll lag stays the same, update is faster, render is unchanged, so yes it would be more responsive.


>> Call people idiots all you like


that comment was not directed at anyone on this site.


>> Although, I'm considering polling at the simulation rate to reduce the input->photon latency below 50ms.


why wouldn't you?   polling tends to be so much faster than update.   and polling less often just introduces lag - right?.   what caused you to poll less often in the first place? surely at some point in the past you used to poll as often as you updated in games.   when did you stop, and more importantly why? i'm most curious as to what would cause such as decision.   as it seems to be an unusual one.   i mean, if polling less often introduces lag, and you poll less often, then it would seem you made a conscious decision to introduce lag, and i'm wondering what on earth could cause you to do that.


>> So -- for me, rendering less often than I update could actually cut 40% off my input->photon latency


that makes sense.  your drawing overhead compared to input and update is so high that drawing less often reduces the input->photon time, by reducing the poll+update lag. you poll and update more often and render less often, so the time from poll to photons goes down on average.


so the real questions are what are the upper and lower limits for these (if there are any).  IE polling Hz, update Hz, render Hz and the resulting poll to photon lag time. they all have minimum rates at which things become unplayable. one or more of them is 15Hz lower limit based on my test results. higher rates in any gets you lower lags times.  higher rates for render gets you smoother animation. i suspect polling rates need be no faster than update rates - can't think of anything it might get you. higher update rates might have some small effect on physics accuracy.


the less often you do something (poll, update, render), the more time you have to do things in general. that why i've used 15 Hz in the past. it gives me 66ms to poll, update, and render - and it all goes to render of course.


so the real question is what are the minimum upper limits? when is a given rate for poll, update or render fast enough? there's no sense doing things more often than necessary. at some point poll to photon lag will be "fast enough".  it seems render will be limited by the monitor refresh rate. you may render to vidram twice, but if the hardware (i was going to say DAC, but they don't use a DAC anymore do they?)  only sends it off to the monitor once, whats the point? so it would seem that render need run no faster than refresh. putting you at like 60Hz or 90Hz for render. if render is say 60Hz, whats the Hz for poll and input that's "fast enough" when it comes to "poll to photon" lag? once that's determined, you need go no faster, and you can concentrate on doing more in the same amount of time, instead of the same amount in less time.

#5294776 responsiveness of main game loop designs

Posted by Norman Barrows on 03 June 2016 - 07:35 AM

>> So I'm an idiot, eh? Oh well, I don't really suppose I could prove otherwise.


that observation was not meant to include those who frequent this site.  this is one of the few places where one can get straight answers from folks who have been there and done that.


>> He's saying HUMANS act at 5 Hz. He's not suggesting that means a game should poll input devices at 5 Hz.


yes, his follow-up response cleared up that point. i first i took it to mean he was polling at 5hz, presenting at ~60Hz, and updating at something > 60Hz.


at the very first i took that to mean the player was getting updated both less often, and for a smaller total time slice, which it obviously couldn't, or the player would move slower than the rest of the world. it must have been a long day.

#5294348 Early Access vs "one shot"

Posted by Norman Barrows on 31 May 2016 - 01:32 PM

>>  potential funding


strikes me as rather desperate means of funding development.  probably not a good idea to rely on early access sales to fund the project.


>> bug testing


you should find all the bugs yourself before showing it to others - especially paying customers on whose word of mouth advertising and reviews your game's entire future might hinge.


you know the old saying, "you only get one chance to make a good first impression".    Eminem's saying is simply restating this old adage in different terms.   


possibly getting feedback when you're at a loss for design solutions or otherwise unsure exactly who your target audience is or exactly what they want (which is general is not a good place to be) seems to be the best use for early access (other than ripping people off).


actually, publicity is the best use. but the game should be in nearly gone gold condition to make a good first impression. when its close to gone gold, early access to generate buzz makes good business sense, assuming its commercially viable (as Microsoft loves to say).











#5294320 responsiveness of main game loop designs

Posted by Norman Barrows on 31 May 2016 - 09:00 AM

total max lag = max time between polls (polling lag) + time between present and input doing other things (other lag) + time from end of present til end of next present that shows results of input polled after the first present (response lag). 


if you poll at 5 Hz, your max polling lag is 200ms.  if you poll right after you present, your other lag is zero. if it takes 33ms to poll, update, and render the results of update, your max response lag is 33ms. for a total of 233ms max lag.  for minumum lag, you lose the poll lag (IE assume they pressed the button on the very last poll), which would give you a minimum lag of 33ms (minus polling time) from button press after present through update, render, and present again. 


i poll at 15hz, my max polling lag is 66ms.   i poll right after i present. my other lag is zero. it takes 66ms to poll, update, render, and present, so my max response lag is 66ms, for a total of 132ms max lag. and thats on a single core at 1.3ghz and onboard graphics. the typical game ready PC is more like 4 core at 3+ ghz with a gtx 700 or 900 series card. i could easily goto 30 fps on such a machine, putting max lag at about 66ms, and min lag at about 33ms minus time to poll (which is negligible compared to render and update).


i think i'd take a lag range from 33 to 66 ms vs one of 33 to 233 ms any day. although it would not animate as smoothly at 30 fps as it would at 59-60 fps.


there seems to be this obsession with going faster. at some point surely we must be fast enough, and can stop trying to go faster, and can instead concentrate on trying to do more at the same speed.  


back when the world was first addressing the issue of how fast is fast enough, movies ran at 24. some folks said 24, other said 30.  i did some experiments to determine the answer.  the answer i cam up with was 15 Hz. the entire simulation must run at at least 15Hz to be sufficiently responsive. 30 if you want it to be snappier (increased responsiveness) with smoother animation. most of the world at that time, doing graphics heavy shooters without much game under the hood, settled on 30 for nice animation. and they could get away with it given the sparse environments rendered and the limited depth of the simulations. i chose the easy way out and settled on 15. that way i have much more time to render and update before i must present. and the games are still playable. most folks don't even realize they run at just 15fps - until you tell them. and nowadays, PCs are fast enough i can kick that up to 30 fps and still have plenty of time to do everything required. maybe even 45 or 50 fps.


one must always be mindful of the impact of changes - even changes made in the name of speed.



>> I'm pretty sure he was joking.... 


see, things are so whacked in game development i couldn't even tell!   i've seen some really crazy and stupid sh*t come down the pike over the years.  i used to think its was only regular software development that was full of idiots.  time has proven otherwise.


that's why i tend to favor this site, as sane engineering practices tend to prevail here. a rare thing. hard pressed, i might come up with perhaps half a dozen to a dozen similar sites at most - and none specialized towards game development.


>> What do you mean with this? updates and frames is not the same thing as game turns


i later realized what hodgeman meant. they poll at 5 hz and update for 200ms, so the player still gets a fair share timeslice. physics runs at faster speeds, similar to stepped movement for projectiles, for greater accuracy, but the overall timeslice length is the same (i assume).


as for turns, vs renders, inputs, updates, cycles, main-loop iterations, etc...

its gets a bit complicated once you unlink things. FPS is no longer the same as inputs per second, or updates per second. and FPS is no longer the same as the input-update-render-present cycle. i find the use of the term "turn" defined as: present, input, update, render results (immediately followed by the next present, beginning the next cycle) is hel[pful. whether these are serial or parallel, the time for a "turn" is whats important.  

#5294142 responsiveness of main game loop designs

Posted by Norman Barrows on 30 May 2016 - 06:39 AM

frankly, this revelation has put me into shock at what passes for "good engineering" in "professional" game development. and is making me seriously reconsider whether my time spent on this forum is time well spent.

#5294139 responsiveness of main game loop designs

Posted by Norman Barrows on 30 May 2016 - 06:31 AM

>> In extreme cases you could improve perceived latency by drawing some things after the main game/simulation graphics, like if your game displays a mouse cursor.


although not explicitly mentioned, this question is mostly with regards to realtime combat (IE FPSRPG type games) - so no mouse cursors.


if it doesn't have to be realtime - who cares? 

#5294137 responsiveness of main game loop designs

Posted by Norman Barrows on 30 May 2016 - 06:26 AM

>> There should also get to be one human player for every core involved, or else the computer is ganging up on the player.


only if you program the AI to do so. having the AI gang up on the player is the oldest form of "cheating" there is.


there are two kinds of games, those that provide a level playing field - and everything else.

#5293900 Bricking up the exit: Denying completion of the Hero's Journey

Posted by Norman Barrows on 28 May 2016 - 01:50 AM

>> - Is it a good idea to make sure that when players do exit (which is inevitable), it's a satisfying exit?


no harm in it.



>> - How can we determine when a player is ready to exit, so we can present the exit, before she continues playing beyond her point of enjoyment? (ideally, we want to encourage use of the exit before the game gets boring, but after he's had as much enjoyment as can be mined out of it)


nigh on impossible. its hard to say when they will get bored.  you might assume they won't get bored until they run out of content, but that's not even a safe bet. they may not be into the content that remains, or they may not have even found it.


- How can we present the exit in a way that players comprehend well?


shouldn't be that hard. reminds me of Sol (Edward G Robinson in his last film) "going home" in the movie Soylent Green with Charelton Heston.

just be sure to make it obvious. i accidentally ended fallout 3 twice by completing the rather short main quest line. and the second time it was unintentional. i found myself at the final quest without ever actively pursuing it.


- Is this actually beneficial for the developer? 


for the developer, no. its more work. and its not enough of selling point to significantly impact sales.



it seems you like closure. there's no harm in adding optional "closure" features to a game. but then again, in real life - the ultimate rpg - there's no closure, no exit for the bored (if there was i would have left this god forsaken rock long ago - i'm just doing time on planet earth).  the only exit is suicide.  so you keep playing til you drop or you're so bored / disgusted / without hope you cap yourself.

#5293897 responsiveness of main game loop designs

Posted by Norman Barrows on 28 May 2016 - 01:02 AM

>> If you accept the argument that there's no need to poll faster than the drawing rate


assuming you update no faster than you poll or render.


just cause you can only draw the screen once every 8 games turns doesn't mean you should let the computer move every turn and only let the user move every 8 game turns.


you have to preserve the fair play of "its my turn, ok, now its your turn, ok now its my turn again."


"i cant draw fast enough to show you whats going on - so you don't get a turn until i can" - that's just silly.


yet from what you say, it seems folks actually do this. no wonder games are such piles of crap these days.

#5293617 responsiveness of main game loop designs

Posted by Norman Barrows on 26 May 2016 - 10:32 AM

>>>> can anyone think of an example that doesn't do this without being less responsive?


>> A game running at 144hz with a 2 frame render lag (~7 ms per frame, or 14ms latency with lag) is still more responsive than a 60hz game (~16ms latency).


that sounds like one right there to me.


thanks all!