Jump to content
Sign in to follow this  
scary_pigeon

what am I doing now?

Recommended Posts

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 by scary_pigeon

Share this post


Link to post
Share on other sites

Will the demo be released in a week?

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

 

:biggrin::biggrin::biggrin:

Edited by Berkut RnR

Share this post


Link to post
Share on other sites
Will the demo be released in a week?

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

 

:biggrin:  :biggrin:  :biggrin:

 

 

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
i think point 4 next, because that looks more fun.

 

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. :help:

Share this post


Link to post
Share on other sites
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.  :help:

 

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

Share this post


Link to post
Share on other sites

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:

 

roads.jpg

Share this post


Link to post
Share on other sites
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! :)

Share this post


Link to post
Share on other sites

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 by scary_pigeon

Share this post


Link to post
Share on other sites

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 by scary_pigeon

Share this post


Link to post
Share on other sites
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 by Dante-JT

Share this post


Link to post
Share on other sites

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 by scary_pigeon

Share this post


Link to post
Share on other sites
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 by Dante-JT

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Shadowcat

Share this post


Link to post
Share on other sites

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 by scary_pigeon

Share this post


Link to post
Share on other sites
'BEER O'CLOCK time' 'a bettrer one' '...undre'

 

 

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

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.usairbooze.gif

Edited by Aerny

Share this post


Link to post
Share on other sites

Awesome video Steve, much better than the previous one. :clapping:

 

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:

goosegreen_settlementWIP1.jpg

goosegreen_settlementWIP2.jpg

 

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":

Puente.jpg

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use, Privacy Policy, and We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue..