The playing and modding SWBF is a very low requirement. They're old and not very GPU intensive. I would imagine pretty much any integrated or dedicated GPU from the past few years to do both with flying colours. The requirement of running the other games sets your bar a bit higher.

Intel's recent integrated GPUs can probably do it but go back too far and they definitely won't be able to, at least not while giving a reasonable frame rate in some of them. I'm defining reasonable here as "stays steady at somewhere above 30FPS". So you'll preferably want to get a laptop with a mid-high level dedicated GPU.

Keep an eye out on what memory type the GPU has, if it's DDR3 it's possibly a low-level one and you should keep looking. If it's GDDR5 it may be worth investigating further.

As a starting point nvidia say's the GTX 760M from a few years back can play Skyrim at 1080p/30+FPS at Med/High settings. If that sounds acceptable it could serve as a starting point for your search.

Obviously once you've found a laptop in your price range that seems to fit your requirements I would suggest doing some research to see if you can find benchmarks for it playing one of the games you like.

I don't have the time personally sorry! Even then I'm not sure you want people to have to install a core.lvl that gives custom shadows designed only for your map. What if they play more than your map in one session? Seems like it may be better to focus on other aesthetic parts of your map.

Not too hard actually. In the case of the Normal shader you'll just need to edit it's definition file so it only uses the basic shaders. You'll have to follow the instructions for installing the toolkit and getting it to produce a core.lvl.

After that for each state definiton in normal.json you'll be interested in these lines. They control which shader function is used for that state.

Quote
    {
      "name": "unlit opaque hardedged",
      "id": 1,

      "passes": [
        {
          "skinned": true,
          "lighting": false,
          "vertex_color": true,
          "texture_coords": true,
          "transform": "position",

These lines here.
          "vertex_shader": "unlit_opaque_vs",
          "pixel_shader": "unlit_opaque_hardedged_ps",

          "vs_target": "vs_2_0",
          "ps_target": "ps_2_0"
        }
      ]
    },

If you play around with swapping those values from different states around you should learn how to replicate what you want.

Yup. Although I don't know why you would want to do that. I'm guessing it would be for performance reasons?

It is probably simpler to force the game to use it's fixed-function rendering path by passing it `/fixedfunction` as a startup argument. It'll accomplish most of the same with a fraction of the work.

Quote from: Dark_Phantom on November 29, 2017, 04:51:34 AM
I'm probably going to get this just to see how much fun I can have and to learn... Thanks for the great work!

Messing with things is a lot of fun. I hope you get some enjoyment and knowledge out of it!

Quote from: Ginev on November 30, 2017, 01:34:30 AM
Now if only there is someone to create the relef terrain thing for pixel shader 3.0 that will be awesome!!!!Im telling you people even if its not perfect its a big thing for this game.When i heard that such thing is possible here i totally forgot about other shaders,not because i dont need them.For example if its easyer i would absolutely love to get the full reflection water shader moved to....lets say some of the non working shaders like  the "sky" shader.If im not mistaken it was 11

I assume you're referring to the .msh file render types? They're actually a poor representation of SWBFII's material system;  I suspect a lot of them are just layovers from SWBF1. And in SWBF1 I suspect a lot of them are just layovers from it's early development days or from other games.

From a typical game object's perspective (after the munger runs) SWBFII effectively only has two render types. Normal and Refraction. in SWBF1 there were more, but that was because it's rendering system was a lot less unified and actually less powerful.

In regards to a dynamic reflection render type, shaders sadly don't have any say over what they're passed, they simply take input data and output a result. So setting up a custom reflection shader is not possible using just the shaders.

However Refraction (surprisingly) might be able to give you something similar to what you want. To perform it's refraction it get's passed a copy of the game scene rendered at a lower resolution. It then projects this texture onto the model with an offset specified by the bump/normal map. If you use a completely grey value for the bump map (RGB{128, 128, 128}) it should turn off the distortion and create an almost reflection effect.

Quote from: RepComm on November 30, 2017, 09:50:13 AM
I'm wondering if we can modify shaders to have pixel point/spot lights emit from nulls/primitives (particularly in vehicles and weapons) that are based accordingly. You'd probably need a reference to the game objects in the scene..

This could make things like a Halloween map that requires the use of a flashlight that actually lights up the buildings that use the shader.

Headlights on vehicles would be so cool!

I've never tested it but if you're using SWBFII you can use -attachlight in a model's option file (Or AttachODF with AttachDynamic in the odf, see the modtools documentation.) and use a spotlight with a projected texture.

As far as doing anything else as you say you would need to control/edit the game's scene in some way, which shaders obviously have no concept of.

As some of you likely know I've been working on this toolkit for a few weeks now and I feel it is now reasonably complete. It allows you to write shaders for the SWBFII in HLSL and have those shaders target either Shader Model 2.0 or Shader Model 3.0. See the readme for more information.

To install and use this you'll need to download or clone the repository from GitHub. Put it into the root of your BF2_Modtools folder. The folder structure should go BF2_ModTools -> shader_toolkit -> src.  Not BF2_ModTools -> shader_toolkit   -> shader_toolkit -> src. After that you can bootstrap the toolkit or you can download this which is a shader_toolkit folder containing a build folder for you to copy into the shader_toolkit you got from GitHub.

After that simply see the Getting Started in the readme for how to use the tool!

GitHub Repository
Prebuilt Compiler and Pre-extracted Premunged Files
Prebuilt core.lvl containing the New Shaders

Quote from: Kit Fisto on November 18, 2017, 10:22:49 PM
...

Yes well as I said I was ignoring the EU in that argument. Perhaps I worded that wrong and I should have explicitly said I was ignoring anything other than the films. In that context you have still weakened my argument by pointing out a couple things I forgot from the films, but I believe the key points still hold.

Quote from: Kit Fisto on November 18, 2017, 01:08:17 PM
Oh dang! I just got out Star Warsed!! You got a point there my friend!
However, since Clone Wars is now Clones vs Droids wouldn't the Clones have control of the palace? 

Not necessarily, let's take the situation Sereja's map is providing and explore it. (I'm going to ignore the EU here and go solely off the films.)

So first we know the Republic had many member worlds and unless the Republic had foreknowledge of an attack against a single planet (assuming that planet was of little strategic value) it is likely it would succeed. The Republic hardly would've had the numbers to maintain a substantial garrison on each member planet.

And in the case of Naboo from the films we know their own security forces were no match for "a battle hardened Federation army". Which would suggest that they would not have been able to offer substantial resistance to an even better equipped Separatist army. (Of course it's possible after the first invasion Naboo went through widespread reforms to maintain an army and defences to prevent another invasion from succeeding. Although given they oppose the creation of a galactic army in the second film it seems unlikely, but still it is certainly possible.)

And remember that Naboo was remote enough that the Senate was hesitant to believe accusations that the Trade Federation had invaded and occupied the planet. This backs up that the Separatists could invade the planet (or at least key portions of it, such as it's capital city) before the Republic could respond.

Nute Gunray also (as depicted in Attack of the Clones) held a severe grudge against Padmé Amidala for besting him and it is believable that he would use his influence to have the planet invaded as a form of revenge.

Overall I believe the situation Sereja depicts of the Republic liberating the planet has a greater thematic basis than them defending the planet. (Although the inverse situation is possible to come up with as well of course.)

Quote from: Dark_Phantom on November 16, 2017, 09:45:45 AM
You need to turn AntiAliasing in your video options up to 8x.  That is what the consensus seems to be when this issue comes up with hover vehicles.

Using V-Sync also fixes the problem I believe and may be more acceptable for people that can't use MSAAx8 at an acceptable frame rate.

Quote from: i|\|(06|\|i70 on November 09, 2017, 06:08:45 AM
HOLY COW !

Your 3D assets are truly the best around here, I still do wonder why you ain't a Master Modder.

I'm pretty sure he is, you just can't see it because his moderator status takes precedent is all.

After a while struggling with it the toolkit now has an implementation of the game's "normal" shader which (outside of mods) does most of the rendering. This brings the total rewritten shader count up to 21 out of 30. There are still some large shaders (like water and normal mapping) left but the toolkit is well on it's way to completion.

I posted a bit about this in the WIP forever... thread recently but now in order to hide from tracking down a bug I've decided to make a proper WIP thread. How nifty!

This is another one of my fun hobby projects relating to SWBFII, which for some reason I find endlessly enjoyable to mess with. The idea is fairly straight forward writing shaders in assembly sounds hard and painful, writing shaders in HLSL sounds hard and painful. But since HLSL is easier to read and write itself I thought it would be nice to be able to edit the game's shaders in it. Thus enters this project to create a build process to compile and munge HLSL shaders and use them in SWBFII instead of the stock assembly ones.

The build process is all but complete and now I am just slowly porting the shaders one by one to HLSL. I've never programmed in HLSL (I'm a GLSL man personally) before and I'm not a graphics programmer (I barely qualify as any form of "programmer" tbh) by any means so it is a challenging process for me. But regardless of that I have been making good progress on it reasonably consistently and I kind of felt like seeking out what interest there was in the small SWBFII community for this. Although I am just making it because I want to edit the shaders myself it's still helpful to know how many (if any) people are interested in it. Hence a WIP thread.

Screenshots would be dull since at this stage if everything is progressing fine and working correctly you can't tell the difference between my rewritten shaders and the game's stock ones. So have some code to look at instead of here.

Although I did have some fun with the rain shader a couple days ago. Isn't it pretty?

Quote from: Gistech on November 01, 2017, 06:41:34 AM
The stock stormtrooper weighs in at 1651 polys without gear and 1877 with the sandtrooper gear, which is within the recommended 1500-2000 tris the documentation suggests.

Ah my mistake. I was basing my figure off what the munged model's LOD says, which must include all the degenerate triangles as well.

Quote from: Gistech on November 01, 2017, 06:41:34 AM
It does but it still produces the sliding animation issue (which you've said is currently not fixable), I haven't yet figured out which factor works best for it though.

Ah I see. I would start with a low one like 2 and work up from there. Whatever gets the player's model and a couple others around it rendering properly without sliding is what I would go for. Then you'll just have to accept that lowres switching around the player is a thing that will (like for the past 13 years) happen.

Quote from: Gistech on November 01, 2017, 06:22:56 AM
I just have to tweak the envelope and the hp_fire positions a bit then these are ready for release. They're a little high-poly for SWBF1 (sitting over 2000 tris) though it it highly possible to reduce polys on these to make them more compatible. They're good for SWBF2, though.

Wait, what? Isn't the stock Stormtrooper in SWBF1 over 2000 triangles anyway?

Also does this not actually work correctly as I thought it did?

I'm in the process of creating a "shader toolkit" for SWBFII so that I (and others) can write shaders for the game in HLSL directly instead of the assembly format Pandemic used. I used that to edit the rain shader.

Once it is ready it will absolutely be released and documented for people other than me to tinker with. Currently though I still have a lot of the game's shaders to rewrite in HLSL for it to be truly useful.