Build A World - new massive game, using Irrlicht

[devsh]

we're having issues with irrlicht's input on Linux, apparently different keyboards don't work

[Dareltibus]

O_O astonishing game

[devsh]

50 OpenGL Extensions later

we did another update (version 0.517)

and I have modified irrlicht in epic ways

-REMOVED THE EVIL IImage COPY WHEN CREATING TEXTURES (no redundant data in RAM)
-INTRODUCED HARDWARE TEXTURE COMPRESSION! (DDS loader which decompresses does not count)

-INTRODUCED 24 NEW ECF_ image formats!

[sodandk]

Update 15-05-2013
- books added
- numerous optimizations of the server
- powersystem bug fixed
- frozen mobs bug fixed
- new eat static soundtrack
- motionblur when user gets damage
- new constructiontool will let user take a construction. select tool and left click on a construction
- repairblock can be used to repair constructions
- lots of wierd construction blocks removed from inventory
- hit esc to close a blue window
- click g on a spawnpoint to activate it. several players can share same spawnpoint
- changed graphics for force field generator
- added country for the player when pressing tab
- force field blinking bug fixed
- added hardware texture compression
- explicit mip maps generated with the lanczos/sinc filter, of for uber high quality and faster load times
- fixed mutiple copies (irrlicht) of graphics in memory. cut 100Mb clean off of memory usage
- firesound bugs fixed
- windturbines sounds lower priority
- added all countries to the epay system
- did a lot of testing... on users maps

[hybrid]

and I have modified irrlicht in epic ways

-REMOVED THE EVIL IImage COPY WHEN CREATING TEXTURES (no redundant data in RAM)
-INTRODUCED HARDWARE TEXTURE COMPRESSION! (DDS loader which decompresses does not count)

Irrlicht also has full DDS texture support since a few weeks And if you provide additional texture handling in your app, then of course some automatisms in the engine can be avoided. But what about texture locking, do you create IImages then? And when do you remove them?

[devsh]

I said DDS loader does not count if it doesnt support texture compression in OpenGL/D3D, we also found out why the DDS loader failed to work on 64bit machines (your DDS header struct has a pointer in it which is 8 bytes on 64bit machines turning the entire thing into 132 bytes instead of 128 and that misaligns a lot of the data members)

OUR mod of the DDS loader removes the software decode (conversion into RGBA) because its pointless AND patent infringing (without a license from S3), if you feed the data to OGL its not a problem because OGL drivers have the license.

The loader also supports loading the mip maps (so you can save load time and have better mip mapping - lanczos filter)

We don't lock() textures, because this is an inferior part of the irrlicht engine (something imposed on the OpenGL implementation to mimic DirectX syntax and behaviour). We do all CPU<->GPU transfers with Asynchronous Texture Transfers (a few buffers inbetween to minimize CPU GPU stall) - in some cases this results in DMA.

[hendu]

As hybrid said, you have old info - the current DDS loader passes them compressed, including mipmaps.

[devsh]

the version in SVN?

[hendu]

Yes, trunk.

[devsh]

also we learned how to differentiate between DXT with RGB or RGBA data

Code: Select all

 
 
void DDSDecodePixelFormat( ddsBuffer *dds, eDDSPixelFormat *pf )
{
    /* dummy check */
    if( dds == NULL || pf == NULL )
        return;
 
    /* extract fourCC */
    const u32 fourCC = dds->pixelFormat.fourCC;
 
    /* test it */
    if( fourCC == 0 )
    {
        *pf = DDS_PF_ARGB8888;
    }
    else if( fourCC == *((u32*) "DXT1") )
    {
        if (dds->pixelFormat.privateFormatBitCount==24)
            *pf = DDS_PF_DXT1;
        else if (dds->pixelFormat.privateFormatBitCount==32)
            *pf = DDS_PF_DXT1_ALPHA;
    }
    else if( fourCC == *((u32*) "DXT2") )
        *pf = DDS_PF_DXT2;
    else if( fourCC == *((u32*) "DXT3") )
        *pf = DDS_PF_DXT3;
    else if( fourCC == *((u32*) "DXT4") )
        *pf = DDS_PF_DXT4;
    else if( fourCC == *((u32*) "DXT5") )
        *pf = DDS_PF_DXT5;
    else
        *pf = DDS_PF_UNKNOWN;
}
 

[hendu]

That's not big-endian safe, nor even buildable by strict compilers.

[devsh]

A) Not my code... this is original irrlicht code!!! The bit which is mine:

Code: Select all

if (dds->pixelFormat.privateFormatBitCount==24)
            *pf = DDS_PF_DXT1;
        else if (dds->pixelFormat.privateFormatBitCount==32)
            *pf = DDS_PF_DXT1_ALPHA;

A strict compiler would compile the above

The rest is all irrlicht... so you see

Anyway, who cares about Big Endian??? Srsly, who will play a game requiring 512mb of VRAM on a PowerPC MAC from 2006???

Before you start worrying about Big Endian compatibility, you better worry about supporting ARM!!!

Actually you may first worry about using linear search 3 times to find your occlusion queries (rofl)

[sodandk]

Epic Tunnel Construction

http://www.youtube.com/watch?v=7ZpZg7WjfeE

[hendu]

Not my code... this is original irrlicht code!!!

It sucks either case Your bit is fine.

Anyway, who cares about Big Endian??? Srsly, who will play a game requiring 512mb of VRAM on a PowerPC MAC from 2006???

Before you start worrying about Big Endian compatibility, you better worry about supporting ARM!!!

Many current ARM and MIPS chips do big-endian. It's not just old Macs.

Actually you may first worry about using linear search 3 times to find your occlusion queries (rofl)

I agree, that also sucks. I'm also doing only manual occlusion queries, not using them via irr.

[sodandk]