Cool stuff, love the video!

However, I don't like packed .exe files like this one.
They increase the startup time, you don't know what stuff it contains and can't be sure if
the program will clean up all the mess that it left somewhere on your hdd. Besides that,
they don't really prevent other people from looking into your project's files. Although I know
that in this case it's made using the old gs-packer, I generally don't open these files.

...and windows doesn't like it either:

Ah gotcha, only reason why I used gs-packer was primarily because it's one self contained file. I didn't really care about the content being "hidden" since I know gs-packer can be hacked with trivial effort. Here is an updated version which is not packed into one exe file.

https://www.dropbox.com/s/979j2u5ztq4nz02/main.cd.zip?dl=0

Thanks for the heads up!

Well that was just my opinion, other ppl might prefer a single executable.

But thanks for the reupload, I'm going to give it a shot asap

Extremely and unforgivably slow on my machine (AMD X4 641 QuadCore 2.80, 4 GB RAM, AMD Radeon HD6670), couldn't even play it (fps below 15-20). Is there any ways to disable shade-c?

@3Run, Hmm well I am actually not using shade-c at all. Does it start off slow (Before player control enabled) or does it get progressively slow as time passes? I will upload a version with the shaders disabled, I am also working on a menu system which will help tweak visual options. As a comparison, I get 60fps on my htpc (AMD A4-5000, 6G RAM, and an AMD R7-200). I will actually build a PC meant for testing based on your specs, I actually have all the necessary parts just lying around lol. Thanks for the info!

I thought you used shade-c, when I saw all those 'pp' .fx files, but now I can see that most of them are just from native shader collection. Nah, it's nothing related to the script part (it just slows down as soon as everything got 'drawn'), it's just visuals (shaders 100%). Let's see how 'non-shader' version will go on. Plus, I couldn't get LAN to run, but I guess it's just not supported yet.

On my machine it runs quite smoothly:
- Intel i7 4770K 4x3.5 GHz (+Hyperthreading)
- AMD Radeon HD7850
- enough RAM (shouldn't be a problem anyway)

My CPU is probably above average but I think my GPU should be quite a bit worse than what most people (gamers) have nowadays.

I didn't play the demo for very long, yet, but this is what I noticed:

> the input seems a bit laggy, might be vsync, delay caused by windowed mode or it's engine related
> like in superku's demo, there still is mouse_force.xy used for the camera's rotation.
I highly recommend you to use mickey.xy instead. This one doesn't cap at ±1.
The values are a lot higher, though, so you have to scale it down a bit.

Hmm I need to look into that, I am able to run LAN fine from two of my test machines without any problems so far. Let me see if I can get a more "stable" version working.

EDIT: Instead of cluttering this thread with my stuff I am going to make my own project thread.

, is this an important issue with mouse_force? Cause I too only used mickey.z and have problems with it (the value gets stuck sometimes, than it doesn't return to 0). Could be its a specific problem with my laptop cause I didn't had it on other computers. I am wondering if mickey.xy could give that problem to.

@Reconnoiter: In my opinion, capping the mouse speed in a first person shooter is a big no-no
especially because the cap in mouse_force is really low.

I rarely use mickey.z (mousewheel) so I can't confirm this problem.
However, mickey x and y have never caused me any trouble as far as I remember.

Edit: oh, but I know that keys remain pressed in an 3dgs application when changing to a different window and back or tabbing out and in again.