Stowelly

Members
  • Content count

    426
  • Joined

  • Last visited

Community Reputation

156 Neutral

About Stowelly

  • Rank
    Member
  1. Future of Gaming

    if you would like an insight into where hardware will likely go, here is a very good read from a reputable source.... Herb Sutter [url="http://herbsutter.com/welcome-to-the-jungle/"]http://herbsutter.com/welcome-to-the-jungle/[/url]
  2. What are the evils of "using namespace std;"

    it defeats the point of having namespaces in the first place, and makes your code harder to read, personally i think it makes more sense to std::string than just "string" as all that tells me is a object called string is being used, it doesn't tell me where abouts it has come from
  3. [quote name='way2lazy2care' timestamp='1308149590' post='4823623'] [quote name='Stowelly' timestamp='1308130086' post='4823553'] thank you for your reply, and that is a very nice solution to a top down method, however this is going to be a side on game with gravity down the Y axis. do you think that using particles, controlling the physics of them on each pipe until they reach a standstill and then maybe delete the particle replacing it with the tube filling up would work? the design may evolve to allowing the pipes to move at some point so after they have reached a standstill it may be necessary to turn them back into particles again, but i guess this would follow the same formula as filling the pipe up but in reverse? [/quote] If you have access to any GDC videos I think last year's (2010) Game physics for beginners focused mostly on fluid dynamics. It's a pretty straight forward problem despite it being complex. Pretty much you do exactly what conventional fluid dynamics formulas do and it just works. The problem being understanding the fluid dynamics formulas. Here's somewhere to start if you don't have access to the GDC vault: [url="http://www.gamasutra.com/view/feature/1549/practical_fluid_dynamics_part_1.php"]http://www.gamasutra...mics_part_1.php[/url] I think Jim Van Verth was the guy that ran the seminar, so there might be something on his website, which I do not know off hand. [/quote] sorry to be a pain, but the only thing that looked related to what you have said in the gdc members section from 2010 is "[url="http://www.gdcvault.com/search/results.php"]Go With the Flow! Fluid and Particle Physics in PixelJunk...[/url]" but that was by a completely different guy than who you mention. any idea of the exact title, or would you be able to private message me the link please? thanks
  4. Different Memory Address

    this isnt really the place for this sort of thing. but I will give you this link and then you are pretty much on your own http://www.ollydbg.de/
  5. Different Memory Address

    I think you are approaching it the wrong way. the memory will almost never be in the same location. you need to use some debugging tools to determine where the memory containing the values you want to modify is allocated, and at this point you store the address and should be able to manipulate however you want
  6. [quote name='way2lazy2care' timestamp='1308149590' post='4823623'] [quote name='Stowelly' timestamp='1308130086' post='4823553'] thank you for your reply, and that is a very nice solution to a top down method, however this is going to be a side on game with gravity down the Y axis. do you think that using particles, controlling the physics of them on each pipe until they reach a standstill and then maybe delete the particle replacing it with the tube filling up would work? the design may evolve to allowing the pipes to move at some point so after they have reached a standstill it may be necessary to turn them back into particles again, but i guess this would follow the same formula as filling the pipe up but in reverse? [/quote] If you have access to any GDC videos I think last year's (2010) Game physics for beginners focused mostly on fluid dynamics. It's a pretty straight forward problem despite it being complex. Pretty much you do exactly what conventional fluid dynamics formulas do and it just works. The problem being understanding the fluid dynamics formulas. Here's somewhere to start if you don't have access to the GDC vault: [url="http://www.gamasutra.com/view/feature/1549/practical_fluid_dynamics_part_1.php"]http://www.gamasutra...mics_part_1.php[/url] I think Jim Van Verth was the guy that ran the seminar, so there might be something on his website, which I do not know off hand. [/quote] thanks for your response, I will chase up whoever has our GDC login and hastle them to let me look at them!
  7. thank you for your reply, and that is a very nice solution to a top down method, however this is going to be a side on game with gravity down the Y axis. do you think that using particles, controlling the physics of them on each pipe until they reach a standstill and then maybe delete the particle replacing it with the tube filling up would work? the design may evolve to allowing the pipes to move at some point so after they have reached a standstill it may be necessary to turn them back into particles again, but i guess this would follow the same formula as filling the pipe up but in reverse?
  8. I think i may have solved it partially..... Particles!! if i represent the water as particles then it is a matter of performing the calculations per particle. however i guess i still need some input into using this idea, id imagine particles will need to be at a rest state at points where i dont want the physics to do any calculations on them, but then also need to respond to collisions from other particles. am i approaching this the right way? and does anyone have anything noteworthy on this subject to mention? thanks
  9. Hi I have decided to start a small side project for myself, a simple 2d game that involves liquid flowing through pipes. to start with I decided that I would use a tilemap based system with each tile representing a segmant of pipe, in order to make it easy for designers to be able to make new maps. now the pipes could be any shape causing the water to flow in different directions, i guess for now until i get some proper art these pipes will be constructed just using solid lines. the bit im having trouble with is, say I specify a start point for the fluid , what would be a good method to determine how to keep the fluid within the boundaries of the pipes and which direction they should flow in, trying to keep the design as flexible as possible, so if we wanted to have new types of pipe that could say invert direction or have a junction that could split the fluid into 2 different outputs etc. im sure there is a very simple solution for this but Im having trouble visualising how it could work. thanks for taking the time to read this
  10. Quote:Original post by phantom For starters I wouldn't use a 2D array; I'd use a 1D array sized as a 2D array. After that it's just a matter of filling the buffer quickly with the data; std::fill() or std::fill_n() would do the job. thanks. what does std::fill do differently than just itterating and assigning values to the elements. im trying to avoid any use of the stl in my app Quote:Original post by zacaj You should be able to use an SDL_Surface for it, since SDL sometimes has HD accelerated drawing. Otherwise, looping through manually is faster than memset Im using software only SDL for my app, but it does seem that sdl fill on a surface is much quicker than how I am doing it. may try that and benchmark it.... im assuming this will require me using fix point values for my Z buffer though Quote:Original post by ibebrett there is a trick you can pull if you are guaranteed to be redrawing over the whole screen every frame. store the z values signed. then on odd frames flip z values and change the z compare mode to larger (. this will work as a long as you are guaranteed to write over every pixel every frame. ah I do like this idea. im not drawing over every pixel, but i might be able to figure out a way of having multiple buffers and utilise it as part of my swap chain, as the back buffer gets cleared I could swap in the Z buffer for this and render to that next frame. hmm will have a think as it might be possible to get it almost for free this way Quote:Original post by Hodgman Modern graphics cards, as well as having the actual array of depth values, also have a quad-tree hierarchy on top of it. Each node in the hierarchy stores the min/max depth value in the cells below it and also has a flag specifying whether there are any values stored below it at all. Using this system, clearing the buffer only involves setting a flag on the root node ;) however, your ZReads and ZWrites obviously become more complex. this does sound a lot more complex than im willing to do for this. but if i cant gain any significant performance with other methods i might look into this. thanks alot for your help guys!
  11. Hi im writing a scanline based software rasterizer. and have just reached the stage of having Z buffered perspectively correct textured objects. and after some profiling its shown that the most significant amount of time spent in my program is in my clear z buffer routine which literally loops through and re initialises the array could anyone please give some suggestions on a better way to do this please? i did consider having 2 z buffers, with a seperate thread to clear the one not currently in use, but im sure there must be a better way, as im using SDL and the function to clear each frame doesnt show up anywhere near as high in my "time spent" [code] void Rasterizer::clear_z_buffer() { for(int i = 0; i < m_screen_width; ++i) { for(int j = 0; j < m_screen_height; ++j) { m_z_buffer[i][j] = 1.0f; } } } [\code] thank you!
  12. Small favour to ask

    well heres the cube in case anyones interested, or if someone searches for this thread (realised some of the uv's are duped, but is minor!) thanks # cube.obj # mtllib cube.mtl g cube v 0.0 0.0 0.0 v 0.0 0.0 1.0 v 0.0 1.0 0.0 v 0.0 1.0 1.0 v 1.0 0.0 0.0 v 1.0 0.0 1.0 v 1.0 1.0 0.0 v 1.0 1.0 1.0 vn 0.0 0.0 1.0 vn 0.0 0.0 -1.0 vn 0.0 1.0 0.0 vn 0.0 -1.0 0.0 vn 1.0 0.0 0.0 vn -1.0 0.0 0.0 vt 0.0 0.0 vt 0.0 1.0 vt 1.0 0.0 vt 1.0 1.0 vt 1.0 0.0 vt 0.0 1.0 usemtl material01 f 1/5/2 7/6/2 5/4/2 f 1/3/2 3/1/2 7/2/2 f 1/5/6 4/6/6 3/4/6 f 1/3/6 2/1/6 4/2/6 f 3/5/3 8/6/3 7/4/3 f 3/3/3 4/1/3 8/2/3 f 5/5/5 7/4/5 8/6/5 f 5/3/5 8/2/5 6/1/5 f 1/5/4 5/4/4 6/6/4 f 1/3/4 6/2/4 2/1/4 f 2/5/1 6/4/1 8/6/1 f 2/3/1 8/2/1 4/1/1
  13. Small favour to ask

    yeah the layout of the box isnt the problem, just didnt really know how to layout the UV's cheers, ill have a look at nehe
  14. Small favour to ask

    Hi, not sure if this is the correct section to ask, but im a programmer currently working on a software rasterizer, but unable to make any assets to test performance with etc I was wondering if there is anyone who would be kind enough to make me a cube made out of triangles that has a uv texture on it exported to .obj and .mtrl at all please? have tried using blender, but i really dont have a clue where to start with this, and im sure its only 2 mins work for someone who is capable of this! many thanks!
  15. New to programming need some help!

    do you have the full error message?