[Bobboau]

http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_8-1-06.zip

it should work now, please test,

also look for anything haveing the wrong Z buffer alpha mode or textures being grainy when they should be smooth(or vice versa), I started to write some new state manageing code before I decided to be nice and fix bugs instead, the D3D stuff basicly just compartamentalised code into seperate functions, so I'm not too woried about that, but I started to write OGL code and, though none of it should be implemented, I may have accedentaly hit a key or something while I was rooting around.

[karajorma]

Just out of interest is this based on the 3.6.9 or HEAD branch? Cause people might like to use it as their standard build if it's based on the former.

[Bobboau]

I just based it off of what I got when I pulled out the most recent copy of CVS (a few weeks ago). I didn't specify any branches

[DaBrain]

You really got D3D working again?!!

Good work man, I'll test the build now and tell you how it worked for me later.


Edit: Ok... it crashes when I try to start a mission. But the techroom works. Looks like D3D doesn't know how to handle -trans textures, they aren't transparent. Some glow maps are greyscale. The interface looks pixelated.

Well I can't say anything about the env mapping...


OpenGL: Looks Fine. Only the font has some very slight problems. Especially the "R".

[Bobboau]

http://freespace.volitionwatch.com/blackwater/fs2_open_d_Bobboau_8-1-06.zip

here is a debug build, maybe that will shed some light on your crash, I didn't get any crashing so I don't have the slightest clue as to what might be causeing it.

[DaBrain]

Ok, I got this in the techroom:

Assert: bm_bitmaps[bitmapnum].handle == handle
File: i:\fso\fs2_open\code\bmpman\bmpman.cpp
Line: 2568
[This filename points to the location of a file on the computer that built this executable]

Call stack:
------------------------------------------------------------------
    bm_lock()    model_page_in_textures()    techroom_select_new_entry()    techroom_do_frame()    game_do_state()    gameseq_process_events()    game_main()    WinMain()    WinMainCRTStartup()    kernel32.dll 7c816d4f()
------------------------------------------------------------------

And this when I try to start a mission:



I can't press any of the buttons...

[Bobboau]

that sort of sounds like something that might make sence to go wrong....

errr... don't have any idea whay it would work on yours but not mine, do you get any other errors?

[DaBrain]

Nope, that's it. Unless you're interested in some unlreleated problems like:

Too many impact effects
some impact effects have no lod 0 (?)


Well the Debug Error has different values with different mission.. if that is of any importance.

[Bobboau]

anything precludeing a crash?

could you use retail data?
(assumeing you have your mod data in a mod folder and can do this easily)

[Backslash]

Somewhat unrelated...

The current Direct3D code doesn't handle effects with alpha channels properly -- at least in the case of the warpmap (in WCSaga for example), it just becomes a white box.  Perhaps you could make a workaround to ignore the alpha channel?  I mean, the proper blending would be nice too but the workaround 'should' be quick...

[DaBrain]

anything precludeing a crash?

could you use retail data?
(assumeing you have your mod data in a mod folder and can do this easily)

My FS2 folder is a compelete mess. Thanks to my new FSU job, I got no sparky.vp anymore (for testtin purposes). I got lots of new effects and maps...

Anyway, OpenGL seems to work perfect for me. No errors. I can try a fresh install, but imo D3D should work just as well as OpenGL...


Let us wait for some more feedback from other people.

[Backslash]

I have done some testing, a couple big missions, and so far it has not crashed.  Environment mapping looks good, nice work.

As DaBrain says, the interface looks pixelated.  I'm not sure what's wrong, it just doesn't look right, even if the 'fix font distortion' is checked (though that helps).

But wow, I hadn't realized how many improvements have been made the last few weeks; already I notice how out of date your CVS checkout is ...mostly to do with autopilot adjustments and things though.  But of course this is a test build.  Good to have anything!

[Nuke]

not sure if this is a bug or not (and more or less pertains to opengl), i remember that back when env worked in direct 3d only, it seemed to behave differently. the cubemap would be seen to move accros the hull not only when the view changes but when the ship turns. lately i noticed that the envmaps move only when the view angle changes, not when the ship turns. i noticed the bug from the cockpits in nukemod, back when they worked on d3d only they would move when you manuvered, they no longer seem to do this. it just seems like an unrealistic reflection. the skybox in scannin crates is the perfect tool for env map debugging

[taylor]

... lately i noticed that the envmaps move only when the view angle changes, not when the ship turns...

It's on my todo list, and it bothers me a bit the way that it currently works as well.  It's lower priority than some of the other 3.6.9 fixes that I have in the works though, so I'm not sure when I'll get to fixing it.

[Bobboau]

http://freespace.volitionwatch.com/blackwater/fs2_open_Bobboau_11-6-06.zip

update! I'm alive!

so, OGL doesn't take into account the ship moving but it does take into account the camera moving? OGL is using a texture coordanant transformation matrix right? that's what D3D does, and it's what makes it posable to use the same texture on every ship and not have to redraw it every frame for every ship.

[Taristin]

SO, does this mean D3D is going to be fixed, now?

[taylor]

so, OGL doesn't take into account the ship moving but it does take into account the camera moving? OGL is using a texture coordanant transformation matrix right? that's what D3D does, and it's what makes it posable to use the same texture on every ship and not have to redraw it every frame for every ship.

I fixed that problem already actually.  It should now work pretty much the same as D3D (I think) and uses a proper texture matrix to make the envmap do the right thing.  The matrix is also cached (so long as the view setup doesn't change) and is reused as much as possible without having to be regenerated (which isn't terribly expensive anyway).

[Nuke]

any chance you could make it possible to script or sexp in a custom cubemap under certain situations, for example if you fly through part of another ship or or to reflect things like cockpit or bridge interior. perhaps an option to include a model when generating a cube map, which could be usefull in mods that use terrain (such as sol).

[taylor]

Not sure about the scripting thing.  If support for that was added then it would probably need to be pre-generated envmaps rather than a game-generated one.  That would also make it much easier to not only script but also code in first place.  It is something that's needed though, I was thinking the same thing last week while playing WCS and commenting to myself how ugly it looks to see the nebula reflected on my ship while I'm inside another ship.  Ugly stuff.

The problem with that is it needs to be real-time, like the envmap that a subspace mission uses.  That is re-generated every frame, but if you were to include ships in that, it would be extremely slow in comparison to how long it takes to generate now.  It's probably something that I'll play with for 3.7 regardless though, since I'm working on speeding up the model render code anyway.  And it would be really neat to have near-real-time reflections of the full environment.

As far as including a model with envmap generation, already planned.  It is mainly for terrain missions (primarily for SoL) that I'm adding support for it.  It wouldn't require a terrain mission, but just have a mission flag for each object which says that the object needs to be rendered to the scene that is captured for the envmap.  This could be one object, or numerous objects.  The only thing would be that it needs to render objects which are stationary thoughout the mission, not going through a tunnel or anything like that, and not too far away (if it's going to go through the trouble of rendering a model then it needs to actually be seen in the envmap).  The game itself wouldn't catch stuff like that (except for the too-far-away case), so it's up to the mission designer to get right.  Getting that wrong wouldn't hurt anything, but the envmap would look rather strange.

[Nuke]

Not sure about the scripting thing.  If support for that was added then it would probably need to be pre-generated envmaps rather than a game-generated one.  That would also make it much easier to not only script but also code in first place.  It is something that's needed though, I was thinking the same thing last week while playing WCS and commenting to myself how ugly it looks to see the nebula reflected on my ship while I'm inside another ship.  Ugly stuff.

i could probibly define a clipping plane in scripting that if crossed, would trigger whatever function switches the cubemap. youd probibly need to define a invisible subsystem to serve as a trigger for sexping it. i have no problem generating cubemaps. i did a skybox tutorial for rendering skyboxes awhile back. it applies to cubemaps as well. not suere if max or truespace can render directly to cubemap. my totorial showed how to rendered out 6 images to use in a skybox pof. even if it dont it would take only minor tweaking in photoshop to make a cube map out of them.

The problem with that is it needs to be real-time, like the envmap that a subspace mission uses.  That is re-generated every frame, but if you were to include ships in that, it would be extremely slow in comparison to how long it takes to generate now.  It's probably something that I'll play with for 3.7 regardless though, since I'm working on speeding up the model render code anyway.  And it would be really neat to have near-real-time reflections of the full environment.

does that mean were finally moving to per texture rendering instead of per object rendering? i hope this comes with beter alpha blending, it would be nice if i can use transparent textures at will, even on subobjects and have them all display properly. its just one of those things that i feel that freespace is missing.