Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Oct 2005
Offline Last Active Yesterday, 08:47 PM

#5235361 Ways to setup true first person viewpoint

Posted by deftware on 17 June 2015 - 06:32 PM

You could just have the camera on the head bone, and dampen it out, so that it's effectively 'chasing' the headbone, instead of solidly fixed to it.

#5233526 Skydome

Posted by deftware on 08 June 2015 - 07:07 AM

I have used skydomes, but I offset/stretch them (when generating them algorithmically at runtime) so that the camera is closer to the top of the dome, and the bottom of the hemisphere at the horizon is lower than the horizon, to better avoid ugly discontinuity artifacts if player is up high above scene geometry.


Also, to eliminate any intersection with scene geometry, I don't even worry about the actual geometry/size of the skydome, I just disable depth writing when I draw it, so that everything that's drawn after the skydome will overlap it by default, even though the skydome is really just almost like a hat the camera is wearing around with a 1-unit radius.


For texturing I would pretty much just use the horizontal coordinate as the texture coordinate, and I would overlap textures and scale them so that there's a certain parallax effect. I would also fade the bottom of the skydome to black so it's not fullbright at the horizon.. This is, of course, also a stylistic choice and other options are available.


You could also incorporate a skybox backdrop, and just use a skydome to add cloud layers. There are a few games that have done this over the years.

#5233523 Expand 2D texture in 3rd dimension to create a model

Posted by deftware on 08 June 2015 - 06:51 AM

I haven't played minecraft more than a few minutes, but I was under the impression that the items/weapons were just regular 3D models, made to look like voxel pixel-art. You could automate this process of generating a model from a texture, and have some other means of specifying the 'thickness' of the resulting model, but it also might be easier to just use regular 3D models.

#5230537 Client side hit detection vs server side with prediction

Posted by deftware on 23 May 2015 - 12:54 AM

It is easier to write, which is sometimes an important trait.
Also, server rewind may still suffer from dropped/delayed packets, where the server comes to a different conclusion than the client.
If you use client-side hit detection, the client will "never" have the feeling of lag (but may, instead, have the feeling of someone else shooting them when they feel they alread dove into cover.)


With server-rewind strategies you can experience the worst of both worlds: where sometimes what the client sees isn't what happens on the server, and also client players taking damage after finding cover from an attacker.


As a gamer, though, I would rather that my attacks register exactly, even if that means I may get hit behind a corner. It is vastly more frustrating to me to be skilled and capable of pulling off really great shots, only to have them not register because of high latency jitter, than it is to get hit after running behind a corner. I feel more cheated when my shots don't "register" than when I get hit behind a corner.

#5228493 generic fancy procedural graphics question

Posted by deftware on 12 May 2015 - 02:47 AM

phrase of the day: "generic-fancy"


If I were to take a stab in the dark, I'd say you want to make something that looks good, that wasn't made by hand. Ultimately, procedural systems must be 'crafted' or 'sculpted' in some fashion to make anything resembling something our brains can recognize and interpret as something, otherwise it's just noise. The trade-off is that the more crafting you work into your procedural content, the less varied and novel it becomes, and it will start being repetitive and all 'look the same'.


To make something more varied with an equal amount of 'crafting' you will end up with more content that is less complex/intricate.

#5228117 Is it efficient to sort a "render-queue" for less texture-switches?

Posted by deftware on 09 May 2015 - 09:08 AM

Another option is to just load all your textures into a single bound texture, whether that be a texture atlas, or a texture-array, or even a 3D texture (where each object gets a Z coordinate based on which texture it needs). For many different sized textures you'll have to manually figure out the optimal way to organize your textures so they all fit together with optimal usage of texture area. Then you will be doing one texture bind for all of your objects.

#5228115 Is it possible to declare single-bit-variables/struct?

Posted by deftware on 09 May 2015 - 09:01 AM

There is only one situation I've encountered so far that necessitate the use of bitflags via bitwise operators, and that is data serialization, for either network transmission of data or compact storage for file formats.




Often there's way more layers too!
e.g. processor fetches 64 byte cache-lines, then fetches 4 byte words, then operates on a byte within a word.


The primary issue is that it simply takes more work to examine and work with individual bits. Processors are designed (AFAIK) to operate on 32-bit values, primarily. Anything else (a bit, byte, word, etc) takes extra cycles. EDIT: thus, it can be useful for situations that call for having compact data (networking) but in performance-sensitive situations (tight inner loops that execute tens of thousands of times per frame) you'll want to avoid working with individual bits and stick to a data type the platform/system can work with as fast as possible. In the case where you have a gigantic set of booleans, maybe it would be better to use bits for the sake of avoiding cache misses, but it is up to the programmer to determine what works best for what they are trying to do.




in c++ you can declare single bit variables, you need to use the bit-fields specifier.
struct CarProperties
uint8_t EngineRunning:1;
uint8_t OutOfFuel:1;
uint8_t Burning:1;
uint8_t WantedByPolice:1;
uint8_t Electric:1;
uint8_t TwoSeater:1;
uint8_t Airbags:1;
uint8_t DrivenByThePope:1;


I totally forgot about this. I've always just used my own #define BIT(x) (1 << x) to perform bitwise operations.

#define BIT(x) (1 << x)
int flags = 0;
flags |= BIT(FLAG_A);
if(flags & BIT(FLAG_A))

The primary reason for doing it like this, as opposed to defining each flag as a power of two, is that it allows me to also use the FLAG_X defines to index any string tables or other tables that each flag needs a unique value for.

#5228021 3D Texture upload fails

Posted by deftware on 08 May 2015 - 04:40 PM

are you data values from 0-65535


 I  am sure the issue lies in your Format and InternalFormat, and then also perhaps how your data is actually stored (just because they are unsigned shorts doesn't mean they are 0-65535, but hopefully they are).


 Read some updated glTexImage docs concerning InternalFormat. It's usually the culprit in situations like this.

#5227426 uniform buffers versus array uniforms

Posted by deftware on 05 May 2015 - 09:31 PM

this should help you http://www.gamedev.net/topic/655969-speed-gluniform-vs-uniform-buffer-objects/

#5226545 Java Challange

Posted by deftware on 30 April 2015 - 12:37 PM

    fld st(0)
    fxch st(2)

#5224744 Unity3d Simple Soil Simulation

Posted by deftware on 21 April 2015 - 01:51 PM


You can draw such terrain with a single quad. Just create a texture either by rendering your terrain into it somehow or by filling it texel by texel yourself.

how will the physics work then ? should i write it by myself?



You update the texture every frame. You handle positions of the dirt as a series of dirt-columns across the screen. Every frame you update by breaking columns where an explosion hits them (or crater, etc) and then output that to the texture. To speed it up you could also write just the changing parts of the world to the texture, instead of the whole thing.


There is also the requirement that you can code simple abstract concepts, like an array of dirt columns, and be able to generate textures.


Whenever I want to do something that I don't know how to do, there is always learning involved. So, be prepared to learn something.

#5222805 Programming fake 3d using sdl?

Posted by deftware on 12 April 2015 - 02:39 PM

Wyrframe is pretty much dead-on.. Keep in mind that an actual 3D solution would be more difficult than actually having a sphere, because you can't actually map a checkerboard texture to a sphere in 3D space.

#5221243 Interpolation Issue

Posted by deftware on 04 April 2015 - 12:17 AM

160ms is just fine so long as your scheme for dealing with sparse information is sound. 160ms is 6.25hz, which seems great if you're handling incorporating the received information properly. If your game doesn't need everything to be as fast as possible, then the strategy hplus mentioned about buffering updates and interpolating between two known good updates is probably your best bet..


You could even go so far as to use cubic splines to interpolate between multiple updates to get maximum smoothness. The real issue is in how fast your objects move, how much inertia they have (which helps hide update intervals), and how you interpolate between updates.


One strategy I had was to just constantly be interpolating entities toward their correct position, allowing known velocity to affect them as well. This was basically some form of interpolation without there ever really being a direct path from 'where i am' to 'where i should be'.. The objects were allowed to just float around using normal physics, and network updates would basically give them a goal to move toward. This would allow for great error at times, but was uber smooth. Basically I would set an interpolation-time of about 1 second, and each time I'd receive an update I would calculate the current position vs actual position delta, and scale it to a vector that would take 'interpolation-time' seconds to move the entity from where it was to where it should be.. Typically this worked out so that by the time the object reached where it should be, a new update had arrived and it would begin moving to the next position. This kept it in constant flow. At the time I was not dealing with jitter, so it didnt work too great over the internet, but it was nice with a low update rate.

#5221172 Interpolation Issue

Posted by deftware on 03 April 2015 - 01:09 PM

personally, I avoid jitter by measuring the deviance from the known rate of incoming packets..


IE: if the server is sending 20 updates per second, I know that each incoming packet *should* be 50ms apart. So I just measure what time each update packet arrives, and can use that in combination with the previous packet to determine how late any latency jitter has caused a packet to be. I use that to extrapolate incoming object positions using their velocity.


This keeps the irregular latency from causing positional info to make objects jerkily accelerate/decelerate. Dropped packets must be accounted for as well, to prevent them from causing what appears to be a giant acceleration (because it looks like a really really late packet, when really the previous one never made it).. This can be done by measuring intervals of the known update spacing (50ms, for instance).

#5221078 Anyone got any ideas where 4k a sec is coming from?

Posted by deftware on 03 April 2015 - 03:46 AM

have you tried commenting our various function calls?  to be honest I am very suspect of your LoadMedia stuff. It could be something your code is using, not necessarily just your code, that is causing the leak.