Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Oct 2005
Offline Last Active Oct 24 2016 11:01 AM

#5226545 Java Challange

Posted by on 30 April 2015 - 12:37 PM

    fld st(0)
    fxch st(2)

#5224744 Unity3d Simple Soil Simulation

Posted by 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 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 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 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 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.

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

Posted by on 01 April 2015 - 12:04 PM

you're not loading that explosion every frame are you?

#5219915 From scratch vs Unity

Posted by on 28 March 2015 - 11:44 PM


 When you use an existing engine your creative freedom is confined to the engine designer's conception of what a game consists of. It's using a "solution". It is formulaic, and predictable because it is generalized to encompass common methods and techniques for producing a game experience. This is great for a few things, such as learning how games work and what goes on behind the scenes. Also it is great for someone with experience and know-how who can really 'work' an existing engine and produce something of professional quality in a time-efficient manner.


 Ultimately, those who do their own thing will be the ones who are most capable, and well-situated to actually make things move forward. They will evolve the conception of what a game can be, and then everybody will follow suit.


 Case-in-point: Minecraft popularized the voxel-esque block-world concept, and then suddenly everybody and their mom was making a block-world game. Correct me if I am wrong but I imagine that virtually all available engines at the time of Minecraft's development were confined to the world being some sort of heightmap or BSP tree. This is the type of limitation that stifles one's ability to think and create freely, outside the confines of someone else's idea of what a game is made of, or how it works.


 All-in-all, it comes down to preference. What someone wants to do, and how they want to do it.

#5212959 How do I know if I'm an intermediateprogramming level?

Posted by on 25 February 2015 - 02:50 PM


#5199377 A few general questions to point me in the right direction

Posted by on 21 December 2014 - 02:10 AM

the glow effect is usually either a part of a sprite texture (additively blend a blurred version with the texture) and then the texture is just rendered additively to the scene.


alternatively, for a more dynamic and 'present' glow a fragment shader is used, where the scene is rendered into a framebuffer texture and this texture is then fed into the shader via fullscreen quad, this shader then additively blends the original texels with blurred texels. typically a box-blur is used because of its speed (and thus, two passes for horizontal/vertical). Another approach is using the prefix sum via Summed Area Table (related http://docs.nvidia.com/gameworks/content/gameworkslibrary/graphicssamples/d3d_samples/d3dcomputefiltersample.htm)

#5199376 Compute Fog of war with unit Line-of-sight

Posted by on 21 December 2014 - 01:58 AM

 My first suggestion is to only check a fixed number of tiles per frame. Secondly, group units together that are near one-another using some clustering algorithm, and then use the largest visibility radius of those units to do the visibility check for all of them as if they are one unit. This will reduce what is mostly redundant checking.


 Thirdly, perhaps use a lower-resolution FOW map than what the actual map tiles are at. Maybe FOW tiles are 2x2 game tiles. This will speed everything up 4x. Using a separate map to represent FOW simplifies rendering as another pass over the scene.


 Oh, and another idea is not to trace lines from each unit to each tile, or vice-versa, but to find all occlusion-tiles (non-pathing tiles) and cast FOW 'shadows' outward from them away from units. This would basically be starting with all tiles within view radius, then subtract hidden tiles - instead of tracing lines to all of them. Make sure you don't cast FOW shadows into another unit's visible area, though.


 Good luck.





 A quick way to roughly check if one tile is within another's shadow is to use the dot product of the vector from the unit to the non-pathing tile and the vector from the unit to the tile you are checking for visibility. Check that the dot product of these two vectors is *close* to 1.0, in that, they are almost the same (but not demanding exact).. The more margin (epsilon?) you allow for, the less likely your FOW will have holes behind occluders, but the more likely that occluders will cast larger FOW 'shadows'. I hope this all makes sense.

#5197919 Weird particle lag?

Posted by on 12 December 2014 - 09:17 PM

enabling/disabling GL_VERTEX_ARRAY for each single particle is a red flag.


using individual VBOs for each particle is a red flag.


Update the positions of all your particles and dump that to a single VBO in a single glBufferSubData call. Then render all of them with one single DrawElements call. Doing all these state changes and stuff for each individual particle is not going to work.

#5195263 Super Cool Effects

Posted by on 28 November 2014 - 04:51 PM

particle systems and blending.

#5191742 Can't load .wav files with SDL

Posted by on 07 November 2014 - 07:21 PM

The Windows operating systems (Vista, Win7, Win8, etc...) by default hides the file extensions to prevent less computer-savvy users from accidentally changing the extension and confusing programs trying to open them.


I couldn't believe when they started doing this, I believe it was after 98/ME... and, yes, I used ME between 98 and XP, once upon a time.

#5191609 Can't load .wav files with SDL

Posted by on 06 November 2014 - 07:45 PM

Actually, the error message should be "Mix_LoadWAV_RW with NULL src", shouldn't it? Did you accidentally copy the error message wrong? wacko.png


Are you positive your filepath is correct? Could you post the filepath you are using? It seems to be saying it that Mix_LoadWAV() isn't even receiving the raw binary data from the file. It's not a parsing issue, or anything like that - it's not even getting the file data.


Try logprinting your fileName.c_str() to make sure it's correct.


In these cases sometimes I actually dive into SDL's actual code to see what causes certain errors.