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.

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

Thanks Kartoffel , 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.

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).

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

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

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

+1

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

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.

uhm.. I'll show you in 10min

Ok thanks, maybe i miss something but this is very interesting topic.