scary_pigeon

perhaps a statistical model to model that dependent on speed and apparant motion from the view of the target.

soon

screenshots arent doctored. -- recently we had some trouble with collision detection. things working perfectly on my computer and then inforiating and depressingly failing on dantes despite various versions. It turned out that i was sending him an old exe as i had changed the folder in which the compiler compiled to. And had forgotten about the change.

maths today. its some time since i did calculus.

going to get this bullet collision sorted firstly.

oh you fixed it? well done.

yes, he always has problems with that email. my latest news is that i've been playing guild wars far too much and I've had to tear myself away from it to do some much needed JT development. the current focus codewise for me is object bullet collision detection. the slow down that occurs when bullets come withing test range of the object can nolonger be ignored. its long overdue this area of optmisation. from my trips in Guild Wars some virtual lovers loving: me and my wives: maybe one day thunder-works will do a RPG. we have a Load on demand terrain system that can handle caves and such - and server-client handled load on demand player/agent and object system. just a brain fart.

i keep playing guild wars. i will try to do a few hours coding before bed. the current coding aim is to optimise bullet collision detection code.

well normal glass actually is about 50% transparent or so i remember - but yeah, i think the canopy reflection might be a tad overdone.

a beter one - bits that are falling off given different velocities and stuff -looks mroe interesting http://thunder-works.com/img/bitshi.avi

there is now a movie - i was not able to as it was approaching BEER O'CLOCK time, saturday night. to produce a bettrer one. but the effect can been seen of objects breaking off undre impact of missile. movie: http://www.thunder-works.com/img/wipsept242005hi.avi

and even more memory clean up. at the moment, embarrasingly every bullet or particle created takes up memory - and when it is no longer needed, is kept in memory unused. looking into that. latest pebbles. 1) terrain/object physics interaction. for some reason my plane when it hits the ground isnt behaving entirely convincingly. 2) the ability to shoot down other objects with missiles. technically thats already there, i once fired a missile and saw that the tail of another plane was shot off - but it still carried on flying - behaviour scripts need writing and tweaking on that score. do this tomorrow 3) make memory footprint smaller: means use of texture compression/deallocation of textures. at the moment the page file continues to expand as more terrains are loaded. in the past this was fine because ever large landscape wide texture was a general one, now they are terrain specific/ DONE 4) addition of roads (to later be followed by junction waypoint program to enable ground vehicles to navigate terrain) DONE 5) creation of decent user interface that comprehends aircraft despawning and point scoring. wondering if we can get the hyperlobby guy to add on Jet Thunder for beta purposes

as skorpion said. i am in england, dante is in brazil. a lot of our research flight manuals and photos were got by some spies in argentina.

well today, i fixed some quite bad memory leaks that would lead the game to freezing within 10-20 minutes. the next step is to clean up some more code, more memory related stuff. For a while I have often treated c++ like java - that is, pretend memory leaks dont exist.

u've got format of file, and internal format for texture. jpgs, dds's they're unfolded out raw, then placed in a texture in some internal format - then that memory that is no longer needed is freed. i will try disabling display lists - see if that does something. because right now, with textures dissabled, thats the only thing thats happening.

i will sometimes fly around without shooting anything. and the use of uncompressed tga's wont make any difference other than induce a larger stutter as the larger file is loaded- the image data is then dumped - and a separate graphics memory/system memory area is used to store the texture in whatever internal format is used. again when disable the texture loader routines the memory footprint remains the same. so im a bit stumped. graphic wise the thing thats staying the same as before and after texture on and texture off test - is display lists. I wonder if our fairly large terrains and objects result in large display lists. i can test that by switching off display lists for terrain (we get blank screen then) if memory footprint continues to grow at huge rates, then it is terrain mesh related- but that seems improbable.

hmm. the plot thickens, ive added texture compression and the memory footprint stayed the same. i even tried dissabling texture loading and the memory footprint continued more or less as before. this suggests that all textures are currently fitting withing my gfx card memory - but something else is taking up lots of memory.

nice comment idle. genious programmer that you are: i dont suppose you know how to add texture compression into a glut program. I've done it before in win32 apps, but supprisingly perhaps from the screenshots - I havent got a clue what i'm doing. most of its trial and error and half understood code ripped from various tutorials. i'll be taking a look at this as soon as stop procrastinating. thats point 3 - in that stuff needed for demo listed above.

for the online demo, I perceive only a few hurdles: 1) terrain/object physics interaction. for some reason my plane when it hits the ground isnt behaving entirely convincingly. 2) the ability to shoot down other objects with missiles. technically thats already there, i once fired a missile and saw that the tail of another plane was shot off - but it still carried on flying - behaviour scripts need writing and tweaking on that score. 3) make memory footprint smaller: means use of texture compression/deallocation of textures. at the moment the page file continues to expand as more terrains are loaded. in the past this was fine because ever large landscape wide texture was a general one, now they are terrain specific/ 4) addition of roads (to later be followed by junction waypoint program to enable ground vehicles to navigate terrain) 5) creation of decent user interface that comprehends aircraft despawning and point scoring. step 4 done. as a test:

for now, change the spawn locations in the server script. that might help you.

i think point 4 next, because that looks more fun.

that would be awsome wouldnt it? i've a week of work to work on it solid - dont know if i'll get all the major points done - then we might not want to potentially embarras ourselves with bad code and things so demo will be betad in some way.

it is there and it isnt. its supposed to be damage affects fm. but its not coded yet. our fm is controlled in a lua script file. and on the C side when damage occurs a luafunction is called applydamage(subobjectid,amountofdamage) or something like that - but the damage functions are empty at the moment as I've not got round to putting anything in them. but you can consider it concrete. there is no 1990's bubble collision detections for us and knocking off a wing will have expected consequences. there is a bit of a can of worms in some ways though. how do realistically model bullet strikes that go penetrate the objects armor - such that it is - and then hits a critical component? that is probably the sort of thing you will see in the like of latest IL2 derived project, the battle of britain thing? instead for us - collisions on particular subobjects, like fragments of the wing will probabilitistically be linked to component failiors we think are present at the site of that general impact area. so strikies on the fusalage of a fighter will provide a chance of damaging the engine in some way - and wing areas where we think fuel tanks are - of leaks and fires. oh and as each component suffers insults, it switches to different textures before falling off.

i was just thinking about that. im in uk, dante is in brazil - we send each other files but sometimes not entirely sure at what stage each is at. I'm not sure what his level of development is for the other cockpits. Easiest will be the electronically lacking pucara or skyhawk pit. a mirage vs sea harrier match up might have been interesting. the online demo is the easy one i think. What scares me still is our promise on the dynamic campaign. single player means gameworld complexity. online demo just means take off and pwn.

for the online demo, I perceive only a few hurdles: 1) terrain/object physics interaction. for some reason my plane when it hits the ground isnt behaving entirely convincingly. 2) the ability to shoot down other objects with missiles. technically thats already there, i once fired a missile and saw that the tail of another plane was shot off - but it still carried on flying - behaviour scripts need writing and tweaking on that score. 3) make memory footprint smaller: means use of texture compression/deallocation of textures. at the moment the page file continues to expand as more terrains are loaded. in the past this was fine because ever large landscape wide texture was a general one, now they are terrain specific/ 4) addition of roads (to later be followed by junction waypoint program to enable ground vehicles to navigate terrain) 5) creation of decent user interface that comprehends aircraft despawning and point scoring. i have a week off work to work on this.