It appeared that SE2 wouldn't build on Windows 10 (and on top of that had some XAudio2 issues). We got a pull request with fixes submitted last night (on github). I'll try merging it today (if not, early next week), but if you want to test it now - it's there: https://github.com/motorsep/StormEngine2
All good - SE2 builds with MSVC2017 under Windows 10 fine and runs. Also a lot of warnings that pop up during build process were eliminated.
What's changes are needed to adapt some custom d3 and d3xp mods for SE2?
As I remember BFG had a two main problems - binarized assets and swf menu.
Thanks.
You'll need to rewrite scripts and shaders (if those mods are based on GPL engine). If the mods have changed menu, then the menu code should be changed and new swf files should be added.
Quote from: bitterman on September 17, 2018, 10:20:59 PM
What's changes are needed to adapt some custom d3 and d3xp mods for SE2?
As I remember BFG had a two main problems - binarized assets and swf menu.
Thanks.
Assets are get binarized on initial load by the engine. You still work with old ascii assets during development.
I released source SWF files, so you can make your own SWF menu from scratch using proper tool.
SE2 is mostly good for games that are made from scratch. You can adjust original Doom 3 scripts to run with SE2, but we added a lot of goodies that break stock Doom 3 scripts.
Thanks, guys.
I'm looking at some .cpp files in yours /neo/d3xp/script.
RBDOOM changes marked as "//RB".
Are your "goodies" marked somehow?
Quote from: bitterman on September 19, 2018, 10:00:56 PM
Thanks, guys.
I'm looking at some .cpp files in yours /neo/d3xp/script.
RBDOOM changes marked as "//RB".
Are your "goodies" marked somehow?
Not everything.. Some programmers didn't want to leave any trace of their work (ex-ID software programmer). But, why?! Just use the engine as-is.
Any information about the latest minimum system requirements for developing with and running the engine?
Quote from: LDAsh on September 23, 2018, 04:40:57 AM
Any information about the latest minimum system requirements for developing with and running the engine?
Same as for Doom 3 BFG.. If you can run Doom 3 BFG, you can run SE2..
Lol, good ol' id Tech - updated video drivers - now it's crashing on startup ::)
Just as opinion.
I'm really keep in mind possible migration to one of d3 modified engines (like dhewm3, RB or SE2).
It's pity but can find "developer friendly" info about SE2 (not to mention a full presentation with examles etc).
Perhaps a professional programmer sees all changes on the fly but I'm not. Also perhaps you don't needed a followers.
You just say: "Guys, we totally broken some subsystems, documentation are gone but you can use it as is because it's great!" :)
Sorry for any incoveniences.
Did you forget it's FOSS ? ::) >:D
Agree. Noob's comment indeed.
This script's incompatible is from RB or from SE2 only?
What kind of changes are there?
P.S. wallrun material and underwater view warping - interesting.
Quote from: bitterman on September 24, 2018, 12:00:13 PM
Agree. Noob's comment indeed.
This script's incompatible is from RB or from SE2 only?
What kind of changes are there?
Rb Doom 3 runs Doom 3 BFG content as-is. SE2 has quite a few enhancements so it can't run Doom 3 BFG scripts out of the box. Just compare doom_events and se2_events scripts and you'll find the differences.
Win7 64, MSVC 2013 CE:
QuoteError C2065: "XAUDIO_DEBUG_ENGINE" :undeclared identifier.
I got it to compile w/o any issues (MSVC 2017 32-bit), just trying to get a test map to run. :) Issue is related to the player start. I think I need to get the player.def/script updated correctly (am using/modifying scripts from the Blender Games d3BFG starter kit).
Quote from: bitterman on September 24, 2018, 01:30:18 PM
Win7 64, MSVC 2013 CE:
QuoteError C2065: "XAUDIO_DEBUG_ENGINE" :undeclared identifier.
MSVC 2017 CE is what we were building it with 32bit and 32bi OpenAL. I didn't even try 64bit because .. no point in using 64bit builds unless you have massive world.
Win7, 32 bit, openal - ok.
Underwater view warping - dirty hack :)
Btw motorsep's code changes marks as "// motorsep ...".
Quote from: The Happy Friar on September 24, 2018, 02:06:00 PM
scripts from the Blender Games d3BFG starter kit).
Thanks, useful.
********************
Hmm, not so fast... "XINPUT1_4.dll".
Quote from: bitterman on September 25, 2018, 10:40:03 AM
Underwater view warping - dirty hack :)
Well, either that or have no warping view underwater ;)
Making games is all about hacks.
Quote from: bitterman on September 25, 2018, 10:40:03 AM
Btw motorsep's code changes marks as "// motorsep ...".
duh, common sense...
And all API Set Stub ... :)
It is not for Win7?
Quote from: bitterman on September 25, 2018, 11:19:07 AM
And all API Set Stub ... :)
It is not for Win7?
Probably because Steam, XB, PS4 had to be stubbed out for GPL release ?
The code can be build on Win7 but cannot be run.
Perhaps problem is in proper version which must be set before building.
Just look at comment about w7 and w8:
SDL_dxjoystick.c
WIN_LoadXInputDLL(void)
{
DWORD version = 0;
if (s_pXInputDLL) {
SDL_assert(s_XInputDLLRefCount > 0);
s_XInputDLLRefCount++;
return 0; /* already loaded */
}
version = (1 << 16) | 4;
s_pXInputDLL = LoadLibrary( L"XInput1_4.dll" ); /* 1.4 Ships with Windows 8. */
if (!s_pXInputDLL) {
version = (1 << 16) | 3;
s_pXInputDLL = LoadLibrary( L"XInput1_3.dll" ); /* 1.3 Ships with Vista and Win7, can be installed as a redistributable component. */
}
if (!s_pXInputDLL) {
s_pXInputDLL = LoadLibrary( L"bin\\XInput1_3.dll" );
}
if (!s_pXInputDLL) {
return -1;
}
Some troubles with SDL version, I think.
Looks like current in source code is for win8 and above.
Quote
XInput is a cross-platform API that has shipped for use on Xbox 360 as well as versions of Windows, including Windows XP, Windows Vista, Windows 7, and Windows 8. On Xbox 360, XInput ships as a static library that is compiled into the main game executable. On Windows, XInput is provided as a DLL that is installed into the system folders of the operating system.
There are three current versions of the XInput DLL today. Choose the appropriate version of XInput based on the functionality of XInput you use and the versions of Windows you intend to support.
There are three current versions of the XInput DLL today. Choose the appropriate version of XInput based on the functionality of XInput you use and the versions of Windows you intend to support.
XInput 1.4: XInput 1.4 ships as part of Windows 8. Use this version for building Windows Store apps or if your desktop app requires Windows 8.
XInput 9.1.0: XInput 9.1.0 ships as part of Windows Vista, Windows 7, and Windows 8. Use this version if your desktop app is intended to run on these versions of Windows and you are using basic XInput functionality.
XInput 1.3: XInput 1.3 ships as a redistributable component in the DirectX SDK with support for Windows Vista, Windows 7, and Windows 8. Use this version if your desktop app is intended to run on these versions of Windows and you need functionality that is not supported by XInput 9.1.0.
Before I try to build whole solution (includes ZERO_CHECK).
As I found ZERO_CHECK reruns cmake.
Therefore it causes a wrong result IMO.
Then I build only idLib and SE2.
It's works. There is a SE2 on Win 7:
SE2 have a lot of modifications in menus code. E.g. added control widget list (sliders, buttons etc.).
What are advantages?
Quote from: bitterman on October 02, 2018, 07:44:30 AM
SE2 have a lot of modifications in menus code. E.g. added control widget list (sliders, buttons etc.).
What are advantages?
It doesn't have a lot of modifications. The only modifications were made is to make it work with SWF menus I had to reverse engineer. Nesting of some elements didn't make sense, so I had to adjust it to work. SWF files are also on github, so one can make totally custom menus / HUD / PDA.
Quote from: bitterman on October 01, 2018, 10:12:23 PM
Before I try to build whole solution (includes ZERO_CHECK).
As I found ZERO_CHECK reruns cmake.
Therefore it causes a wrong result IMO.
Then I build only idLib and SE2.
It's works. There is a SE2 on Win 7:
Lol, that's not how it should look when properly built.
This is how it should be:
https://www.youtube.com/watch?v=fEzs-eRdP5k
Quote from: motorsep on October 02, 2018, 09:09:28 AM
Lol, that's not how it should look when properly built.
It's just a collage with few screens.
Next time I try to start it with some custom maps.
It's looks good but I still worry about non-flexible closed menus part.
In case of SE2 also random modified part (I mean AddTextSlider and more, Menu_Widget_Item.cpp up from 12 to 17 kB etc.) :)
Quote from: bitterman on October 02, 2018, 12:37:53 PM
It's looks good but I still worry about non-flexible closed menus part.
In case of SE2 also random modified part (I mean AddTextSlider and more, Menu_Widget_Item.cpp up from 12 to 17 kB etc.) :)
What are you talking about?! C++ code is there, Flash source files are also there. Do whatever you please (non-commercial games) with them. Or make you own.
Quote from: The Happy Friar on September 24, 2018, 02:06:00 PM
Issue is related to the player start. I think I need to get the player.def/script updated correctly
They rename 'player_doommarine' to 'player_female' (I even found her name) ;)
But worts of all is:
hipJoint = animator.GetJointHandle( value);
In comparison with D3BFG the SE2 gives a wrong 'modelDef' with numJoints = 0.
This gives an error. Perhaps missed some assets but not sure.
********* P.S. It was a bad idea to mess with code without proper assets. ************
motorsep, how looks player.def?
Map's format is same as d3bfg? I have a flow bug with map butter error.
Snehk did a base asset pack a while ago.
http://idtechforums.fuzzylogicinc.com/index.php?PHPSESSID=ap8ard3u53lnas80ofvdudgln4&topic=603.0
I have also been playing around with the engine for a while. I like it, but there are a few things that those that are used to d3 will not expect. The sound call is different (forget what it is off the top of my head) and it's back to quake-style liquids (not a bad thing, just different). Overall, it is a very good engine.
Quote from: bitterman on October 06, 2018, 02:54:21 AM
motorsep, how looks player.def?
Map's format is same as d3bfg? I have a flow bug with map butter error.
Player def from Phaeton: https://pastebin.com/MP0HWpKT
map format is the same, but you obviously need to built it with dmap from SE2. Also if you have stuff that isn't defined in materials/defs, you might have issues.
Quote from: silverjoel on October 06, 2018, 11:02:31 AM
Snehk did a base asset pack a while ago.
404, but thanks anyway.
Quote from: motorsep on October 06, 2018, 03:55:59 PM
Player def from Phaeton: https://pastebin.com/MP0HWpKT
map format is the same, but you obviously need to built it with dmap from SE2. Also if you have stuff that isn't defined in materials/defs, you might have issues.
Yes, looks like this one, some problems with rendermodel. Need a blackbox and _white.
Is fs_game works?
Quote from: bitterman on October 06, 2018, 02:54:21 AM
? I have a flow bug with map butter error.
How can anyone understand that? :)
I mean a "floating bug with map buffer".
The asset pack is down until I'll improve it and make a more complete version.
All the problems were related to the missing assets.
Picture looks blurry IMO (look at "Wall").
I'll clean and re-upload my asset pack soon, but it won't be continued. I focus on other things right now, and once I'll be back to id Tech 4, it'll be on fhDoom fork.
Quote from: Snehk on October 08, 2018, 05:07:33 PM
... and once I'll be back to id Tech 4, it'll be on fhDoom fork.
Abandoning Storm Engine 2 ? :)
Can you show any vechicle.def and any water.mtr?
Quote from: bitterman on October 12, 2018, 11:25:01 PM
Can you show any vechicle.def and any water.mtr?
Vehicle: https://drive.google.com/open?id=1b1yWSbXoAbRsLxteP23cZ7_ZObFmZAE5
Water materials: https://pastebin.com/00R3bmB4
Quote from: motorsep on October 08, 2018, 05:24:04 PM
Quote from: Snehk on October 08, 2018, 05:07:33 PM
... and once I'll be back to id Tech 4, it'll be on fhDoom fork.
Abandoning Storm Engine 2 ? :)
Yes, at least for now. I'm just too busy to fix all the bugs in it (which are pretty much game breaking), whereas the only problems with fhDoom right now are framerate issues (Doom 3 works smoothly enough for me on this fork) and roe stability.
I may return to it once I'll have enough time to have a good look at everything.
Quote from: Snehk on October 13, 2018, 11:26:24 AM
Yes, at least for now. I'm just too busy to fix all the bugs in it (which are pretty much game breaking), whereas the only problems with fhDoom right now are framerate issues (Doom 3 works smoothly enough for me on this fork) and roe stability.
I may return to it once I'll have enough time to have a good look at everything.
I thought you were making a standalone game with it.
I thought so as well, but ultimately, I decided that fhDoom might be worth a try for development after I'll port some of SE2 and TDM features to it (avoiding bugs hopefully). It's still pretty solid without them though, and much more stable than SE2 (vehicles, RMB crashing the engine for no reason - just as examples).
Quote from: Snehk on October 13, 2018, 06:03:57 PM
RMB crashing the engine for no reason
I get the same in D3 or BFG. Missing script and related stuff, I think.
Quote from: Snehk on October 13, 2018, 06:03:57 PM
I thought so as well, but ultimately, I decided that fhDoom might be worth a try for development after I'll port some of SE2 and TDM features to it (avoiding bugs hopefully). It's still pretty solid without them though, and much more stable than SE2 (vehicles, RMB crashing the engine for no reason - just as examples).
fhDoom has no vehicles beyond what vanilla Doom 3 offered.
Feeling like UT :)
@bitterman
The issue with vehicles that loading a savegame with vehicle crashes the engine. That's really the main issue with SE2 at this time.
Speaking of vehicles, played RAGE last night. Noticed that sometimes vehicles are spawned above the ground and dropped after loading a savegame. As if they not really saving vehicles, but only save its stats and location/rotation of the entity and re-initialize / re-spawn it after loading of the savegame is done.
SE2 currently saves all the physics and constraints of the vehicle/suspension as far as I recall.
Do you see Q4 code (about vehicle stuff)?
It may be useful.
P.S. just as example:
/*
================
rvVehicleAnimated::Save
================
*/
void rvVehicleAnimated::Save ( idSaveGame *savefile ) const {
savefile->WriteVec3( storedPosition );
savefile->WriteStaticObject ( physicsObj );
savefile->WriteAngles ( viewAngles );
savefile->WriteFloat ( turnRate );
// why are we writing out the viewAxis here???
savefile->WriteMat3 ( viewAxis );
// TEMP
animator.Save( savefile );
}
/*
================
rvVehicleAnimated::Restore
================
*/
void rvVehicleAnimated::Restore ( idRestoreGame *savefile ) {
savefile->ReadVec3( storedPosition );
physicsObj.SetSelf( this );
physicsObj.SetClipModel( new idClipModel( GetPhysics()->GetClipModel() ), 1.0f );
savefile->ReadStaticObject ( physicsObj );
RestorePhysics ( &physicsObj );
physicsObj.EnableClip();
savefile->ReadAngles ( viewAngles );
savefile->ReadFloat ( turnRate );
savefile->ReadMat3 ( viewAxis );
// TEMP - restore animator, because it was cleared when loading the AF
animator.Restore( savefile );
animator.GetJoints( &renderEntity.numJoints, &renderEntity.joints );
animator.GetBounds( gameLocal.time, renderEntity.bounds );
// TEMP
additionalDelta.Zero();
}
You remind me about D3 SDK.
Well, feel free to fix it and submit pull request to the github repo. :)
The vehicle code in the Q4 SDK was (is?) near identical to the stuff in the D3 SDK, and it's not GPL so it can't be combined with the D3 codebase either way. ETQW was the same. Everything seems to have changed in the engines for those games (and ETQW didn't have saves too, so that was a non-issue for them).
mt how to use 'glow' stage in buggy.mtr?
Is it implenented from RB? Is it really glow (even in the dark)?
THF, it can be used as analogue, I belive. And even reworked.
I sent you the material, so it's all there. It is indeed a glow (Image-based Bloom) with halo.
And no, it's not from RB. In fact, RB was used as base, before tr3b added bunch of fancy things.
Quote from: motorsep on October 23, 2018, 09:31:55 AM
I sent you the material, so it's all there.
Nope, you forgot :)
It was recreated by me from .md5mesh.
Sorry :)
I see this fragment in to Code, but not sure about syntax.
Somethings like
{
glow
map textures/glow.tga
}
?
Material:
https://pastebin.com/HGKasY1q
_glow.tga is the same as _lights.tga, but half the resolution (512^2 is for lights and 256^2 is for glow)
Done!
Doesn't look like it's working. Or maybe screenshot is too small. I don't see any halo/bloom around headlights.
You might want to check r_* cvars to see if HDR is on and glow is on.
Yep
Yep, now we are talking 8)
Btw funny fact about vehicles:
In D3 main part of vehicle's code located in AFEntity.cpp and it can get control via impulse_40 from Player.cpp.
Looks like AFEntity.cpp from D3BFG (and perhaps from RB too) has same stuff but impulse_40 was excluded from Player.cpp so vehicle's code can not get control either way.
In SE2 impulse_40 was reverted back, replaced with BUTTON_USE and stuff from AFEntity.cpp significantly extended (added new 4wd spawnclass, exhaust particle system etc).
P.S. Now I try to understand what is autodriving, waypoints and related stuff. In SE2 test map I see only vanilla 'path_corner'.
Vehicle auto-drives between path_corners.
Yes, the vehicle auto-drives along path_corner at start if path_corner set as "target" for vehicle's entity.
Is there a way to bring back normal view in editor's window?
Not sure what is cause for this distortion.
You should really use DarkRadiant for Doom 3 mapping and use one window where you switch between perspective and ortho views with hotkeys, like in Blender.
I think it was assumed you'd use DR for the engine so not much work was put in fixing issues with the built in editor, right Motorsep?
Quote from: The Happy Friar on October 30, 2018, 09:59:26 PM
I think it was assumed you'd use DR for the engine so not much work was put in fixing issues with the built in editor, right Motorsep?
That is correct. Doom 3 Radiant was simply made workable (just because it was more work to rip it out completely) with the engine. Although it should be as usable as original Doom 3 Radiant.