Sorry your browser is not supported!

Hello game creators, I some questions for the Dark GDK experts out there.

I was messing with the second tutorial and I used a #DStudio mesh as an object.

First issue is that I noticed that the result would maintain the same colors that you would see in a viewport of 3DStudio but they showed nearly NO shading at all to give a 3D appearance and they also showed NO mapping that I used withing the materials editor of 3DStudio that give a reflection look.

Does Dark GDK loose everything from the 3DStudio file or is there other ways to get those to show up in the final compilation in MSVC++ or do I need some other calls from the GDK hmmmmmm???

The second issue is that while the final item functions fine while compiling and debugging within MSVC++ when I close MSVC++ then go and simply double click on the execution file that MSVC++ created it maintains nothing more than a black screen. Thsi also happens with the terrain tutorial as well.

What am I doing wrong here to have that happen???

Thanks in advance.

CrypticDragon

I don't have much time right now, so only a short answer - in 3D studio the model is shaded with some special functions, you need to apply the same functions in your game to see the same result. Generally that's not an easy task, but GDK offers some such effects (like dbSetReflectionShadingOn etc.)



Are you sure you run the .exe in the same folder where the needed files (images/textures,models) are stored? I guess not.

Thanks, I was allready looking at that list...

dbSetLightMappingOn ( int iObject, int iImage )
dbSetDetailMappingOn ( int iObject, int iImage )
dbSetBlendMappingOn ( int iObject, int iImage, int iBlend )
dbSetSphereMappingOn ( int iObject, int iImage )
dbSetCubeMappingOn ( int iObject, int iFace1, int iFace2, int iFace3, int iFace4, int iFace5, int iFace6 )
dbSetBumpMappingOn ( int iObject, int iImage )
dbSetCartoonShadingOn ( int iObject, int iShadeImage, int iEdgeImage )
dbSetRainbowShadingOn ( int iObject, int iRainbow )
dbSetShadowShadingOn ( int iObject )
dbSetReflectionShadingOn ( int iObject )
dbSetAlphaMappingOn ( int iObject, int iPercentage )
dbSetEffectOn ( int iObject, char* szFXFile, int iTextureFlag )
dbSetShadingOff ( int iObject )

...they list some explanation for their use in a link. I would like to see an example for a few of them and others are pretty much self explanatory for us who have also been using 3DS and graphics software for many years. I guess I could play with each one and see how well they work at creating the same effect as the 3DS render engine.

I did purchase T.ED, 3DWorldStudio, Dark Shader, EZRotate, and Enhanced animation which should help me out a little bit. I did notice that mesh animations created on the 3DS objects will transfer over to DARK GDK.



That was my next try and yes, placing all of the files into the same directory as the EXE file solved the issue. This now creates another issue. While encryption is one my favorite areas in C++ and C# many who release a game will need to encrypt each of the files used since they need to placed in the same folder as the EXE or whatever sub folder used in the C++ coding. Encrypting the image and mesh files would be only to prevent another individual from theft of those image and mesh files. Of course the encrypted files would have to be loaded into RAM, then decrypted to the origional files in RAM, then the encrypted files would need to be deleted from the RAM to free up that memory for the software.

Is there a simple way to do this or do I need to create my own routine to run at the start of the game???

THANKS

CrypticDragon

no simple way for encryption... but a possibly easier way would be a utility that "looks" randomly changes all the verts around like a media scrambler, then you could "rebuild it" ... this would allow dbLoadObject("filename",objid) at least versus some other solution - reason is you can't LoadObject from a memory location, only a file, so you have some limitations there - decrypt in some weird place on user's machine - eventually they find it if they crash your program, OR save scrambled memblock "snapshots" of meshes and images, and in game load, unscramble etc. Or like I said obfusciate the actually media so you can still load them from disk with native commands - and just do some decrption depending how you scrambled em - and for what file type... DBO/Direct.x one way...maybe vert manipulation, images, maybe obscure xor algorythm, sound - random block of data rearranging would be funny - as your sound would play but be TOTALLY HOSED.

Just ideas...

Thanks,

Your right, we can only do a call to the GDK such as...

dbLoadObject( char* szFilename, int iObject )

...or any of the other calls to load files. The only way around that which in essence could defeat the purpose would be to to create a routine that loads just before the GDK call. It would load the encrypted file, which is NOT a standard filename or extension (i.e.file432.jjsjr), to RAM, decrypt the encrypted file to an array of characters or integers 0 to 255 within RAM, write the decryted characters or integers to the correct filename on the hardrive, then do the call dbLoadObject, then the IMPORTANT part MULTISHRED and DELETE the correct filename from the hardrive. This would be a longer required load time for the program but I have seen several games that seem to take a long time to load such as a game called Ballistics. I noticed that all of their files are .wav, .dds, or .diesel extensions. That leaves their .wav files wide open for sure. I guess you can always create little animations that give the illusion of the program loading.

I think your idea of obfuscation sounds good since obfuscation is sort of an encryption idea and it possibly could take less time to load the final program at start up. It would be better than just leaving the files there for anybody to take and use or modify.

Maybe in the future the GDK folks could create an area that loads any file name to RAM and gives us the ability to write our own decryption. The files would be encrypted before the game releases so that is not a problem. Then they could allow us to load the correct file string of chars or integers 0 to 255 values to the GDK system from a simple array. Just a guess but I would think that within the GDK once you load a file name it probably places the integer value of each 8 bit char 0 to 255 into an integer array possibly.

CrypticDragon

CrypticDragon