a few questions about pro

Posted By: Reconnoiter

a few questions about pro - 01/16/15 16:44

Howdy,

I am thinking about upgrading from commercial to pro but was wondering about the following:

- Scene manager, how good it is? Does it work only for blocks? Or also for models and terrain?

- Under the tab 'version' under 'Shaders' is listed that pro has +compiler, what does '+compiler' mean?

- Is the resource packer any good? (to 'hide' models & textures etc.)

- Can the starting screen (that white window) be changed entirely?

Thanks alot as always.
Posted By: Kartoffel

Re: a few questions about pro - 01/16/15 17:04

1: no idea
2: it means you can compile shaders as .fxo files, i think
3: well it's definitely not secure, but normal users shouldn't be able to access your stuff
4: again no idea, but I don't think so
Posted By: Reconnoiter

Re: a few questions about pro - 01/16/15 20:59

Thanks Kartoffel laugh , anyone know the answer to question 1 and 4? I know the starting screen can be edited a bit through a wdl iirc but I want to know if it can be changed alot.
Posted By: Superku

Re: a few questions about pro - 01/16/15 23:27

1. Do you mean the BSP tree? It used to be the default tree in prior acknex versions and is well suited for (mostly) indoor or oldschool shooters and games like Doom, Quake, Forsaken/ Descent and similar.
The region_set feature is nice though, especially for suppressing stuff like content in a house when the player is outside of it.

2. The shader pre-compiler is pretty useful and should be used for any final release. You can then simply use the *.fxo instead of the *.fx files for your material effects and the shaders will not be compiled on the fly each time you run the game (which can take up to several seconds, depending on the shader complexity).

3. There are some limitations like not being able to use file_... instructions on files in the *.wrs resource but apart from that there's no reason to not use it. I find it way more "professional" too to only have one or multiple *.wrs files instead of all your game resources lying there in some data subfolder.

4. The starter definition is a joke by modern standards, it's from old A4 days but you can do some simple stuff with it (preferably hiding it I guess).
Posted By: HeelX

Re: a few questions about pro - 01/17/15 09:57

Scene Management:

The ABT (Adaptive Binary Tree) scene manager does the job very well I think, given that it calculates the scene tree during runtime. It was mainly designed for model/terrain based outdoor scenes, because outdoor stuff was a huge pain in the ass with BSP - where the scene tree was precalculated, and for open areas it simply sucked because you usually had "just one" scene node.. no optimization done.

The thing is, all versions below pro use actually ABT trees for rendering - so if you would upgrade to PRO, scene management would be only a valid consideration if you are doing indoor scenes and want to switch to BSP wink

Shader Compiler:

It only works for "static" shaders... some of the shader packages here do some sort of dynamic compilation of shaders to be more flexible. I know that my SSAO solution does this, and I am not sure if it is done in Shade-C. But most regular shaders can be compiled. The returned FXO files are the already compiled shaders and they are just dumped into memory - hence the faster loading speed. You can also put them into WRS files... so this is a nice thing, really.

WRS files:

Some people claim that they can hack the WRS format and I know only two people here that had success with it. However, the thing is: if someone is really into hacking your game, he will succeed. And: If you really throw in strong encryption... it might be harder to hack your stuff, but your game has to encode it as welll, which makes it slower, and it needs maybe more memory and so on.

For instance, a lot if the popular, major AAA games in which content is "encoded" or stored in proprietary formats... they all get "hacked" sooner or later and then they have an active modding scene.

I really share the opinion of Superku.

One additional remark: you can select WRS files during runtime, which enables the following possibilities:

- LOCALIZATION: write a function "STRING* get_lang_str(STRING* key)" and store your strings etc. into files which can be read from WRS. Then, put all your string content depending on the language into multiple WRS files "lang_en.wrs", "lang_de.wrs", "lang_fr.wrs", etc... and use add_resource to load the WRS file for the desired language

- TEXTURE QUALITY: generate from your hi-res textures medium and low quality versions and put them into WRS files "tex_hi.wrs", "tex_med.wrs" and "tex_lo.wrs" ... because they all have the same filenames, but you load the WRS depending on the user choice, you can dynamically change texture quality and therefore memory footprint by switching WRS files

- UPDATES / PATCHES: when delivering a new patch you simply have to update the EXE file for code patches or just a WRS for content patches

Using one WRS file to put all your content into one single encoded file is maybe the most used approach here, but if you combine it with add_resource and the fact, that different WRS files can contain files with the same name, you can really do advanced stuff! Very recommended!

Starter Screen:

It is very unprofessional to show the default splashscreen, yes. - But if you are using "static" resources like SOUND* m = "mymusic.ogg" and such, the engine loads it on startup, and when it takes longer, it is *very nice* to have a feedback about this. So putting an image of your game on the screen and showing the progress bar is a nice thing to have.

On the other hand, games should be written (in my oppinion) that all content is loaded during runtime and/or streamed ... because it just feels better to click that EXE and -voila!- the game is there, full screen and already running. So, in that case I would like to disable the starter window.

In any case, it makes sense to buy pro just to do this when releasing demos/the full game to the public for the sake of "polishness".
Posted By: Iglarion

Re: a few questions about pro - 01/17/15 10:34

I can't agree with Kartoffel that the packer is so insecure. Of course nothing is secure, but for all these years i still have not heard that someone broke wrs. I think that at one time when 3DGS was very popular, JCL even offered a reward for this. So from that side there is no reason to worry. There is one theory that if you know full file name you can take away this file from wrs, but i do not think that these are things that should worry us. Most important thing is compression level is great (lets say my 2GB game is resized to 400mb) and you do not need search and select all files you need. Simply packer read names from wmp and script and put them in wrs with one click. All files that are not used will be ignored. Also there no difference betwen loading time in unpacked and packed game.

Edit:
Ok i just hear from HeelX that someone hack wrs. One man is JCL but i do not know who is second smile

Quote:
...it makes sense to buy pro just to do this when releasing demos/the full game to the public for the sake of "polishness".
+1
Posted By: Kartoffel

Re: a few questions about pro - 01/17/15 11:02

I think it was MQ32 or Chaosscoder who managed to get game files out of a packed resource.

Also you can easily get the textures or meshes by exporting them at runtime, which even works with AAA titles because there's no way to prevent that.

The same counts for shaders, however, if you compile your shaders you can only access the compiled D3D assembly code which is pretty much useless for people that want to know how your shaders work wink
Posted By: Iglarion

Re: a few questions about pro - 01/17/15 11:17

Quote:
Also you can easily get the textures or meshes by exporting them at runtime, which even works with AAA titles because there's no way to prevent that

Hmm i dont think so. Most of AAA titles use packer who not write files on HDD but in memory, like 3dgs packer do. Yes there are some packers around here who export files on HDD and later when game is closed this files was delated, but this is not the case here. Export one file from wrs with engine function or some hack utility is bit different of hack complete wrs and get away all files including animated models.
Posted By: Kartoffel

Re: a few questions about pro - 01/17/15 11:18

uhm.. I'll show you in 10min
Posted By: Iglarion

Re: a few questions about pro - 01/17/15 11:21

Ok thanks, maybe i miss something but this is very interesting topic.
Posted By: Kartoffel

Re: a few questions about pro - 01/17/15 11:37

so.. here's some stuff from the ue4 elemental demo:



What I want to say with this is that you can access everything thats loaded into the ram at runtime and monitor every single drawcall.

Edit: so as long as you don't encrypt your textures & meshes and decrypt them everytime you need the information by using vertex and pixel shaders you can't make your stuff unaccessible grin
Posted By: Reconnoiter

Re: a few questions about pro - 01/17/15 11:57

Thanks that was alot of usefull information!

Quote:
1. Do you mean the BSP tree? It used to be the default tree in prior acknex versions and is well suited for (mostly) indoor or oldschool shooters and games like Doom, Quake, Forsaken/ Descent and similar.
The region_set feature is nice though, especially for suppressing stuff like content in a house when the player is outside of it.
, yes the BSP and portals ( scene manager ), I was wondering if it could be used for preplaced models too, but its only for blocks right? I am working on a own realtime map editor (but no WED placed block support I think but it does have WED-like compiling) and its hard to get back to WED grin .

Quote:
4. The starter definition is a joke by modern standards, it's from old A4 days but you can do some simple stuff with it (preferably hiding it I guess).
, so using a simple script made in e.g. visual studio is the only way to overhaul it? I need to change it for some program. For games I can live with it, but for programs its just really awkward.

Quote:
One additional remark: you can select WRS files during runtime, which enables the following possibilities:
, that sounds really handy. I don't mind if the best hackers out there can hack it, just as long as it protects against most c&p people I am happy laugh .



Posted By: Quad

Re: a few questions about pro - 01/17/15 15:42

off-topic: I have a wrs unpacker for a6 and a7 wrs files in source code format(not public, not planning to share) i wrote a couple of years back sitting on my hdd somewhere.
Posted By: alibaba

Re: a few questions about pro - 01/17/15 15:47

Off-Topic2: Also possible with QuickBMS
Posted By: Superku

Re: a few questions about pro - 01/17/15 15:59

It doesn't make a difference whether or not WRS unpackers exist, as already mentioned multiple times before in this thread you can "hack" any game and extract resources. They - the "hackers" - are not allowed to use your stuff anyway.

@Reconnoiter: The so called portals are generated automatically by the map compiler and used by the BSP tree but only for WED blocks, yes.
Posted By: alibaba

Re: a few questions about pro - 01/17/15 16:14

Just trying to keep the forum alive grin
Posted By: Ch40zzC0d3r

Re: a few questions about pro - 01/17/15 16:37

First 4 bytes of a WRS telling you which WRS format it is.
A8 uses WRS4 (0x57 0x52 0x53 0x34), followed by 32 bytes for the name.
Now, thats the header of the file. How do we decrypt it?
After every 32 bytes, the name of the file follows.
Now we simply XOR all the data content by the value 0xAA for WRS4.
This works for every gamestudio WRS packer since A4.
The only thing changed was the XOR byte.
Pro: XOR is fast
Con: Why not change the XOR bytes with the current reading offset? Thats so easy to reverse..
Would take some more time to figure out...
Seriously, just pack a .exe in WRS and look at the first 2 bytes (always MZ, called PE Signature)
Now you can simply figure out which byte was used to xor (simple math)
Posted By: Reconnoiter

Re: a few questions about pro - 01/17/15 18:35

@Superku, thanks for the info.
Its a shame it actually does not work for preplaced models/terrain. Could it in theory be possible?
Or are blocks just to different from models?
Posted By: WretchedSid

Re: a few questions about pro - 01/17/15 20:50

Originally Posted By: Ch40zzC0d3r
Why not change the XOR bytes with the current reading offset? Thats so easy to reverse..
Would take some more time to figure out...

Because to make it effectively secure you need a key of the length of the content, and the key can't be ever shared with anyone you don't trust. This would essentially be a one time pad. It would also be useless, because you either share the key and obfuscate it in your binary somewhere but have it still accessible to unpack your data, or you don't and your users won't be able to play the game anymore.

It really boils down to the following: At some point you have to access the data on the client machine. So the application itself has to somehow be able to unpack them.

You can obfuscate it, or do hacks like having a slave .exe that launches your actual .exe and attaches itself as a silent debugger to it. Windows only allows one debugger attached per application, so it makes it harder for third party to attach a real debugger and watch the execution of your program.

Really, the only reason you probably want encryption and resource packs is for updates: Sign your resource packs cryptographically and check the signature at runtime. That way you can at least make sure that no one is supplying malicious updates to the user.
Posted By: Ch40zzC0d3r

Re: a few questions about pro - 01/17/15 21:29

Originally Posted By: WretchedSid
Because to make it effectively secure you need a key of the length of the content, and the key can't be ever shared with anyone you don't trust. This would essentially be a one time pad. It would also be useless, because you either share the key and obfuscate it in your binary somewhere but have it still accessible to unpack your data, or you don't and your users won't be able to play the game anymore.

It really boils down to the following: At some point you have to access the data on the client machine. So the application itself has to somehow be able to unpack them.

You can obfuscate it, or do hacks like having a slave .exe that launches your actual .exe and attaches itself as a silent debugger to it. Windows only allows one debugger attached per application, so it makes it harder for third party to attach a real debugger and watch the execution of your program.

Really, the only reason you probably want encryption and resource packs is for updates: Sign your resource packs cryptographically and check the signature at runtime. That way you can at least make sure that no one is supplying malicious updates to the user.


Well your completely right here.
But most people wont even try to decrypt the file when they notice that the encryption is not only xored by a byte or dword.
All Im saying is to make it a bit harder for those people out there tongue
Btw, you can detach a debugger from a process.
Posted By: LemmyTheSlayer

Re: a few questions about pro - 01/18/15 10:07

You don't actually need pro's resource packer:
http://www.opserver.de/ubb7/ubbthreads.php?ubb=showflat&Number=376045&page=1

And for shader compilation you can use the fxc.exe from the latest Directx 9 SDK
or write your own compiler (call the function D3DCompile from the D3DCompile_**.dll. It's surprisingly easy)
Posted By: Reconnoiter

Re: a few questions about pro - 01/18/15 12:27

Hi Lemmy,

Thanks but I get a 'nicht gefunden' /not found error.
Posted By: LemmyTheSlayer

Re: a few questions about pro - 01/18/15 14:19

I'll see if i can find a copy on my hard drive

Edit:
I found a slightly modified version i made some time ago. It requires a zlib1.dll for compression.
Click to reveal..

Code:
/*
Filepacker script based on the super simple filepacker by Thomas Oppl
Usage:
	Create resource file:
	FILE* <file pointer> = fopen("<file name>", "wb");
	
	Add a file:
	addfile(<resource file pointer>,"<name of file to be added>");
	
	Don't forget to use fclose(<file pointer>) after adding all files!
	
	Load a resource into the engine buffer:
	loadresources("<resource file name>");
	
*/

#include <acknex.h>
#include <stdio.h>

int compress(byte *dest, long *destlen, const byte *source, long sourcelen);
API(compress, zlib1)

int compress2(byte *dest, long *destlen, const byte *source, long sourcelen, int level);
API(compress2, zlib1)

int uncompress(byte *dest, long *destlen, const byte *source, long sourcelen);
API(uncompress, zlib1)

void encipher(unsigned int num_rounds, unsigned long *v, unsigned long *k) // 64-bit block feistel network with a 128-bit key
{
	unsigned long v0 = v[0], v1 = v[1], i;
	unsigned long sum = 0, delta = 0x9E3779B9;
	for(i = 0; i < num_rounds; i++)
	{
		v0 += (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
		sum += delta;
		v1 += (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum >> 11) & 3]);
	}
	v[0] = v0; v[1] = v1;
}

void decipher(unsigned int num_rounds, unsigned long* v, unsigned long* k) // 64-bit block feistel network with a 128-bit key
{
    unsigned long v0 = v[0], v1 = v[1], i;
    unsigned long delta = 0x9E3779B9, sum = delta * num_rounds;
    for(i = 0; i < num_rounds; i++)
    {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + k[(sum >> 11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + k[sum & 3]);
    }
    
    v[0] = v0; v[1] = v1;
}

void encipherbuffer(char *buffer, long Size)
{
	unsigned long key[4] = {15671, 176, 807912, 235807};
	long offset = 0;
	while(offset < Size - 8)
	{
		encipher(64, (unsigned long*)(buffer + offset), key);
		offset += 8;
	}
}

void decipherbuffer(char *buffer, long Size)
{
	unsigned long key[4] = {15671, 176, 807912, 235807};
	long offset = 0;
	while(offset < Size - 8)
	{
		decipher(64, (unsigned long*)(buffer + offset), key);
		offset += 8;
	}	
}

void addfile(FILE *fp, char *filename)
{
	long Size;
	char *buffer = file_load(filename, NULL, &Size);
	
	long compressedsize = (Size + 12) * 1.1; // must be a bit bigger than the source buffer
	char *compressedbuffer = (char*)sys_malloc(sizeof(char) * compressedsize);
	
	compress2(compressedbuffer, &compressedsize, buffer,Size,9);
	printf("\nname: %s | size: %d | compressedsize: %d", filename,Size, compressedsize);
	
	encipherbuffer(compressedbuffer, compressedsize);
	
	long length = str_len(filename);
	
	fwrite(&length, sizeof(long), 1, fp);
	fwrite(filename, sizeof(char) * length, 1, fp);
	fwrite(&Size, sizeof(long), 1, fp);
	fwrite(&compressedsize, sizeof(long), 1, fp);
	fwrite(compressedbuffer, sizeof(char) * compressedsize, 1, fp);
	
	sys_free(buffer);
	sys_free(compressedbuffer);
}

void loadresources(char *filename)
{
	FILE *fp = fopen(filename, "rb");
	if(!fp) {error("couldn't open file!"); return;}

	long length;
	while(fread(&length, sizeof(long), 1, fp)) // while not eof
	{	
		char *name = (char*)sys_malloc(sizeof(char) * (length + 1));
		fread(name, sizeof(char) * length, 1, fp);
		name[length] = 0; // termination
		
		long Size;
		fread(&Size, sizeof(long), 1, fp);
		long compressedsize;
		fread(&compressedsize, sizeof(long), 1, fp);
		
		char *compressedbuffer = (char*)sys_malloc(sizeof(char) * compressedsize);
		fread(compressedbuffer, sizeof(char) * compressedsize, 1, fp);
		
		//printf("name: %s | size: %d | compressedsize: %d", name, Size, compressedsize);
		
		decipherbuffer(compressedbuffer, compressedsize);
		
		char *buffer = (char*)sys_malloc(sizeof(char) * Size);
		uncompress(buffer, Size, compressedbuffer, compressedsize);
		add_buffer(name, buffer, Size);
		
		sys_free(name);
		sys_free(compressedbuffer);
	}

	fclose(fp);
}

void loadresources_file(char *resourcename, char* filename)
{
	FILE *fp = fopen(resourcename, "rb");
	if(!fp) {error("couldn't open file!"); return;}

	long length;
	while(fread(&length, sizeof(long), 1, fp)) // while not eof
	{	
		char *name = (char*)sys_malloc(sizeof(char) * (length + 1));
		fread(name, sizeof(char) * length, 1, fp);
		name[length] = 0; // termination
		
		if(!str_cmpi(filename,name))
		{
		   sys_free(name);
		   continue;
		}
		
		long Size;
		fread(&Size, sizeof(long), 1, fp);
		long compressedsize;
		fread(&compressedsize, sizeof(long), 1, fp);
		
		char *compressedbuffer = (char*)sys_malloc(sizeof(char) * compressedsize);
		fread(compressedbuffer, sizeof(char) * compressedsize, 1, fp);
		
		//printf("name: %s | size: %d | compressedsize: %d", name, Size, compressedsize);
		
		decipherbuffer(compressedbuffer, compressedsize);
		
		char *buffer = (char*)sys_malloc(sizeof(char) * Size);
		uncompress(buffer, Size, compressedbuffer, compressedsize);
		add_buffer(name, buffer, Size);
		
		sys_free(name);
		sys_free(compressedbuffer);
		fclose(fp);
		return;
	}

	fclose(fp);
}




This should work out of the box. If not, it will at least give you a basic idea on how to do it.
Posted By: Reconnoiter

Re: a few questions about pro - 01/18/15 15:54

Thanks, thats very kind of you laugh
© 2024 lite-C Forums