News:

One Minute Game Review by The Happy Friar: https://ugetube.com/@OneMinteGameReviews
Also on Rumble: https://rumble.com/c/c-1115371

idTech 4 (aka Doom 3 tech) Discord Server! https://discord.gg/9wtCGHa

Main Menu

Messing with Storm Engine 2

Started by Snehk, July 23, 2017, 02:52:44 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Snehk

Hello there, I'm new to this forums (though I've been checking it for possible reference from time  to time).

I like to mess with game engines and I picked up Storm Engine 2 recently (like, downloaded yesterday and started working with it today). I always wanted to try my skills with Doom 3 engine. Today's progress:


  • Compiled the engine, ran the executable to check if it'd work
  • Changed hardcoded player_female classname into player
  • Checking available reference (idDevNet, d3starterkit, some Doom3 mods) I added scripts and defs required to run a level (scripts and defs that came with SE2 are still used, replacing them wasn't neccessary but it's something that I'll do at some point), they're quite rough and bare bone, but work
  • Made simple dev texture with normal and specular maps, material for it and then made a simple room in DarkRadiant and compiled
  • Commented out checks for bones (eg. bone_hip), so the engine would allow loading a level without player model

This took me a while, but this day was like: run several errands then get back to engine and figure out what goes where, and then do something else again. Here's the result (brightness in the level is too high, but this level is just a test). Add to it that I'm only (if not less) halfway decent programmer and Doom 3 modding rook.



Not sure if this thread should be in this forum section...

motorsep

Glad to see someone finally grabbed our engine and messing with it :)

Snehk

SE2, just like idTech 4 BFG is quite good engine, only problem is lack of documentation, but things are quite easy to reverse engineer so checking other projects or starter packs for reference make things easier.

I'm thinking about bringing back old GUI. I know that it still applies to world surfaces, and that bringing old HUD back is a matter of few simple edits in Player.cpp (there's both code for swf and gui HUD, even commented). Not sure about menu, and tweaking it all for widescreen. I'll have to either ask OpenTech Engine guys about it or dive deeper into code.

motorsep

Quote from: Snehk on July 24, 2017, 03:05:15 AM
SE2, just like idTech 4 BFG is quite good engine, only problem is lack of documentation, but things are quite easy to reverse engineer so checking other projects or starter packs for reference make things easier.

Sorry, there was no time to make docs. But there are enough comments to the additions and bug fixes in the code (although not for all of it).

Quote from: Snehk on July 24, 2017, 03:05:15 AMI'm thinking about bringing back old GUI. I know that it still applies to world surfaces, and that bringing old HUD back is a matter of few simple edits in Player.cpp (there's both code for swf and gui HUD, even commented). Not sure about menu, and tweaking it all for widescreen. I'll have to either ask OpenTech Engine guys about it or dive deeper into code.

Why would you even do that?! I spent ~6 month reverse engineering SWF GUI and provided source Flash files. All you'd need to do is new art. Almost entire new full screen GUI system is C++ driven (except dialog menus).

Snehk

#4
I meant documentation on creating assets. I'm not planning to touch code you've changed too much if at all.

Changing the GUI is mostly to see how hard it could be and how it'd work with the engine, but I was planning to stick with SWF in the long run. Only problems I see with them is that I've never worked with Flash or Actionscript, and Flash is deprecated.

I'll probably start working on a better level once I'll have more time than just a minute to post.

Right now everything I do is to get better with asset creation pipeline for the engine and scripting game logic. I'll probably add new maps and test enemies, and only then determine if I'll develop any bigger project on SE2. I know that there's UE4 or Unity free for development, worked with UE4 (don't like Unity's license model), and I'm not too much into it. All those visual editors confuse me even more than Doom's GUI code...

motorsep

While there is no Flash, there is Adobe Animate CC, which is re-branded Flash.

Snehk

Good to know, though Adobe stuff is costly. I might try with FlashDevelop, even though bitterman had problems with using it and getting stuff working. Still it's worth checking out.

Snehk

Haven't done too much due to lack of time. Noticed that GUI Editor crashes on start-up every time I try to launch it. I'm using Windows 10, maybe it has some problems with that? Another issue: Particles editor loads properly, but it's window is too big. It's not resizeable and there are no sliders to get down to other options. Is the resolution hard-coded or does it scale up to screen resolution?

I scripted in func_static by checking engine code and original Doom 3 scripts. It loads models properly, I tried with an .ase model (.lwo are a bit of a pain to load). I'm also working on an animated model, already tried exporting a test md5 from Blender and it worked.

argoon

#8
Quote from: Snehk on August 04, 2017, 02:39:59 PM
Haven't done too much due to lack of time. Noticed that GUI Editor crashes on start-up every time I try to launch it. I'm using Windows 10, maybe it has some problems with that? Another issue: Particles editor loads properly, but it's window is too big. It's not resizeable and there are no sliders to get down to other options. Is the resolution hard-coded or does it scale up to screen resolution?

I scripted in func_static by checking engine code and original Doom 3 scripts. It loads models properly, I tried with an .ase model (.lwo are a bit of a pain to load). I'm also working on an animated model, already tried exporting a test md5 from Blender and it worked.

I don't know if Motorsep messed with the original idtech 4 tools but they do have some requirements to work well, some are, disable antialising (r_multiSamples 0), run on a window, etc.

For example this is how i open the gui editor using a .bat file and it works (I use the fhDoom engine).

QuotefhDOOM.exe +set r_fullscreen 0 +set fs_game mygame +set r_multiSamples 0  +set r_gamma 1 +set r_mode 6 +set vid_restart +editguis

+set fs_game mygame is optional if you don't know, this is used only if your game data is not run from the original base folder.

btw to easily test a gui, without the Quake 4 gui editor, do the following:

make a .bat file and put this on it:

QuotefhDOOM.exe +set r_fullscreen 0 +set fs_game doombra +set r_multiSamples 0  +set r_gamma 1 +set r_mode 6 +set vid_restart +testgui /guis/guiname.gui

Then use on the console:

reloadGuis // this to see gui file changes almost in real time

gui_debug 1 // To see a red frame around all the GUI objects.

Btw this red frames should show on the quake 4 gui editor as well, but for some reason they don't show for me, if that happens to you, you can use the "border" windowDef option to use a custom frame around the object making it easily visible.

Also the gui editor works (minus the red frames) for me on W10, it is crash prone so save often, some times it crash's because you have a syntax error on your gui file (unfortunately shows no good error message when it crashes) other times it will show a total black window, mostly because you have some assets missing or also some syntax error, afaik there's no easy way to debbug gui files but the code is not that complex and the engine console do show some obvious gui errors.

I have used other idtech 4 tools before, like the particle editor, AF(ragdool) editor, the material editor, etc, all of them have their problems and quirks, you just need to find what they are and work around them.

(unless BFG is different) Before you spend days looking (like i did) onNamedEvent's are not able to be called by the script system only by the c++ code, and to call a custom gui file from a script you need to explicitly call it from a entity with "gui" key "guis/guiname.gui" value.


About models:

I mostly use lwo for static models imo is a much superior format because is binary (so is faster to load but BFG already transforms all formats to binary so is not that important to you), another reason i also use it, is, you don't need to edit it by hand to make materials work, like you sometimes need with .ase models, if i'm recalling well is also the format id used the most for Doom 3 (after MD5 for animations) and lastly afaik Blender (i personally use Modo) supports .lwo you just need to enable it on the preferences.

Good luck :).     




Snehk

Thanks for help! I'll try to run the editor with those settings later, I still need to figure out what to do with particle editor to be able to work with it. I may have messed something with materials first time I tried .lwo model. I use Wings3D to model geometry and UV map. I use blender only for rigging, animation and export.

motorsep

We did a lot of work on GUI Editor (fixes and enhancements). However, everyone was on Windows 7 at the time of the development.

I didn't want to get into this again, but here is the proof that everything works just fine (without any CMD line arguments, but MSAA is definitely set to 0 by default):



I am on the whole new system / PC and all I did was check out my SVN and running 32-bit exe.

Btw, 64bit tools are not quite tested, so if you run 64bit binary, you might be out of luck. Use 32bit binary.

motorsep

Quote from: argoon on August 04, 2017, 09:20:31 PM... another reason i also use it, is, you don't need to edit it by hand to make materials work, like you sometimes need with .ase models, if i'm recalling well is also the format id used the most for Doom 3 (after MD5 for animations)..

Not if you use my exporters (which are on github too). Everything exports to be used out of the box - no manual editing.

Snehk

I've been using 64bit binary, so maybe that's the problem. Thanks for providing me with info that tools weren't quite tested for 64bit binaries, as well as with proof that everything works fine on latest Windows.  Sorry for taking your time too.

I'll most probably get to check argoon's method and 32bit binary tomorrow and post if they worked.

motorsep

Quote from: Snehk on August 05, 2017, 03:35:19 PM
I've been using 64bit binary, so maybe that's the problem. Thanks for providing me with info that tools weren't quite tested for 64bit binaries, as well as with proof that everything works fine on latest Windows.  Sorry for taking your time too.

I'll most probably get to check argoon's method and 32bit binary tomorrow and post if they worked.

Np. We eliminated the need in using any cmd arguments, so if his method doesn't work, it's most likely do to engine changes.

Snehk

#14
Checked the commandline method by argoon and still got a crash, so I promptly compiled a 32bit binary and gui editor loaded flawlessly. The issue with particles editor was still there though, and I haven't modified code for it in any way.



The editor window is not resizeable, does not scroll down and it's not possible to drag the window upwards beyond the edge as far as I know. Guess I'll have to dig in it's code.