Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Feb 2007
Offline Last Active Today, 08:49 AM

Posts I've Made

In Topic: New Cryengine/Unity/Unreal 3rd/2nd/1st person shooter

Today, 08:33 AM

So, how much funding you got for this already?
...because I don't know if you're aware, but what you've described would cost millions (pounds, dollars...) to make. Many, many millions. And if you're not cutting corners, then, many, many more millions than the games that do apparently cut corners... So, like, a hundred millions?
If you don't have a hundred million dollars, then you should probably try to design a game that's possible to make with less money than that.
P.S. Infinite detail is not a game engine. It's a point cloud visualization tool that's not at all suitable for games with terrible, terrible hype videos full of mistruths from a snake oil salesman...

Pretty certain it's a joke. Even the fact that he puts great but old games like Crusader no remorse on there indicates that he's older, and shouldn't be inexperienced enough to suggest this seriously.

One would hope, but he's done it from an account name which a few minutes of googling gave me his personal details... so not just a fake troll account.

In Topic: Question about GI and Pipelines

Today, 07:39 AM

No, it would be possible with either. 
...but, the voxel dataset itself can also be deferred or forward lit :lol: You can voxelize material properties and then light the voxels, or you can light them during the voxelization process! Which gives forward scene + forward voxels, forward scene + deferred voxels, deferred scene + forward voxels, deferred scene + deferred voxels... 
Lighting in general tends to be more efficient in a deferred pipeline, which is why people use it :)

You can write most of your lighting code to not care about whether you're using forward or deferred, and then have two different sets of shaders that both call this shared lighting code. That lets you fairly easily support both for testing :)

In Topic: Steamworks <16?

Today, 07:27 AM

Search for "germany sole trader". e.g. here's the different kinds of businesses: http://www.commercial-register.com/legalformsgermany.html

GmbH (equiv to LLC) is what you'd ideally get as it means that the business is a separate legal entity to you (important if someone sues you!), but "sole trader" is the easiest option.


Apparently "sole trader" is Einzelunternehmen?




And you will need to talk to a real accountant / tax consultant. Apparently you have something called the Bundessteuerberaterkammer who might be of help.

In Topic: Steamworks <16?

Today, 06:42 AM

Yeah as above, you (probably) at least need to be a sole proprietor. You will have to check the laws in your country for how you declare income gained from sales.


e.g. In my country, to declare income gained from sales or contract-work, you must be a business. So, I am registered as a sole proprietor so that I carry out independent work by myself. This was a quick 10 minute registration on the tax office website for free, and just gives me a "business number" which is required for taxation purposes. There is no legal distinction between myself and this "business" -- if the business earns money then I report it on my personal tax forms, and if the business owes money then I pay it out of my personal bank account.


If it's not possible for you to register own own sole proprietorship, you may be able to get a family member to do it for you... however, this will impact their own personal taxation situation. For example, they may end up paying more tax on their existing job...

You will have to speak to an accountant within your country to find out the best kind of company/business to create.

In Topic: responsiveness of main game loop designs

Today, 01:28 AM

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

assuming you update no faster than you poll or render.[/size]
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.[/size]
you have to preserve the fair play of "its my turn, ok, now its your turn, ok now its my turn again."[/size]
"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.[/size]
yet from what you say, it seems folks actually do this. no wonder games are such piles of crap these days.

We're talking about some pretty small time slices here. In my example, the sim is running at 480Hz and the user is seeing it at 60Hz, which is the limit of most people's monitors. It's literally drawing as fast as possible. Human high-level conscious thought, by latest research, only updates at approx 5Hz :lol: The simulation rate being higher than the display rate simply results in more fidelity -- e.g. integration of physics can be more accurate, not unfairness...
For example, in my racing sim, I can run the tire logic at 6000Hz to ensure that they behave realistically when cornering at 300MPH -- but I can also only allow the AI drivers to output new steering/acceleration/braking commands at 10Hz if I want them to appear human. My choice of tire simulation fidelity means nothing to AI vs Human fairness...
Moreover, a world-champion starcraft player, a professional athlete who trains full time, can manage about 400 actions per minute, which is impossibly high for us mortals. That's ~6.7 actions per second... or at 60Hz, that's one action every 9 frames, on average. So the best video game players in the world are already only getting approx one turn in eight, and can only manage to keep up with a computer "turn for turn" in a ~7Hz simulation... meaning that if you're running your update loop even at 15Hz, the computer is still getting twice as many "turns" as the player, which by your logic is grossly unfair???
No one would play a 7Hz action game these days, so obviously rendering at the user's input rate is not a good idea. Rendering as fast as possible makes the game more responsive for the user as the game-event->photon->cognition->motion->keyboard loop becomes shorter. At lower framerates, this whole loop gets longer, so the user is given a disadvantage -- even if they react as fast as humanly possible (about 200ms), they're given the handicap of the photons informing them of the event later than possible.
In my example I chose to poll at the rendering rate, but that's not required either. You could poll once per update, and still render once every N updates -- this would allow the user to input commands at the simulation rate, but only be able to see the results of them at the display rate. Note though that audio devices have pretty high output rates (e.g. in KHz instead of Hz :) ) so audio cues could still be output at the simulation rate.
Fact is that in general, a high framerate game will be more responsive than a low-framerate one, decoupling the simulation and rendering rates doesn't necessarily impact responsiveness, and decoupling rates doesn't have to impact the fairness of the game.

Anyway, in the OP you asked if it's possible to update faster than render, without harming responsiveness. And yes, you can, as long as you're ok with the sim having higher temporal fidelity than the user's monitor... In any case, responsiveness does not have to decrease- it can be the same as before.
In fact, responsiveness can actually improve in a decoupled simulation!
In a traditional loop running at 30Hz, the delay between a key-press occuring and being picked up by the poll is between 0 and 1 frames, or on average, 0.5 frames, or 16.7ms. There's then 33.3ms between the poll and when until the CPU finishes the next frame (which consumes that input), for 50ms average delay between a keypress, and the draw commands resulting from it being sent to the GPU:

0ms        33.3ms               66.6ms
| Frame 1  | Frame 2            |
 Key press | Poll,Update,Render |

In a decoupled loop where there's 3x Poll/Update pairs per draw, there's also less time between polling, so now we're polling every ~5.6ms, so a key-input waits an average of ~2.8ms before being picked up by a poll.
Events picked up by a poll now wait either 16.7ms, 11.1ms or 5.6ms (average 11.1ms) before the next draw starts, and 16.7ms until that draw completes, for 30.5ms average delay between a keypress, and the draw commands resulting from it being sent to the GPU:

0ms                16.6ms           33.3ms
|   Key Press     |                 |
| Frame 1 Sim     | Frame 2 Sim     |
| P,U | P,U | P,U | P,U | P,U | P,U |
| Frame 0 Draw    | Frame 1 Draw    |
| Draw            | Draw            |

So in a traditional loop, the input latency is one and a half frames on average, while in this particular decoupled loop it's actually less than one frame on average!