what am I doing now?

[scary_pigeon 0]

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.

Edited September 16, 2005 by scary_pigeon

[Shadowcat 0]

That sounds like a good sort of middle-ground. Thanks for the reply!

[Berkut RnR 0]

Will the demo be released in a week?

Is that true? It's Awesome!!!!

 

Edited September 16, 2005 by Berkut RnR

[scary_pigeon 0]

Will the demo be released in a week?

Is that true? It's Awesome!!!!

 

   

<{POST_SNAPBACK}>

 

 

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.

[+Dante-JT 6]

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

 

 

Maybe give priority to the issue above, can't stay flying for more than 10 minutes because Windows says "page file is being increased, some programs may have access denied to page file while its increased..." JT client is one of these programs, and so it closes.

[scary_pigeon 0]

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

[+Dante-JT 6]

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

<{POST_SNAPBACK}>

 

Ah, Ok.

 

The problem with point 3, is that its quite hard to test the whole (larger) terrain I'm inserting now, because client closes due to memory issue before I reach the far edges of the island. Probably will be even worse with roads. Maybe I should alter my initial spawn position to test the far alway regions, but this seens like a palliative.

[scary_pigeon 0]

Ah, Ok.

 

The problem with point 3, is that its quite hard to test the whole (larger) terrain I'm inserting now, because client closes due to memory issue before I reach the far edges of the island. Probably will be even worse with roads. Maybe I should alter my initial spawn position to test the far alway regions, but this seens like a palliative. 

<{POST_SNAPBACK}>

 

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

[scary_pigeon 0]

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:

 

[Guest |d13m0b]

Looking forward to try out the demo when you get it released. It's great to see that your progress is so persistent and result of quality! :)

[scary_pigeon 0]

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.

Edited September 21, 2005 by scary_pigeon

[scary_pigeon 0]

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.

Edited September 21, 2005 by scary_pigeon

[+Dante-JT 6]

hmm. the plot thickens, ive added texture compression and the memory footprint stayed the same.

 

Maybe the textures need to be compressed as well instead of staying as TGAs as they are now - in Taikodom for example, we have to open textures in Photoshop and save them as .dds compressed file format. The memory footprint went to less than a third of what it was before.

 

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

 

Check this:

OpenGL's answer to this situation is texture priorities. A single function call, glPrioritizeTextures(), is all that is required, and it works with texture objects.

 

void glPrioritizeTextures(GLsizei n, GLuint *textures, GLclampf *priorities);

 

This function lets you tell OpenGL which texture objects are the most important to keep in graphics memory.

 

Explained in Gamasutra article "Texture Priorities"

http://www.gamasutra.com/features/19990723..._objects_07.htm

 

 

 

- but something else is taking up lots of memory.

 

That's really strange. Probably related to that bullets/memory leak?

Edited September 21, 2005 by Dante-JT

[scary_pigeon 0]

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.

Edited September 21, 2005 by scary_pigeon

[+Dante-JT 6]

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.

 

Stutter reduction is also a very desirable effect of the use of texture compression.

 

EDIT: he just said too that if you load the textures as TGA then compress it, as you probably is doing, you will end up using more or less the same memory as before (bad). You must load the textures already compressed - either in .dds or whatever other texture file format compression, to make it work as it should do.

 

again when disable the texture loader routines the memory footprint remains the same.

 

According to a Hoplon programmer here (we're talking about the issue), Taikodom for example, had an absurd memory footprint of more than 1Gb. It was a must to reduce it to be able to run normally in a PC with 256 MB. Texture compression played a big role in this massive reduction but he said there is other things involved like discharging textures/managing whats needed and what is not and other specifics.

 

They completed the goal and now Taikodom had its memory footprint reduced from 1Gb to around 256 MB. They could help us in that matter.

 

 

 

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.

 

Around 15x .asc terrain meshs of around 500kb average - would increase only 7.5 MB of the memory footprint, so as you say, seems improbable really.

Edited September 21, 2005 by Dante-JT

[scary_pigeon 0]

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.

[scary_pigeon 0]

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.

[Shadowcat 0]

Such comments always remind me of this, from the postmortem of "Heavy Gear 2" at Gamasutra:

The Darkside engine created specifically for Heavy Gear II was an engineering gem. Although game players get a solid dose of its extraordinary graphics and animation capabilities, at its core it is nothing but a simple memory manager and leak tracker. This property of the engine allowed the programmers to track down and remedy most of the nastier bugs in the game long before it hit the QA floor. Beyond its concrete foundation, its modular design and expert use of C++ made it a snap to add or delete the different systems we wished to experiment with. Most of the foundation code and graphics subsystem was shared with our 3D layout tool, saving us a ton of extra work. This extensibility and proper use of the C++ language was invaluable as we faced a deluge of changing design requirements and additional game features.

Edited September 22, 2005 by Shadowcat

[scary_pigeon 0]

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

Edited September 24, 2005 by scary_pigeon

[scary_pigeon 0]

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

[Aerny 0]

'BEER O'CLOCK time' 'a bettrer one' '...undre'

 

 

Sure, which such a hurry like you where under attack, man!

Kiep op de koed wurk! LOL

 

Joking appart: Nice video! The debris was a bit slow in my opinion but I am sure you are going to work that out later. (?)

 

Cheers,

 

 

Aerny

 

P.S. so... do you know him? Sorry for the rubbish.

Edited October 3, 2005 by Aerny

[+Crusader 2,101]

nice video :) the working HUD looks good

[scary_pigeon 0]

a beter one - bits that are falling off given different velocities and stuff -looks mroe interesting

 

http://thunder-works.com/img/bitshi.avi

[+Dante-JT 6]

Awesome video Steve, much better than the previous one.

 

As for myself, I've been busy lately creating the first settlement of the islands, and an important one: Darwin/Goose Green settlement (Pradaria del Ganso), where the first major land battle occured (and both sides used their aviation in CAS role); below first tests I'm doing of the settlement position (map accurate) and overall look:

 

In Argentina, Ariel Cancio is modelling one of our first 'landmarks', the Bodie Creek Bridge, which is situated a few miles south of Goose Green and is considered now a tourist stop as "one of the southernmost suspension bridges in the world":

Lenght, width and height of towers are accurate based on info we researched. This chap here got a few interesting photos he took:

http://www.kpadgett.org.uk/falklands/Pages/bodie.htm

[scary_pigeon 0]

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.